BitDelta: Phục vụ 14 mô hình Zen từ một cụm GPU

Kinh tế của việc phục vụ các biến thể mô hình đã tinh chỉnh vốn bất lợi theo mặc định.

Một mô hình 70B tham số ở dạng BF16 cần 140GB bộ nhớ GPU. Nếu có 14 biến thể tinh chỉnh của mô hình đó — mỗi biến thể là một hồ sơ năng lực, một chuyên môn miền, hoặc một chỉnh hành vi khác nhau — kiến trúc phục vụ thẳng thắn cần 14 lần tải mô hình riêng: 1.96TB bộ nhớ GPU, 14 tiến trình suy luận riêng, và chi phí hạ tầng 14x. Với mỗi biến thể sau biến thể đầu, bạn trả đủ giá cho tri thức nền gần như hoàn toàn trùng lặp.

BitDelta (arXiv:2402.10193) phá vỡ nền kinh tế này. Cách nhìn thanh lịch và toán thì đơn giản.

Nền tảng toán học

Gọi W_base là ma trận trọng số của mô hình nền và W_ft là ma trận trọng số tương ứng trong một biến thể tinh chỉnh. Delta hành vi là:

Δ = W_ft - W_base

BitDelta nén delta này xuống độ chính xác 1-bit:

W_ft ≈ W_base + α · sign(Δ)

Trong đó α là hệ số tỉ lệ theo từng ma trận, tính bằng trung bình giá trị tuyệt đối của Δ:

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

Phép lấy dấu thu mỗi delta vô hướng về một bit — dương hoặc âm. Hệ số tỉ lệ α khôi phục độ lớn. Gộp lại, xấp xỉ này nắm thông tin hướng của bản cập nhật tinh chỉnh với chi phí lưu bằng 1/32 delta đủ độ chính xác (1 bit so với 32 bit cho mỗi phần tử tham số).

Vì sao cách này đứng được? Tinh chỉnh trên một mô hình tiền huấn luyện lớn tạo ra các delta mà kỳ vọng thì nhỏ so với trọng số nền. Mô hình nền nắm cấu trúc chủ đạo của ngôn ngữ; tinh chỉnh nắm các sửa đổi hành vi bên trên cấu trúc đó. Khi delta nhỏ, dấu của mỗi phần tử là biểu diễn nhiều thông tin nhất của phần tử đó — độ lớn gần như đều trên ma trận delta, nên α · sign(Δ) là một mã hiệu quả.

Có thể nói chặt hơn. Nếu mô hình hóa Δ_ij như biến ngẫu nhiên Laplace với vị trí 0 và tỉ lệ b:

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

Dấu giữ thông tin hướng một cách trọn vẹn. Phần mất thông tin chỉ nằm ở biến thiên độ lớn, mà một hệ số tỉ lệ α khôi phục được một phần. Với delta tinh chỉnh mà biến thiên độ lớn thấp (sửa hành vi chứ không phải chuyển tri thức), xấp xỉ là chặt.

Giảm bộ nhớ: với mô hình 70B ở dạng BF16, trọng số nền chiếm 140GB. Delta của mỗi biến thể tinh chỉnh, ở dạng BF16 đầy đủ, sẽ thêm 140GB nữa. Ở dạng BitDelta, mỗi delta chiếm khoảng 8.75GB (70B bit = 8.75GB, cộng các vô hướng α, không đáng kể). Cụm 14 biến thể đi từ 14 × 140GB = 1.96TB xuống 140GB + 14 × 8.75GB ≈ 262GB — giảm 87%.

Kiến trúc phục vụ

┌─────────────────────────────────────────────────────────────────┐
│                    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    │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

Lúc suy luận, đường ống phục vụ là:

1. Yêu cầu đến kèm model: "zen4-coder"
2. Bộ định tuyến xác định mục bộ nhớ đệm delta của zen4-coder
3. Dựng lại trọng số hữu hiệu ngay lúc chạy: W_eff = W_base + α_coder · sign(Δ_coder)
4. Chạy lượt tiến với trọng số đã dựng
5. Trả về câu trả lời

