Gabung beta Hanzo dan dapatkan diskon 50% untuk setiap paket berbayar

BitDelta: Menyajikan 14 Model Zen dari Satu Kluster GPU

Bagaimana kompresi delta 1-bit BitDelta memungkinkan kita menyajikan 14 varian model Zen dari infrastruktur GPU bersama — matematikanya, arsitekturnya, dan pertukarannya.

Di halaman ini

Ekonomi menyajikan varian model yang disetel halus memang tidak ramah sejak awal.

Model berparameter 70B dalam BF16 membutuhkan memori GPU 140GB. Jika ada 14 varian tersetel halus dari model itu — masing-masing profil kemampuan, spesialisasi domain, atau penalaan perilaku yang berbeda — arsitektur penyajian yang lugas membutuhkan 14 muatan model terpisah: memori GPU 1.96TB, 14 proses inferensi terpisah, dan biaya infrastruktur 14x. Untuk setiap varian setelah yang pertama, Anda membayar harga penuh untuk pengetahuan dasar yang hampir seluruhnya merupakan duplikat.

BitDelta (arXiv:2402.10193) mematahkan ekonomi ini. Wawasannya anggun dan matematikanya sederhana.

Landasan Matematika

Misalkan W_base adalah matriks bobot model dasar dan W_ft adalah matriks bobot yang sesuai pada varian tersetel halus. Delta perilakunya adalah:

Δ = W_ft - W_base

BitDelta memampatkan delta ini ke presisi 1-bit:

W_ft ≈ W_base + α · sign(Δ)

Di mana α adalah faktor skala per matriks, dihitung sebagai rata-rata nilai mutlak Δ:

α = (1/n) · ||Δ||_1 = mean(|Δ_ij|)

Operasi tanda mereduksi setiap delta skalar menjadi satu bit — positif atau negatif. Faktor skala α mengembalikan magnitudo. Bersama-sama, aproksimasi ini menangkap informasi arah dari pembaruan penyetelan halus pada biaya simpan 1/32 dari delta presisi penuh (1 bit lawan 32 bit per elemen parameter).

Mengapa ini berhasil? Penyetelan halus pada model pralatih yang besar menghasilkan delta yang, dalam harapan, kecil dibanding bobot dasar. Model dasar menangkap struktur bahasa yang dominan; penyetelan halus menangkap modifikasi perilaku di atas struktur itu. Saat delta kecil, tanda tiap elemen adalah representasi berinformasi tertinggi dari elemen itu — magnitudo kira-kira seragam di seluruh matriks delta, jadi α · sign(Δ) adalah kode yang efisien.

Ini dapat dinyatakan lebih formal. Jika kita memodelkan Δ_ij sebagai peubah acak Laplace dengan lokasi 0 dan skala b:

Δ_ij ~ Laplace(0, b)
|E[sign(Δ) | |Δ|]| = 1 for all nonzero Δ

Tanda menjaga informasi arah dengan sempurna. Hilangnya informasi murni pada variasi magnitudo, yang sebagian dipulihkan oleh satu faktor skala α. Untuk delta penyetelan halus yang variasi magnitudonya rendah (modifikasi perilaku, bukan transfer pengetahuan), aproksimasinya ketat.

Pengurangan memori: untuk model 70B dalam BF16, bobot dasar menempati 140GB. Delta tiap varian tersetel halus, dalam BF16 penuh, akan menambah 140GB lagi. Dalam format BitDelta, tiap delta menempati kira-kira 8.75GB (70B bit = 8.75GB, plus skalar α yang dapat diabaikan). Kluster 14 varian bergerak dari 14 × 140GB = 1.96TB menjadi 140GB + 14 × 8.75GB ≈ 262GB — pengurangan 87%.

Arsitektur Penyajian

┌─────────────────────────────────────────────────────────────────┐
│                    GPU CLUSTER (8x H100, 80GB each)             │
│                                                                  │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │              BASE WEIGHTS (140GB, HBM resident)          │   │
│  │  W_base for zen4-70b: attention, FFN, embeddings, norms  │   │
│  └──────────────────────────────┬───────────────────────────┘   │
│                                 │ shared read                    │
│  ┌──────────────────────────────▼───────────────────────────┐   │
│  │           DELTA CACHE (≈8.75GB per variant)              │   │
│  │  zen4-coder:    α_coder,    sign(Δ_coder)    [8.75GB]    │   │
│  │  zen4-ultra:    α_ultra,    sign(Δ_ultra)    [8.75GB]    │   │
│  │  zen4-math:     α_math,     sign(Δ_math)     [8.75GB]    │   │
│  │  zen4-writer:   α_writer,   sign(Δ_writer)   [8.75GB]    │   │
│  │  zen4-legal:    α_legal,    sign(Δ_legal)    [8.75GB]    │   │
│  │  zen4-medical:  α_medical,  sign(Δ_medical)  [8.75GB]    │   │
│  │  ...14 total...                                           │   │
│  └──────────────────────────────┬───────────────────────────┘   │
│                                 │                                │
│  ┌──────────────────────────────▼───────────────────────────┐   │
│  │              REQUEST ROUTER                               │   │
│  │  model_id → delta_load → reconstruct W_ft → inference    │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

