llm-d 1.0 diperkenalkan di PyTorch Conference dengan tumpukan inferensi untuk produksi

Para kontributor proyek llm-d mengumumkan llm-d 1.0, tumpukan layanan inferensi terdistribusi native Kubernetes, pada 20 Oktober 2026 di PyTorch Conference North America, menurut pengumuman IBM Research. IBM mengatakan bahwa rilis ini membawa llm-d melampaui tahap mendemonstrasikan teknik kinerja secara terpisah dan dimaksudkan untuk membantu organisasi mengelola deployment model secara internal seiring meningkatnya biaya inferensi.

llm-d dirancang untuk menerapkan tumpukan inferensi bagi model apa pun, pada akselerator apa pun, di cloud mana pun. Red Hat, IBM, dan Google adalah pengelola utama proyek ini serta mendirikan llm-d bersama CoreWeave dan NVIDIA; AMD, Cisco, Hugging Face, Intel, Lambda, dan Mistral AI bergabung sebagai kontributor. Cloud Native Computing Foundation (CNCF) menjadi tuan rumah llm-d sebagai proyek sandbox. IBM menggambarkan hasilnya sebagai alternatif netral vendor bagi organisasi yang menginginkan kinerja inferensi kelas terdepan—sebagaimana disebut IBM—tanpa bergantung sepenuhnya pada satu penyedia model proprieter, cloud, atau platform perangkat keras.

Carlos Costa, Distinguished Engineer di IBM Research sekaligus salah satu pendiri dan pengelola utama llm-d, mengatakan bahwa versi 1.0 menghadirkan tingkat kematangan yang diperlukan untuk menjalankan llm-d seperti layanan penting lainnya. Ia menunjuk pada API yang stabil, beberapa tenant dengan prioritas yang saling bersaing dan berbagi infrastruktur yang sama, serta pembaruan yang tidak mengganggu operasional.

Fitur Baru di Versi 1.0

Catatan rilis v1.0.0 proyek ini, yang diterbitkan di GitHub pada 20 Oktober 2026 dengan tag yang ditandatangani dan diverifikasi, mengedepankan kualitas layanan multi-tenant: pengendalian alur yang mempertimbangkan prioritas dan keadilan, disertai pengurangan beban secara terkendali, termasuk mekanisme penerimaan probabilistik, keadilan yang mempertimbangkan program, dan penilaian prioritas giliran. Dengan demikian, permintaan yang sensitif terhadap latensi dan beban kerja agen yang melonjak dapat berbagi satu kumpulan sumber daya tanpa saling menghambat saat terjadi kelebihan beban. Konfigurasi pengendalian alur dipusatkan dalam satu kolom flowControl.

Untuk operasional tanpa waktu henti, router kini memiliki ketersediaan tinggi dengan siaga panas dan pembaruan bertahap yang aman, sementara pengontrol DisaggregatedSet mengelola replika prefill dan decode sebagai satu unit logis, dengan peluncuran terkoordinasi, pembaruan serentak, kesiapan yang bergantung pada snapshot Pod, serta perutean revisi native. API konfigurasi router naik ke v1, Responses API mendukung previous_response_id, dan jalur permintaan pemilih endpoint diperkuat demi keandalan, kinerja, dan skalabilitas. Panduan akselerator yang mempertimbangkan topologi untuk DRA dan DRANET juga disertakan.

Layanan yang memahami agen menambahkan plugin session-state-producer dan afinitas sesi yang terus berkembang agar percakapan multi-giliran tetap dekat dengan konteks yang tersimpan dalam cache. Penjadwalan berdasarkan prioritas giliran dan status Responses API membantu agen menggunakan kembali konteks di berbagai giliran. Rilis ini menyelaraskan komponen proyek pada v1.0.0, menambahkan komponen ekosistem, termasuk integrasi dengan ai-dynamo/modelexpress untuk pemuatan bobot model secara peer-to-peer, paket llm-d-api-extensions, serta perangkat diagnostik llm-d-pd-utils, dan menghentikan build image kontainer llm-d-rocm milik proyek sendiri. Image server model mencakup build vLLM dan SGLang untuk berbagai target akselerator, sementara panduan pemisahan prefill/decode kini mensyaratkan LeaderWorkerSet v0.11.1 atau yang lebih baru dengan API DisaggregatedSet diaktifkan.

Teknik Inti dan Pengendalian Alur

