Penskalaan adaptif-beban

Jalur penyajian MoE Kvasir tumbuh dan menyusut seiring lalu lintas: koordinator melibatkan kembali worker terbukti di bawah kejenuhan, dan bridge merekrut node menganggur dengan menaikkan permintaan pakar — semuanya berbasis-tarik, sehingga perangkat ber-NAT pun ikut bergabung.

Jalur penyajian MoE Kvasir menskala secara elastis seiring beban, dalam dua lapisan yang saling bekerja sama. Saat sepi, koordinator melayani semuanya secara lokal demi jalur tercepat per token; saat jenuh, dua lapisan di bawah menumbuhkan swarm — dan menyusutkannya lagi saat lonjakan berlalu.

Status mesin. Sharding pada butiran pakar dibangun dan didemonstrasikan di mesin Kvasir sebelumnya, dan hasil-hasil di bawah ini berasal dari kerja itu. Mesin saat ini, [p4](/wiki/p4), melayani pada butiran lapisan hari ini; memindahkan sharding pakar ke atasnya sudah dirancang dan sedang dikerjakan. Di mana sebuah detail menyebut nama perkakas atau rute, itu adalah yang berjalan di mesin sebelumnya.

Lapisan 1

Sisi koordinator: dispatch adaptif-beban

Koordinator backbone (sebuah linkcpp-server yang menjalankan model penuh) melayani pakar terutekan entah pada GPU-nya sendiri (cepat, lokal) atau dengan men-dispatch-nya ke worker jarak-jauh. Sebuah thread latar memutuskan yang mana, setiap beberapa detik:

  • Ia menjajaki slot inferensi miliknya sendiri. Ketika busy >= saturation threshold (default 2), koordinator sedang di bawah beban.
  • Di bawah beban, jika sebuah worker yang terbukti aktif — yang last_serve_ms > 0, artinya benar-benar pernah menghitung pakar sebelumnya — koordinator terus men-dispatch kepadanya melewati batas-waktu-diam normal, mengutamakan throughput agregat ketimbang latensi per-token.
  • Worker yang tersambung tetapi tak pernah melayani (ponsel yang menyambung ke relay namun tak pernah menghitung) tidak direkrut di bawah beban, karena men-dispatch kepadanya akan menggantikan jalur lokal yang cepat dengan fallback yang lambat. Worker baru tetap mendapat percobaan pertama lewat jendela tenggang singkat.
  • Kueri-diri dibatasi waktu sehingga penjajakan yang macet tak pernah bisa memblokir dispatch.
Lapisan 2

Sisi bidang kendali: rekrutmen adaptif-beban

Bidang kendali mengawasi setiap koordinator MoE dan menumbuhkan kumpulan worker saat diperlukan:

  • Sebuah loop latar menjajaki slot tiap koordinator dan mencatat kejenuhan per model.
  • Selama sebuah model jenuh, target replika-pakar efektifnya dinaikkan (base + boost). Pasar cakupan lalu membaca pakar-pakar yang sudah tercakup sebagai langka kembali, dan sebuah model tanpa worker aktif di-seed dari metadata GGUF-nya (jumlah pakar) sehingga permintaan terlihat bahkan dari nol.
  • Node yang menganggur menjajaki pasar permintaan (/api/expert-volunteer) dan diberi sepotong (layer, expert-range) untuk dilayani. Mereka mengunduh potongan itu, menyambung ke relay, dan mendaftarkan cakupan; bidang kendali secara otomatis mengaitkan mereka ke peta dispatch koordinator.
  • Saat beban surut, target turun kembali dan permintaan lenyap, sehingga worker ekstra tak lagi di-dispatch dan menua keluar.

Desainnya berbasis-tarik: node meminta pekerjaan alih-alih didorong, sehingga worker di balik NAT berpartisipasi tanpa konektivitas masuk. Sebuah node yang direkrut di Lapisan 2 yang mulai melayani menjadi worker yang terbukti yang lalu dipertahankan tetap terlibat oleh Lapisan 1 di bawah beban — kedua lapisan berpadu menjadi satu loop elastis.

Observabilitas: GET /api/moe/recruitment melaporkan busy/kejenuhan per-model serta target base vs efektif; /api/expert-demand membawa flag recruiting.