llm-d 1.0 siap produksi—upgrade model tak perlu menghentikan layanan

Pada 20 Oktober 2026, kontributor proyek merilis llm-d 1.0 untuk inferensi model besar di lingkungan produksi. Versi ini membawa routing dengan instans siaga, kendali multitenansi, API konfigurasi stabil, dan pembaruan bergulir yang menjaga lalu lintas ketika komponen layanan diganti. Bagi tim platform, perubahan utamanya terasa saat beberapa penyewa berebut kapasitas atau revisi layanan model harus berganti tanpa memutus permintaan yang sedang berjalan.

Dalam demonstrasi yang dipaparkan IBM, GLM 5.2 pada GPU NVIDIA mencapai lebih dari 6,6 juta token keluaran per menit pada puncaknya dan melayani hingga 3.000 agen coding serentak tanpa preemption, dengan perkiraan biaya per token 5–10 kali lebih rendah daripada harga API komersial pembanding pada tarif sewa cloud saat itu. Angka tersebut berasal dari konfigurasi dan beban agen tertentu. Kesiapan operasional rilis ini sudah terlihat dari fitur yang tersedia, sedangkan hasil latensi dan biaya pada tiap armada tetap perlu diukur sendiri.

Router membagi kapasitas menurut penyewa dan prioritas

Dalam satu armada, permintaan interaktif yang sensitif terhadap latensi dapat datang bersamaan dengan rangkaian panggilan agen yang panjang dan mendadak. Pengendali aliran llm-d mengelompokkan permintaan menurut identitas penyewa atau beban kerja serta tingkat prioritasnya. Router melayani kelompok berprioritas lebih tinggi lebih dahulu, lalu membagi giliran di antara penyewa dalam kelompok yang sama agar satu lonjakan tidak menguasai antrean.

Ketika backend padat, router dapat menahan permintaan sebelum mengirimnya ke server model yang sudah sibuk. Pengendali penerimaan juga dapat mengurangi permintaan yang diterima saat beban melampaui kapasitas. Namun, kebijakan ini harus dikonfigurasi: perilaku bawaan masih meniru urutan kedatangan, sehingga memasang versi baru saja belum mengubah pembagian layanan antarpelanggan.

Rute berbasis sesi menangani kebutuhan lain dari agen. Permintaan lanjutan diarahkan kembali ke replika yang masih menyimpan konteks dalam cache KV selama replika itu belum penuh; ketika penuh, permintaan dapat dialihkan. Penjadwalan berdasarkan giliran percakapan dan dukungan status Responses API mengurangi kebutuhan mengirim serta menghitung ulang riwayat yang sama. Keuntungannya paling relevan untuk pekerjaan yang berulang kali memakai konteks panjang.

Pembaruan bergulir menjaga prefill dan decode tetap seversi

Perubahan yang paling langsung menyentuh ketersediaan layanan adalah koordinasi saat revisi diganti. Instans siaga pada Endpoint Picker dapat mengambil alih penjadwalan ketika router aktif gagal atau diperbarui. Pada penerapan terpisah, prefill mengolah prompt dan decode menghasilkan token jawaban; keduanya harus dapat bertukar data cache secara cocok agar satu permintaan selesai.

DisaggregatedSet memperlakukan replika prefill dan decode sebagai satu unit versi. Kesiapan pasangan baru diperiksa sebelum router mengirim permintaan kepadanya, sementara routing yang sadar revisi mencegah tahap lama dan baru tercampur dalam satu permintaan. Mekanisme itu memungkinkan pergantian bertahap saat armada masih melayani lalu lintas. Dalam laporan SiliconANGLE, Carlos Costa, salah satu pengelola proyek, menyebut sasarannya “upgrades that don't interrupt operations”.

Kesinambungan layanan bergantung pada jalur pembaruan dan konfigurasi komponen yang dipakai. Perubahan pada mesin inferensi, konektor cache, atau penempatan replika tetap membutuhkan pasangan tahap yang kompatibel serta kapasitas selama pergantian. API konfigurasi yang stabil memberi dasar bagi otomasi revisi, tetapi ketersediaan aktual juga bergantung pada cara tiap tahap dikuras dan diganti di klaster pengguna.

Bukti penerapan dan angka uji mengukur hal berbeda

Jejak penggunaan di layanan nyata menunjukkan bahwa komponen llm-d telah melewati beban produksi, meski tiap pemasangan memilih fitur dan tingkat ketahanan yang berbeda. Google Cloud membangun GKE Inference Gateway di atas Endpoint Picker, sedangkan Mistral AI memakai llm-d untuk layanan inferensi regional. JetBrains menjalankannya di balik agen coding Junie. Contoh tersebut memperlihatkan ragam lingkungan yang memakainya, bukan satu konfigurasi baku untuk seluruh pengguna.

Hasil demonstrasi menggambarkan kapasitas pada beban agen yang padat, sementara perbandingan biayanya memasukkan asumsi tarif sewa dan harga API pembanding. Throughput token keluaran, waktu tunggu permintaan interaktif, tingkat penggunaan ulang cache, dan biaya total armada adalah ukuran yang berbeda. Kenaikan pada salah satunya belum memastikan layanan lain akan lebih murah atau lebih responsif.

Untuk menilai kesiapan produksi, tiga lapis bukti perlu dipisahkan: kemampuan operasional yang tersedia, penerapan yang sudah berjalan, dan hasil ekonomi dari beban uji tertentu. Contoh pengguna memberi alasan untuk mempertimbangkan rilis ini bagi platform besar; demonstrasi memberi titik pembanding untuk kapasitas. Kelayakan migrasi tetap bergantung pada kecocokan mesin model, akselerator, cache, dan pola lalu lintas yang akan dilayani.

Observabilitas menentukan risiko migrasi

Router yang menahan antrean dan memilih replika juga memindahkan sebagian gejala kemacetan dari server model ke lapisan penjadwalan. Karena itu, waktu tunggu di router, latensi menurut kelas prioritas, tingkat penggunaan ulang cache, dan keberhasilan perpindahan revisi menjadi sinyal operasi yang relevan. Tanpa pemisahan metrik tersebut, kenaikan latensi sulit ditelusuri ke antrean, ketimpangan beban antarpengguna, atau kapasitas server model.

Uji migrasi yang paling menentukan adalah menjalankan beban campuran saat sebagian armada diperbarui, lalu melihat apakah permintaan yang sedang berlangsung tetap selesai dan kelas interaktif mempertahankan target latensinya. Pada sistem yang memisahkan prefill dan decode, kecocokan revisi serta kapasitas sementara perlu masuk ke pengukuran itu. Hasilnya akan menunjukkan apakah pembaruan tanpa penghentian layanan berlaku pada konfigurasi produksi yang dipilih.

Baca juga:

• GPT-5.6 masuk Kiro, tetapi klaim hemat biaya 82% perlu dibaca hati-hati
• Gemini Gems menghemat prompt berulang—berkas acuan tetap perlu dibatasi
• Agen coding hanya lolos 23,9%—membangun agen layanan masih jauh dari selesai