Dua kotak setaraf DGX Spark, satu model: satu salinan pada setiap unit mengatasi pembahagiannya

Operasi2026-10-31

Selama tujuh minggu, model bahasa tempatan kami berjalan secara berpecah merentasi dua mesin NVIDIA GB10 dengan paralelisme tensor. Pada 22 Oktober, kami menggantikannya dengan salinan penuh model pada setiap mesin dan proksi sambungan-minimum di hadapannya. Keluaran meningkat daripada kira-kira 180 kepada 210 token sesaat, dan mana-mana mesin kini boleh dimulakan semula tanpa menghilangkan model tersebut.

Sebab kami memecahkannya

Setiap mesin mempunyai 128 GB memori yang dikongsi oleh CPU dan GPU. Pada September, model itu muat pada satu mesin, tetapi cache-nya hampir tidak muat: binaan vLLM yang kami gunakan tidak dapat mengekalkan cache KV model ini dalam FP8, jadi cache tersebut dalam BF16, dan satu mesin mempunyai ruang untuk 499,110 token cache. Itu kurang daripada dua permintaan pada konteks penuh model sebanyak 262,144 token. Dibahagi merentasi kedua-dua mesin dengan paralelisme tensor melalui pautan rangkaian langsung mereka, cache berkembang kepada lebih tiga juta token. Kami memecahkan model untuk ruang, bukan untuk kelajuan.

Apa yang berubah

Binaan 4-bit baharu bagi model yang sama (NVFP4, dihasilkan dengan penyulingan sedar kuantisasi) mengambil kira-kira 71 GiB memori, dan binaan vLLM komuniti untuk GB10 (eugr/spark-vllm-b12x) menjalankan cache-nya dalam FP8. Kini satu mesin menyimpan keseluruhan model dan cache 0.76 hingga 1.08 juta token, ruang untuk 2.9 hingga 4.1 permintaan pada konteks penuh, bergantung kepada berapa banyak memori yang diberikan oleh mesin tersebut. Kedua-dua salinan menggunakan penyahkodan spekulatif model itu sendiri (MTP, empat token draf). Sebelum beralih, kami menjalankan ujian panggilan alat kami pada binaan baharu: ia mendapat skor 86, manakala binaan yang digantikannya mendapat 75.

Apa yang kami ukur

Satu salinan berdiri sendiri, mengikut bilangan permintaan yang dilayan serentak: dengan prompt pendek, 1 permintaan menghasilkan 36 token sesaat, 4 menghasilkan 82, 8 menghasilkan 109 dan 16 menghasilkan 150. Dengan prompt lebih panjang bagi agen e-mel kami, 4 menghasilkan 81, 8 menghasilkan 113 dan 16 hanya 87: selepas lapan permintaan sedemikian, lebih banyak permintaan menjadikannya lebih perlahan.

Untuk satu petang, satu salinan mengambil paling banyak 12 permintaan serentak dan satu lagi 8. Yang pertama menghasilkan 91 hingga 93 token sesaat dan selesai 26 hingga 27 permintaan seminit; yang kedua 81 hingga 83 token sesaat dan 22 permintaan seminit. Kedua-duanya kini mengambil 12.

Apa yang kami korbankan

Ruang. Model berpecah mempunyai satu cache lebih tiga juta token; salinan-salinan mempunyai dua cache yang lebih kecil, dan permintaan hanya boleh menggunakan cache bagi salinan yang melayannya. Agen kami menghantar banyak permintaan pendek dan sederhana, dan bagi mereka, throughput lebih penting. Jika anda melayan beberapa konteks yang sangat panjang serentak, pembahagian mungkin masih pilihan yang lebih baik. Kami mengekalkan setup berpecah, dan menukar kembali hanyalah satu skrip.

Apa yang tidak kena semasa peralihan

1. Sebelas minit tanpa model, kemudian 30 saat ralat 502. Model berpecah perlu berhenti sebelum salinan boleh dimuat pada mesin yang sama, jadi agen kami menunggu kira-kira sebelas minit. Apabila salinan pertama muncul, proksi terus menjawab "502 no live upstreams" selama kira-kira 30 saat lagi: ia telah menandakan backend sebagai gagal semasa mereka turun (max_fails=3, fail_timeout=30s) dan tidak mencubanya semula sehingga masa itu tamat.
2. Klien yang melangkau proksi. Salah satu kerja kelompok kami mempunyai alamat mesin pertama dalam konfigurasinya, jadi seluruh bebannya pergi ke satu salinan manakala satu lagi mempunyai kapasiti lebihan. Setiap klien kini melalui proksi; alamat mesin sendiri hanya untuk pemeriksaan kesihatan.
3. Metrik yang melompat. Pemantau throughput kami membaca /metrics vLLM melalui proksi. Dengan dua backend, bacaan berturutan datang daripada salinan berbeza, pengira melompat ke sana sini, dan pemantau melaporkan model sebagai kebuluran. Ia kini membaca setiap salinan secara langsung dan menjumlahkannya.
4. Watchdog lama yang akan menghentikan salinan baharu. Konfigurasi berpecah mempunyai watchdog yang memulakan semula perkhidmatannya apabila model berhenti menjawab. Perkhidmatan baharu mengisytiharkan Conflicts= dengan yang lama, jadi pemulakan semula itu akan menghentikan salinan baharu. Ia perlu dimatikan dengan systemctl disable --now, bukan sekadar dihentikan, kerana lapisan operasi kami memulakan semula unit yang didayakan tetapi tidak berjalan.
5. Memori pada mesin yang menjalankan kerja lain. Satu mesin juga menjalankan pangkalan data dan bina tapak kami. Dengan gpu-memory-utilization vLLM pada 0.78, hanya 5 GiB tinggal untuk semua yang lain, jadi kami menurunkannya kepada 0.74 dan memulakan semula hanya salinan itu sementara yang lain menanggung beban. Pada mesin ini, bahagian yang anda berikan kepada vLLM diambil daripada memori yang sama dengan semua yang lain.

Jika anda mempunyai dua mesin ini

• Jika model dan cache yang anda perlukan muat pada satu mesin, jalankan salinan pada setiap satu di belakang proksi sambungan-minimum. Pecahkan model hanya apabila satu mesin tidak dapat menyimpan cache yang anda perlukan.
• Arahkan setiap klien ke proksi, termasuk kerja kelompok dan konfigurasi lama.
• Baca metrik daripada setiap salinan secara langsung.
• Berikan setiap mesin bahagian memorinya sendiri, mengikut apa lagi yang berjalan padanya.
• Tetapkan berapa banyak permintaan yang dilayan oleh satu salinan secara serentak dengan trafik anda sendiri: untuk campuran kami, 12 lebih baik daripada 8.
• Jangka bahawa peralihan akan mengambil model untuk tempoh selama salinan mengambil masa untuk bermula, dan rancangkan untuknya.

Factory Floor menyertakan proksi dan konfigurasi pelancaran untuk satu atau dua mesin, pemeriksaan kesihatan dan ujian penggunaan alat yang kami jalankan sebelum menukar model, dengan watchdog dan pengawal keselamatan memori untuk baki mesin.