BitDelta：一つのGPUクラスタから14種のZenモデルを配信

微調整したモデル変種を配信する経済性は、初期状態では不利です。

BF16 の 70B パラメータモデルには 140GB の GPU メモリが要ります。そのモデルの微調整変種が 14 あると — それぞれ別の能力プロファイル、領域特化、または振る舞いの調整です — 素朴な配信構成は 14 回の別ロードを要します。GPU メモリは 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 ビット、正か負、に落とします。スケール係数 α が大きさを戻します。合わせると、この近似は微調整更新の方向情報を、全精度差分の保管コストの 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 で、典型的なプロンプト長のプリフィルコストに比べれば無視できます。再構成カーネルはメモリ律速ではなく計算律速なので、GPU の世代が進むほどよく伸びます。

生成スループット（トークン/秒）は基底モデルとどの 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. 融合後のアダプタの品質が両方のタスクで閾値を超えたら、元を追い出し、融合版を保管する

この方針は、プールが予算 B を使うアダプタを高々 K 個に抑えつつ、原則に沿った融合で要求された全アダプタの被覆を最大にします。

Zen のエッジ配備（Hanzo Desktop とモバイル）では、K-Merge によって、そうでなければ装置の保管上限を超えるモデル族をローカルに配信できます。モデル保管が 16GB 空いている装置は、似たアダプタを要求時に融合する K-Merge プールで、8 種の異なる振る舞いプロファイルを配信できます。

基盤の詳細

差分の保管形式: 1 ビットの符号行列はパックした int8 テンソルとして保管します（1 バイトあたり 8 ビットなので、重み 4096×4096 の 70B パラメータ層は 4096×512 の int8 にパックされます）。α のスケール係数は float32 で、出力次元ごとに一つ保管し、合計は差分の保管のおよそ 0.1% です。

コールドスタートの振る舞い: 変種の差分が GPU の SRAM にキャッシュされていないとき（例えばその変種が 10 分要求されていない）、最初のリクエストは 70B モデルでおよそ 200ms の差分ロード遅延を払います。NVMe の逐次読み速度で 8.75GB を NVMe から HBM へ移す時間です。最初のリクエストのあと、差分は LRU 方針で追い出されるまで GPU SRAM の差分キャッシュに残ります。

キャッシュ追い出し方針: リクエスト率で重みづけた LRU です。リクエスト率の高い変種は固定し、流量の低い変種は追い出しの対象です。実際には、流量上位 6 変種は常にキャッシュに駐在し、残る 8 変種が残りのキャッシュを LRU 追い出しで分け合います。

リクエストの経路制御: 配信ルータは変種ごとの処理中リクエストを追跡し、行頭ブロックを防ぎます。zen4-coder の差分をロード中なら、届く zen4-coder のリクエストは各自が独立したロードを起こすのではなく列に並びます。

結果として、14 種の Zen モデル変種を 8x H100 ノードから配信します。同等の能力には以前は 112x H100 ノードが要りました。基盤コストの低下は漸進的ではありません。BitDelta はマルチテナントのモデル族を経済的に成り立たせます。

---

Zen のモデルは zenlm.org で利用できます。API は hanzo.ai です。