Dua mesin kelas DGX Spark, satu model: salinan di masing-masing mengalahkan pembagian

Ops2026-10-31

Selama tujuh minggu, model bahasa lokal kami berjalan terbagi di dua mesin NVIDIA GB10 dengan paralelisme tensor. Pada 22 Oktober, kami menggantinya dengan salinan penuh model di setiap mesin dan proxy least-connection di depannya. Throughput naik dari sekitar 180 menjadi 210 token per detik, dan salah satu mesin kini dapat restart tanpa mematikan model.

Mengapa kami membaginya

Setiap mesin memiliki 128 GB memori yang dibagi antara CPU dan GPU. Pada September, model muat di satu mesin, tetapi cache-nya hampir tidak muat: build vLLM yang kami gunakan tidak dapat menyimpan KV cache model ini dalam FP8, sehingga cache berada dalam BF16, dan satu mesin hanya memiliki ruang untuk 499.110 token cache. Itu kurang dari dua permintaan pada konteks penuh model sebesar 262.144 token. Dibagi di kedua mesin dengan paralelisme tensor melalui tautan jaringan langsung mereka, cache tumbuh menjadi lebih dari tiga juta token. Kami membagi model demi ruang, bukan kecepatan.

Apa yang berubah

Build 4-bit yang lebih baru dari model yang sama (NVFP4, dibuat dengan distilasi sadar-kuantisasi) membutuhkan sekitar 71 GiB memori, dan build vLLM komunitas untuk GB10 (eugr/spark-vllm-b12x) menjalankan cache-nya dalam FP8. Kini satu mesin menyimpan seluruh model dan cache sebesar 0,76 hingga 1,08 juta token, ruang untuk 2,9 hingga 4,1 permintaan pada konteks penuh, tergantung pada berapa banyak memori yang diberikan mesin. Kedua salinan menggunakan speculative decoding bawaan model (MTP, empat token draf). Sebelum beralih, kami menjalankan uji pemanggilan alat pada build baru: skornya 86, sedangkan build yang digantikan 75.

Apa yang kami ukur

Satu salinan berdiri sendiri, berdasarkan jumlah permintaan yang dilayaninya secara bersamaan: dengan prompt pendek, 1 permintaan menghasilkan 36 token per detik, 4 menghasilkan 82, 8 menghasilkan 109, dan 16 menghasilkan 150. Dengan prompt lebih panjang dari agen email kami, 4 menghasilkan 81, 8 menghasilkan 113, dan 16 hanya 87: setelah delapan permintaan semacam itu, penambahan permintaan justru memperlambat kinerja.

Selama satu sore, satu salinan menangani maksimal 12 permintaan secara bersamaan dan salinan lainnya 8. Salinan pertama menghasilkan 91 hingga 93 token per detik dan menyelesaikan 26 hingga 27 permintaan per menit; salinan kedua menghasilkan 81 hingga 83 token per detik dan 22 permintaan per menit. Keduanya kini menangani 12 permintaan.

Yang kami korbankan

Ruang. Model terbagi memiliki satu cache lebih dari tiga juta token; salinan-salinan tersebut memiliki dua cache yang lebih kecil, dan sebuah permintaan hanya dapat menggunakan cache dari salinan yang melayaninya. Agen kami mengirim banyak permintaan pendek dan sedang, sehingga throughput lebih penting bagi mereka. Jika Anda melayani beberapa konteks sangat panjang sekaligus, pembagian mungkin tetap menjadi pilihan yang lebih baik. Kami mempertahankan pengaturan terbagi, dan kembali ke sana hanya memerlukan satu skrip.

Yang bermasalah selama peralihan

1. Sebelas menit tanpa model, lalu 30 detik error 502. Model terbagi harus berhenti sebelum salinan dapat dimuat di mesin yang sama, sehingga agen kami menunggu sekitar sebelas menit. Ketika salinan pertama aktif, proxy terus menjawab "502 no live upstreams" selama sekitar 30 detik lagi: proxy telah menandai backend sebagai gagal saat mereka mati (max_fails=3, fail_timeout=30s) dan tidak mencoba lagi hingga waktu tersebut habis.
2. Klien yang melewati proxy. Salah satu pekerjaan batch kami memiliki alamat mesin pertama dalam konfigurasinya, sehingga seluruh bebannya pergi ke satu salinan sementara salinan lain memiliki kapasitas yang tersedia. Setiap klien kini melalui proxy; alamat mesin sendiri hanya untuk pemeriksaan kesehatan.
3. Metrik yang melonjak. Monitor throughput kami membaca /metrics vLLM melalui proxy. Dengan dua backend, pembacaan berturut-turut berasal dari salinan yang berbeda, penghitung melompat-lompat, dan monitor melaporkan model tersebut kekurangan pasokan. Kini monitor membaca setiap salinan secara langsung dan menjumlahkannya.
4. Watchdog lama yang akan menghentikan salinan baru. Konfigurasi terpisah memiliki watchdog yang memulai ulang layanannya ketika model berhenti menjawab. Layanan baru mendeklarasikan Conflicts= dengan yang lama, sehingga restart tersebut akan menghentikan salinan baru. Watchdog harus dimatikan dengan systemctl disable --now, bukan hanya dihentikan, karena lapisan ops kami memulai ulang unit yang diaktifkan tetapi tidak berjalan.
5. Memori pada mesin yang menjalankan pekerjaan lain. Satu mesin juga menjalankan basis data dan build situs kami. Dengan gpu-memory-utilization vLLM pada 0.78, hanya tersisa 5 GiB untuk semua hal lain, sehingga kami menurunkannya ke 0.74 dan hanya memulai ulang salinan tersebut sementara salinan lain menanggung beban. Pada mesin-mesin ini, porsi yang Anda berikan ke vLLM diambil dari memori yang sama dengan semua hal lain.

Jika Anda memiliki dua mesin seperti ini

• Jika model dan cache yang Anda butuhkan muat pada satu mesin, jalankan satu salinan di setiap mesin di belakang proxy least-connection. Bagi model hanya jika satu mesin tidak dapat menampung cache yang Anda butuhkan.
• Arahkan setiap klien ke proxy, termasuk pekerjaan batch dan konfigurasi lama.
• Baca metrik dari setiap salinan secara langsung.
• Berikan setiap mesin porsi memorinya sendiri, sesuai dengan apa lagi yang berjalan di sana.
• Tetapkan berapa banyak permintaan yang dilayani satu salinan sekaligus dengan trafik Anda sendiri: untuk campuran kami, 12 lebih baik daripada 8.
• Perkirakan bahwa peralihan akan menghilangkan model selama waktu yang dibutuhkan satu salinan untuk memulai, dan rencanakan untuk itu.

Factory Floor menyertakan proxy dan konfigurasi peluncuran untuk satu atau dua mesin, pemeriksaan kesehatan dan uji penggunaan alat yang kami jalankan sebelum beralih model, beserta watchdog dan pengaman memori untuk sisa mesin.