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。