BitDelta：從單一圖形處理器叢集提供 14 個 Zen 模型

提供微調模型變體的經濟性，預設就很不利。

一個 70B 參數的模型以 BF16 儲存需要 140GB 圖形處理器記憶體。若有該模型的 14 個微調變體——各自代表不同的能力輪廓、領域專精或行為調校——直白的服務架構就要 14 次分開載入：1.96TB 圖形處理器記憶體、14 個獨立推論程式、14x 的基礎建設成本。從第二個變體起，你是在為幾乎完全重複的基礎知識付全額。

BitDelta（arXiv:2402.10193）打破了這筆帳。洞見優雅，數學也很簡單。

數學基礎

設 W_base 為基底模型的權重矩陣，W_ft 為微調變體中對應的權重矩陣。行為增量是：

Δ = W_ft - W_base

BitDelta 把該增量壓縮到 1 位元精度：

W_ft ≈ W_base + α · sign(Δ)

其中 α 是依矩陣計算的縮放因子，取 Δ 絕對值的平均：

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

符號運算把每個純量增量收成一個位元——正或負。縮放因子 α 恢復幅度。合在一起，這個近似以全精度增量 1/32 的儲存成本捕捉微調更新的方向資訊（每個參數元素 1 位元對 32 位元）。

這為何成立？ 在大型預訓練模型上微調，產生的增量在期望上相對基底權重很小。基底模型捕捉語言的主導結構；微調捕捉疊在該結構上的行為修改。增量很小時，每個元素的符號就是該元素資訊量最高的表示——幅度在增量矩陣上大致均勻，因此 α · sign(Δ) 是一種高效編碼。

可以更形式地表述。若把 Δ_ij 建模為位置 0、尺度 b 的拉普拉斯隨機變數：

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

符號完整保留方向資訊。資訊損失純粹來自幅度變化，單一縮放因子 α 只能部分找回。對幅度變化很低的微調增量（行為修改而非知識遷移），近似是緊的。

記憶體削減: 對 BF16 格式的 70B 模型，基底權重佔 140GB。每個微調變體的增量若用完整 BF16，會再加 140GB。BitDelta 格式下，每份增量約佔 8.75GB（70B 位元 = 8.75GB，另加可忽略的 α 純量）。14 個變體的叢集從 14 × 140GB = 1.96TB 變為 140GB + 14 × 8.75GB ≈ 262GB——削減 87%。

服務架構

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

推論時，服務管線是：

1. 請求抵達，帶著 model: "zen4-coder"
2. 路由器定位 zen4-coder 的增量快取項
3. 即時重建有效權重：W_eff = W_base + α_coder · sign(Δ_coder)
4. 用重建後的權重做前向計算
5. 回傳回應

第 3 步是關鍵路徑。重建是一個融合 CUDA 核心，同時讀取基底權重和增量位元，在暫存器或共享記憶體中重建有效權重，而不把完整的 W_eff 具體化到 HBM。重建與矩陣乘法可以融進同一次核心執行——重建出的權重從不以獨立張量的形式完整存在。

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

融合核心把 HBM 頻寬峰值壓在基底權重的大約 1.5x——而不是 2x，因為增量以打包位元讀入，並在融合操作期間於快速 SRAM 中解開。

延遲概況

實務上，在 14 個變體的 Zen 服務叢集上：

變體	P50 首詞元	P99 首詞元	相對基線
zen4（基底）	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

BitDelta 重建帶來的首詞元時間開銷是 2-4ms——相對典型提示長度的預填成本可以忽略。重建核心受計算限制而非記憶體限制，因此能隨圖形處理器的代際良好擴展。

生成吞吐（詞元/秒）在基底模型與任一 BitDelta 變體之間相同，因為重建只發生在預填階段。KV 快取填滿之後，自迴歸生成步走標準矩陣乘法路徑。

品質：1 位元壓縮失去了什麼？

誠實的答案：很少，而且有仔細的上界。

BitDelta 的品質下降取決於任務。在微調資料中表現充分的任務上，行為增量很強——符號可靠地捕捉主導梯度方向。在微調分布邊緣的任務上，增量較弱——近似引入的雜訊相對訊號更多。