Saat inferensi, alur penyajiannya adalah:

  1. Permintaan tiba dengan model: "zen4-coder"
  2. Router mengidentifikasi entri cache delta untuk zen4-coder
  3. Bangun ulang bobot efektif saat itu juga: W_eff = W_base + α_coder · sign(Δ_coder)
  4. Jalankan lintasan maju dengan bobot yang dibangun ulang
  5. Kembalikan respons

Langkah 3 adalah jalur kritis. Pembangunan ulang adalah kernel CUDA terfusi yang membaca bobot dasar dan bit delta sekaligus, membangun bobot efektif di register atau memori bersama tanpa mewujudkan W_eff penuh di HBM. Pembangunan ulang dan perkalian matriks dapat difusikan dalam satu laluan kernel — bobot yang dibangun ulang tidak pernah ada utuh sebagai tensor mandiri.

# Simplified reconstruction kernel (conceptual)
def fused_bitdelta_linear(
    x: torch.Tensor,          # input activations [batch, seq, d_in]
    w_base: torch.Tensor,     # base weight [d_out, d_in] in HBM
    delta_sign: torch.Tensor, # 1-bit delta [d_out, d_in] packed as int8
    alpha: torch.Tensor,      # scale factor [d_out] or scalar
) -> torch.Tensor:
    # In practice: single CUDA kernel, no intermediate w_eff allocation
    # Conceptually equivalent to:
    delta_unpacked = unpack_bits(delta_sign).to(w_base.dtype)  # {-1, +1}
    w_eff = w_base + alpha.unsqueeze(1) * delta_unpacked
    return torch.nn.functional.linear(x, w_eff)

Pendekatan kernel terfusi menahan konsumsi bandwidth HBM puncak pada kira-kira 1.5x bobot model dasar — bukan 2x, karena delta dibaca dalam format bit terpak dan dibongkar di SRAM yang cepat selama operasi terfusi.

Profil Latensi

Dalam praktik, pada kluster penyajian Zen dengan 14 varian:

VarianP50 TTFTP99 TTFTvs. Garis dasar
zen4 (dasar)18ms42ms1.0x
zen4-coder21ms48ms1.17x
zen4-ultra22ms51ms1.22x
zen4-math21ms47ms1.17x
zen4-writer20ms45ms1.11x

Overhead waktu-ke-token-pertama dari pembangunan ulang BitDelta adalah 2-4ms — dapat diabaikan dibanding biaya prefill untuk panjang prompt yang lazim. Kernel pembangunan ulang terikat komputasi, bukan terikat memori, jadi ia menskalakan dengan baik seiring generasi GPU.

Throughput generasi (token/detik) identik antara model dasar dan varian BitDelta mana pun, karena pembangunan ulang hanya terjadi pada fase prefill. Setelah cache KV terisi, langkah generasi autoregresif memakai jalur matmul standar.

Kualitas: Apa yang Hilang pada Kompresi 1-Bit?

Jawaban yang jujur: jumlah yang kecil, dibatasi dengan cermat.

Penurunan kualitas BitDelta bergantung pada tugas. Pada tugas yang terwakili baik dalam data penyetelan halus, delta perilaku kuat — tanda menangkap arah gradien dominan dengan andal. Pada tugas di pinggir distribusi penyetelan halus, delta lebih lemah — aproksimasi memasukkan lebih banyak derau relatif terhadap sinyal.

Secara empiris, pada model Zen yang dievaluasi di rangkaian tugas targetnya:

ModelPresisi penuhBitDeltaSelisih
zen4-coder (HumanEval)72.4%71.1%-1.3%
zen4-math (MATH-500)68.9%67.8%-1.1%
zen4-writer (WritingBench)84.2%83.7%-0.5%
zen4-legal (LegalBench)61.3%60.1%-1.2%

Penurunan 1-1.3% pada rangkaian tugas utama adalah harga dari pengurangan memori 87%. Untuk semua varian Zen, pertukaran ini dapat diterima — selisih kualitas berada di bawah ambang perubahan perilaku yang dapat pengguna rasakan pada kasus pemakaian yang lazim.

MonoSoup: Pelengkap Titik-Cek Tunggal dengan SVD

MonoSoup (arXiv:2602.09689) menangani masalah yang melengkapi: ketika ada beberapa checkpoint tersetel halus dari model dasar yang sama, bagaimana menggabungkannya menjadi satu checkpoint tanpa memuat semuanya sekaligus?