Bước 3 là đường găng. Việc dựng lại là một nhân CUDA hợp nhất, đọc đồng thời trọng số nền và bit delta, dựng trọng số hữu hiệu trong thanh ghi hoặc bộ nhớ dùng chung mà không hiện thực hóa đầy đủ W_eff trong HBM. Dựng lại và nhân ma trận có thể hợp nhất trong một lượt nhân — trọng số đã dựng không bao giờ tồn tại trọn vẹn như một tensor độc lập.

# 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)

Cách nhân hợp nhất giữ mức tiêu thụ băng thông HBM đỉnh ở khoảng 1.5x trọng số của mô hình nền — không phải 2x, vì delta được đọc ở dạng bit đóng gói và được mở trong SRAM nhanh trong lúc phép hợp nhất chạy.

Hồ sơ độ trễ

Trong thực tế, trên cụm phục vụ Zen với 14 biến thể:

Biến thể	P50 TTFT	P99 TTFT	so với nền
zen4 (nền)	18ms	42ms	1.0x
zen4-coder	21ms	48ms	1.17x
zen4-ultra	22ms	51ms	1.22x
zen4-math	21ms	47ms	1.17x
zen4-writer	20ms	45ms	1.11x

Phần thời gian thêm đến token đầu do dựng lại BitDelta là 2-4ms — không đáng kể so với chi phí prefill cho độ dài prompt thông thường. Nhân dựng lại bị chặn bởi tính toán, không phải bởi bộ nhớ, nên nó mở rộng tốt theo các thế hệ GPU.

Thông lượng sinh (token/giây) giống nhau giữa mô hình nền và mọi biến thể BitDelta, vì việc dựng lại chỉ xảy ra ở pha prefill. Sau khi bộ nhớ đệm KV đã đầy, bước sinh tự hồi quy dùng các đường matmul chuẩn.

Chất lượng: Nén 1-bit làm mất gì?

Câu trả lời thẳng: một lượng nhỏ, được chặn cẩn thận.

Sự giảm chất lượng của BitDelta phụ thuộc tác vụ. Với tác vụ được dữ liệu tinh chỉnh đại diện tốt, delta hành vi mạnh — dấu nắm hướng gradient chủ đạo một cách chắc. Với tác vụ ở rìa phân bố tinh chỉnh, delta yếu hơn — xấp xỉ đưa vào nhiều nhiễu hơn so với tín hiệu.

Về mặt thực nghiệm, trên các mô hình Zen được đánh giá bằng bộ tác vụ mục tiêu của chúng:

Mô hình	Đủ độ chính xác	BitDelta	Chênh
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%

Mức giảm 1-1.3% trên các bộ tác vụ chính là cái giá của việc giảm 87% bộ nhớ. Với mọi biến thể Zen, sự đánh đổi này chấp nhận được — chênh chất lượng nằm dưới ngưỡng thay đổi hành vi mà người dùng nhận ra trong các ca dùng thông thường.

MonoSoup: Phần bù một checkpoint bằng SVD

MonoSoup (arXiv:2602.09689) xử lý một bài toán bổ sung: khi có nhiều checkpoint tinh chỉnh của cùng mô hình nền, làm sao hợp chúng thành một checkpoint mà không tải tất cả cùng lúc?

MonoSoup áp SVD lên véctơ tác vụ (Δ = W_ft - W_base) để xác định các thành phần hạng thấp nắm nhiều thông tin hành vi nhất, rồi gộp chúng qua các 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

Cắt SVD ở hạng r là một bước khử nhiễu: tinh chỉnh có xu hướng sửa mô hình dọc theo một số ít hướng phương sai cao trong không gian trọng số. Nắm các hướng đó bằng SVD đã cắt rồi hợp chúng sẽ giữ bản chất hành vi của mỗi checkpoint, không kèm nhiễu ở các hướng giá trị kỳ dị thấp hơn.

