770 GB 检查点同步从36秒压到15秒：Baseten把父版权重留在GPU上，暂停只剩0.8秒
核心概要
Baseten 把增量权重同步的父本从主机内存搬回 GPU，使约 770 GB 的 GLM-5.3 检查点同步从 36 秒、6 秒请求暂停降到 15 秒、0.8 秒暂停，吞吐最高提升 3.2 倍。此前每个副本要在主机内存保留完整父本，8×B300 节点上它与 1.1 TB 主机 KV 缓存无法共存，缓存只能缩到 275 GB。新路径只读取发生变化的 GPU 位置，并用增量校验和验证后再写入。
深度剖析
增量权重同步不再需要在主机内存里保留一份完整的父本检查点，GPU 显存成为唯一父本。 此前每个副本都在主机内存保存完整父本，约 770 GB 的 GLM-5.3 在 8×B300 节点上与 1.1 TB 主机 KV 缓存无法共存，缓存被迫缩到 275 GB，且每次更新要把 CPU 副本提升为新策略，耗时约 45 秒并阻塞下一个增量。 同一份约 770 GB 的 GLM-5.3 检查点，同步时间从 36 秒降到 15 秒，请求暂停从 6 秒降到 0.8 秒，吞吐提升最高 3.2 倍。
解码器只处理发生变化的字节，不再生成稠密的 XOR 张量，也不读取模型权重。 旧设计需要主机内存中的父本把 XOR 字节还原成新值，并在每次更新后修补这份副本，形成 GPU 与 CPU 两个事实来源。 启动时从本地磁盘加载模型、按引擎实际 GPU 布局校验每个对外服务的张量并记录逐张量 Adler-32 校验和，随后删除该副本；增量到达时直接遍历 zstd 命令，只保留非零 XOR 字节的位置与掩码。
增量校验和可以按变化字节逐个修正，无需重新哈希整个张量。 朴素做法是对整个张量重新计算 Adler-32，开销随张量大小增长。 从启动时记录的校验和出发，每个变化字节按位置、旧值和新值加一次修正，再与训练端发布的校验和比对；该优化使整个更新最多快 2.3 倍，Kimi K3 的 30 GB 增量从约 230 秒降到约 100 秒，损坏下载或错误父本会在任何 GPU 写入前被拒绝。
省下的主机内存转为 KV 缓存卸载，长前缀的智能体负载因此受益。 在并发 16 时 KV 缓存本就装得进 GPU，卸载没有差别；并发 48 时智能体前缀超出 GPU 显存但装得进主机内存。 Kimi K3 在 AgentX 基准上，并发 48 时缓存命中率从 2% 升到 92%，每 GPU 输出吞吐提升 3.2 倍；从主机内存重载被逐出的 15 万 token 前缀耗时 0.48 秒，而重新预填充需 4.9 秒。
启示与展望
演示范围是单副本、使用训练端形状的固定增量，计时从训练端发出增量同步请求到副本开始服务新策略；模型为约 770 GB 的 GLM-5.3 与 1.7 TB 的 Kimi K3，后者跑在两个各四卡的 GB300 节点上。
文中说明所有运行都是单副本、使用训练端形状的固定增量，计时从 S3 标记到第一个新响应；并发 16 时 KV 缓存卸载没有带来差别，收益只在并发 48 这类前缀超出 GPU 显存的设置中出现。