Pada 21 Agustus, tim infrastruktur Ling milik Ant Group, bersama Alibaba dan tim SGLang, merilis komponen bernama Weight Cache Daemon di blog LMSYS: sebuah proses yang tetap berada di memori GPU, menyimpan bobot yang sudah terkuantisasi dan terpotong-potong, sehingga engine inferensi yang baru dijalankan bisa memetakannya lewat CUDA IPC tanpa penyalinan sama sekali. Menurut angka yang dirilis tim, waktu pemuatan bobot untuk Ling-2.6-1T FP8 turun dari sekitar 495 detik menjadi 0,63 detik, dan total waktu startup turun dari 8,8 menit menjadi 0,528 menit.
Delapan dari Delapan Setengah Menit Habis untuk Membaca Disk
Tim memecah satu siklus startup penuh dan mengukurnya tahap demi tahap. Ling-2.6-1T FP8 yang berjalan di 8 unit H20-3e, dengan bobot disimpan di NVMe SSD 3,5T, membutuhkan sekitar 527 detik dari mulai dijalankan hingga siap menerima permintaan. Dari jumlah itu, pemuatan bobot memakan 495 detik, atau 93,9%; inisialisasi tokenizer 13 detik, inisialisasi terdistribusi torch 5 detik, penangkapan CUDA graph 7,7 detik, dan sisanya jika dijumlahkan kurang dari 6 detik.
Setiap GPU harus membaca sekitar 120 GB safetensors dari disk, melakukan deserialisasi, memotongnya sesuai skema tensor paralel, lalu menjalankan kuantisasi FP8 dan penyusunan ulang bobot — totalnya 161 potongan. Alur ini harus dijalankan dari awal setiap kali restart, padahal hasilnya sebenarnya deterministik: model yang sama dengan konfigurasi yang sama akan selalu menghasilkan tensor yang identik di memori GPU, dan seringkali tensor itu masih ada di sana tepat setelah proses sebelumnya berhenti.
Bagi lingkungan produksi, beberapa menit ini berarti latensi ekor P99 melonjak tajam selama restart, permintaan yang sedang diproses gagal total atau mengantre tanpa batas, dan rolling upgrade maupun pemulihan dari kegagalan sama-sama terhambat oleh siklus ini.
Menyimpan Bobot Tetap di Memori GPU
Setiap GPU menjalankan satu proses daemon, satu untuk setiap TP rank. Daemon memuat sekali lewat alur penuh dari disk, lalu mengekspor semua parameter dan buffer dalam model.state_dict() sebagai handle CUDA IPC dan menyerahkannya lewat Unix socket ke proses engine mana pun yang tersambung. Di sisi engine, struktur model dibangun terlebih dahulu di meta device tanpa mengalokasikan memori sama sekali, lalu pointer data setiap parameter diarahkan ke tensor yang sudah dipetakan. Kedua proses berbagi memori fisik GPU yang sama tanpa penyalinan sama sekali sepanjang proses. Parameter hasil pascapemrosesan dari kuantisasi FP8, seperti weight_scale, ikut disimpan dalam cache sehingga tidak perlu dikuantisasi ulang.
Ada dua lapis pengaman. Pertama adalah fingerprint konfigurasi: jalur model, pembagian TP/PP/DP, metode kuantisasi beserta hash konfigurasinya, dan dtype semuanya harus cocok, ditambah kemampuan komputasi GPU dan versi torch yang dicatat sebagai penanda lingkungan. Arsitektur atau versi torch yang berbeda mengambil jalur pascapemrosesan yang berbeda pula — bobot bisa saja terpetakan dengan mulus tapi menghasilkan nilai yang salah — sehingga memasukkan informasi lingkungan ke dalam fingerprint mengubah kegagalan tersembunyi semacam ini menjadi ketidakcocokan yang eksplisit, lalu kembali memuat dari disk.
Lapis kedua adalah daftar putih metode kuantisasi. Saat ini yang sudah tervalidasi hanya tanpa kuantisasi dan block-wise FP8; per-tensor FP8, Marlin, dan AWQ/GPTQ langsung memicu error. Alasannya, IPC hanya mengekspor data tensor mentah, sementara metode-metode tersebut menyimpan sebagian efeknya di metadata sisi Python, atau menyusun ulang dan mentranspos bobot — jika dipetakan langsung, nilainya akan salah. Tim memilih membuatnya gagal secara eksplisit, bukan diam-diam memberikan hasil yang keliru.
Jika daemon crash, engine yang sedang berjalan tidak terpengaruh — reference count CUDA masih berlaku, dan memori baru dilepas setelah kedua sisi berhenti. Setelah daemon dijalankan ulang, ia membaca ulang dari disk dan mengekspor ulang handle-nya sebelum engine baru bisa tersambung lagi.
Sekaligus Menyelesaikan Masalah Biaya Hot Standby
Komponen ini punya tiga mode: daemon (engine sendiri yang menjalankan daemon, startup pertama tetap lambat), client (tersambung ke daemon yang sudah berjalan, restart dalam hitungan sub-detik), dan off (default, membaca dari disk — 405 hingga 411 detik untuk Ling-2.6-1T).
Lebih praktis daripada percepatan startup adalah beberapa pola deployment yang jadi mungkin. Beberapa instance engine di GPU yang sama bisa memetakan bobot yang sama, sehingga disk hanya dibaca sekali dan kuantisasi hanya dijalankan sekali. Layanan online berprioritas tinggi dan pemrosesan batch offline berprioritas rendah bisa berbagi satu GPU, dan yang belakangan bisa langsung dijalankan ulang dalam hitungan sub-detik setelah dipreempsi. Dalam skema failover primer-cadangan, engine cadangan memetakan bobot yang sama tanpa penyalinan dan tetap dalam keadaan hangat, lalu mengambil alih dalam satu detik setelah instance utama down.
Poin terakhir ini jelas-jelas soal biaya. Hitungan kasarnya: satu instance Ling-2.6-1T menempati 8 unit H20-3e; hot standby tradisional berarti 8 GPU lagi menganggur di sampingnya. Beralih ke standby berbagi bobot menghilangkan seluruh kelompok GPU yang menganggur itu. Hal yang sama berlaku untuk rolling upgrade — dengan estimasi sekali restart memakan 8,8 menit, setiap instance membakar sekitar 1,2 jam-GPU dalam kondisi menganggur per siklus restart, dan untuk klaster dengan ratusan instance, satu putaran upgrade bisa menumpuk hingga ratusan jam-GPU.
Belum Selesai
Weight Cache Daemon baru fase pertama dari Fast Engine Recovery Framework. Roadmap-nya menargetkan cold start di bawah 10 detik dan failover hot-standby di bawah 1 detik. Selanjutnya direncanakan serialisasi CUDA graph, caching kernel, dan optimasi inisialisasi terdistribusi. Berdasarkan rincian di atas, ketiganya jika dijumlahkan sekitar 26 detik — bagian terbesar yang tersisa setelah pemuatan bobot.
Angka untuk kelas Qwen3-235B FP8 juga ikut dirilis: bobot sekitar 235 GB, pemuatan dari disk 306 hingga 327 detik, pemetaan IPC di bawah 1 detik — sekitar 500 kali lebih cepat. Kelas Ling-2.6-1T mencapai sekitar 780 kali lebih cepat.
Blog tersebut juga menyinggung Kimi K3 berparameter 2,8T yang baru saja dirilis. Semakin besar jumlah parameter, waktu pemuatan dari disk ikut naik hampir linear, sementara pemetaan IPC nyaris konstan — selisih ini hanya akan makin melebar. Bagi tim yang sudah menjalankan model berparameter triliunan, biaya sekali restart sedang bergeser dari "menunggu beberapa menit" menjadi "hampir tidak perlu menunggu," dan pergeseran ini memengaruhi lebih dari sekadar angka ketersediaan — juga memengaruhi keberanian mengubah konfigurasi lebih sering, dan keberanian menjejalkan dua layanan di satu GPU yang sama.
Sumber: blog teknis LMSYS Org, CocoLoop, dokumentasi proyek SGLang; rincian waktu startup serta perbandingan angka pemuatan bobot dan pemetaan IPC diambil dari tabel benchmark satu node yang dipublikasikan tim.