Chúng tôi dùng MonoSoup trong các lần huấn luyện Zen như một bước lấy trung bình checkpoint: mỗi 1000 bước gradient, chúng tôi hợp checkpoint hiện tại với checkpoint tốt nhất trước đó bằng MonoSoup, thay vì lấy trung bình thẳng. Việc này giảm nhiễu huấn luyện và cho đường cong mất mát trơn hơn, chất lượng cuối tốt hơn.

K-Merge: Quản lý adapter LoRA trực tuyến cho biên

K-Merge (arXiv:2510.13537) giải một dạng khác của bài toán phục vụ: ở biên, nơi lưu trữ bị giới hạn bởi ngân sách cố định B GB, làm sao phục vụ K adapter LoRA cho hiệu quả?

K-Merge giữ một hồ các adapter đã hợp, với ràng buộc tổng lưu trữ không bao giờ vượt B. Khi một adapter mới không có trong hồ được yêu cầu:

1. Tính độ tương đồng từng cặp giữa adapter mới và mọi thành viên hiện có trong hồ (độ tương đồng cosine trên các véctơ tác vụ)
2. Xác định adapter hiện có giống nhất
3. Hợp adapter mới vào adapter giống nhất qua OPCM (hợp bằng phép chiếu trực giao)
4. Nếu chất lượng adapter đã hợp trên cả hai tác vụ vượt ngưỡng, loại bản gốc và lưu bản đã hợp

Chính sách này bảo đảm hồ chứa nhiều nhất K adapter tiêu thụ ngân sách B, đồng thời tối đa độ phủ mọi adapter được yêu cầu bằng cách hợp có nguyên tắc.

Với triển khai biên của Zen (Hanzo Desktop, di động), K-Merge cho phép các họ mô hình phục vụ tại chỗ mà nếu không sẽ vượt giới hạn lưu trữ của thiết bị. Một thiết bị còn 16GB lưu trữ mô hình có thể phục vụ 8 hồ sơ hành vi khác nhau bằng một hồ K-Merge hợp các adapter giống nhau theo yêu cầu.

Chi tiết hạ tầng

Định dạng lưu delta: các ma trận dấu 1-bit được lưu thành tensor int8 đóng gói (8 bit mỗi byte, nên một lớp 70B tham số với trọng số 4096×4096 đóng thành 4096×512 int8). Các hệ số tỉ lệ α được lưu ở dạng float32, một hệ số cho mỗi chiều đầu ra, tổng cộng khoảng 0.1% dung lượng lưu của delta.

Hành vi khởi động lạnh: khi delta của một biến thể không nằm trong bộ nhớ đệm SRAM của GPU (ví dụ biến thể đó không được yêu cầu trong 10 phút), yêu cầu đầu trả một khoản trễ tải delta khoảng 200ms với mô hình 70B — thời gian chuyển 8.75GB từ NVMe sang HBM ở tốc độ đọc tuần tự của NVMe. Sau yêu cầu đầu, delta ở lại bộ nhớ đệm delta trên SRAM của GPU cho đến khi chính sách LRU loại nó.

Chính sách loại bộ nhớ đệm: LRU có trọng số theo tốc độ yêu cầu. Biến thể có tốc độ yêu cầu cao được ghim; biến thể ít lưu lượng có thể bị loại. Trong thực tế, 6 biến thể đứng đầu theo lưu lượng luôn thường trú trong bộ nhớ đệm; 8 biến thể còn lại chia phần bộ nhớ đệm còn lại với việc loại theo LRU.

Định tuyến yêu cầu: bộ định tuyến phục vụ theo dõi các yêu cầu đang xử lý theo từng biến thể và ngăn chặn đầu dòng: nếu delta của zen4-coder đang được tải, các yêu cầu zen4-coder đến sau sẽ xếp hàng, thay vì mỗi yêu cầu tự kích một lần tải riêng.

Kết quả: 14 biến thể mô hình Zen được phục vụ từ các nút 8x H100, trong khi năng lực tương đương trước đây cần các nút 112x H100. Mức giảm chi phí hạ tầng không mang tính tăng dần. BitDelta làm cho họ mô hình đa người thuê đứng vững về kinh tế.

---

Mô hình Zen có tại zenlm.org. Truy cập API tại hanzo.ai.