Sejak diluncurkan, proyek ini berfokus pada lima pendekatan untuk meningkatkan inferensi: perutean yang mempertimbangkan cache prefiks, yang mengarahkan permintaan ke infrastruktur yang mungkin sudah menyimpan konteks bersama; pemindahan cache KV, yang memindahkan informasi tersimpan di antara sumber daya GPU, CPU, dan penyimpanan; optimasi inferensi batch; pemisahan prefill/decode, yang memisahkan pembacaan prompt dari pembuatan respons; serta paralelisme pakar berskala luas, yang mendistribusikan model mixture-of-experts berukuran besar ke banyak akselerator. Teknik-teknik tersebut sudah ada sebelum versi 1.0; menurut IBM, hal baru dalam rilis ini adalah integrasi dan kematangan operasional di sekelilingnya, yakni disiplin operasional hari kedua untuk mempertahankan kinerja saat lalu lintas berubah, perangkat keras mengalami kegagalan, perangkat lunak diperbarui, atau pengguna yang berbeda bersaing memperebutkan sumber daya yang sama.

Dalam versi 1.0, pengendalian alur, keadilan, dan penentuan prioritas dimaksudkan untuk mencegah beban kerja yang melonjak membebani layanan yang sensitif terhadap latensi, baik saat beban kerja berbagi perangkat keras yang sama maupun saat menggunakan beragam akselerator. Permintaan juga dapat terus diarahkan ke infrastruktur yang sesuai selama beberapa giliran agar cache prefiks tetap hangat. llm-d bekerja dengan mesin inferensi seperti vLLM atau SGLang, serta menambahkan kemampuan perutean terdistribusi dan operasional di atasnya. Stephen Watt, wakil presiden di kantor direktur teknologi Red Hat, mengatakan bahwa llm-d menyatukan ekosistem PyTorch dan CNCF dengan menghadirkan orkestrasi native Kubernetes langsung ke vLLM dan mesin inferensi modern.

Hasil yang Diperlihatkan dan Biaya yang Disebutkan

Dalam postingan tolok ukur yang diterbitkan pada 22 Juli 2026, proyek ini mengukur penyajian model untuk agen menggunakan GLM-5.2, yang dijelaskan di sana sebagai model campuran pakar dengan 744 miliar parameter, 39 miliar di antaranya aktif, dan 78 lapisan. Analisis beban kerja menggunakan data dari 219 sesi produksi Claude Code. Dalam sesi-sesi tersebut, permintaan agen utama memiliki median 195 ribu token masukan dan menghasilkan 317 token keluaran, sementara 96% giliran agen utama menggunakan kembali setidaknya 90% token masukannya. Postingan tersebut melaporkan bahwa perutean yang mempertimbangkan prefiks berhasil memanfaatkan 96–97% penggunaan ulang tembolok yang tersedia dalam beban kerja. Dengan asumsi tarif sewa H200 sebesar $2,71 per jam GPU, postingan itu memperkirakan biaya penyajian yang dihosting sendiri pada dua konfigurasi 64 GPU sebesar $0,05 hingga $0,08 per satu juta token masukan dan $1,92 hingga $3,55 per satu juta token keluaran. Menurut para penulis, angka tersebut hanya mencakup biaya sewa GPU dan mengasumsikan beban berkelanjutan.

Dalam demonstrasi terpisah, IBM dan Red Hat menerapkan GLM-5.2 pada 544 GPU NVIDIA H100. Model dengan bobot terbuka yang memiliki sekitar 753 miliar parameter dan sekitar 39 miliar parameter aktif ini digambarkan dalam laporan IBM Research. IBM melaporkan bahwa pada puncaknya, penerapan tersebut menghasilkan lebih dari 6,6 juta token keluaran per menit saat melayani hingga 3.000 agen pengodean secara bersamaan tanpa preemption, dan konfigurasi operasi dengan 2.500 agen mampu mempertahankan laju 7.612 permintaan per menit. IBM menyatakan bahwa, dengan tarif sewa cloud saat ini, biaya menjalankan GLM-5.2 sendiri pada GPU H100 dengan llm-d per token 5 hingga 10 kali lebih rendah daripada harga API komersial yang setara. “Melayani ribuan agen secara bersamaan tanpa preemption memberi operator jalur yang meyakinkan untuk beralih dari hasil tolok ukur ke penerapan produksi,” kata Maroon Ayoub, insinyur pembelajaran mesin senior principal di tim rekayasa inferensi Red Hat.

Menurut laporan yang sama, di balik hasil tersebut, bidang data yang terdisagregasi menyelesaikan 6,2 juta transfer tembolok KV dengan rata-rata 2,71 GiB per transfer tanpa satu pun kegagalan transfer, dan semua tolok ukur selesai tanpa kesalahan penyajian.