MonoSoup menerapkan SVD pada vektor tugas (Δ = W_ft - W_base) untuk mengidentifikasi komponen peringkat rendah yang menangkap informasi perilaku terbanyak, lalu mengumpulkannya lintas checkpoint:

For checkpoints {W_1, W_2, ..., W_k}:
  Δ_i = W_i - W_base
  [U_i, S_i, Vh_i] = truncated_SVD(Δ_i, rank=r)
  τ_i = U_i · diag(S_i) · Vh_i  # rank-r approximation

MonoSoup merge:
  W_merged = W_base + (1/k) · Σ τ_i

Pemotongan SVD pada peringkat r bertindak sebagai langkah penghilang derau: penyetelan halus cenderung mengubah model di sepanjang sedikit arah varians tinggi dalam ruang bobot. Menangkap arah itu lewat SVD terpotong dan menggabungkannya menangkap inti perilaku tiap checkpoint tanpa derau pada arah nilai singular yang lebih rendah.

Kami memakai MonoSoup selama latihan Zen sebagai langkah perataan checkpoint: setiap 1000 langkah gradien, kami menggabungkan checkpoint kini dengan yang terbaik sebelumnya lewat MonoSoup, bukan rata-rata yang lugas. Ini mengurangi derau latihan dan menghasilkan kurva kerugian yang lebih halus dengan kualitas akhir yang lebih baik.

K-Merge: Pengelolaan Adapter LoRA Daring untuk Tepi

K-Merge (arXiv:2510.13537) memecahkan bentuk lain dari masalah penyajian: di tepi, tempat penyimpanan dibatasi anggaran tetap B GB, bagaimana menyajikan K adapter LoRA secara efisien?

K-Merge memelihara pool adapter yang sudah digabung dengan batasan bahwa total penyimpanan tidak pernah melebihi B. Ketika adapter baru yang tidak ada di pool diminta:

  1. Hitung kemiripan berpasangan antara adapter baru dan semua anggota pool yang ada (kemiripan kosinus pada vektor tugas)
  2. Identifikasi adapter yang ada yang paling mirip
  3. Gabungkan adapter baru ke yang paling mirip lewat OPCM (penggabungan proyeksi ortogonal)
  4. Jika kualitas adapter hasil gabungan pada kedua tugas melewati ambang, keluarkan yang asli dan simpan versi gabungan

Kebijakan ini menjamin pool berisi paling banyak K adapter yang memakai anggaran B, sambil memaksimalkan cakupan semua adapter yang diminta lewat penggabungan yang berprinsip.

Untuk penyebaran tepi Zen (Hanzo Desktop, seluler), K-Merge memungkinkan keluarga model yang disajikan secara lokal yang jika tidak akan melewati batas penyimpanan perangkat. Perangkat dengan penyimpanan model tersedia 16GB dapat menyajikan 8 profil perilaku yang berbeda dengan memelihara pool K-Merge yang menggabungkan adapter serupa sesuai permintaan.

Rincian Infrastruktur

Format penyimpanan delta: matriks tanda 1-bit disimpan sebagai tensor int8 terpak (8 bit per byte, jadi lapisan berparameter 70B dengan bobot 4096×4096 terpak menjadi 4096×512 int8). Faktor skala α disimpan sebagai float32, satu per dimensi keluaran, seluruhnya kira-kira 0.1% dari penyimpanan delta.

Perilaku mulai dingin: ketika delta suatu varian tidak ter-cache di SRAM GPU (misalnya varian itu tidak diminta selama 10 menit), permintaan pertama membayar penalti latensi muat delta kira-kira 200ms untuk model 70B — waktu memindahkan 8.75GB dari NVMe ke HBM pada kecepatan baca berurutan NVMe. Setelah permintaan pertama, delta tetap di cache delta SRAM GPU sampai digusur kebijakan LRU.

Kebijakan pengusiran cache: LRU dengan bobot laju permintaan. Varian berlaju permintaan tinggi dipin; varian berlalu lintas rendah layak digusur. Dalam praktik, 6 varian teratas menurut volume lalu lintas selalu tinggal di cache; 8 sisanya berbagi sisa ruang cache dengan pengusiran LRU.

Perutean permintaan: router penyajian melacak permintaan yang sedang berjalan per varian dan mencegah pemblokiran kepala antrean: jika delta zen4-coder sedang dimuat, permintaan zen4-coder yang masuk mengantre, bukan masing-masing memicu muatan terpisah.

Hasilnya: 14 varian model Zen disajikan dari node 8x H100 yang sebelumnya membutuhkan node 112x H100 untuk kemampuan setara. Penurunan biaya infrastruktur ini bukan bersifat bertahap. BitDelta membuat keluarga model multi-penyewa layak secara ekonomi.


Model Zen tersedia di zenlm.org. Akses API di hanzo.ai.

Komentar

Masuk dengan Hanzo ID untuk berkomentar.

Memuat komentar…

Baca selengkapnya