經驗上，在按其目標任務集評估的 Zen 模型中：

模型	全精度	BitDelta	差值
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%

主要任務集上 1-1.3% 的下降，是記憶體削減 87% 的代價。對所有 Zen 變體，這筆交換可以接受——品質差異低於典型用例中使用者能察覺的行為變化門檻。

MonoSoup：SVD 單一檢查點補足

MonoSoup（arXiv:2602.09689）處理一個互補問題：同一基底模型存在多個微調檢查點時，如何在不同時載入全部檢查點的情況下，把它們合併成一個檢查點？

MonoSoup 對任務向量（Δ = W_ft - W_base）做 SVD，找出捕捉最多行為資訊的低秩分量，再跨檢查點聚合：

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

在秩 r 處截斷 SVD 是一步去雜訊：微調傾向於沿權重空間中少數高變異方向修改模型。用截斷 SVD 捕捉這些方向再合併，能留下每個檢查點的行為要點，而不帶入較低奇異值方向上的雜訊。

我們在 Zen 訓練中把 MonoSoup 用作檢查點平均步驟：每 1000 個梯度步，用 MonoSoup 把目前檢查點與先前最佳檢查點合併，而不是直白平均。這降低訓練雜訊，損失曲線更平滑，最終品質更好。

K-Merge：面向邊緣的線上 LoRA 配接器管理

K-Merge（arXiv:2510.13537）解決服務問題的另一種形態：在邊緣，儲存被限制在固定預算 B GB 時，如何有效率地提供 K 個 LoRA 配接器？

K-Merge 維護一個已合併配接器池，約束是總儲存永不越過 B。當請求到一個不在池中的新配接器時：

1. 計算新配接器與池中每個現有成員的兩兩相似度（任務向量上的餘弦相似度）
2. 找出最相似的現有配接器
3. 經由 OPCM（正交投影合併）把新配接器併入最相似的那個
4. 若合併後的配接器在兩項任務上的品質都超過門檻，則剔除原來的配接器，存下合併版本

該策略保證池中至多有 K 個配接器、佔用預算 B，同時透過有原則的合併，最大化對所有被請求配接器的覆蓋。

對 Zen 的邊緣部署（Hanzo Desktop 與行動端），K-Merge 讓本會超出裝置儲存上限的模型族可以在本地提供。一台有 16GB 可用模型儲存的裝置，可以靠按需合併相似配接器的 K-Merge 池，提供 8 種不同的行為輪廓。

基礎建設細節

增量儲存格式: 1 位元符號矩陣以打包的 int8 張量儲存（每位元組 8 位元，因此一層 70B 參數、權重為 4096×4096 的層打包成 4096×512 的 int8）。α 縮放因子以 float32 儲存，每個輸出維度一個，合計約為增量儲存的 0.1%。

冷啟動行為: 當某個變體的增量不在圖形處理器 SRAM 快取中（例如該變體已有 10 分鐘未被請求），第一個請求要為 70B 模型支付大約 200ms 的增量載入延遲——以 NVMe 循序讀速度把 8.75GB 從 NVMe 傳到 HBM 的時間。第一個請求之後，增量留在圖形處理器 SRAM 的增量快取裡，直到被 LRU 策略剔除。

快取剔除策略: 帶請求率加權的 LRU。高請求率變體被釘選；低流量變體可以被剔除。實務上，按流量排前 6 的變體始終駐留快取；其餘 8 個用 LRU 剔除共享剩餘快取空間。

請求路由: 服務路由器追蹤每個變體的在途請求，並避免佇列前端阻塞：若 zen4-coder 的增量正在載入，後續的 zen4-coder 請求排隊，而不是各自觸發獨立載入。

結果：14 個 Zen 模型變體由 8x H100 節點提供，而同等能力此前需要 112x H100 節點。基礎建設成本的下降不是漸進的。BitDelta 讓多租戶模型族在經濟上可行。

---

Zen 模型可於 zenlm.org 取得。API 存取見 hanzo.ai。