穿越者必备：一台手机装下现代文明，在古代直接开挂

2026-09-09T00:00:00+00:00

假如明天一睁眼，你穿越到了古代。

没有电网，没有互联网，没有搜索引擎，更没有云端大模型。你背不出《天工开物》，记不住怎么轮作，也分不清发酵失败和正常起泡。脑子里那些“我好像在短视频里看过”的现代知识，真到要用的时候，十有八九只剩一句：这东西到底怎么做来着？

别人穿越带打火机，你带一台装有 zllm-app 的手机。

手机里完整装着 MiniCPM5-2B。模型权重就是知识本身，不需要网络，不需要服务器，不需要提前准备问题清单。种粮、制肥、酿酒、翻译、建水车、办工坊、训练队伍，想到什么就问什么。

再带一块折叠太阳能板和一个充电宝：白天晒太阳，晚上召唤现代文明。

这不是穿越，是开管理员权限。 </video>

屏幕上先敲下一句穿越开局题，MiniCPM5-2B 当场把种粮、制肥、酿酒和队伍训练铺成路线图；紧接着再敲一句中文，英语、日语、韩语同时到手。飞行模式也拦不住，因为整个答案都从手机里长出来。

先把神器装进口袋</h2> zllm-app 0.1 SM8635 预览版 APK（8.7 MB）</a>
SHA-256：d3cbc48b928da4932cea37c4538dc0ed687336b1c4d5d93d18692b3f92d2cb5a</code>
这是可直接安装的技术预览版。APK 不把 2B 模型硬塞进安装包：首次启动会自动从 Hugging Face 或魔搭择快下载约 2.6 GiB 核心模型，支持断点续传和 SHA-256 校验。模型就位后，断网也能继续对话。
当前机型限制</h3> 项目</th> 当前支持边界</th></tr></thead> 已完整验证机型</td> Motorola XT2451-4</td></tr> SoC / NPU</td> Qualcomm SM8635（骁龙 8s Gen 3）/ HTP V73</td></tr> 内存</td> 12 GB 已验证；更低内存暂不支持</td></tr> 系统与 ABI</td> Android 16、arm64-v8a 已验证</td></tr> 存储</td> 核心模型约 2.6 GiB，建议至少预留 4 GiB</td></tr> </tbody></table> 当前模型包和 QNN context 图是针对 SM8635 / HTP V73 构建的。其他骁龙机型、其他 HTP 版本、联发科、三星或麒麟平台目前均不在支持范围内。神器已经出世，但这一版先只认这块 NPU。 现代文明，不在云端，就在模型权重里</h2> 大多数 AI App 离开网络就只剩一个输入框。zllm-app 不一样：MiniCPM5-2B 的权重、tokenizer、对话模板和推理引擎全部在手机本地。 你问一句，手机自己算；模型答一句，答案直接从本地生成。问题不用发给任何服务器，回答也不需要从千年后的互联网传回来。 文字 ───────────────────────┐ ↓ 语音 → SenseVoice 本地识别 → MiniCPM5-2B ↓ 高通 HTP/NPU 推理 ↓ 流式回答、自动保存 </code></pre> 只要手机还能亮，知识就还在。 我们真的把它跑在了高通 NPU 上</h2> “手机里跑大模型”最容易写成一句宣传语，真正做起来却是一场硬仗。 这次真机是一台 Motorola XT2451-4，搭载 SM8635、12 GB 内存和 HTP V73，运行 QAIRT 2.38。我们没有把模型扔给 CPU 慢慢磨，而是正面接入 Qualcomm QNN：动态加载 libQnnHtp.so</code>，创建 backend、device、context 和执行图，把 MiniCPM5-2B 的核心计算送进手机 NPU。 最终，embedding、42 层 Transformer、final norm 和词表投影全部在 HTP 上跑通。SenseVoice-Small 的 encoder 和 CTC head 也进入 HTP：按住麦克风说话，手机先在本地把语音转成文字，再把问题交给 MiniCPM5-2B，答案一边生成一边显示。 中间踩过的坑足够写一本小册子： 固定前缀的 activation outlier 把量化范围拉歪，42 层 K/V 误差一度完全不可接受；</li> QNN 在这套硬件和 SDK 上不能直接使用我们原本期待的 S32/F16/F32 输出路径，只能重新设计 S8 输入、S8 输出和 scale 还原；</li> 全 INT4 很快，却在长生成中跑偏；全 INT8 质量稳，却只有 8.97 tok/s；</li> DSpark 推测解码成功跑通，但 draft 接受率不够，5.723 tok/s 反而比普通 decode 更慢；</li> 每次重新加载 43 张图，光启动成本就要几秒，最后给 decode 和 ASR runner 加上常驻模式，让图只加载一次。</li> </ul> 最终的 2B INT8 方案，长回答实测约 8.7–9.8 tok/s。常驻图复用后，App 内第二问从 14.1 秒降到 9.65 秒。长输入超过阈值时，再由 AR8 批量 prefill 接管；831-token 新会话从原来的 95–143 秒缩短到 36.9 秒。 这不是 PPT 里的“支持 NPU”，而是一部真实手机、一套真实 QNN 图、一条从输入框到流式回答的完整链路。 第一问：穿越第一周，怎么活下来？</h2> 别人刚穿越，先吟诗、认亲、找靠山。你打开 zllm-app，先解决真正重要的事：饮水、食物、住处、安全、当地气候和权力结构。 几秒之后，手机给出第一天、前三天和第一周行动表。 别人还在研究自己是哪朝哪代，你已经开始建立根据地。 第二问：怎么让粮食翻倍？</h2> 古代真正的硬通货不是金银，是粮食。 你不需要背下一整套农学教材，只要告诉 zllm-app：这里是什么气候，地里种什么，什么时候播种，叶子是什么颜色，去年收了多少。它会替你把问题拆开：选种、育苗、轮作、堆肥、排水、密植、除草、虫害、收割、晾晒、仓储。 第一年，你让农户留下对照田，记录每块地的播种量、肥料和收成。第二年，经验不再靠“老辈人说”，而是变成一张张能比较的账。哪种种子产量高，哪种堆肥有效，哪块地容易积水，全部有据可查。 别人靠天吃饭，你开始做农业实验。 当粮食稳定增长，你就不只是养活自己。你能养活工匠、商队、护卫和一座正在扩张的城。 第三问：没有化肥厂，怎么做肥料？</h2> 穿越者不可能第一天手搓一座化工厂，但你有模型，就知道技术树该从哪里点。 先从腐熟堆肥、绿肥、轮作、豆科固氮、草木灰和排水开始；再根据作物表现区分缺氮、缺磷、缺钾；每次只改一个变量，做小块对照，记录投入与产量。 最可怕的不是你会背某个配方，而是你知道怎样试验、怎样排错、怎样把偶然经验变成可复制的方法。 一个村学会，十个村照做；十个村做成，整片土地的产量都开始上涨。 这才是知识真正的威力。 第四问：粮食多了，怎么酿酒、制醋、保存食物？</h2> 农业有了余粮，发酵就是下一棵科技树。 温度、卫生、容器、时间、批次记录——zllm-app 会把看似玄学的“祖传手感”拆成流程。哪一批酒用了什么原料，什么时候入缸，什么时候起泡，什么时候出现异味，全部记下来。 稳定的酒能贸易，醋能调味和加工食物，发酵技术还能继续延伸到酱、腌菜和长期储藏。 别人家酿酒靠运气，你的工坊开始做质量管理。 第五问：语言不通？手机就是你的鸿胪寺</h2> 穿越不一定落在中原，也可能掉进商路、边城、港口，甚至一个完全听不懂当地话的地方。 这时候，翻译不是锦上添花，是保命技能。 MiniCPM5-2B 的真机质量回归已经覆盖翻译小样本；语音前端 SenseVoice-Small 支持中文、英文、日语、韩语和粤语，中文、英文、粤语都通过了手机端 HTP 转写门禁。你可以让对方对着手机说，再让 zllm-app 整理含义、翻译成自己的语言，还能把回信改写成更礼貌、更正式或更适合交易的版本。 别人遇到异族商队只能比手画脚，你能谈价格、问路线、读契约、写回信。 一台手机，就是翻译、书记官和外交顾问。 商路从此不再是地图上的线，而是你的情报网、贸易网和人才网。 第六问：古代怎么练出一支强军？</h2> 真正决定一支军队战斗力的，从来不只是武器。 zllm-app 给你的，是一整套组织系统：十人一组、逐级负责；统一口令、队列和集合时间；固定训练体能、负重、行军、警戒、救护和撤离；建立粮秣清点、装备登记、伤病记录和奖惩制度；每次行动结束必须复盘。 别人练兵靠将领当天心情，你开始使用标准训练表。 别人行军走散、粮草不明、命令传错，你的队伍知道谁负责谁、物资在哪里、出了问题向谁报告。平时能修堤、救火、护粮、搬运；战时令行禁止，不会一声锣响就乱成一团。 你带去的不是某一种神兵利器，而是现代组织学。 这东西比神兵更可怕。 一部手机，就是一棵完整的科技树</h2> 穿越者最容易犯的错误，是一上来就想造蒸汽机。 真正的发展顺序是：先解决水和粮食，再建立记录与度量；有稳定余粮后组织工匠；有工匠后改进农具、窑炉、水车和作坊；有剩余产能后再发展冶炼、机械、交通和教育。 你手里的资源</th> 下一步可以做什么</th></tr></thead> 一块地、一些种子</td> 轮作、育苗、堆肥、对照田、储粮</td></tr> 粮食开始富余</td> 酿酒、制醋、食品加工、建立仓储</td></tr> 能接触不同语言的人</td> 翻译、贸易、外交、搜集技术</td></tr> 有木匠和铁匠</td> 改农具、做水车、统一零件尺寸</td></tr> 有稳定税粮</td> 养工匠、办学堂、建道路、训队伍</td></tr> 有成熟工坊</td> 发展冶炼、机械、印刷与规模生产</td></tr> </tbody></table> 模型不是替你凭空造出机器，而是让你永远知道：目标是什么，原理是什么，缺什么条件，先做哪一步。 穿越者真正的外挂</h2> 一台手机，MiniCPM5-2B，zllm-app，高通 NPU，再加一块折叠太阳能板。 没有网络，照样问答；没有云端，照样生成；说一句话，SenseVoice 在本地识别；答到一半退出，会话和 KV 还能保存；换一个话题，可以另开一条完全独立的对话。 别人穿越，知识全靠脑子里那点模糊印象。 你穿越，口袋里装着一位不会睡觉的农学顾问、工艺顾问、翻译、历史老师、组织教官和技术总监。 从第一口干净的水，到第一亩高产田；从第一缸稳定的酒，到第一支令行禁止的队伍；从第一次跨语言交易，到一整套不断向前滚动的技术体系——所有问题，都可以从手机屏幕上的一句话开始。 这就是 zllm-app。 完全离线，把现代文明装进口袋。 真要挑剔，这件穿越神器还差最后一块拼图：TTS。等它能把答案直接念出来，手机里这位现代军师就不只能为你写策，还能当场开口。 不过也好。 神器，不可轻易示人。 这一声，就留给下一个版本。 从总共 1M 到 15+ 路 × 1M：GLM-5.3 KV Cache 换出的容量突破 2026-09-08T00:00:00+00:00 **这次优化最大的收益，是把原来总共约 1M token 的上下文容量，推向 15+ 路、每路 1M token 历史同时 decode 的规模。**同一套 GPU，能够同时承接的长历史容量朝着 15+ 倍扩展。 原来，一份百万 token 的长对话就可能吃掉整套系统的上下文预算。现在，每台机器的 1 TiB 主机内存开始承接 MLA 历史，GPU 留下 32K 热缓存供当前计算使用。我们要支持的是多位用户各自带着百万 token 历史持续生成，而不是只把结束的会话存下来。 **15+ 路 × 1M 是本轮的容量估算规模，尚不是已经完成的并发性能实测。**下文会展开它的内存账；近乎无损的速度结论来自已经完成的 50K 对照。这两项成果分别回答“能承接多少历史”和“换出会损失多少速度”。 我们做到了一个有明确验收范围的结果：固定 50,023 token 输入、1,024 token 输出，保留 32K GPU 热缓存，MLA 历史换到主机内存后，MTP=3 三组对照的吞吐损失为 0.15%–1.30%；不开 MTP 的三组对照略快约 2%。所有完整输出都与各自基线一致。 这个结果来得并不直接。最初我们想把索引计算也交给 CPU，后来退回；热缓存一度损失约三成速度；几次局部优化看起来很有道理，完整模型却没有变快；最后那一点不稳定，又把我们从 attention kernel 带到了 Linux 内存管理和 GPU 驱动。 这篇文章按决策的形成过程展开：为什么走一条路，什么证据让我们保留它，又是什么证据迫使我们转向。 起点：把容量和当前计算的工作集分开</h2> 硬件沿用上一篇 GLM-5.3 优化文章</a>的双机系统：每台 8 张 AMD Radeon PRO W7900D，单卡 48 GiB，EPYC 9334 平台，每台 1 TiB RAM。节点内使用 HIP P2P，节点之间通过 TCP 传递层段边界的 activation；没有 XGMI。 这次改变的是 KV 的放置。权重和每层计算仍留在负责它的设备，历史数据也留在对应节点的主机内存中。 机会来自 GLM-5.3 的稀疏注意力路径：DSA 索引器从历史中选出 Top-2048 位置，MLA attention 消费选中的 KV。部分后续层复用 selection，但各层仍有自己的 KV 内容。 因此，全历史需要保存的规模，与一轮 attention 真正消费的规模，可以分开管理。 本次 Q8G64 MLA 每行包含 512 B latent、16 B scale 和 128 B RoPE 数据，共 656 B。原始工程记录的容量账如下；它只计算 MLA 数据，不含 DSA、MTP 层、元数据、对齐或 scratch。 对象</th> MLA 数据大小</th></tr></thead> 50,000 token，单层单副本</td> 31.281 MiB</td></tr> 50,000 token，78 个主模型层、两份副本合计</td> 4.765 GiB</td></tr> 一层选中 2,048 行，单副本</td> 1.28125 MiB</td></tr> 32,768 行热缓存，单层单副本</td> 20.5 MiB</td></tr> </tbody></table> 单份 50K 历史还不惊人，但它会随会话数量和长度累积。我们的目标是让 GPU 上主要的 MLA 历史存储被热缓存容量约束，增长部分由 RAM 承担。 这里的“热缓存”也不是只保留最近 32K token 的滑动窗口。**旧位置仍保存在 RAM，DSA 仍可以选中它们；缓存未命中时再读取。**它改变物理位置，不主动截断模型可访问的历史。 第一次决策：CPU 既存历史，也做 Indexer？</h2> 最初的方案相当自然：主机有大量内存和 CPU 核心，既然历史准备放在 RAM，就让 CPU 完成全历史打分和 Top-K，再把选中的 KV 送给 GPU。 这样还有一个调度上的诱惑：得到 selection 后，后续复用选集的层可以提前搬运历史 KV，与 GPU 的独立工作重叠。 我们已有 CPU Q8 打分、blocked 布局和向量化实现，于是补上固定 worker team、局部直方图、Top-K 工作区复用、增量 mirror、回滚和预取。这条路值得验证，不能只靠“CPU 比 GPU 慢”就否定。 真机结果却给了两个独立的否定理由。 第一是速度。50K 测试中，GPU 基线约 14.03 token/s，CPU DSA 候选只有 10.92–11.32 token/s。CPU 算术之外，query 回传、线程协调、选集上传和 GPU 等待也进入关键路径。历史上 131K 的 CPU 测量不能简单乘以 50/131</code>，因为活跃 worker 数也随上下文改变。 第二是正确性。CPU Q8 query 的最终选集与 GPU BF16 query 的精确路径存在 cutoff 差异，固定贪心输出发生分叉。CPU 内部计算自洽，并不等于它与原 GPU 路径等价。 决定：保留 GPU exact DSA，关闭 CPU selection；继续推进 MLA 历史的 RAM 驻留。 这次退回缩小了问题。存储容量扩展可以独立成立，不必等 CPU 索引路线成功。提前预取仍是有价值的重叠机会，但不能预先记成零开销。 第二次决策：先让 CPU 管理 GPU 热缓存</h2> 保留 GPU selection 后，早期热缓存路径仍需要把选集交回主机：CPU 查映射、判断命中、整理缺失行，再提交上传和 GPU attention。 这条路首先验证了容量方向，但性能很差。2026 年 9 月 7 日的早期战役中，真实 32K 热缓存配置经历 packed 复制和批量 mirror 修正后，三轮中位仍约 10.41 token/s。该阶段报告相对其参考值约慢 29%；这些早期数字包含不同诊断条件，不能与后文最终验收直接拼成严格 A/B。 这里先暴露了两个具体问题。 **一个是换出分支丢掉了原来的压缩复制路径。**此前 owner 量化一次，再把每行 656 B 的 packed KV 复制给 peer。进入热缓存后，fallback 变成两端各自 append、重新量化，也损失了原有通道重叠。于是先把 packed 复制接回热缓存。 **另一个是小传输的次数。**逐层、逐 token 更新主机镜像，78 层的 owner 与 peer 合计可以产生 156 次流操作。尝试把每行分成三段并增加在途传输后，操作数变为 468，性能反而退到约 8.8 token/s。 这个实验否定了“增加异步并发就能解决传输成本”的直觉。数据本来就很小，更多提交可能比更多字节更贵。 改成每 64 行批量回传后，操作数量大幅下降，全量缓存阶段确实改善。但进入真正热缓存后，仍有明显差距。 随后我们尝试把 peer 镜像维护移入 worker 锁段，又让 append kernel 双写连续日志。三轮中位分别约 10.39 和 10.06 token/s，没有得到预期的量级收益。 **决定：保留批量日志和必要的生命周期修复；撤回“锁迁移、日志双写足以解决主要差距”的判断。**实现完成与性能假设成立，需要分别验收。 一次必须承认的误判：占比最高，不等于回退来自那里</h2> 我们曾给热缓存 attention 加同步 trace。测得的总时间里，kernel 占 77.4%，主机锁与 remap 约占 22%。当时据此判断：剩余问题主要在窗口 attention kernel。 后续复核推翻了这个归因方法。 这份 profile 测的是候选自身的绝对时间构成，没有证明 GPU 常驻与换出之间的差额发生在同一位置。常驻路径本来也要执行 attention。另外，同步与 trace 把完整运行压到约 4.21 token/s，已经明显改变了原有提交和重叠关系。 据此提出的 selected gather 方向，检查源码时又发现已有相关实现。需要验证的是实际热路径和依赖，不能把已有机制重新当作待实现方案。 我们调整测量方法：诊断只用来定位，正式性能关闭 profile、trace 和额外同步；每个候选配同版本 GPU 基线，完整输出一致后再比较吞吐。需要归因的始终是两条路径的差额。 第三次决策：让 GPU 直接管理热缓存</h2> 新的证据把注意力带回提交链：GPU 已经算出 selection，却要让 CPU 等待回读，再做映射和打包，才能继续提交 attention。一次选集回传的主机等待曾达到约 0.7–1.2 ms；其中包含此前 GPU 排队，不能把它全算成复制时间，但它确实暴露了控制往返。 于是改变缓存管理的位置。选集留在 GPU，GPU 直接查热槽；命中读显存，未命中读已注册的 RAM mirror，形成当前 attention 使用的紧凑选集。 GPU exact DSA ──→ 历史位置 selection │ ▼ GPU hot gather ├─ 命中：读显存热槽 本节点 RAM 历史 ────└─ 未命中：读注册的主机内存 │ ▼ 紧凑 KV → GPU attention 新增 KV → GPU recent 环 → 分批回传 → RAM 历史 </code></pre> 主机内存因此承担历史容量，GPU 保持索引、缓存查找和 attention 的连续执行。CPU 仍负责资源与生命周期管理，但不再为每次 selection 主持一轮查表和搬运。 它也没有让 PCIe 读取免费。早期某些采样窗口 miss 不到 1%，说明这个负载具有缓存复用机会；不能由此保证所有输入都有相同命中率。 最初 GPU 管理版本约 11.72 token/s，仍有首次注册停顿。提前注册并补齐多行路径后，甚至有一轮退到 5.13 token/s。我们继续保留方向，但不把“稳态事件间隔接近常驻”当作完整吞吐通过。 GPU 管缓存也会犯错：跨 block 可见性与置换长扫描</h2> MTP 把单行路径里不明显的问题放大了。一次 verify 会处理多行，多个 query 可能选到同一个缺失位置。 早期实现允许同一次 gather 内，一个 block 读另一个 block 刚填的热槽。真实 MTP 测试出现异常 scale，随后没有有限的可选 token。 我们把可见性边界收紧：**本轮新填的槽，到下一轮才作为命中来源；同轮重复 miss 直接读取 RAM。**本轮正在使用的槽先 pin，新增但尚未回传到 RAM 的 token 则由 recent 环保护。 之后完整 1,024-token MTP 输出与同版本常驻一致，但吞吐只有 16.175 对 27.530 token/s，仍慢约 41.2%。两边接受的 draft 都是 665 个，差距不能归因于 MTP 接受率。 接下来把小批 verify 也接回 owner→peer packed KV 复制，候选升到 20.035 token/s。这是值得保留的完整执行路径修复。 缓存置换又带来一个反直觉结果。使用带引用位的时钟置换时，在“热窗已满、引用位全部置位、只有 1% miss”的合成压力形态下，少数 miss block 要负责长距离清扫，gather 达到约 1.03–1.07 ms。miss 更多时，反而可能因参与清扫的 block 增多而更快。 改成跳过当前 pin 槽的环形替换后，同一探针降到约 0.032 ms（2,048 行）。但是完整 MTP 运行只有 19.767 token/s，没有体现探针的巨大收益。 决定：保留更简单的置换实现，消除已证实的压力形态；否定“这个局部热点就是完整差距”的推断。 第四次决策：离开 attention，检查提交线程在做什么</h2> 缩小到活跃 decode 线程的 CPU 采样，发现约 21.1% CPU cycles 落在主机 memcpy。调用链最终落到只读 MoE 权重对象的 clone</code>：每次向 worker 提交工作，都可能深拷贝 Dense router。 这与 KV 的语义无关，却真实地影响了同一条执行链。修复让只读权重组通过 Arc</code> 共享，保留算子和权重数值。 我们也给 GPU 常驻基线加入同一修复。v15 同版本 MTP 对照达到 25.425 对 26.832 token/s，损失收窄到 5.24%。这是显著改善，但仍略超 5% 门槛；21.1% 的 CPU 采样占比也不能换算成等比例端到端收益。 后续继续复用 recent 环承载 peer 日志，省掉重复复制；移交 prefill 已有的缓冲，减少热缓存切换时的分配与释放；小日志用 compute 拷贝和打包，减少 DMA 队列操作。 这些改变没有一次性解决问题。某轮 no-MTP 进入 4.80%，下一轮 MTP 又损失 9.87%。日志里不断出现 0.6–1.2 秒的长停顿，即使大多数事件间隔已经接近常驻。 我们没有删掉前 128 个 token，也没有只取 p50 来宣布完成。用户实际等待的这些停顿必须计入原有完整 decode 口径。 第五次决策：从慢 kernel 追到操作系统页迁移</h2> 设备时间线显示，长停顿未必落在 hot gather。一次采集中 gather 最大只有约 0.054–0.056 ms，却有约 792 ms 的同步等待，整条流水线几乎没有设备工作。 这时，把 profiler 中一个被拖长的 kernel 名称当作根因，会再次走错路。我们开始对齐两台机器的系统设置与驱动行为。 关闭 NUMA 自动平衡：方向正确，证据还不够</h3> 发现 Amd-1 的 kernel.numa_balancing=0</code>，Amd-2 为 1</code>，长停顿集中在后者。统一关闭后，第一组 MTP 损失只有 0.51%，看起来已经成功。 但第三组交错复测损失 5.49%，门禁停止。决定保留系统设置一致性，继续寻找剩余长尾，不用平均值掩盖失败组。 预先写入注册范围的尾页：一个被实验否定的解释</h3> 另一个假设是：RAM mirror 预留容量中的尾页尚未实际写入，后续追加首次触页影响了 GPU 映射。于是注册前把 spare capacity 写零，保持有效 KV 字节和逻辑长度不变。 该候选仍出现 7.35% 损失和秒级间隔。预触页没有解决稳定性，不能把它写成最终根因。 主动内存整理：终于取得调用链证据</h3> 进一步使用 BPF 对齐实际推理进程、失效地址和恢复 worker，捕获到这样的路径： kcompactd → proactive_compact_node → migrate_pages → try_to_migrate_one → amdgpu_hmm_invalidate_hsa → 相关队列恢复工作 </code></pre> 这次证据确认了主动页整理、HMM 失效与队列恢复路径。失效地址采样中，大量事件并不与显式注册的 KV mirror 相交，所以也不能再把它们解释为“KV 尾页首次写入”。这次采样没有复现之前完整的一秒停顿，因而我们没有声称每次长停顿都已逐一归因。 两台机器随后将 vm.compaction_proactiveness</code> 从 20 调为 0，NUMA 自动平衡保持关闭。Linux 官方文档说明，0 会关闭主动整理，页迁移可能造成应用延迟尖峰；本次因果判断还要靠同设置下的完整对照。Linux 内核文档</a> 这些是实验机的运行时调整，原值和恢复命令均留档，没有修改开机配置。它们属于这次验收条件，不能省略，也不能当作所有 GPU 机器通用的调优配方。 六组交错对照：到这里，才肯定“近乎无损”</h2> 最终使用同一 v23 二进制，固定 50,023 输入、1,024 输出、greedy seed01。换出组启用 32,768 行热缓存，对照组保持 GPU 常驻；双方关闭 NUMA 自动平衡与主动 compaction，关闭 profile、trace、attach 和 CPU DSA。 每次重新启动实验运行时，交错安排常驻与换出顺序。吞吐沿用首个文本事件至 SSE DONE 的原有口径，没有删除停顿。 模式</th> 组</th> RAM 历史 + GPU 热缓存（token/s）</th> GPU 常驻（token/s）</th> 换出吞吐损失</th></tr></thead> MTP=3</td> 1</td> 27.839</td> 27.883</td> 0.157%</td></tr> MTP=3</td> 2</td> 27.923</td> 27.966</td> 0.150%</td></tr> MTP=3</td> 3</td> 27.738</td> 28.102</td> 1.297%</td></tr> no-MTP</td> 1</td> 14.042</td> 13.788</td> −1.846%</td></tr> no-MTP</td> 2</td> 14.029</td> 13.753</td> −2.007%</td></tr> no-MTP</td> 3</td> 14.029</td> 13.747</td> −2.056%</td></tr> </tbody></table> 全部 12 个请求完成，完整输出文件 hash 与各自模式的参考一致。负损失表示换出略快；我们把它理解为这套负载下基本打平，不把它外推成换出必然加速。 这个结果支持的是单路长历史 decode。初始 prefill、追加输入、多会话容量和并发吞吐还需要各自验证。 容量优化必须通过会话生命周期</h2> 一次连续生成跑通，还不足以支撑真实对话。用户会继续追加输入，MTP 会拒绝草稿并回滚，会话还会保存和恢复。 成功路径的完整性边界是：新增 KV 可以先在 GPU recent 环和在途回传中；**导出或恢复全量历史之前，必须补交日志、等待回传，并确认 CPU 行数追上逻辑行数。**不能把已提交的异步复制当作已经落入 RAM。 大段 append prefill 又与 decode 不同。一次要处理大量新行，当前实现会先从 RAM 恢复所需全历史 GPU MLA KV，完成追加，随后 decode 再转回热缓存。小尾块不能被误判成 verify，owner 和 peer 也必须保持一致。 第一次真实大段 append 没通过，暴露的却是 MTP terminal hidden：收尾保存了原始 BF16 残差，后续路径期待 final norm 后的 F32 hidden。修复统一了归一化边界，并处理旧缓存恢复。 v25 随后完成同版本对照：命中 50,085 行历史，追加 9,854 token，最终 prompt 为 59,939 token，生成 1,024 token。完整输出一致。 大段 append 对照</th> 换出</th> GPU 常驻</th></tr></thead> 首 token 时间</td> 17.905 s</td> 18.350 s</td></tr> Decode</td> 26.850 token/s</td> 27.004 token/s</td></tr> </tbody></table> 单组 decode 损失 0.57%。这说明换出后的长对话可以继续追加，但它仍是单组追加验收，不替代前面的六组单路测试。 十路实验：逻辑上省了显存，实际 allocation 仍能把卡撑满</h2> 准备十份独立 50K 历史时，第六份 prefill 在尾节点 OOM。1 Hz 采样最高约 47.98 GiB，还没有进入十路共同 decode。 问题在通用 GPU 内存池。小的长期 KV、热缓存和会话工作区，可以 best-fit 借到 prefill 释放的大块 allocation，并长期占住。逻辑上只用几十 KiB 或 MiB，物理上却可能扣留远大于此的空间；统计又只报逻辑字节，进一步低估占用。 因此我们给长期缓存分配加上精确容量限制，主要 KV/DSA 统计改用实际 allocation 大小，短期 activation 保留原池策略。测试先用大块污染内存池，再验证小热缓存不会占住那些大块。 修复后，v28 完成十份长历史及后续十路 append，整组实际吞吐 98.56 token/s，采样观察到的显存最高约 45.12 GiB。 接着调整并发调度：MTP 深度改为 1 后，完整请求吞吐到 125.26 token/s；每段 decode 合批上限从 4 改为 1，达到 145.67 token/s。后一组与前一组输入、完整输出及 usage 一致。多路工作可以持续推进流水线，单路有效的深推测和较大合批，不一定适合十路。 再单独放宽 A0 的已就绪工作合批上限，得到 145.28 token/s，基本持平，没有证据支持保留，因而撤去该改动。 这些并发数字按实际 completion token 总数除以整个 append 请求墙钟计算，包含请求首尾；没有把 SSE 文本事件数直接当成 token 数。十路结果也没有 GPU 全常驻的对应性能对照，不能用它宣称并发换出无损。最新并发候选尚需回归单路门禁。 容量收益：从总共约 1M，走向 15+ 路各自 1M</h2> 把收益落到使用场景上：原来的总预算约 1M token，如果一位用户带着百万 token 历史，这份预算就基本被占满。换出后，我们希望让 15+ 位这样的用户同时处于 decode，每一路都保有自己的百万 token 历史。 维度</th> 原来的容量口径</th> 换出后的容量估算目标</th></tr></thead> 所有活跃会话的历史总量</td> 约 1M token</td> 15M+ token</td></tr> 每路携带 1M 历史时的规模</td> 约 1 路</td> 15+ 路同时 decode</td></tr> MLA 全历史的主要存储位置</td> GPU 显存</td> 每节点 1 TiB 主机内存</td></tr> GPU 上的 MLA 历史数据</td> 随历史长度增长</td> 每路保留 32K 热缓存，按需读取旧位置</td></tr> </tbody></table> 这就是“容量几乎放开了”的工程含义：在相同 GPU 硬件上，把可承接的活跃长历史规模推向 15+ 倍。它扩展的是多会话的历史容量；15+ 路同时生成时的单路速度，仍由计算、索引、传输和调度共同决定。 15 路百万历史，RAM 装得下吗？</h3> 按本文相同的主模型 MLA 格式，取 1M = 1,048,576 token</code>，78 层、owner/peer 两份副本： 单路 1M 历史 = 1,048,576 × 656 B × 78 × 2 ≈ 99.94 GiB 15 路合计 ≈ 1,499.06 GiB（约 1.464 TiB）主模型 MLA 历史 两台主机 RAM 合计 = 2 TiB </code></pre> 这里必须按两台机器合计 2 TiB 计算，不能把全部历史算到一台 1 TiB 主机上。MLA 历史跟随所属层分散驻留；owner/peer 双副本已经包含在上述数字中，也不意味着每台都保存完整模型的全部历史。 以 15 路为例，主模型 MLA 历史合计约 1.464 TiB；按两节点近似均分，每台约 0.732 TiB。实际按各节点负责的层数分配，仍需逐节点核算余量。**从主模型 MLA 历史载荷看，15 路并没有用尽双机内存，容量可以继续向 15+ 路扩展。**这是编码尺寸推导的容量依据，尚不是整机内存峰值或最大并发路数实测。 与此同时，15 路的 32K 热缓存，主模型两份副本跨全部 GPU 的载荷合计约 46.85 GiB。这一项不随每路历史从 50K 增长到 1M 而同比增长，正是容量扩展的关键。 完整服务预算还要加上 GPU DSA 历史、token 映射、MTP 层、各会话工作区、分配与注册开销，以及 prefill/大段 append 恢复全历史时的瞬态显存。因此，RAM 能容纳这些 MLA 字节，是 15+ 路目标的容量基础，还不是整套系统在这个规模下的验收结论。 目前完成的速度与生命周期实测是：50K 单路近乎无损、约 60K 大段追加，以及十份 50K 长历史的完整并发请求。**下一步最有价值的容量验收，就是把每路历史推到 1M、把活跃路数推到 15+ 路，同时记录真实内存占用、首 token 延迟和持续 decode 吞吐。**当前的 1M admission 配置也要与新的总容量目标匹配。 最后留下的决策</h2> 路线或判断</th> 处理结果</th> 决定性证据</th></tr></thead> CPU 完成最终 DSA selection</td> 本轮退回</td> 速度下降，固定贪心输出分叉</td></tr> MLA 历史放 RAM，GPU 保留热工作集</td> 保留</td> 六组单路对照通过，完整输出一致</td></tr> CPU 主持每次 selection 的热槽管理</td> 主路径转向 GPU 管理</td> 回读等待打断提交链</td></tr> 增加更多逐行异步拷贝</td> 否定</td> 操作数增多，吞吐反而下降</td></tr> 批量日志、packed owner/peer 复制</td> 保留</td> 减少重复处理，补齐单行与 MTP 路径</td></tr> 锁迁移或日志双写足以填平差距</td> 否定</td> 实现后完整吞吐没有量级改善</td></tr> kernel 占比高，所以回退一定在 kernel</td> 撤回</td> 绝对占比不能解释常驻/换出差额</td></tr> 简化 GPU 置换</td> 保留，但不夸大收益</td> 压力探针明显改善，完整模型未同步提速</td></tr> 只读权重深拷贝改为共享</td> 保留</td> 同版本完整对照差距收窄</td></tr> 只关 NUMA 自动平衡就足够</td> 否定“足够”</td> 重复门禁仍失败</td></tr> 预触注册尾页就是长尾解法</td> 否定</td> 秒级停顿与 7.35% 失败组仍在</td></tr> 统一 NUMA、关闭主动整理后验收</td> 本机保留</td> 内核路径证据与六组交错对照支持</td></tr> 小逻辑 buffer 就等于小显存占用</td> 否定</td> 十路准备 OOM，实际 allocation 超额</td></tr> 并发时继续增加 A0 合批</td> 本次撤去</td> 完整吞吐基本持平</td></tr> </tbody></table> 这轮工程最值得复用的，是把历史容量、当前工作集和控制依赖分别处理。RAM 提供容量，GPU 热缓存维持局部访问，GPU 自己消费 selection，批量日志维护新增历史；主机和驱动的内存行为，也必须进入端到端测量。 每一次转向都有一个共同标准：完整请求有没有变好，输出是否一致，失败能否复现。沿着这个标准，我们才把“旁边还有 1T 内存”的硬件余量，变成了可用的长历史容量，并把目标从总共约 1M 推向 15+ 路各自 1M 的同时解码。 资料与口径：依据 zLLM 工程记录 docs/glm53-cpu-kv-decode.md</code>（2026-09-05 至 09-08）、双机基线记录 docs/glm53-rocm-amd12-baseline-20260906.md</code>，并核对本地 GPU 热缓存实现。正式单路数据来自记录中的 cp0-v23</code> 六组门禁；追加为 append-v25</code>，并发为 concurrency-v28</code> 与 concurrency-tuning</code>。历史探索、诊断探针、正式配对和后续并发候选在文中分别标注，不能跨版本合并成同一条严格性能曲线。本文没有重新运行远端 benchmark。 古董机器也能跑顶尖大模型 2026-09-07T00:00:00+00:00 双路老至强，一张 RTX 3060，再加上系统可用约 125 GiB 的内存。这就是这次运行 Qwen3.8-Flash-Next 的全部计算硬件。 在这台机器上，zLLM 已经跑通模型的完整 48 层文本推理，并接入常驻服务。驱动分配的锁页主存方案在最新回归中约为 6.0–6.4 token/s，完成了 50 次请求与 4 次长生成的零失败验证。最新同题同参的单请求 MTP 基线达到 13.158 token/s。 几 token 每秒，意味着回答可以逐步出现在屏幕上，也意味着长答案需要耐心。对一台显存只有 12 GiB 的老平台来说，真正值得展开的是：它怎样把远大于显存的权重用起来，又怎样从“成功生成一次”走到连续提供服务。 老平台的优势，是能装下足够多的内存</h2> 本次机器与模型配置如下，性能与验证结论均来自这台机器的接入记录。 项目</th> 配置</th></tr></thead> CPU</td> 双路 Intel Xeon E5-2696 v4</td></tr> GPU</td> NVIDIA GeForce RTX 3060，12 GiB 显存</td></tr> 系统内存</td> 125 GiB RAM</td></tr> 系统</td> Fedora 44</td></tr> GPU 软件环境</td> NVIDIA driver 610.57.04，CUDA 13.3</td></tr> CPU 与 GPU 连接</td> PCIe 3.0 x16</td></tr> 模型</td> Qwen3.8-Flash-Next，GGUF 架构名 qwen4exp</code></td></tr> 权重</td> unsloth/Qwen3.8-Flash-Next-GGUF</code>，UD-Q4_K_XL 四分片</td></tr> </tbody></table> “古董”主要说的是这套双路 E5 平台。整机仍然依赖一张支持 CUDA 的 GPU，以及足够大的主存。标题中的“顶尖大模型”也不代表本文做过能力排名：这是一篇部署与推理工程实录，没有独立评测模型质量或量化后的能力损失。 仅模型的量化专家权重就有 77,017,907,200 字节，约 71.73 GiB，已经远超显存容量。不过，它采用 MoE，也就是混合专家结构：每层会从 512 个专家中选择 10 个参与当前计算，另有共享专家。 这给了老机器一个机会。全部专家需要有地方存放，但每一步只需把实际选中的专家交给 GPU。大内存承担容量，显存承担当前计算，两者通过 PCIe 配合。 12 GiB 显存怎样装配完整模型</h2> 我们把权重分成三种去向。 权重类型</th> 存放与执行方式</th></tr></thead> 非专家权重</td> 以量化形式驻留显存</td></tr> 约 71.73 GiB 的专家权重</td> 常驻主存，路由命中后按需上传显存</td></tr> 大型 PLE 表与 embedding</td> 读取当前需要的压缩行，再生成计算所需数据</td></tr> </tbody></table> 每到一层，路由先选专家。显存缓存中已经有的直接复用，缺失的从主存上传，随后执行量化专家计算。专家始终保留 GGUF 的压缩编码，没有先全部展开成半精度浮点数。 这一步很关键。如果模型文件在磁盘上很小，运行时却把权重重新撑大，容量和传输上的优势就会丢掉。zLLM 为实际使用的 Q4_K、Q5_K、Q5_1、Q8_0 等格式实现了直接消费压缩权重的 CUDA 算子。 显存中的专家缓存也有固定预算。我们一次申请一块显存，在内部管理区间与引用，确保上一轮计算不再使用某段区域之后，才允许复用。早期依赖动态分配的实现能完成短输出，却会在 128、256 token 的生成中耗尽显存；固定预算让长输出的资源占用有了明确上限。 这里的“按需上传”是主存到显存，专家已经完整驻留主存。PLE 与 embedding 仍可能发生少量随机读盘，因此整个过程仍有磁盘访问。 跑出一次高分之后，真正的难题才出现</h2> 最初的单请求实验，速度从 4.770 token/s 逐步提高。消除缓存命中时的显存深复制、减少主存中转、优化量化读取，再让专家上传与计算重叠，都带来了收益。 我们还接入了 shared MTP：用一个额外的草稿层提出候选 token，再由完整的 48 层模型验证。候选被接受时，一轮验证可以推进多个位置；被拒绝时，则恢复相关状态与缓存。bench 入口的 MTP 循环已经跑通，但常驻 Node 服务的 MTP 仍在收敛，当前线上配置因此关闭 MTP。 早期测试记录如下。这些都是独立进程的一次测量，属于历史实验结果。 场景</th> 输入 / 输出 token</th> 普通解码 token/s</th> MTP token/s</th></tr></thead> 代码题</td> 42 / 128</td> 10.779</td> 12.708</td></tr> 代码题</td> 42 / 256</td> 10.682</td> 11.239</td></tr> 中文聊天</td> 43 / 256</td> 11.371</td> 11.238</td></tr> </tbody></table> 12.708 token/s 的准确含义是：原始 42-token 模板 prompt、生成 128 token、专家缓存 5.25 GiB、MTP 置信度阈值 0.6、专家预取 0、prefill chunk 64、MTP 专家缓存 0.25 GiB，4 个草稿、Q8G64 KV、独立 bench 进程的一次 MTP 测量，接受率 97.1%。在同一配置、同一题目上，驱动 pinned 主存和草稿 pinned 驻留把结果刷新到 13.158 token/s，接受率 97.09%；verify 用时从 8.960 秒降到 8.662 秒，draft 用时从 0.758 秒降到 0.713 秒，上传字节数不变。这是当前最高纪录，仍然不是常驻服务速度，也不包含模型预读。 随后做的 MTP 复测使用了 59 token 的中文代码题提示，得到 8.32 token/s；提示词与 42 token 基线不同，接受率降到 74.6%，验证阶段上传约 126.7 GiB，因此不能与 12.708 做 A/B 比较。45 token 对齐提示的复测仍在进行中。 为什么接入新模型不需要重写整个引擎</h2> Qwen3.8-Flash-Next 的结构很特殊：Hyper-Connection、GDN、PLE、QSA 稀疏注意力和 512 专家路由同时出现。zLLM 仍然能在较短时间内接入，原因是架构把“模型语义”与“设备执行”拆开了。新增模型主要完成三类代码： 描述模型规格：在 src/model_spec/qwen4exp.rs</code> 声明 48 层布局、张量形状、路由常量、QSA/PLE/HC 参数和 GGUF 元数据。</li> 装配并实现模型算法：在 src/runtime/qwen4exp/mod.rs</code> 读取权重、实现前向结构；cpu.rs</code> 提供 CPU reference；cuda.rs</code> 和 cuda_mtp.rs</code> 只组合该模型需要的 CUDA 算子与 MTP 流程。</li> 接入运行入口：在配置和 Node 注册处增加 Qwen4ExpNodeModelConfig</code>、Qwen4ExpCudaEngine</code>，复用已有的 chat template、流式输出、取消、stop/EOS 和 scheduler 协议。</li> </ol> 这次模型专属的 5 个文件合计约 2,228 行 Rust（规格 186 行、装配 588 行、CPU reference 565 行、CUDA 组合 693 行、MTP 196 行）。它们调用的是已有的 GGUF 读取、KV cache、CUDA context/stream、固定显存 arena、专家 LRU、量化 kernel、服务协议和生命周期管理；这些基础设施不需要为每个模型复制一份。具体来说，专家搬运与缓存位于 backend/cuda/expert.rs</code>，Q4/Q5/Q8 packed kernel、attention、routing 和 tensor kernel 由共享模块提供。新模型增加的是“如何解释权重、如何排列计算”，而不是再造一套推理运行时。 这种拆分也让性能和正确性可以分开检验。CPU reference、张量格式对照、单算子 CUDA 测试和逐 token 输出一致性先回答“算得对不对”；固定 arena、分组 DMA、缓存策略和 MTP 草稿长度再用完整请求测量“跑得快不快”。一次 kernel microbenchmark 变快，不能直接合入主线；必须同时通过 reference 对拍、长输出稳定性和同输入端到端吞吐。13.158 token/s 与旧 12.708 的对比中，验收率、轮数和上传字节逐位一致，提升来自 pinned 源上的稳定 overlap 路径；注册普通堆内存的旧快路已经移除。常驻 Node MTP 仍要单独完成正确性与性能验收。 更大的转折发生在服务接入之后。独立进程生成一次就退出，常驻服务却要反复接收请求。运行到第三次、第五次，或者更晚，堆损坏才暴露出来。前一次已经把内存写坏，下一次分配内存时才崩溃，报错的位置未必就是出错的位置。 排查先修复了 PLE 读取时的列宽错误，随后又通过反复对照，把另一类损坏收窄到注册普通堆内存后进行异步 DMA 的直读路径。改用独立的锁页暂存槽后，连续请求通过了，但每次上传多了一次 CPU 内存复制，服务解码从约 6.4 降到了约 4.2 token/s。 最后保留的方案，是让专家权重直接读入 CUDA 驱动分配的锁页主存，并由运行时持续持有这块内存，再从中直接上传 GPU。它消除了额外的主存复制，也避开了原来的普通堆注册路径。 常驻服务的专家上传方案</th> 解码速度</th> 验证结果</th></tr></thead> 旧的注册堆直读</td> 约 6.4 token/s</td> 连续请求发生堆损坏</td></tr> 锁页暂存槽中转</td> 约 4.2 token/s</td> 修复后 30 次请求通过</td></tr> 驱动分配的锁页主存直读</td> 约 6.0–6.4 token/s</td> 50 次请求及 4 次长生成零失败</td></tr> </tbody></table> 这组记录说明了服务路径上的性能恢复。它与前面的短提示 benchmark 配置、执行入口不同，不能直接用来计算性能回退比例。修复后的版本仍需建立同条件的 MTP 性能与正确性基线。 锁页内存还有一个运维细节：进程正常退出后，cuMemFreeHost</code> 会把约 95 GiB 交还给驱动的 host 池，操作系统的 MemAvailable</code> 不会立刻恢复；下次分配可以复用，但当前的内存预检可能误拒运行。强制 SIGKILL</code> 则可能留下 NVIDIA 驱动记账泄漏，最终需要重启。部署时应使用可执行清理逻辑的优雅退出，并避免用 pkill -9</code> 回收节点。 限制速度的，是每个 token 要搬多少权重</h2> 大内存解决了“放在哪里”，接下来就要支付搬运成本。 早期代码题的 256-token MTP 测试中，每个输出 token 平均对应约 632.5 MB 的专家上传。这台机器的锁页传输探针测得 11.90 GB/s，按该带宽计算，仅搬运这些数据就需要约 53.2 毫秒/token。 20 token/s 的总时间预算只有 50 毫秒/token。仅传输就已经超过预算，还没有算上 GPU 计算、草稿生成和同步。这解释了为什么当时没有达到 20 token/s，也解释了为什么继续增加草稿长度没有持续提速。 这笔账针对当时的配置，不能当作最新服务的耗时分解。但它指出了后续方向：提高有用专家的复用，减少重复上传，让搬运与计算更充分地重叠。GPU 利用率再高，也无法抵消关键路径上必须等待的数据传输。 实际使用，还要看首字等待与服务回收</h2> 解码速度描述的是开始生成之后的速度。长材料送进模型，首先要经过 prefill，也就是输入处理。接入稀疏 QSA 注意力后，记录中约 10.6K token 的输入处理耗时为 351.2 秒。因此，这台机器处理长文档时，首字等待可能以分钟计。 记录中的 65,536 是经过测试的上下文配置上限；它不能被解读为已经完成 65,536-token 满长输入测试。更长的上下文仍有待验证，视觉能力也尚未接入。 最新锁页主存方案还有一个实际运维问题：在该环境中，强制杀死持有大量锁页内存的进程后，出现过驱动未回收内存的现象，最终需要重启机器恢复。常规回收应采用能够执行资源释放的退出流程；原记录尚未验证优雅退出是否能完全消除这一问题。 正确性证据同样有边界。早期 CUDA 输出与自有 CPU reference 做过对照，代码题和中文聊天的 256-token MTP 输出也曾与普通解码逐 token 相同。但独立 llama.cpp 对照在第五个 token 出现分歧，完整 logits 对齐尚未完成。这些验证支持已测场景的工程判断，不能替代模型质量评测。 老机器的价值，被软件重新挖出来了</h2> 这次接入最有意义的结果，是把一台双路 E5、125 GiB 内存、12 GiB 显存的机器，变成了能够运行完整 Qwen3.8-Flash-Next 文本模型的推理节点。 代价也很具体：专家占用约 77 GB 主存，PCIe 限制生成速度，长输入有明显等待，服务退出还需要继续验证。当前约 6.0–6.4 token/s 的服务记录，与单请求 MTP 的 13.158 token/s 属于不同入口和口径。 老平台的大内存、消费级显卡的计算能力，以及量化模型的稀疏结构，能够在合适的执行方式下配合起来。把每份权重放到合适的位置，保持压缩编码，管理好异步传输的生命周期，这些软件工作让已有硬件承担了原本看起来超出容量的任务。 本文依据 zLLM《接入 Qwen3.8-Flash-Next 实录》及其 2026-09-07 后续记录整理。未重新运行 benchmark；历史单请求成绩与最新服务验证分别列示。 来自阿布扎比的 K2-Horizon 到底怎么样？M5 实测：会做题，写中文却翻车 2026-09-06T00:00:00+00:00 来自阿布扎比的 K2-Horizon 到底怎么样？让它算一道题，再让它写一篇文章，得到的是两张很不一样的成绩单。 zLLM 接入 K2-Horizon-MoVA-36B-A4B 后，我在一台 Apple M5、24 GiB 统一内存的 Mac 上，用 IQ3_XS 量化版本试了两道题，又让它写了两篇中文短文。蜗牛爬井和猫抓老鼠都答对了。但到了菜市场随笔，正文开始混入英语、日语和阿拉伯语片段，最后因为重复生成而停止。 把温度降到零之后，文章有了改善，却没有完全解决问题。不过，在评价模型之前还得回答一个更基础的问题：zLLM 为了让它在 Metal 上完整跑起来，究竟接入了什么？K2-Horizon 并不是换一组矩阵尺寸就能复用普通 Transformer 的模型。它把稀疏专家放进了 attention 的 value 路径，一层里会出现两套路由。 因此，这篇文章有两条主线：前半部分讲 zLLM 如何把 K2 的 GGUF、MoVA、MoE 和 KV cache 接成完整推理；后半部分再看会做题与能稳定写好中文之间的距离。 先认清来源：IFM 总部在阿布扎比</h2> K2-Horizon 来自 Institute of Foundation Models，简称 IFM。根据官方介绍，IFM 隶属穆罕默德·本·扎耶德人工智能大学（MBZUAI），总部位于阿联酋阿布扎比，在巴黎和硅谷设有研究中心。K2 Horizon 系列于 2026 年 9 月 3 日发布。 IFM 机构介绍</a>；官方发布公告</a> 因此，把它直接称为“欧洲模型”并不准确。更准确地说，这是一个由总部位于阿布扎比、在巴黎和硅谷设有研究中心的全球团队推出的模型。 36B 的容量，约 4B 的激活量</h2> 这次运行的模型全名是 K2-Horizon-MoVA-36B-A4B。官方以 36B 总参数、每个 token 激活约 4B 参数的口径命名，标称上下文长度为 524,288 tokens。这些是官方规格，本次没有测试 512K 长上下文。官方模型卡</a> 普通 MoE 主要在前馈网络里挑选少量专家。K2-Horizon 的 MoVA 则把专家路由进一步用到 attention 的 value 路径，让注意力中的值表示也能使用稀疏专家。这是这个模型在架构上的一个特点。 IFM 对 MoVA 的说明</a> 本地 GGUF 元数据对应 48 层、2,560 维 hidden、32 个 query heads 和 8 个 KV heads； value experts 是 64 选 4，前馈部分在前 3 个 dense 层之后使用 100 选 8 的 routed experts，另有 shared expert。zLLM 已接入相应的分组 RMSNorm、attention output gate、MoVA、MoE 以及完整的 Metal prefill/decode 路径，并支持 Q8g64 KV cache。 实际使用的权重文件是： K2-Horizon-MoVA-36B-A4B-IQ3_XS.gguf </code></pre> 文件大小为 15,695,083,968 bytes，约 14.62 GiB。它是第三方低比特量化文件，内部混用了 IQ3_S、IQ3_XXS、Q3_K、Q6_K 和 F32 张量，并不是所有参数都存成同一种“三比特”格式。 每个 token 只激活少量专家，减少的是计算量，不代表只需加载 4B 参数的权重。本次测到的质量也只属于这个 GGUF 文件与运行配置，不能直接当成官方 BF16 模型的表现。 接入第一步：不能把 K2 当成普通 GQA</h2> zLLM 没有把 K2 的常量塞进 Metal kernel。模型尺寸、层数、norm、attention、专家数量和 Top-K 都集中在独立的 K2HorizonConfig</code>；打开 GGUF 时，再从元数据逐项读取并校验。 这些校验不只看 hidden size。当前实现会确认模型使用 sigmoid expert routing、选中专家权重需要归一化、每个稀疏层带一个 shared expert、key/value head dimension 一致，以及 dense 前缀后每层都进入 MoE。一个结构不符的 GGUF 会在装载阶段明确失败，而不是带着错误 shape 进入 GPU。 模型编排则放在独立的 runtime/k2_horizon/</code>。它描述的是 K2 一层真实发生的事情： hidden → grouped RMSNorm → query + attention gate → key → dense value（前 3 层）或 64 选 4 value experts（后 45 层） → RoPE + GQA + KV append → attention gate + output projection + residual → grouped RMSNorm → dense FFN（前 3 层）或 100 选 8 routed experts + shared expert → residual </code></pre> 这里最容易接错的是 value。普通 GQA 的 value 是一次线性投影；K2 从第 4 层开始，先用 sigmoid router 和 bias 从 64 个 value experts 中选 4 个，再计算并加权合并它们的输出。它输出 8 个 KV heads、每个 128 维，共 1,024 维 value，随后才进入 attention。 FFN 还有另一套独立路由：100 个 routed experts 选 8 个，同时执行 shared expert，选中权重归一化后再乘 2.5 的缩放因子。两套路由读的是不同权重，服务的是不同数据流，不能因为它们都叫“专家”就合并成一个通用分支。 第三方 GGUF 把很小但敏感的 MoVA router 量化成了 IQ3_S。zLLM 装载时只把这部分局部解码为 F32 并常驻，让路由打分保持稳定；大块 value expert 权重仍保留量化格式交给 Metal 直接计算。这个处理没有放宽整个权重层的契约，也避免为了一个小 router 展开整组专家权重。 接入第二步：IQ3_XS 不是一种 kernel</h2> 文件名写着 IQ3_XS，真正打开张量目录后却能看到五种存储类型：322 个 IQ3_S、 240 个 IQ3_XXS、3 个 Q3_K、1 个 Q6_K 和 232 个 F32 张量。一个只实现“IQ3”的入口远远不够。 为完整执行这个文件，Metal 路径需要处理普通量化 GEMV、gate/up 融合、按专家编号索引的 gate/up/down、MoVA 的 64 选 4 value 计算，以及 250,624 词表的 Q6_K lm_head。这些 kernel 直接读取 packed GGUF 权重；如果每生成一个 token 都先全量反量化， 14.62 GiB 文件带来的容量和带宽收益就会被破坏。 prefill 与 decode 也不能硬套一个执行形态。prefill 同时处理多行 token，先完成批量路由，再按 expert 分组执行；decode 每次只有一行，走设备常驻的 Top-K 结果和 indexed expert kernel。在 45 个稀疏层里，每层有 100 个 FFN experts，一共 4,500 组 expert 权重，约 10.00 GiB。本次零配置运行会在加载阶段把它们预载到统一内存可见的 Metal 资源中，避免生成过程中逐层读盘。 接入第三步：24 GiB 里还要给 KV 留位置</h2> “权重文件只有 14.62 GiB”不等于剩余内存都能拿来做上下文。模型运行还需要 expert resident 资源、activation、scratch、Metal 对象和系统本身。zLLM 启动时读取模型结构与机器预算，再计算每 token 的 KV 成本。本机日志给出的结果是： 权重 14.62 GiB KV 预算 0.96 GiB KV 每 token 约 101,376 bytes 最终上下文 9,216 tokens </code></pre> K2 在 24 GiB 机器上采用单独的四分之三工作集上限，并至少给系统留 2 GiB 余量。 KV cache 默认使用 Q8g64：每 64 个值共享一组量化参数。短上下文使用 direct attention；超过 256 tokens 后切到 split-KV，把历史分段并行计算，再归并局部结果。这也是为什么模型标称 524,288 tokens，而这台机器的零配置入口只选择 9,216 tokens。 完整 decode 怎么压进一次 replay</h2> 普通 decode 一轮要走完 48 层。早期 profile 里，单个 token 会产生约 1,100 个 Metal commands；如果每轮都由 CPU 重建和提交这张图，调度成本会不断重复。 zLLM 为 K2 单独实现了完整单 token decode replay。第一次记录从已上传的 token embedding、48 层 attention、两套 expert 路由、MoE、final norm、lm_head 到 argmax 的执行序列；之后只更新 token、position 和 KV 写入位置，再重放同一计划。Q8 attention 的 replay 会根据当前位置选择 direct 或 split-KV pipeline，因此跨过 256-token 边界后仍使用正确的长上下文路径。 这里有一个容易被性能数字掩盖的限制：greedy 生成可以重放整轮；使用 temperature/top-p 随机采样时，需要取得 logits 并维护采样状态，当前 K2 路径不会进入同一 replay 快路。所以后面的官方采样写作测试，不能拿 greedy 的约 30 tok/s 直接类比。 “能出字”之前，先证明数值链路成立</h2> 接入验收没有停在“模型加载成功”。现有记录包含几组分层验证： K2 的 Q8 direct/split KV append 与 reference 对拍通过；</li> BF16 split-KV 曾发现 vectorized kernel 参数绑定回归，修复后通过 CPU oracle；</li> Q6_K GEMV 与解码权重后的 dot product 对拍通过；</li> 250,624 词表下，Metal top-p sampling 用多个随机点与 CPU reference 逐点一致；</li> 完整真实权重完成 load、prefill、decode、Q8 KV 和 replay 端到端运行。</li> </ul> 同一组四道短题在 low/greedy 设置下，zLLM 与 llama.cpp 对同一个 GGUF 给出了逐题相同的错误答案；切到 high reasoning 并给足预算后，既有 llama.cpp 记录在 3 个随机种子中得到 12/12 正确。这个对照不能证明所有数值绝对一致，但它排除了“那四个答案只在 zLLM 上算错”的简单归因。 console 还踩过一个比 kernel 更隐蔽的坑：通用入口曾显式发送 enable_thinking=false</code>。 K2 的 chat template 会把它解释成一个空思考围栏，相当于强制模型直接回答，输出容易出现多语种混杂。修复后的入口不替 K2 决定这个字段，让模板保持默认 high thinking；MiniCPM5 和 Qwen 仍按各自已经验证的设置处理。模型支持不止是矩阵乘法，模板语义同样属于推理正确性。 现在跑多快，瓶颈在哪里</h2> 相同 55-token prompt、greedy、256-token completion 的既有记录中，llama.cpp 使用 F16 KV， prefill 为 0.322 秒，decode 为 7.800 秒，即 32.691 tok/s；zLLM 使用 Q8 KV，最好记录的 prefill 为 5.999 秒，decode 为 8.623 秒，即 29.690 tok/s，慢 9.18%。 这不是一场完全同配置的 KV 对照，但足以说明当前状态：decode 已接近，短 prompt prefill 仍明显落后。单 token profile 中，两套 sigmoid router——100 选 8 的 FFN 路由和 64 选 4 的 value 路由——排在 GPU 时间前列；256 tokens 之后的 split-KV 和 replay 提交成本也还有空间。 最后一轮压力测试曾因机器热降频，把直通 decode 从约 30 ms/token 拉到 80–100 ms/token。因此文章保留降频前的可复现数据，不拿过热后的瞬时结果代表正常性能。 先给足思考预算，再看答案</h2> 测试采用 high 思考档，temperature 为 1.0，top_p 为 0.95，与官方推荐一致。每个请求的上下文上限为 9,216 tokens，最多生成 4,096 tokens；问题之间不共享对话历史。官方推荐设置</a> 思考档位不是界面上的显示选项。本地模板会根据档位改变提示中的思考标记；关闭思考时，还会注入一个空的思考围栏。拿一个仍在思考、却被几十个 token 上限截断的输出评分，很容易把“还没答完”误写成“答错了”。 这里两道题都生成到了正常结束： 题目</th> 正确答案</th> 实测答案</th> 生成 token 数，含思考</th></tr></thead> 蜗牛白天爬 3 米、夜里滑 2 米，爬出 10 米深的井需要几天？</td> 第 8 天</td> 第 8 天</td> 1,344</td></tr> 3 只猫 3 分钟抓 3 只老鼠，9 只猫抓 9 只老鼠需要多久？</td> 3 分钟</td> 3 分钟</td> 700</td></tr> </tbody></table> 蜗牛题的关键是最后一天爬出后不再下滑。猫抓老鼠的关键是工作并行，猫与老鼠数量同时增加三倍，时间不变。模型最终都处理对了。 但第一道题的解释里已经出现了这样的句子： 每天 daytime 爬升 3 米， nighttime 回滑 2 米 </blockquote> 后面还有“白天下爬到”这样的病句。答案正确，并没有让说明文字自动变得自然。 一写菜市场，问题就明显了</h2> 第一篇写作测试要求： 请写一篇400至600字的中文生活随笔，题目《雨停之后的菜市场》。通过具体人物、动作、声音和气味组织文章，语言自然克制，不写提纲，不解释写作过程，直接给出标题和正文。 </blockquote> 提示要求全程使用中文，没有任何外语写作要求。模型给出的正文开头却是： 雨刚停，菜市场还不全是人。薄荷黑布遮在丑毛さらに码头上，粪水从竹筐的缝隙里滴着Becoming一条条银白色的短河。 </blockquote> さらに</code> 是日语，Becoming</code> 是英语。后面继续出现 Granny</code>、へえ</code> 和 السجائر</code>，末尾停在ポリ袋ákááááááááá</code>，运行时给出的结束原因是 repetition</code>。 这已经超过了“有一点翻译腔”的程度。即使把外语删掉，句子也没有清楚的人物、动作与空间关系。按只统计正文汉字的口径，最终只有 88 字，远没有完成要求的随笔。 第二篇换成说明性短文，题目是《小模型能做题，就能写好文章吗？》，要求区分答案正确、推理可靠和语言自然，并给出一个具体例子。 这一次有了完整段落，但正文仍然写出： Such表述语言自然。 </blockquote> 最后把推理过程写成一段连贯的文字 describing the solving journey, 语言自然。 </blockquote> 结尾甚至出现： 再 fingernail 推理的透明度和语言的自然度。 </blockquote> fingernail</code> 在这里没有合理语义。问题还不只在词汇：文章把“语言自然”说成文字创作专属，又试图用一道方程的解法证明写作能力，论证范围也没有把握好。 这篇的结束原因是 stop</code>。它提醒我们：正常停止，只代表生成过程结束；文章是否合格，还要读正文。 温度降到零，能改善多少？</h2> 我保留 high 思考档，用完全相同的两条写作提示，把 temperature 改成 0，各再运行一次。 文体</th> temperature=1.0</th> temperature=0</th></tr></thead> 菜市场随笔</td> 多语种混杂，重复终止；正文 88 个汉字</td> 正常结束，489 个汉字；仍夹杂英语</td></tr> 评价维度短文</td> 正常结束，481 个汉字；有无意义英语插入</td> 正常结束，652 个汉字；中文明显改善，但超出篇幅要求</td></tr> </tbody></table> 这里的字数只统计标题后正文中的汉字，不含标点、拉丁字母与 Markdown 标记。 零温度的菜市场随笔有了完整场景，但仍写出 freshly 捕来的鲫鱼</code>、Somehow 却不显得刺鼻</code>、女孩 grabs 住鱼</code>。声音描写也很奇怪：模型把议价声写成“咔嚓”。 评价维度短文改善得更多，没有再出现前一轮那种无意义的外语插入。文中的 AI</code> 是常见缩写，不应算作语言失控。不过，它仍没有守住 400–600 字的要求。 因此，这轮结果不能简单概括成“它不会中文”。更准确的是：在这组提示和当前运行环境下，中文写作的完成度、语言一致性与指令遵循还不稳定，文体和生成设置都会影响体验。 这里还留着一个工程问题：异常来自哪里？本次没有用相同提示对照 BF16 权重，也没有在另一个引擎上重跑这两篇文章，因此无法分开量化损失、引擎数值、模板和模型自身的影响。降低温度还会改变当前 zLLM K2 路径的采样状态与 replay decode 的启用资格，这组对照也不能用来做严格的单一因素归因。 它足以说明当前这套本地配置的使用体验，却不足以给整个模型家族下结论。 在 zLLM 中运行</h2> 从 zLLM 仓库目录使用已经编译好的 release 程序，权重路径替换成自己的位置： ./target/release/zllm-metal \ /Volumes/ORICO/models/K2-Horizon-MoVA-36B-A4B-IQ3_XS.gguf </code></pre> --release</code> 属于 Cargo 的构建参数，不需要传给 zllm-metal</code>。加载完成后直接输入问题，/reset</code> 清空对话，/exit</code> 退出。本机启动时自动选择了 9,216-token 上下文；官方标称的 512K 不等于这台机器的可用容量。 这次接入让 zLLM 多了一条可运行的 MoVA 模型路径，真实写作又给它补上了能力边界。以后再看一个模型的做题成绩，我会顺手让它写一篇具体的生活随笔：没有唯一答案的任务，往往更容易看清语言是否连贯、细节是否成立，以及一篇文章能不能真正交到读者手里。 测试记录</h2> 测试日期为 2026 年 9 月 6 日。环境为 Apple M5、24 GiB，GGUF IQ3_XS，Metal，Q8g64 KV cache。共六次独立请求，temperature=1.0 的四次请求未固定随机种子；temperature=0 的两次为写作对照。生成预算均为 4,096 tokens，包含思考与回答。本次采样生成不作为 replay 性能测试。 正式运行入口是 zllm-metal</code>，传入 K2 的 GGUF 路径后自动识别并加载模型。质量测试复用了 zllm-metal</code> 的正式推理路径和已有 release 构建，没有重新编译引擎。记录中的源码 HEAD 仅表示测试时的工作区版本，不等于已核实的二进制构建提交。运行时返回合并文本流，未单独拆分思考与回答；本文只从明确标题后的正文摘录写作内容，按末尾的最终答案核验做题结果，没有把思考中的英语算成中文正文错误。 完整提示、六次原始输出、结束原因和运行版本指纹（JSON）</a> 可供复核。另附采样日志</a>、零温度日志</a>、采样配置</a>和零温度配置</a>。 JSON 已将日志中的换行还原，模型文字保持原样。配置含测试机的路径，跨机器复现时需要修改。 算子验证与先前的性能记录见既有接入报告</a>，其中的数据与这次写作测试分别记录。 双8卡(AMD W7900D)机器如何跑 GLM5.3 2026-09-05T00:00:00+00:00 16 张显卡，总共 768 GiB 显存，运行 GLM-5.3，最初却只有 4.08 token/s：每生成一个 token，要等约 245 毫秒。 显存足够把模型装下，并不意味着算力就能顺利叠加。我们的两台机器各有 8 张 48 GiB 的 W7900D，节点内走 PCIe 4.0，节点间走 TCP，没有可供这条执行路径使用的 XGMI 高速互联。模型必须分布在多张卡上，但每增加一次跨卡协作，都可能给单个 token 增加一次等待。 这轮 zLLM 的 ROCm 优化，就是从这个约束出发：先减少层内通信，再优化每张卡上的实际工作，最后通过 MTP 推测解码减少完整模型的执行轮数。 直接核对 Amd-1 的结果文件后，单卡 stage、不开 MTP 的完整测试为 11.321 token/s；最新双卡算子并行版本三轮达到 13.842–14.043 token/s，中位数 13.968，约 14 token/s。相比最初约 4.08 token/s，单卡 stage 路线的吞吐提高到约 2.77 倍。 旧双卡版本叠加 MTP 的完整测试还记录了 25.275 token/s。它证明组合路线已经运行过，但不能据此认定最新约 14 token/s 的版本加上 MTP 也已经完成验收。 数据说明：本文主结果来自 Amd-1 上的 JSON 与运行日志。测试语料文件名为 50k-allgpu.txt</code>，实际请求输入为 46,152–46,158 token，输出均为 1,024 token。Decode 速度按首个文本事件之后的 1,023 个生成 token 除以剩余生成时间计算；下文“50K”沿用语料名称，算子 profile 中的 50K 则是其工作量口径。不同提交、nonce 与 MTP 配置的结果不能视为同版本严格 A/B。 </blockquote> 先决定数据在哪里，再决定怎么并行</h2> 单路自回归生成有一个硬约束：下一个 token 必须等待当前 token 完成采样。 对这次测试的 78 层模型，一个 token 要依次经过所有层、最终输出投影（LM Head）和采样，才能开始下一轮。把这些层放到 16 张卡上，只是把执行链分段，不能自动让同一个 token 同时穿过所有层。 我们的起点是让每张卡负责一段连续、完整的层。权重、KV Cache、稀疏注意力索引状态、专家权重和临时工作区都留在本地，只有层段边界的 hidden activation 需要交接： </a> 点击图片可放大查看。图中数据量与延迟按各自尺度绘制；层内 profile 含嵌套 scope，不应相加为完整 token 的耗时比例。 这里的“单卡 stage”指每段由一张卡执行，整个模型仍然使用 16 张卡。 此前尝试过更细的双卡协作：一层中反复交换 query、selection 和专家计算的 partial，每层有 4–6 次交接。数据量未必大，但每次交换后的 event 等待都会把两张卡的进度差带入关键路径。重复 78 层后，局部计算并行省下的时间，被协作成本抵消。 因此，单请求 decode 的近似账本应该是： 每 token 延迟 ≈ 所有 stage 的串行执行时间之和 + stage 交接 + LM Head、采样和回环 </code></pre> 这也决定了如何理解“负载均衡”。多个请求或多个 prefill chunk 可以重叠时，最慢 stage 会限制流水线吞吐；单请求逐 token decode 则首先取决于整条链的总时间。调整层边界只有在减少等待、改善执行效率或缓解资源限制时，才会带来收益。 从 4.08 到 11.32，时间省在了哪里</h2> 归档测试使用 GLM-5.3 UD-IQ4_XS GGUF、78 层、Q8G64 KV，使用“50K”语料（实际约 46.15K token），生成 1,024 token，关闭 MTP、DSpark 和旧双卡协作路径。 阶段</th> Decode（token/s）</th> 每 token 延迟</th> 主要变化</th></tr></thead> 初始单流水线</td> 4.084</td> 244.8 ms</td> 完成拓扑调整，单行算子仍待优化</td></tr> 单卡 stage（非并行）</td> 11.321</td> 约 88.3 ms</td> 专用 IQ kernel、MLA 优化、Q8 shared expert、W8 直读与调度优化</td></tr> </tbody></table> 按 11.321 token/s 换算，吞吐约为最初的 2.77 倍，单 token 延迟减少约 63.9%。下面展开其中最有效的几项变化。 Decode 只有一行，不能直接照搬大矩阵乘法</h3> Prefill 一次处理多行输入，适合用矩阵乘法摊薄权重读取成本。普通 decode 一次只有一行，更接近矩阵乘向量（GEMV）：每读入一大批权重，只计算一个 token 的输出。 这时，权重读取、反量化指令、线程映射和 kernel 启动开销都很显眼。我们针对 gfx1100 直接编写 HIP/ROCm 算子，为 IQ3_S、IQ4_XS 和 Q8/W8A16 建立专用路径。 例如，IQ3_S 的 gate/up 使用 8-lane subgroup，再通过 u16</code> 宽读取降低加载开销。在布局和输出 bit pattern 不变的前提下，探针时间从约 207–211 微秒降到 188–190 微秒。 但相似代码不保证相似收益。IQ4_XS down 当时的有效带宽已约为 465 GB/s；移植另一种码本读取写法，时间反而从 102 微秒退化到 144 微秒。这个实验说明，在当前 shape 上，继续围绕码本缓存做文章并没有抓住主要瓶颈。 最值得保留的一次优化：别把量化权重重新撑大</h3> MLA，也就是多头潜在注意力，是每层都会执行的聚合热点。其中 kv_b</code> 的驻留格式曾经浪费了大量带宽。 旧路径把 W8 权重先解成 F16，再以 F32 dense 形式常驻，方便后续 absorb/PV 计算使用。磁盘上的权重虽然量化了，执行时却重新膨胀：相关阶段每层需要读取约 58.6 MB。 新路径让算子直接消费 W8 权重和 scale，流量降到约 14.7 MB，减少到原来的四分之一。完整测试从约 9.76 提升到 10.50/10.28 token/s，两轮平均收益约 6.5%。 这是比“再换一个 tile”更直接的优化：如果热路径最终还是读取 F32，量化就只节省了模型文件大小，没有充分兑现执行时的带宽优势。 其他 MLA 优化也有效。PV 连续加载向量化后，设备 scope 从约 0.484 降到 0.439 ms/layer，完整模型收益约 2.5%–3.5%；selected scan 把 QK 中主要由一个 wave 完成的工作分给 8 个 wave，partial 与 merge 合计从约 90.6 降到 57–59 微秒。 不过，这些局部节省不会自动等额转化成 token 延迟下降。下一部分解释为什么。 Kernel 快了，整条链却可能更慢</h2> DSA 稀疏注意力索引器要从历史位置中选出后续注意力计算使用的集合。在 50K 场景中，score 计算约 91 微秒，已经达到 profile 估算计算上限的约 68%；radix select 的串行尾部更值得处理。 原实现最后两级由一个线程块串行重扫。拆成多级 kernel 后，相关 kernel 时间从约 105 降到 96 微秒，确实更快了。但新增两次各约 12 微秒的 launch 后，完整 select 仍约 139 微秒，没有得到预期的端到端收益。 这些实验使我们的优化单位逐渐变大：先看一个 kernel，再看完整算子，最后看整个 stage 在 token 关键路径上的耗时。 主要限制</th> 本轮代表</th> 有效方向</th></tr></thead> 权重读取带宽</td> q_b</code>、kv_b</code>、MoE 权重流</td> 压缩驻留、连续宽读取、共享权重读取</td></tr> 计算与反量化指令</td> DSA score、IQ 解码</td> 调整 wave 映射、缩短指令依赖</td></tr> 同步与调度</td> radix 多级选择、launch、双卡 join</td> 减少交接、融合依赖链、消除 bridge copy</td></tr> </tbody></table> 下图把更新后的原始记录中的带宽数据展开： </a> 图中的有效带宽来自权重字节数除以 kernel 时间，是分析指标；本轮没有取得可用的底层显存流量与 occupancy counter，不能把它当成硬件计数器实测。 Graph 实验：启动更快，完整请求反而慢了 4%–5%</h2> HIP Graph 的思路是把重复执行的 kernel 依赖链预先记录下来，后续直接 replay，减少逐个提交 kernel 的开销。对于单行 decode 中大量短 kernel，这个方向很自然。我们的实验也确实测到了启动收益，但接入生产路径后，收益没有兑现。 探针有效，端到端无效</h3> 在 64 个小 kernel 组成的探针中，eager 设备时间线约为 0.76–0.80 ms，预热后的静态 Graph replay 约为 0.23–0.27 ms。折算到每个节点，大约从 12 微秒降到 4 微秒。这说明 Graph 能压缩提交间隙；它并没有让 kernel 内部的计算和权重读取变快。 但在修复正确性之后，5 节点 MoE Graph 的完整请求对照结果如下： 同二进制、50K 输入 × 1,024-token decode</th> 第一轮</th> 第二轮</th></tr></thead> Graph 关闭</td> 9.509 token/s</td> 9.607 token/s</td></tr> Graph 开启</td> 9.119 token/s</td> 9.124 token/s</td></tr> 吞吐变化</td> −4.1%</td> −5.0%</td></tr> </tbody></table> 这是历史 Graph 专项实验，修复提交为 b4433700</code>，结果记档于 51a4f30d</code>。这些数值只用于说明开关 Graph 的同版本对照，本文最新单卡 stage 主口径为已核对的 11.321 token/s，不能把这次历史回退比例直接套到最新版上。 为什么省下 launch，还是亏了</h3> 关键在于固定地址带来的桥接成本。这个实现的 Graph 节点记录了设备指针，而上游输出需要搬到 Graph 使用的固定槽位。每层因此多出 3 次设备到设备的 D2D 拷贝，以及这些拷贝对应的 host 提交开销。 实验只包住了 5 个节点，能够摊薄的 launch 间隙有限；新增的桥接工作却每层都要执行。按单节点探针的差额粗算，5 个节点仅对应约 40 微秒的潜在节省，这只是量级估计，并不是生产 Graph 的净收益。真正的账要包含桥接、replay 和后续依赖等待，完整测试已经给出了负收益答案。 同时，小段 MoE Graph 没有覆盖 attention 中较长的串行链，也不会减少专家权重读取、反量化计算或跨卡等待。它只优化了关键路径上的一小部分，却为接入这一小部分增加了固定成本。 正确性问题修好了，性能问题仍然存在</h3> 更早的版本还出现过死循环、NaN 和非法访存。根因是 Graph 构建期间使用的中间 buffer 在构建结束后被释放回内存池，但节点仍保留旧设备指针。内存池复用这些地址后，replay 就可能读写其他对象的内存。 独立探针没有复现，是因为探针一直持有相关 buffer；生产运行的资源生命周期不同。修复让 Graph 对象持有所需 buffer，保证 replay 期间地址仍然有效。强加同步曾短暂掩盖症状，但长上下文测试仍失败，因为同步无法修复悬垂指针。 上表的负收益是在修复后测得的。因此，“能稳定 replay”和“能降低端到端延迟”是两个分别需要验收的结果。 什么条件下值得再试</h3> 这次实验后，生产路径保持 decode_graph=false</code>。后续值得验证的是覆盖更长依赖链的整层 Graph：上游直接写入固定 workspace，消除额外 bridge copy，同时由 Graph 明确持有其引用的资源，避免工作区扩容或内存池复用使旧指针失效。 覆盖范围扩大后，仍需在同一二进制、相同输入和输出正确性要求下，关闭 profiler 测完整请求。Graph 的验收指标是最终 token 延迟，不是录进去了多少个节点，也不是 replay 探针快了多少。 双卡并行为什么没有接近翻倍</h2> 优化单卡路径后，我们重新尝试双卡算子并行。新的 parallel_operator_pairs</code> 在 MLA 中拆 query heads，在 MoE 中拆中间维，并在较大的 attention 和 FFN 边界归并结果。 交换格式也一起调整。KV 由 owner 量化一次，只传新增的 Q8 latent、scale 和 rope 信息，单 token、单层的 KV 交换从 2,304 B 降到 656 B，减少 71.5%。Router 则在两侧重复计算，省去传递路由表的握手。 单卡 stage 与双卡路线的非 MTP 性能量级如下： 执行方式</th> Decode（token/s）</th> 每 token 延迟</th></tr></thead> 每个 stage 使用单卡（非并行）</td> 11.321</td> 约 88.3 ms</td></tr> 双卡 operator pair，三轮中位</td> 13.968（约 14）</td> 约 71.6 ms</td></tr> </tbody></table> 以 11.321 token/s 为参照，双卡三轮中位数约高 23.4%，每 token 的延迟减少约 16.7 毫秒。这是不同版本之间的量级比较，不是同版本只切换并行开关的严格 A/B。双卡拆分的收益远小于理想二分，profile 给出了几个具体原因。 首先，拆 query heads 没有拆历史扫描。两卡仍各自 gather Top-2048、扫描完整逻辑 KV。MLA 的 pair scope 约 0.35–0.45 ms/layer，与单卡的 0.35–0.36 ms/layer 相比，基本没有加速。 其次，大权重计算拆开了，整层依赖链没有一起减半。Norm、router、DSA selection、部分共享专家工作和结果归并仍要付出成本，FFN/MoE 整段只快约 30%–40%。 最后，attention 和 MoE 每层都要双向交换 partial。仅 peer-copy kernel 在 78 层累计就约 3.8 ms/token，此外还有 event、join 和两侧进度差。 以上瓶颈来自较早双卡版本的 profile，用来解释优化方向，不能直接当作最新 da1e40be</code> 版本的耗时分解。在这组 profile 中，跨节点 TCP 的裸传输只有几十微秒/token，主要损失反而发生在节点内的逐层协作。真正需要减少的是重复扫描和同步等待，单纯缩小消息字节数还不够。 按照 Amdahl 定律，未拆分的串行工作会限制整体加速；新增的通信和同步还会进一步抵消收益。两张卡都在忙，并不意味着每个 token 的关键路径缩短了一半。 继续优化的方向是让 owner 保存唯一的权威 hidden 状态，把 partial 改为向 owner 单向归约，减少反向交换和重复 residual；再探索按历史维度拆分 DSA/MLA，让两张卡真正各扫一部分历史。跨越下一档性能需要改变数据分工。 MTP 的收益，来自少跑几次完整模型</h2> 当普通 decode 的单 token 延迟已经优化到约 88.3 毫秒，继续抠掉几微秒的边际收益会越来越小。MTP 提供了另一个方向：先提出多个候选 token，再由目标模型验证，让一轮昂贵的验证提交多个有效 token。 它没有消除自回归语义，而是利用候选前缀，把部分逐 token 工作变成多行验证。是否更快，取决于每轮最终接受多少 token，以及 draft、verify、回退和状态追赶的总成本。 Amd-1 的 paired-mtp5-g2-50k-d1024-r1.json</code> 记录了真实的双卡加 MTP 测试：输入 46,152 token、输出 1,024 token，decode 用时 40.475 秒，吞吐 25.275 token/s。配置为 parallel_operator_pairs=true</code>、draft depth 5、verify group rows 2；日志确认 MTP L78 也使用 operator pair。 对应完整请求日志记录：target rounds 为 315，验证候选 1,567 个，接受 709 个，候选接受率 45.25%。按日志口径，每个 target round 平均提交约 3.25 个 token（1,024 / 315）。每层 draft depth 的接受数依次为 241、179、130、92、67，说明加深候选深度后，后续位置的有效产出逐步减少。 同一路线其他配置的完整测试为：depth 3 / group 2 达到 23.793 token/s，depth 5 / group 1 为 20.647 token/s。它们说明 verify 组织方式会影响端到端收益；由于请求 nonce 与配置不同，这里不把差值归因于单一因素。 25.275 是旧双卡配置的一次完整实测，不是最新 da1e40be</code> 双卡版本加 MTP 的成绩，也不是多轮稳定基线。 日志中的 1,024-token 请求先完成，随后才出现 rocprof 附加的另一轮诊断；本文不把后续 profiler 结果混进这一吞吐数字。最新双卡版本仍需单独验证 MTP 组合的速度与正确性。 对这条路线，下一步最值得关注的也不是单独增加 draft depth，而是让多行 verify 真正共享投影、MLA 和 MoE 的权重读取。多验证一行的成本越低，接受更多候选才越有价值。 正确性同样要覆盖状态：候选不匹配后，target KV、DSA selection 和 MTP cache 必须回到正确位置；接受前缀后，相关缓存还要完成追赶。最终吞吐必须建立在这些状态一致的基础上。 为什么选 4 bit：可以升到 5/6 bit，FP8 超出了当前硬件预算</h2> 我们当前选择 4-bit 量化，是为了先给长上下文、MTP 和多卡执行留出足够的显存余量。4 bit 是当前部署的起点，后续可以上升到 5 bit、6 bit。按照我们对这条执行路径的判断，升位基本不会带来性能损失，但模型质量会有明显提升。 如果更看重回答质量，这比继续压低权重 bit 数更值得做。 位宽增加不等于端到端耗时同比增加。当前单路 decode 的时间还包含 DSA、attention、kernel 提交、跨卡同步和采样回环；低 bit 格式本身也要支付码本、scale、符号处理和反量化指令的成本。因此，从 4 bit 升到 5/6 bit 后，权重读取量增加，并不会直接变成同等比例的 token 延迟增加。这里的判断针对本项目的模型、硬件和执行路径；本文没有列出 5/6 bit 的独立速度或质量测评数值。 FP8 则越过了另一条边界：在当前这套硬件上，无法满足本文完整部署的显存预算。 这套机器的高质量 4-bit checkpoint 已约 362 GiB，按权重翻倍粗估，8-bit 接近 724 GiB，而 16 张卡的物理显存合计只有 768 GiB。剩余约 44 GiB 还要容纳长上下文 KV、DSA 索引状态、MTP、peer 副本、workspace、HIP runtime 和显存碎片，无法支撑当前部署。这个判断首先来自容量与运行余量，不是说 API 无法表达 FP8。 权重方案</th> 本项目的选择与判断</th></tr></thead> 4 bit</td> 当前主路径，优先保留上下文与执行余量</td></tr> 5/6 bit</td> 可升级方向；在当前路径上基本不损失性能，质量可明显提升，部署时需重新核算显存余量</td></tr> FP8</td> 当前硬件无法满足完整部署的显存预算</td></tr> </tbody></table> 实际执行也不要求所有张量使用同一位宽。当前 routed expert 使用 IQ3_S/IQ4_XS，适合直接消费的投影保留 W8A16，KV 使用 Q8G64，LM Head 使用 Q8G128。升级权重位宽时，仍应按算子选择格式，并用目标任务检查质量收益。 无论选择 4、5 还是 6 bit，都应让热路径直接消费压缩权重，避免重新膨胀成 F32 常驻。这样，增加的显存预算才能用于改善模型质量，而不是消耗在不必要的中间表示上。 下一步，继续沿完整请求计时</h2> Prefill 已有历史 cooperative 路径在 50K 口径下达到 1331.62 token/s 的归档结果。它属于另一执行配置，不能与最新 decode 数字拼成同一次运行的成绩。下一阶段希望补齐多行算子、改善 chunk 与 stage 调度，向 1500 token/s 推进，并用完整 50K 的首 token 延迟验收。 Decode 的下一步是在最新双卡版本上重新验证 MTP：先检查输出与缓存状态，再测多轮接受率、多行验证成本和完整请求吞吐。旧配置的 25.275 token/s 提供了实验依据，但 30+ 仍只是目标，不能把不同版本的收益直接相乘。 最新记录还提到，目标 GPU 在执行本地层段的活跃窗口里，有效占用可达到 70% 以上。它不代表 16 张卡在整段单路 decode 中同时达到 70% 利用率，也不能与硬件 occupancy 混用。局部工作已经更紧凑，是否改善用户等待时间，仍要回到端到端计时。 这轮优化中，我们保留了能减少权重读取的 W8 直读，也否决了微基准更快、整条链却没有收益的尝试。后续仍沿用同一标准：用 reference 检查数值和状态，用 profiler 找到等待发生在哪里，最后关闭 profiler，在相同输入与配置下测完整请求。 每个 token 都要走完的那条路，才是最终需要优化的对象。 资料口径：算法与历史实验依据 2026-09-05 更新的项目优化记录；当前速度由 Amd-1 的原始 JSON、配置与日志交叉核对。以下为本次引用的完整请求，未重新运行 benchmark。 路线 / 结果文件</th> 输入 token</th> 输出 token</th> Decode（token/s）</th></tr></thead> 单卡 stage：c343909e-current-routepair-no-mtp-strict1024-r1.json</code></td> 46,158</td> 1,024</td> 11.321</td></tr> 双卡：paired-directjoin-da1e40be-formal-no-mtp.json</code></td> 46,153</td> 1,024</td> 14.043</td></tr> 双卡复测：paired-directjoin-da1e40be-formal-recheck-no-mtp.json</code></td> 46,153</td> 1,024</td> 13.842</td></tr> 双卡复测：paired-directjoin-da1e40be-formal-recheck-no-mtp-r2.json</code></td> 46,153</td> 1,024</td> 13.968</td></tr> 旧双卡 + MTP：paired-mtp5-g2-50k-d1024-r1.json</code></td> 46,152</td> 1,024</td> 25.275</td></tr> </tbody></table> 结果文件分别位于 Amd-1 的 /workspace/zllm-kv-eval-run/runs/</code> 和 results/</code>，基础语料 SHA-256 一致，nonce 不完全相同。最新三轮双卡结果的输出 SHA-256 一致；这验证了这三轮输出一致性，不等同于独立模型质量评测。部分 runner 的 topology</code> 字段沿用了“16 serial stages”模板，运行日志实际确认双卡路线每节点为 4 个 owner-peer pair，两节点共 8 个逻辑 stage。 算法层：从注意力、KV Cache 到 FFN 与 MoE 2026-09-04T00:00:00+00:00 算法层回答的不是“在哪块 GPU 上跑”，而是“这一步数学上应该得到什么”。在 zLLM 中，它首先是一组设备无关的规格、数据流和 CPU f32</code> reference：CPU oracle 给出可读、可测的正确性基准，Metal、CUDA、ROCm、Vulkan 与 NPU kernel 则是在同一语义上的加速实现。 这一区分很重要。高性能 kernel 可以换布局、融合算子、降低精度或并行提交，但不能悄悄改变 causal mask、RoPE、Top-K 路由、KV 写入位置或数值定义。新算法先在 CPU/reference 上钉住 shape、边界与结果，再与设备实现做 oracle 对拍；通过 oracle 只证明局部语义一致，最终仍要执行完整 prefill/decode 并验证输出与性能。 1. 从 token 到下一 token</h2> 可以把一层 Transformer 类比为一次有结构的思考，但不要把类比当成生物学结论：模型的“角度、形状、视觉、语义、历史、关系”并不是六个预先命名的槽位，而是训练后分布在高维向量中的特征方向。一个维度通常也没有独立、稳定的人类解释。 完整路径是： 分词：tokenizer 把文本或多模态占位符变成 token id。token 是词、子词、字节片段或特殊符号，不必等同于一个汉字或单词。</li> 向量化：embedding 按 id 查表，把离散 token 变成 hidden_size</code> 维向量；位置编码再让注意力知道顺序与相对位置。</li> 逐层加工：每层先用 attention 从当前与历史 token 聚合相关信息，再用 FFN 或 MoE 对每个 token 的表示做非线性特征变换；归一化与残差连接贯穿其中。</li> 输出：final norm 与 LM head 把 hidden 投影到词表大小的 logits，采样或贪心选择一个 token。decode 把它作为下一轮输入，直到 EOS 或达到长度上限。</li> </ol> “升维、矩阵乘法、合并、降维”究竟是什么</h3> 若一行 hidden 写成 x ∈ R^d</code>，线性层本质是 y = xW</code>。矩阵乘法把旧坐标的加权组合映射到一组新坐标：它既可把 d</code> 维投影到更宽的 d_ff</code> 维，也可投影成 Q/K/V，或把多头结果映射回 d</code> 维。 升维不是凭空增加事实，而是提供更宽的中间工作空间，使门控与非线性能够表达更多特征组合。</li> 多头把同一 hidden 投影到多个子空间。不同 head 可能学到局部、语义、位置、指代或视觉关系，但并没有人工规定“第 3 头就是形状”。</li> 合并通常是对 value 的加权求和，再拼接多个 head；它是在聚合信息，不是把原句复制一遍。</li> 降维用输出投影或 FFN down projection 回到 hidden_size</code>，从而能与残差相加并送入下一层。它是学习得到的投影，不等于简单删除末尾若干维。</li> </ul> 因此“一层的实际思考过程”更准确地说，是 attention 的跨 token 读取与 FFN 的逐 token 特征变换交替进行；层数提供连续的表示修正，而向量维度提供每一步的表达空间。 2. Attention：决定此刻应读取哪些信息</h2> 经典 scaled dot-product attention 为： Attention(Q,K,V) = softmax(QKᵀ / √dₖ + mask)V</code> 可以用三个问题理解它：Q 是“当前在找什么”，K 是“每段历史用什么索引被找到”， V 是“找到后取回什么内容”。causal mask 保证生成第 N 个 token 时看不到未来。《Attention Is All You Need》</a>用全局 self-attention 替代了当时序列模型中的循环主干，但今天的主流模型已经发展出多种计算与存储折中。 这些方案并不都是“门限分组”，应按压缩发生的位置区分： 方案</th> 核心办法</th> 主要减少什么</th> zLLM 对应</th></tr></thead> MHA，多头注意力</td> 每个 Q head 有自己的 K/V head</td> 基线方案，表达力强但 KV 较大</td> 通用多头几何与 block/reference 语义</td></tr> MQA</td> 所有 Q head 共享一组 K/V</td> KV Cache 与 K/V 带宽</td> 可视为 num_kv_heads = 1</code> 的 GQA 退化形态</td></tr> GQA，分组查询注意力</td> 一组 Q heads 共享一个 K/V head</td> KV Cache、K/V 投影和带宽</td> attention/gqa.rs</code>，支持 full/sliding window 与 hybrid layer</td></tr> MLA / Gated MLA</td> 把 KV 压到低秩 latent，需要时重建；可带输出门</td> KV 表示与投影开销</td> attention/mla.rs</code>，用于 GLM-5.2、DeepSeek-V3、Kimi-K3 等编排</td></tr> Sliding / Block Attention</td> 只看最近窗口或显式可见块</td> 长上下文 attention 计算</td> gqa::CausalWindow</code>、attention/block.rs</code></td></tr> DSA / MSA</td> 学习索引器或块索引，每个 query 只选 Top-K token/块</td> 长上下文的 QK 与 AV 计算</td> attention/dsa.rs</code>、attention/msa.rs</code></td></tr> 压缩稀疏注意力</td> 保留近期窗口，把更早历史池化压缩后选择或全读</td> 远端历史的存储与计算</td> attention/compressed_sparse.rs</code></td></tr> Gated DeltaNet / KDA</td> 用短卷积和固定大小 recurrent state 递推历史</td> 避免随上下文线性增长的完整 KV</td> attention/gated_delta_net.rs</code>、attention/kda.rs</code></td></tr> </tbody></table> 门控、分组、低秩和稀疏选择是四件不同的事。门控控制信息通过多少；GQA 让多个 query head 共享 KV；MLA 压缩表示；DSA/MSA 只让当前 query 聚焦一部分历史。它们都像人类思考中的“聚焦”：当前问题不必同时、同强度地翻阅全部记忆，但工程上必须明确这种聚焦是否仍扫描全历史来做选择，否则“稀疏结果”未必带来稀疏计算。 3. KV Cache：历史信息的可复用表示</h2> 自回归生成每轮只多一个 token。如果每轮都重新计算此前全部 token 的 K 和 V，大量矩阵乘法会被重复。KV Cache 保存各层已经得到的历史 K/V 或等价状态，decode 只计算新 token，再让它查询历史并追加新记录。 它可类比为“工作记忆的索引和内容”，但不是原始对话的无损副本： GQA 保存较少的 KV heads；MHA/GQA 的容量通常仍随 token 数线性增长。</li> MLA 保存归一化后的低秩 latent 与 RoPE 分量，读取时再重建所需表示。</li> zLLM 的 MLA cache 支持 F16</code>，也定义了 latent INT8 per-group、RoPE 保持 F16 的布局；量化减少容量，但会引入可测的数值误差。</li> sliding window 只需保留有效窗口；DSA/MSA 还要维护索引信息。</li> Gated DeltaNet 与 KDA 保存固定大小 recurrent/短卷积 state，它们与 full attention KV 的更新语义不同，不能强塞进同一种存储抽象。</li> </ul> kv_cache/mod.rs</code> 负责逻辑层到 cache 槽的映射、GQA/MLA 形态、格式、步长、容量和有效长度等设备无关语义；backend 才负责 buffer 分配、驻留位置、量化 kernel 与同步。KV 跟随负责该层计算的设备驻留，多机按连续完整层切分时也不跨网络搬运每层 KV。 4. FFN：每层内部的特征加工</h2> Attention 解决“从别的 token 取什么”，FFN 解决“当前 token 取到信息后怎样变换”。主流 gated MLP 可概括为： y = W_down(act(xW_gate) ⊙ (xW_up))</code> gate/up 把 hidden 投影到更宽的 intermediate 空间，激活函数与逐元素乘法形成非线性选择，down 再投影回 hidden。zLLM 的 moe/dense_mlp.rs</code> 保存这一平台无关数据流，当前激活规格覆盖 SiLU、clamped SiLU、SiTU、OpenAI 风格 SwiGLU 与 GELU-Tanh；矩阵乘法仍由 backend capability 实现。 Dense FFN 与 MoE</h3> Dense FFN 的整套 gate/up/down 权重对每个 token 都参与计算。它可被口语化为“一层的全部专家都工作”，但源码里 dense MLP 是一个完整网络块，并不是先存在许多专家再全部选中。 MoE 则放置多组 expert FFN，由 router 给每个 token 打分并只激活 Top-K routed experts；shared experts 可始终执行。这个设计更接近大脑中“不同区域按任务活跃”的类比：总参数容量很大，但单个 token 的活跃计算量较小。这个类比只解释稀疏激活，不意味着 Transformer expert 对应固定脑区或具备可命名的人格。 zLLM 的 FFN/MoE 模块边界如下： 模块</th> 功能</th></tr></thead> moe/dense_mlp.rs</code></td> dense gated MLP 的规格、激活与 gate/up → activation → down</code> 数据流</td></tr> moe/routing.rs</code></td> 路由分数、Top-K、分组 assignment 与活跃 expert 统计</td></tr> moe/topk_moe.rs</code></td> routed/shared expert 的组合、路由后缩放和输出累加</td></tr> moe/latent_moe.rs</code></td> 原 hidden 做路由，低维 latent 进入 routed expert，shared MLP 仍读原 hidden</td></tr> moe/prefill.rs</code></td> 多 token prefill 的 expert 分组执行与合并</td></tr> moe/expert_predictor.rs</code></td> 根据真实历史路由预测后续 expert，服务异步预取；不持权重、不执行 I/O</td></tr> </tbody></table> MoE 首先降低的是每 token 的计算量，不会自动降低模型总权重。高吞吐、低延迟场合通常需要让大量甚至全部 expert 权重驻留内存/显存，所以显存占用仍接近完整 MoE 模型；router 省下 FLOPs，却没有让未选 expert 从文件中消失。 在容量受限且性能要求较低的场合，可以把冷 expert 放在 CPU 内存或 SSD，路由后按需流式加载；zLLM 也把 expert source、prefetch 与预测反馈放在 backend/runtime 边界上。但这会引入 I/O 延迟、预取命中率、并发工作集和抖动问题。只有加载与当前层计算真正重叠，且命中率足够高，流式 expert 才可能在可接受延迟下换取较低驻留量。 5. zLLM 算法层的模块地图</h2> 目录/模块</th> 它定义什么</th> 它不负责什么</th></tr></thead> attention/mod.rs</code></td> 注意力家族的设备无关规格入口</td> 设备 buffer 与 command submission</td></tr> attention/rope.rs</code></td> 位置旋转、布局与 reference</td> 模型 tokenizer</td></tr> attention/gqa.rs</code>、mla.rs</code></td> GQA/MLA 几何、窗口、投影关系与 f32 reference</td> 平台专属融合 kernel</td></tr> attention/dsa.rs</code>、msa.rs</code></td> token/block 评分、因果 Top-K 与稀疏选择语义</td> 宣称所有选择路径天然是 O(K)</td></tr> attention/compressed_sparse.rs</code></td> 滑窗、压缩历史、可见位置与选择计划</td> 具体压缩 buffer 的物理驻留</td></tr> attention/gated_delta_net.rs</code>、kda.rs</code></td> recurrent/conv state 的形态、更新与 reference</td> 将其伪装成普通 KV Cache</td></tr> attention/hybrid.rs</code></td> full attention 与线性/recurrent attention 的混合层状态</td> 决定设备放置策略</td></tr> attention/hyper_connection.rs</code>、attn_res.rs</code></td> 多残差流、attention residual 等层内连接语义</td> HTTP 会话或跨节点传输</td></tr> moe/*</code></td> dense FFN、Top-K/latent MoE、路由、共享 expert 与预取反馈语义</td> SSD/显存分配和 DMA</td></tr> kv_cache/*</code></td> cache 逻辑布局、格式、容量、有效长度与持久化数据边界</td> 某平台的分配、同步和 kernel</td></tr> runtime/prefill.rs</code></td> 通用 chunk、batch、stage 与完整层循环</td> 某个模型的 layer 顺序</td></tr> runtime/generation.rs</code></td> token 生成、EOS、位置推进生命周期</td> 具体 attention/FFN 数学</td></tr> runtime/<model>/</code></td> 按模型规格组合 embedding、每层 attention + FFN、norm、LM head</td> 复制 backend 算法实现</td></tr> </tbody></table> 生产执行只有三种完整任务：NewPrefill</code> 创建新 session 与 cache，AppendPrefill</code> 在已有历史后追加一段 token，DecodeRound</code> 输入一个 token、跑完所有层、追加状态并产生下一个 token。算法层规定正确顺序，runtime 组合完整模型，backend 管资源与提交，kernel 加速局部计算。 6. CPU oracle 如何守住正确性</h2> CPU oracle 的价值不是“CPU 也能勉强跑模型”，而是把复杂设备优化拆成可验证问题： 用小而真实的 shape 验证分词后位置、mask、RoPE、矩阵维度和 cache append。</li> 用确定输入对比 CPU f32</code> reference 与设备 kernel，检查 shape、有限值、绝对/ 相对误差，以及稀疏索引和 MoE expert id 这类离散结果。</li> 逐层比较 hidden、路由与 logits，定位误差从哪一层开始放大。</li> 固定 token 序列做 prefill/decode 回归，并测试 cache 边界、追加前缀和长上下文。</li> 最后跑完整模型任务；编译通过、单算子 oracle 通过、固定 token 一致与真机性能达标是四种不同状态，不能互相替代。</li> </ol> 容差必须按 dtype、量化方式和误差传播设定，不能把统一的宽松阈值当作正确。对于 Top-K 路由、causal 选择、cache 长度和提交位置，很多不变量必须精确相等；对于 F16/BF16/量化矩阵输出，才使用有依据的 atol/rtol</code>。即使局部 kernel 对拍通过，也可能因为额外转换、同步或不合适的 shape 让端到端性能倒退，因此正确性 oracle 之后仍需要完整 prefill、decode 吞吐、峰值内存与稳定性验证。 这就是算法层在 zLLM 中的定位：它不是又一套设备实现，而是所有设备实现共同遵守的数学合同。CPU reference 让合同可执行、可回归；attention/KV 定义怎样读取历史， FFN/MoE 定义怎样加工当前表示，runtime 再把它们组合成一次完整而可验证的生成。 量化不是压缩包：从模型分层到 4-bit 推理的工程真相 2026-09-03T00:00:00+00:00 大模型量化最容易被讲成一句话：把 16-bit 权重压到 4-bit，模型缩小四倍。这句话没有错，却漏掉了几乎所有真正困难的部分。 量化首先解决的是容量问题：权重太大，显存或统一内存放不下。它还有一个潜在收益——速度可能更快：decode 常常受内存带宽限制，权重每生成一个 token 都要重新读一遍，4-bit 权重比 BF16 少搬很多字节。但“文件更小”不自动等于 “推理更快”。如果运行时先把 4-bit 全量反量化成 F16/F32，或者设备没有对应的 packed kernel，容量与带宽收益会被部分甚至全部抹掉。 所以量化不是一个文件转换选项，而是一条贯穿模型规格、权重装配、设备驻留、算子和质量验证的完整执行路径。 一、先分层：模型是什么，权重怎样存，是两件事</h2> 在 zLLM 中，模型层没有被做成一个包办一切的 Model</code> 黑盒。它被拆成几类稳定职责： model_spec/<model> 架构常量：层数、hidden、attention、MoE、tokenizer id runtime/<model> LayerSpec 展开与完整 prefill/decode 编排 weight/model checkpoint 张量名、shape 校验、模型装配 weight/format FP8、W4A16、GGUF K-quant 等字节布局 weight/codec 无 IO 的 reference decode 与布局转换 backend + kernel 权重驻留、格式分派与设备直接计算 </code></pre> 这套分层有一个关键结果：模型架构不等于权重编码。同一个线性层可以来自 BF16、 FP8、NVFP4、W4A16 或 Q4_K；格式层只解释字节，模型适配层只认名字和 shape， runtime 只描述数据流，backend 才根据设备能力选择 kernel。 这也避免了两种常见污染：格式解析代码里写满某个模型的张量名，或者 GPU kernel 里硬编码 6144</code>、256</code> 之类的模型维度。前者使新格式无法跨模型复用，后者使 “支持一种模型”伪装成了“实现一个通用算子”。 二、量化到底解决什么</h2> 1. 第一目标：让权重装得下</h3> 忽略 scale、元数据和未量化张量，一个 (N) 参数模型仅权重的理论体积约为： BF16 / FP16：2N bytes INT8： 1N bytes INT4： 0.5N bytes </code></pre> 因此 70B 模型的裸 BF16 权重约 140 GB，理想 4-bit 约 35 GB。实际 GGUF Q4_K_M 会高于严格的 4 bit/weight，因为分块 scale、minimum、对齐，以及被保留为更高精度的敏感张量都占空间。量化也只压缩它所覆盖的数据：KV Cache、activation、临时 buffer 和运行时本身仍要单独预算。 在离散 GPU 上，这决定模型能否进入显存；在 Apple UMA 上，它决定模型、KV、系统和应用能否共享同一物理内存而不触发严重内存压力。UMA 省掉了传统的 Host→VRAM staging，不代表内存容量变成无限。 2. 第二目标：减少搬运，换取速度</h3> 单 token decode 的大矩阵乘常接近 GEMV：计算复用低，瓶颈往往是读取权重，而不是乘加次数。若 4-bit 权重保持 packed，kernel 在寄存器或局部块内解码并立即累加，一次读取能带来接近四倍于 BF16 的有效权重密度。这是量化可能加速的根本原因。 但加速有三个前提： 设备有适合该格式的直接 kernel；</li> 解码、scale 处理、activation 转换和调度开销没有吃掉带宽收益；</li> 测的是完整 prefill/decode，而不是孤立的解码函数。</li> </ol> zLLM 在真实 Qwen3.8 CPU decode 路径中，Q4_K packed AVX2/FMA 直接点积曾把 16-token decode 从 107.483 秒降到 7.578 秒；继续融合相邻 gate/up 后为 7.183 秒。这个约 15 倍的变化包含“删除逐块 F32 展开”和专用向量化的共同收益，不能解释成 4-bit 对 BF16 的普遍加速倍数。反例同样重要：Gemma 4 的某个 Q4_K 双输出 kernel 虽通过 CPU oracle，完整链路却从 35.9 降到 35.5 tok/s，最终被回退。量化只提供更低的带宽下限，能否兑现要看整条路径。 三、基本思路：不是全局舍入，而是利用权重局部性</h2> 最粗糙的量化，是拿整张矩阵的最大最小值建立一个比例尺： q = round(w / scale) # 对称量化 w_hat = scale * q q = round((w - offset) / scale) # 非对称量化 w_hat = offset + scale * q </code></pre> 问题在于，权重分布并不均匀。少数离群值会把全局量程拉大，让大部分普通值挤在少数几个整数格子里。现代权重量化因此依赖三种“分层、分级、局部”的选择。 第一层是块内局部性。 不给整张矩阵共用一个 scale，而是按 32、64、128 或 256 个权重分组。每组有自己的 scale，组越小越能贴合局部分布，但元数据占比、访存复杂度和 kernel 成本也越高。 第二层是张量和通道的敏感度。 attention 的 value/output、FFN down projection、 embedding、LM head 对误差的敏感度可能不同，甚至同一张量不同通道也不同。因此 “Q4_K_M” 里的 M 不是所有权重都机械使用同一精度，而是让重要张量用更高档位。AWQ 的核心观察也类似：由 activation 分布识别少量 salient weights，保护它们比只最小化权重自身误差更有效。 第三层是层级局部性。 误差会沿深度传播，前层造成的 hidden 偏移会改变后层路由、attention 和最终 token 排序。逐层或逐块校准比一次全局量化更能控制累积误差；MoE 还要覆盖真实的 expert 路由分布，否则“没有在校准集里被选中的专家” 可能被草率量化。 这就是为什么量化格式通常不仅保存低 bit code，还保存分组 scale、minimum，甚至 importance matrix。有效 bit 数也因此不是标签上的整数：以 llama.cpp 的 Llama 2 表为例，Q4_K_M 的实际平均约为 4.80–4.84 bits/weight，而不是正好 4。 常见 GGUF 量化格式怎么选</h3> 先澄清一个经常被混用的概念：GGUF 是容器格式，不是某一种量化算法。一个 GGUF 文件保存 metadata、tokenizer、tensor directory 和张量数据；其中不同张量可以分别使用 F32、F16、Q4_K、Q6_K、IQ4_XS 等类型。因此文件名写着 Q4_K_M</code>，不代表里面每个 tensor 都是同一种 4-bit block。 常见格式可以分成四组： 家族</th> 常见名称</th> 结构与用途</th> 选择提示</th></tr></thead> 经典 block</td> Q4_0、Q5_0、Q8_0</td> 一组整数 code 配一个 scale，布局简单、kernel 覆盖广</td> Q4_0 适合兼容优先；Q8_0 常作高质量对照或量化点积的 activation 格式</td></tr> K-quant</td> Q3_K、Q4_K、Q5_K、Q6_K</td> 256 权重 super-block 内再保存子块 scale/minimum</td> Q4_K_M 是常见起点；Q5_K_M、Q6_K 用容量换质量</td></tr> I-quant</td> IQ2_、IQ3_、IQ4_NL、IQ4_XS</td> importance-aware、非线性码本或查表解码</td> 同 BPW 下质量可能更好，但必须确认目标 backend 有直接 kernel</td></tr> 混合配方</td> Q3_K_S/M/L、Q4_K_S/M、Q5_K_S/M、UD-*</td> 按 tensor 敏感度分配不同类型</td> 后缀描述整模型配方；实际类型应读取 GGUF tensor directory 确认</td></tr> </tbody></table> S/M/L</code> 最容易被误读。它们通常表示 Small、Medium、Large 的混合精度方案：例如某些 attention 或 FFN 张量升到更高 bit，其他张量保持主档位。它们不是简单的 “同一种 Q4 多三个压缩级别”，实际 BPW 也会随模型结构而变。 IQ4_XS</code> 与 Q4_K_M</code> 都在 4-bit 附近，却不是可随意互换的同一布局。前者使用非线性量化/码本思路，把有限 code 更贴近真实权重分布；后者使用成熟的 K-quant 分层 scale。前者可能以更低 BPW 获得很强质量，后者通常拥有更广泛、稳定的设备 kernel。选择时要同时看模型质量、文件大小和当前 backend 的直接执行白名单。 实际选型可以从下面的顺序开始：资源非常紧才进入 IQ2/Q2/Q3；大多数本地部署先测 Q4_K_M 或已有高质量校准的 IQ4_XS；质量敏感且内存允许则测 Q5_K_M/Q6_K；Q8_0 适合作为接近高精度的量化基线。任何发布者自定义的 UD-Q4_K_XL</code> 等名称，都应先检查内部 tensor types——它可能在不同层混用 Q4_K、Q5_K、Q6_K 和 IQ4_XS，只支持 Q4_K</code> 的 kernel 并不一定能加载整份模型。 四、为什么 4-bit 常是甜点位</h2> “甜点位”不是说 4-bit 永远最好，而是说它经常处在三条曲线的交点：容量已经大幅下降，设备仍容易高效解码，质量损失还没有像 2/3-bit 那样陡增。 llama.cpp 对 Mistral 7B、WikiText-2、512 context 的一组同口径测试很直观： 格式</th> perplexity</th> 相对 FP16 增幅</th></tr></thead> Q3_K_S</td> 6.0021</td> 5.44%</td></tr> Q3_K_M</td> 5.8489</td> 2.75%</td></tr> Q4_K_S</td> 5.7349</td> 0.75%</td></tr> Q4_K_M</td> 5.7259</td> 0.59%</td></tr> Q5_K_S</td> 5.7100</td> 0.31%</td></tr> </tbody></table> 从 Q3_K_M 到 Q4_K_M，困惑度增幅从 2.75% 降到 0.59%；再从 Q4_K_M 加到 Q5_K_S，只改善到 0.31%，但权重带宽和体积继续增加。这正是典型的“膝点”。另一组 Llama 33B 数据中，FP16、Q6_K、Q5_K_M、Q4_K_M、Q3_K_M 的 perplexity 分别为 4.1557、4.1598、4.1675、4.2081、4.3594，也呈现相似趋势。 这些数字只能证明该模型、该数据集、该 context、该量化器下的趋势。perplexity 不是聊天质量、代码正确率或长思考稳定性的同义词；0.59% 也不表示每个回答只差 0.59%。接近决策边界的 token、长链条中的早期分叉、MoE router 的 Top-K 变化，都可能把很小的局部误差放大成完全不同的输出。 因此更稳妥的经验是： 资源够时，Q5/Q6 更接近基线；</li> 容量和 decode 带宽都紧时，优先从现代 grouped/mixed 4-bit 开始；</li> 3-bit 以下需要更强的校准、重要性加权或训练补偿，不能只做朴素舍入；</li> embedding、LM head、norm、router、视觉投影等敏感部分是否保留高精度，要由模型结构与任务测试决定。</li> </ul> 五、为什么模型“可以被量化”</h2> 神经网络不是一套每一步都要求 bit-exact 的符号程序。大量参数共同形成冗余表示，相邻的权重值常能映射到相同量化格点而不改变宏观能力；LayerNorm/RMSNorm、残差连接和过参数化也给小扰动留下了容忍空间。量化利用的是这种统计冗余。 生成本身又是概率过程。模型输出的是下一个 token 的 logits，经 softmax、temperature、 top-k/top-p 和随机采样才成为文本。温度大于零时，即使权重完全相同，两次回答也可能不同；即使 greedy 解码，两个非常接近的 logit 也可能因微小数值扰动交换顺序。 但这不能推出“量化误差无所谓”。正确说法是：开放式生成通常没有唯一字符串答案，评价对象往往是“好”和“更好”，而不只是“对”和“错”；量化质量必须用分布和任务指标判断，而不能只做逐字比较。数学、代码、工具参数、JSON schema 等任务仍然有硬正确性边界。 量化模型偶尔还会在某个 benchmark 上高于浮点基线。这可能来自量化噪声打破了原有错误偏好，也可能只是有限样本、采样方差或评测器噪声。它说明质量不是逐位单调的，不说明量化普遍提升模型。只有跨 seed、跨数据集、带置信区间的重复结果，才值得称为反向收益。 六、训练与校准在补偿什么</h2> 训练后量化（PTQ）不改模型参数，只用少量代表性样本估计 scale、clipping、通道重要性或 Hessian 近似。GPTQ 逐层补偿量化一个权重对其余权重造成的误差；AWQ 利用 activation 识别并保护显著权重。它们的共同点是：优化目标不再是“每个权重离原值最近”，而是“这一层在真实输入上输出尽量不变”。 量化感知训练（QAT）则在训练/微调时模拟舍入与裁剪，让参数主动适应低精度格点。它成本更高，但在 3-bit、2-bit、activation 量化或高敏感任务上更重要。校准集也必须贴近部署分布：代码模型用纯百科文本校准，长推理模型只用短句校准，MoE 模型遗漏大量 expert，都可能得到漂亮的平均误差和糟糕的真实输出。 还要区分权重量化、activation 量化与 KV Cache 量化。W4A16 只把权重降到 4-bit， activation 仍以 16-bit 参与计算；W4A8 会进一步减少流量，却引入动态范围和融合 kernel 的新约束；KV 量化影响长上下文容量，也可能持续扰动 attention。三者不能用一个“4-bit 模型”标签混在一起。 七、围栏：约束结构，但不要伪造正确性</h2> 量化后最危险的质量问题，不一定表现为乱码。更常见的是 logit margin 变小、思考链提前分叉、长推理逐步漂移，或者工具调用在某个标点上选错 token。 工程上需要三层围栏： 算子围栏：reference decode、CPU oracle、逐层 hidden/logit 误差、真实 shape 校验，先证明低精度路径实现正确；</li> 生成围栏：JSON Schema、工具名、结束标签和 stop token 在采样前进入 token fence，保证结构合法；重复循环由独立的 generation guard 处理；</li> 质量围栏：固定 prompt 的 greedy 回归、perplexity、任务集、长上下文、多 seed 开放式评测，以及关键任务的人工审查。</li> </ol> 生成围栏只能保证“格式允许”，不能保证参数语义正确。更不能因为加了 JSON 修复器，就把量化造成的 tool selection 漂移藏起来。对于思考链，也不应把“逐字一致”设为唯一目标：chain-of-thought 本来就可能因采样而变化，而且可见推理文本不等于模型内部计算。更可靠的办法是同时检查最终答案/工具结果、关键中间约束、结束原因、循环率、长度分布，以及同一解码策略下的成功率变化。 尤其要防止一种假通过：短题、greedy、最终答案碰巧一致，于是宣布量化无损。长链条中每一步的小 logit 偏移都可能累积；应加入需要数千 token 的推理样本，记录量化前后的答案正确率、异常重启、重复、提前 EOS 和超长尾。围栏负责拦住协议级灾难，评测负责发现语义退化，两者不能相互替代。 八、工程中最容易踩的坑</h2> “支持”必须拆成四种状态</h3> 能解析文件 ≠ CPU reference 能解码 ≠ 设备存在 packed 直接 kernel ≠ 某模型默认端到端路径已经使用 </code></pre> 这四种状态必须分别记录。zLLM 在装配期验证完整执行路径：量化权重没有目标设备 kernel 就加载失败，Metal 路径禁止偷偷反量化成 F16 来掩盖能力缺口。 packed 必须一直保持到 kernel</h3> 加载时展开 F32 也许最容易写，却把体积和访存优势清零。正确的数据生命周期是：容器定位 packed bytes，format 解释布局，model 校验名字和 shape，backend 让它驻留， kernel 按块读取 code/scale 并直接累加。临时解码只在寄存器、SIMD lane 或短生命周期 scratch 中发生。 不要忽略非权重内存</h3> 权重从 16-bit 降到 4-bit，不代表峰值内存恰好除以四。长上下文 KV、prefill activation、MoE expert 工作集、视觉 encoder、output logits 和 command buffer 都可能成为新峰值。容量规划必须列出每份数据的位置、格式、消费者和生命周期。 性能必须端到端测</h3> 分别记录 TTFT、prefill tok/s、decode tok/s、峰值内存、SSD 等待、GPU 利用率与温度。量化 GEMV 快了，不代表 command submission、反量化 activation 或 output head 没有成为新瓶颈。移动设备和无风扇 Mac 还要区分冷机与热稳态。 正确性不能只看“输出通顺”</h3> 至少要依次验证：codec 对拍、单算子 oracle、逐层差分、固定 token 回归、完整任务集。 shape 与 dtype 以 checkpoint 实测为准；norm 是一维还是二维、某个投影是 BF16 还是 FP8，任何“按道理应该”都不如加载时断言。 结语</h2> 量化的真正价值不是把模型文件做小，而是重新安排“精度、容量、带宽和计算”之间的预算。4-bit 常成为甜点位，是因为它在许多模型上跨过了容量门槛，也仍能保留接近高精度的统计质量，并且适合现代设备做 packed 直算；它不是一个脱离模型、数据、硬件和任务的魔法数字。 一条可信的量化路径应当同时回答四个问题：哪些权重以什么粒度被量化，哪些敏感部分被保护；设备是否真的直接消费 packed 格式；速度收益是否出现在完整请求中；质量围栏是否覆盖长思考、结构化输出和真实任务。只有这四个答案都明确，“模型能跑”才能升级为“模型值得被部署”。 参考资料</h2> GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers</a></li> AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration</a></li> llama.cpp：Mistral 7B 量化困惑度对比</a></li> llama.cpp：不同模型与 K-quant 的困惑度记录</a></li> llama.cpp quantize：当前格式、体积与 Llama 3 8B 困惑度增量</a></li> </ul> 用 Rust 统一管理内存与显存所有权：从 Arc 到 GPU Completion 2026-09-02T00:00:00+00:00 在 GPU 推理代码里，最难维护的往往不是矩阵乘法，而是一个更朴素的问题：这块内存到底属于谁，它什么时候可以释放？ Rust 的借用、Arc</code>、Mutex</code> 和 Drop</code> 能把这个问题变得非常直接，但前提是先分清三件不同的事：谁拥有资源、谁可以修改资源、GPU 什么时候使用完资源。如果不做区分，给所有对象统一套上 Arc<Mutex<_>></code>，代码虽然能够通过编译，却会引入不必要的锁，甚至仍然可能在异步 kernel 尚未完成时提前释放显存。 zLLM 要建立一条贯穿所有 backend 的完整所有权链： 模型/文件中的数据 │ Arc<File> / Vec<u8> / Vec<f32> ▼ RocmWeight 或 RocmTensor │ Arc<DeviceBuffer> ▼ DeviceBuffer（唯一显存 allocation owner，Drop 负责回收或释放） │ backend mempool 决定复用策略；Arc clone 被 in-flight 状态保留 ▼ DeviceCompletion + HIP event（GPU 真正完成后才退休资源） </code></pre> 这套机制的关键不是“到处使用智能指针”，而是让每一种类型准确表达一种生命周期。本文说明这套机制的定义、用法、优势和边界。 1. 先回答结论：不是 Arc<Mutex<Tensor>></code></h2> 对于只读权重和大多数不可变 Tensor，推荐形态是： Arc<DeviceBuffer> Arc<RocmCooperativeMlaWeights> // 只有确实需要独立共享整个权重组时 </code></pre> 而不是： Arc<Mutex<DeviceBuffer>> Arc<Mutex<RocmCooperativeMlaWeights>> </code></pre> Arc</code> 回答“有多少个使用者共同拥有它”，Mutex</code> 回答“多个线程如何独占修改它”。权重加载后通常只读，克隆 Arc</code> 就能共享底层 allocation，没有必要为了读取指针而加锁。 &RocmCooperativeMlaWeights</code> 也不是资源 owner。它只表示当前函数临时借用一个已经存在的权重组： fn run_attention(weights: &RocmCooperativeMlaWeights) { // 函数调用期间可以读取权重；不取得整个权重组的所有权。 } </code></pre> zLLM 把 cooperative MLA 权重保存在 RocmPrefillExperts</code> 的 HashMap<usize, RocmCooperativeMlaWeights></code> 中，查询时返回引用： pub(super) fn cooperative_mla_layer( &self, layer: usize, ) -> Result<(RocmContext, &RocmCooperativeMlaWeights), BackendError> { let weights = self.cooperative_mla.get(&layer) .ok_or_else(/* ... */)?; Ok((peer.context, weights)) } </code></pre> 这里的顶层引用已经足够，因为 RocmPrefillExperts</code> 拥有权重组，调用者只在当前计算中读取它。权重组内部的每个 RocmWeight</code> 又通过 Arc<DeviceBuffer></code> 拥有真正的显存。因此即使 RocmWeight</code> 被 Clone</code>，显存也不会重复上传或复制。 只有当整个权重组要脱离 RocmPrefillExperts</code>，进入后台任务、队列或多个独立执行器长期共享时，才值得把 map 的值升级为 Arc<RocmCooperativeMlaWeights></code>。 2. 第一层：CPU 内存和文件句柄的所有权</h2> 所有权链从模型文件开始，并遵循三种典型模式。 2.1 独占字节：Vec<u8></code> / Vec<f32></code></h3> Safetensors 的 TensorData</code> 直接拥有读取出来的字节： #[derive(Clone, Debug)] pub struct TensorData { pub name: String, pub dtype: String, pub shape: Vec<usize>, pub data: Vec<u8>, } </code></pre> Vec</code> 是最直接的 RAII owner：结构存在，字节存在；结构被释放，字节也被释放。需要转换时，to_f32()</code> 返回一个新的 Vec<f32></code>，所有权随返回值移动给调用者。这种数据没有共享需求，不需要 Arc</code>，更不需要 Mutex</code>。 2.2 共享文件：Arc<File></code></h3> GGUF matrix 不会为每个 tensor 重新打开模型文件，而是保存共享文件句柄： pub struct GgufMatrix { pub name: String, pub rows: usize, pub columns: usize, file: Arc<File>, offset: u64, bytes_len: usize, bytes: Arc<OnceLock<Vec<u8>>>, } </code></pre> 矩阵切片通过 Arc::clone(&self.file)</code> 共享文件，同时拥有独立的 offset 和 shape。最后一个 matrix 释放后，文件句柄自然关闭。OnceLock<Vec<u8>></code> 则表达“原始字节最多惰性加载一次”；读路径无需每次竞争互斥锁。 2.3 共享可变索引：Arc<Mutex<HashMap<...>>></code></h3> Safetensors shard cache 是 Mutex</code> 真正适合出现的地方： type SharedShards = Arc<Mutex<HashMap<String, Arc<CachedShard>>>>; </code></pre> 这里有一个会被多个 store 共同修改的 HashMap</code>，所以既需要 Arc</code> 共享目录，也需要 Mutex</code> 串行化插入。map 中的 shard 自身是 Arc<CachedShard></code>；拿到 shard 以后即可释放 map 锁，后续读取不必一直持锁。 全局缓存只保存 Weak</code>，防止全局表永久拥有所有模型： type SharedShardCaches = HashMap<PathBuf, Weak<Mutex<HashMap<String, Arc<CachedShard>>>>>; </code></pre> 这是一种值得统一采用的缓存模式：全局 registry 用 Weak</code> 定位，真实使用者用 Arc</code> 拥有，Mutex</code> 只保护 registry 的结构变化。 3. 第二层：DeviceBuffer</code> 是显存的唯一 owner</h2> ROCm 路径中最重要的资源类型是 DeviceBuffer</code>： pub struct DeviceBuffer { device_id: i32, pointer: *mut c_void, bytes: usize, capacity_bytes: usize, recyclable: bool, async_allocated: bool, owner: Option<Arc<DeviceBuffer>>, // 省略 stage completion 与 deferred upload 状态 } </code></pre> 它同时记录设备、裸地址、逻辑大小、真实 allocation 容量、分配方式和可选上游 owner。HIP 裸指针只被关在这个底层类型里；backend 和 runtime 不直接负责调用 hipFree</code>。 真正的释放策略集中在 Drop for DeviceBuffer</code>： impl Drop for DeviceBuffer { fn drop(&mut self) { if self.owner.is_some() { return; // view 不释放 owner 的 allocation } if self.async_allocated { // 优先在正确 stream 上 hipFreeAsync } if self.recyclable { // 能安全复用时归还显式 pool } // 其余情况最终 hipFree } } </code></pre> 从上层看，分配和释放因此成为普通 Rust 值的创建与离开作用域： let buffer = Arc::new(DeviceBuffer::allocate(device_id, bytes)?); let another_user = Arc::clone(&buffer); drop(buffer); // allocation 仍存在 drop(another_user); // 最后一个 Arc 消失，才进入 DeviceBuffer::drop </code></pre> RAII 在这里带来的不仅是“自动 free”，还把同步分配、异步分配、显式复用池和 view 统一到了同一个释放入口。调用者不需要记住这块地址最初来自 hipMalloc</code>、 hipMallocAsync</code> 还是 pool。 4. 第三层：Tensor 把逻辑信息与物理存储组合起来</h2> ROCm Tensor 的定义是： #[derive(Debug, Clone)] pub struct RocmTensor { pub data: Vec<f32>, pub rows: usize, pub cols: usize, pub dtype: RocmTensorDType, pub layout: RocmTensorLayout, pub device: Option<Arc<DeviceBuffer>>, } </code></pre> 它区分两类信息： rows</code>、cols</code>、dtype</code>、layout</code> 是逻辑 Tensor 描述；</li> data</code> 是必要时存在的 host shadow；</li> device</code> 是可选的设备 resident allocation。</li> </ul> 构造一个纯设备 Tensor 时，上层只移动或共享 buffer： fn device_tensor_with_arc( buffer: Arc<DeviceBuffer>, rows: usize, cols: usize, dtype: RocmTensorDType, ) -> RocmTensor { debug_assert_eq!( buffer.bytes(), rows * cols * dtype.element_bytes(), ); RocmTensor { data: Vec::new(), rows, cols, dtype, layout: RocmTensorLayout::RowMajor, device: Some(buffer), } } </code></pre> RocmTensor::clone()</code> 会复制少量 metadata、按需复制 host Vec</code>，并克隆设备 buffer 的 Arc</code>；它不会复制显存内容。只要任意 Tensor、权重、cache 或 in-flight 任务还持有这个 Arc</code>，allocation 就不会进入 Drop</code>。 这一层让 kernel 接口可以借用： fn kernel(input: &RocmTensor, weight: &RocmWeight) -> Result<RocmTensor, Error>; </code></pre> 借用负责限制当前 CPU 调用栈中的访问；Tensor 内部的 Arc<DeviceBuffer></code> 负责底层 allocation 的共享所有权。两者职责不同，组合起来才完整。 5. 第四层：权重是不可变资源集合，不是互斥状态</h2> RocmWeight</code> 用枚举表达权重真正的 resident 形态。Dense 权重可以拥有 host F32 和设备副本；W4A16、W8A16、FP8、MXFP4、GGUF 则直接拥有 packed code、scale 等 Arc<DeviceBuffer></code>： enum RocmWeightInner { Quantized(RocmQuantizedWeight), Dense { data: Vec<f32>, resident: Option<Arc<DeviceBuffer>>, resident_bf16: bool, router_bf16: Arc<OnceLock<Arc<DeviceBuffer>>>, }, Gguf(GgufMatrix), } </code></pre> RocmCooperativeMlaWeights</code> 再把同一执行能力所需的六个权重组合起来： #[derive(Clone)] struct RocmCooperativeMlaWeights { owner_q_b: RocmWeight, peer_q_b: RocmWeight, owner_kv_b: RocmWeight, peer_kv_b: RocmWeight, owner_o: RocmWeight, peer_o: RocmWeight, } </code></pre> 这个 struct 的价值是表达“一层 cooperative MLA 的完整 resident 权重集合”，不是提供并发控制。字段加载完成后保持不变，所以只读借用或 Arc</code> 共享即可。 惰性生成的派生权重使用 OnceLock</code>，例如 BF16 router cache： Arc<OnceLock<Arc<DeviceBuffer>>> </code></pre> 这比 Mutex<Option<Arc<DeviceBuffer>>></code> 更精确：类型直接保证只初始化一次，初始化完成后的热路径只读取结果。 6. View：子 Tensor 必须反向拥有原 allocation</h2> GPU Tensor 经常只使用大 buffer 中的一段。如果 view 只保存偏移后的裸指针，原 buffer 一旦离开作用域就会释放，view 立即悬空。 zLLM 的 DeviceBuffer::view</code> 把上游 owner 存进 view： pub fn view( owner: Arc<DeviceBuffer>, offset: usize, bytes: usize, ) -> Result<DeviceBuffer, String> { let pointer = unsafe { owner.pointer.cast::<u8>().add(offset).cast() }; Ok(DeviceBuffer { device_id: owner.device_id, pointer, bytes, owner: Some(owner), // view 自己不回收 allocation .. }) } </code></pre> 所有权关系变成： RocmTensor └─ Arc<View DeviceBuffer> └─ Arc<Owner DeviceBuffer> └─ HIP allocation </code></pre> view 的 Drop</code> 发现 owner.is_some()</code> 后不会释放裸地址；它只减少 owner 的引用计数。最后一个 view 和原 owner 都消失后，真实 allocation 才会被释放或放回池。 这是用 Rust 封装显存后非常典型的收益：原本需要人工约定的“slice 不能活得比 base buffer 久”，现在由结构本身保证。 7. 最容易漏掉的一层：GPU 异步生命周期</h2> 到这里仍然没有完全解决问题。HIP kernel launch 通常是异步的：Rust 函数已经返回、局部 Arc</code> 已经 drop，并不代表 GPU 已经读完对应地址。 危险的伪代码如下： fn launch(input: Arc<DeviceBuffer>) { unsafe { hip_launch(input.device_pointer()) }; } // input 在 CPU 侧释放，但 GPU 可能仍在执行 </code></pre> 因此完整机制必须增加“完成所有权”。zLLM 用 DeviceCompletion</code> 记录当前 stream 上的 HIP event，并持有这批异步工作仍依赖的资源： pub struct DeviceCompletion { device_id: i32, event: usize, p2p_sources: Mutex<Vec<PendingP2pSource>>, stage_inputs: Vec<Arc<DeviceBuffer>>, recycled: Mutex<Vec<(usize, usize)>>, retired: AtomicBool, } </code></pre> 提交阶段形成的临时输入与 P2P 来源被转移进 completion： let completion = DeviceCompletion::record(device_id)?; while !completion.is_complete()? { // CPU 可以处理别的请求 } // event 完成后，p2p source、stage input 和待回收 allocation 才退休 </code></pre> 对于 ordered P2P，代码会克隆来源 buffer 的 Arc</code>，把它放进 PendingP2pSource</code>，再由消费端 completion 持有。于是来源卡上的 allocation 至少存活到复制或 peer read 真正完成，而不是只活到 hipMemcpyPeerAsync</code> 返回。 Mutex</code> 在 DeviceCompletion</code> 中也是局部使用：它保护可能被轮询、等待或析构路径共同退休的两个可变队列。它没有包住 Tensor，也没有包住 GPU 数据本身。 这给出一个非常重要的公式： 安全的 GPU 资源生命周期 = Rust 所有权（Arc / Drop） + GPU 顺序（stream / event） + in-flight 引用保留（completion owns Arc） </code></pre> 缺少任何一项都不完整。Arc</code> 不理解 GPU event，HIP event 也不会自动增加 Rust 引用计数；DeviceCompletion</code> 是把两个世界接起来的桥。 8. 复用池：释放不等于马上 hipFree</code></h2> 高性能推理不能让每个临时 Tensor 都直接触发同步 hipFree</code>。DeviceBuffer</code> 的 Drop</code> 会依据来源和状态选择： view：只释放对 owner 的引用；</li> async allocation：优先 hipFreeAsync</code>，保持 stream 顺序；</li> recyclable buffer：进入 stage 延迟回收或设备池；</li> 其他独占 allocation：最终调用 hipFree</code>。</li> </ol> 池本身用 Mutex<DeviceBufferPool></code> 保护 metadata： struct DeviceBufferPool { buffers: HashMap<(i32, usize), Vec<usize>>, pending: HashMap<(i32, usize), Vec<PendingDeviceBuffer>>, bytes: HashMap<i32, usize>, available_events: Vec<usize>, } </code></pre> 需要锁的是空闲地址列表、pending event 和计账，而不是 allocation 中的数十 MiB 数据。锁的作用域仅覆盖一次取出或归还，kernel 执行期间不会持锁。 这种设计把“逻辑释放”和“物理释放”分开：最后一个 Arc</code> 消失代表业务不再需要 Tensor；Drop</code> 再根据 event 与 pool 状态决定 allocation 是立即 free、异步 free 还是安全复用。上层算法无需知道这些差异。 9. Backend 无关的资源池契约</h2> 只分析 DeviceBufferPool</code> 会产生一个错误印象：仿佛内存池是 ROCm/HIP 的特殊优化。zLLM 把资源池定义为所有 backend 共同遵守的资源能力： ROCm 的 DeviceBufferPool</code> 保存 available 与 pending allocation，并用 HIP event 判断何时可重新使用；</li> Metal 的 MetalContext::scratch_pool</code> 按 (tag, len, slot)</code> 保存 metal::Buffer</code>，利用同一 command queue 上的提交顺序复用 workspace；</li> CPU Tensor 主要由 Vec<T></code> 拥有，普通 allocator 承担大部分工作，并不一定需要 GPU 式 event pool。</li> </ul> 所以 pool 的架构归属是 backend 资源管理能力，而不是 ROCm kernel 的公共语义。backend/mod.rs</code> 用统一的 MemoryPool</code> trait、MemoryRequest</code>、 MemoryKind</code> 与 MemoryLifetime</code> 定义契约。ROCm 的物理 pool 位于 kernel/rocm/hip/device_buffer.rs</code>，Metal 的物理 pool 位于 backend/metal/context.rs</code>；公共契约只统一请求和 RAII handle，不移动平台实现。 9.1 通用的应该是生命周期语义，不是裸指针实现</h3> HIP、Metal、CUDA 和 CPU 的 allocation 不能被强行塞进一个最低公分母： HIP 有 device id、stream-ordered allocation、跨卡 event 和 P2P 生命周期；</li> Metal 的 MTLBuffer</code> 本身是引用计数对象，使用 command buffer/queue 表达完成；</li> CUDA 有 stream、event、cudaMallocAsync</code> 和设备 mempool；</li> CPU 没有 GPU completion，alignment、NUMA、pinned memory 才是主要差异。</li> </ul> 因此 backend 无关层不应持有 *mut c_void</code>，也不应直接规定 hipFreeAsync</code> 一类平台动作。它真正需要统一的是五个问题： 申请：需要多少字节、对齐、用途和位置？ 拥有：返回的 storage 由哪个 RAII handle 持有？ 借出：同一 allocation 如何形成 Tensor/view？ 退休：最后一个逻辑使用者退出后，设备是否已经完成？ 复用：满足哪个 completion 条件后，allocation 可以重新进入 available？ </code></pre> 统一接口这样表达这条边界： trait MemoryPool { type Memory: Clone + Send + Sync + 'static; fn allocate_memory( &self, request: MemoryRequest, ) -> Result<Self::Memory, BackendError>; fn memory_bytes(&self, memory: &Self::Memory) -> u64; } struct MemoryRequest { bytes: usize, alignment: usize, kind: MemoryKind, lifetime: MemoryLifetime, tag: Option<&'static str>, slot: usize, } enum MemoryKind { Scratch, Activation, Cache, Weight, Transfer, } enum MemoryLifetime { Operation, Stage, Session, Model, } </code></pre> Metal 的 cached_zero_buffer_slot()</code> 通过这一 trait 申请 Scratch；ROCm 的 concat_token_rows()</code> 和 reserved concat allocation 通过同一 trait 申请 Operation/Stage Activation。接口刻意不增加统一 view()</code> 或 retire_after()</code>：view 由平台 storage 保留 owner，retirement 接到 StageExecutionBackend::Completion</code> 和 backend RAII Drop</code>，避免复制一套完成协议。 9.2 Pool 与 Arc</code> 各管一半</h3> Arc</code> 与 mempool 不能相互替代： Arc strong_count > 0 → 仍有逻辑 owner，不能退休 Arc strong_count == 0 → 进入 Storage::drop / retire → completion 未完成：进入 pending → completion 已完成：进入 available 下一次同类 allocation → 从 available best-fit/tag-slot 复用 → 没有合适块才向设备申请新 allocation </code></pre> Arc</code> 决定“业务是否仍然引用资源”，pool 决定“业务释放后物理 allocation 去哪里”。 GPU completion 位于两者之间，决定资源何时从 pending 变成 available。这三者组合才是一套完整的 backend 内存管理。 9.3 ROCm 与 Metal 的策略为什么不同</h3> ROCm DeviceBufferPool</code> 按 (device_id, capacity)</code> 管理裸 allocation，并区分 buffers</code> 与 pending</code>。这是因为 host 端 drop 时 GPU 可能尚未执行完成，必须用 event 推进 pending；同时 best-fit 容量复用能适应不同 prefill shape。 Metal scratch_pool</code> 按 (tag, len, slot)</code> 管理 Buffer</code>。tag</code> 防止语义上可能同时活跃的 workspace 意外别名，slot</code> 则允许多个同尺寸切片同时存在。同一 queue 上 “写入、消费、下一次写入”的顺序为复用提供安全边界。 因此，backend 无关不等于所有 backend 使用相同 key 和相同容器： 层次</th> 应统一</th> 不应统一</th></tr></thead> runtime</td> Tensor 用途、生命周期等级、stage/session 边界</td> HIP event、Metal command buffer</td></tr> backend capability</td> allocate/view/retire/completion 的行为契约</td> pool 的 key、best-fit 算法、平台句柄</td></tr> backend 实现</td> 本平台内一致的 owner 与回收路径</td> 另一平台的同步原语</td></tr> kernel</td> 借用输入、写入输出</td> 决定全局资源驻留和 pool 策略</td></tr> </tbody></table> 9.4 权重、activation、KV 与 scratch 不能共用一种回收策略</h3> 统一 pool 还必须保留数据用途，而不能只看字节数： resident 权重：模型生命周期内常驻，通常不进入短期复用池；</li> KV/DSA cache：属于 session，可增长、持久化或迁移，不能被 stage 结束回收；</li> activation：跨若干 kernel 或 stage，由 completion 决定退休；</li> scratch/workspace：生命周期最短，最适合按 tag/shape 高频复用；</li> pinned host staging：受 DMA completion 约束，不能按普通 Vec<u8></code> 处理。</li> </ul> 也就是说，backend 无关的 mempool 首先需要统一“生命周期等级”，然后让 ROCm、 Metal、CUDA 或其他 backend 选择物理实现。若只提供 alloc(bytes)</code> / free(ptr)</code>，上层仍然无法表达权重、KV 和临时 workspace 的根本区别。 9.5 统一架构边界</h3> zLLM 的 mempool 遵守以下不变量： 保留 RocmTensor</code>、MetalTensor</code> 等 backend associated type，不制造统一 dyn Tensor</code>；</li> backend 生命周期边界统一描述 allocation 用途、stage completion 和 session retirement；</li> ROCm 用 event 驱动 pending → available</code>，Metal 利用 command queue 顺序与 retained Buffer</code>；</li> Tensor/storage handle 持有 pool return token，或在 Drop</code> 中回到所属 pool；</li> 公共 capability 只表达真实共性，不建立通用裸指针 allocator，不让平台差异反向污染 runtime。</li> </ol> 完整关系是： Backend ├─ Tensor / Weight / Cache associated types ├─ Completion（平台自己的 event/command buffer/fence） └─ Memory lifecycle policy ├─ allocate ├─ retain in flight ├─ retire to pending └─ promote/reuse/release </code></pre> runtime 只表达资源用途与生命周期，不知道底层使用 HIP pool、Metal buffer cache、CUDA mempool 还是普通 CPU allocator。 10. 一套统一的使用规则</h2> 所有 backend 代码统一遵守下面的规则。 场景</th> 推荐类型</th> 原因</th></tr></thead> 函数内临时读取 Tensor/权重</td> &RocmTensor</code>、&RocmWeight</code></td> 不转移所有权，作用域最短</td></tr> 多个 Tensor/权重共享一块显存</td> Arc<DeviceBuffer></code></td> 最后一个使用者负责触发回收</td></tr> 共享整组只读权重</td> Arc<Weights></code>，或由单一 manager 拥有并返回 &Weights</code></td> 不需要锁</td></tr> 只初始化一次的派生权重</td> OnceLock<Arc<DeviceBuffer>></code></td> 语义比互斥 Option 更准确</td></tr> 可变 cache/registry metadata</td> Mutex<HashMap<...>></code></td> 只保护结构变化</td></tr> 全局但不应永久保活的 cache</td> Weak<T></code> registry + Arc<T></code> user</td> 自动随最后一个用户退出</td></tr> 大 buffer 的逻辑切片</td> view 内保存 Arc<owner></code></td> 防止 base allocation 提前释放</td></tr> 异步 kernel/P2P 依赖</td> completion 持有 Arc<DeviceBuffer></code></td> 直到 event 完成才退休</td></tr> 独占、短生命周期 CPU 数据</td> Vec<T></code> / Box<T></code></td> 避免无意义引用计数</td></tr> </tbody></table> 新增 GPU 接口时，可以按下面的顺序审查： 裸 pointer 是否只存在于 DeviceBuffer</code> 或 kernel FFI 边界？</li> 返回 view 时是否保留了 owner？</li> Arc</code> 的最后一个 CPU 引用消失时，GPU 是否可能仍在使用它？</li> 如果可能，哪个 completion/event 持有它？</li> Mutex</code> 是否只保护确实可变的 metadata，锁内是否包含 I/O、同步或 kernel 等待？</li> cache 是否需要 Weak</code> 防止永久驻留？</li> </ol> 11. 一个从加载到异步执行的完整例子</h2> 下面的简化例子展示这套机制如何连起来： // 1. 上传后，Arc 成为 resident allocation 的共享 owner。 let q_b = Arc::new(DeviceBuffer::upload(device_id, q_b_bytes)?); // 2. 权重只读，不加 Mutex。 let weights = Arc::new(MlaWeights { q_b: Arc::clone(&q_b), }); // 3. Tensor view 反向持有 q_b，避免基址先释放。 let shard = Arc::new(DeviceBuffer::view( Arc::clone(&weights.q_b), shard_offset, shard_bytes, )?); // 4. kernel 只借用资源。 launch_mla(input_buffer.as_ref(), shard.as_ref())?; // 5. 如果 GPU 工作越过当前 Rust 作用域，submission 必须取得 Arc。 submission.retain(Arc::clone(&input_buffer)); submission.retain(Arc::clone(&shard)); let completion = DeviceCompletion::record(device_id)?; // 6. 业务 owner 可以先退出；in-flight owner 仍保活 allocation。 drop(weights); drop(shard); // 7. event 完成后，completion 释放引用；最后一个 Arc 触发 Drop， // DeviceBuffer 决定归还 pool、hipFreeAsync 或 hipFree。 completion.wait()?; </code></pre> 这里的 submission.retain()</code> 表达统一语义；各 backend 把它落实到自己的 in-flight 资源集合。ROCm 由 active stage、ordered P2P pending source 和 DeviceCompletion</code> 完成保活，Metal 由 command buffer 的 retained resources 完成保活。 12. 这套机制带来的实际优势</h2> 生命周期从约定变成类型关系</h3> RocmTensor → Arc<DeviceBuffer></code>、View → Arc<Owner></code>、 Completion → Vec<Arc<DeviceBuffer>></code> 都可以直接从字段看出来。开发者不再依赖 “调用者应该记得晚一点 free”这样的口头约定。 显著减少重复上传和复制</h3> 克隆 RocmWeight</code> 或 RocmTensor</code> 只增加设备 buffer 的引用计数，权重显存不会被复制。量化 codes、scales 和派生 BF16 cache 也能独立共享。 错误路径自动收敛</h3> 函数在中途使用 ?</code> 返回时，已经构造成功的 Vec</code>、Arc</code>、Tensor 和 buffer 会按逆序析构。大部分错误分支不再需要手写多段 cleanup。 资源策略在 backend 内独立实现</h3> runtime 只使用 backend 的 Tensor/Weight/Completion 契约；ROCm 使用 hipFreeAsync</code>、显式 pool、stage 批量回收和 event 驱动退休，Metal 使用 command queue 与 scratch pool，两者都不改变模型算法。 并发边界更清楚</h3> 不可变数据用 Arc</code>，一次性初始化用 OnceLock</code>，可变 metadata 才用 Mutex</code>。锁竞争因此集中在小型 registry 和队列，而不是扩散到权重读取热路径。 13. 仍然需要保持警惕的边界</h2> 这套机制很强，但不是自动正确。 unsafe impl Send/Sync for DeviceBuffer</code> 是对底层 HIP 行为的人工承诺，编译器无法替我们证明跨线程和跨设备操作安全；每条新 FFI 路径仍需遵守 device/stream 规则。</li> Arc</code> 只能防止 Rust 对象析构，不能自动建立 producer/consumer stream 顺序。数据依赖仍要用 stream ordering 或 event 表达。</li> host shadow 与 device resident 同时存在时，要明确谁是最新副本；引用计数不能解决数据一致性。</li> Arc</code> 环会导致资源永久不释放。owner 方向应保持单向：view 指向 allocation， allocation 不反向拥有 view；registry 需要时使用 Weak</code>。</li> Drop</code> 不适合返回错误。真正要求“确认 GPU 已完成”的边界，应显式调用 wait()</code> 或由 scheduler 轮询 completion，析构只作为最后的安全网。</li> 不应为了形式统一把所有 Tensor 都改成 Arc<Tensor></code>。通常共享的是大块 storage， Tensor metadata 本身很小，按值移动或克隆更简单。</li> </ul> 结语</h2> Rust 可以极大降低 CPU 内存与 GPU 显存的生命周期管理复杂度。zLLM 的统一答案是： Vec / Arc<File> 管理 host 数据与文件 RocmWeight / RocmTensor 描述逻辑资源 Arc<DeviceBuffer> 共享物理显存 Drop 统一回收、异步释放与复用策略 owner Arc 保证 view 不悬空 DeviceCompletion + HIP event 保证 GPU 用完以后才退休 Mutex 只保护真正可变的 registry 与回收队列 backend mempool 统一生命周期语义，各平台保留自己的分配与完成原语 </code></pre> 因此，真正值得推广的不是 Arc<Mutex<Tensor>></code> 这个单一写法，而是这套分层的所有权协议：借用表达当前调用，Arc</code> 表达共享存活，Mutex</code> 表达可变互斥， Drop</code> 表达资源归还，event/completion 表达设备完成。 每个原语只做自己擅长的一件事，组合起来才能同时得到安全、性能和较低的开发复杂度。 解耦：让模型、算法、后端与算子独立演进 2026-09-01T00:00:00+00:00 日期：2026-08-28 初稿；2026-09-01 重写。本文基于当前源码中的 model_spec/</code>、 runtime/</code>、backend/</code>、kernel/</code>、weight/</code> 与 server/</code> 整理，描述已经存在的依赖边界，不把尚未落地的通用 Planner 或远端 Expert RPC 写成现状。 zLLM 的解耦目标不是“目录看起来整齐”，而是让变化沿正确的轴发生：模型架构变化主要进入 spec 与 runtime，新的数学语义先进入领域层，设备差异停在 backend，局部性能优化落到 kernel。一次完整推理仍由这些层共同完成，但任何一层都不需要知道所有下层实现。 1. 分层全景</h2> 主依赖沿中轴自上而下。权重格式是一条侧向数据通道：model_spec</code> 提供 shape， weight</code> 解析文件与编码，backend 决定最终 resident 形态；它不反向控制模型编排。 图中的五层主干和一个设备实现区域不是六个运行时进程，而是六类职责。设备实现内部，backend/<platform></code> 与 kernel/<platform></code> 是并列协作关系：前者管理 tensor、权重、cache、提交和迁移，后者实现参数化局部计算；两者共同兑现上层 capability，而不是 backend 层层调用一个更低级的 kernel“平台”。生产请求仍然执行完整的 New Prefill、Append Prefill 或 Decode Round；解耦只改变代码依赖与资源所有权，不把完整模型拆成彼此不知道上下文的局部演示流程。 各层一句话职责(与 README "核心边界"一致): bin/runtime、bin/tools:平台入口组合,一切 --config <yaml></code> 驱动;无模型专属、验证或 profiling binary(验证与性能归独立的 zllm-bench 项目)</li> embedded:进程内 Engine</code>,复用与服务模式相同的结构化 JSON 语义,不启动 HTTP、scheduler 或 iroh(详见 06 篇 §6)</li> server/:HTTP/H3 协议(Chat / Anthropic / Responses)、node、scheduler 与 iroh stage transport;网络服务生命周期不散落在 crate 根或模型 runtime</li> model_spec/<model>:平台与执行无关的架构配置——Config 纯常量,自身零依赖;是 runtime 编排与 weight 装配共同依赖的单一规格定义</li> runtime/<model>:LayerSpec 展开、平台无关执行编排与同目录 <backend>_*.rs</code> 平台组合;Config 经 re-export 保持定义靠近使用点</li> attention/、moe/、kv_cache/、norm.rs:领域规格、通用算法与 f32 reference 语义(设备无关)</li> backend/:平台资源、cache、completion、stream/command buffer、驻留与调度；按 capability 和数据格式选择 kernel</li> kernel/:参数化算子，模型维度不得硬编码；ROCm 的 HIP 主体已拆成独立 source.hip</code>，Rust launcher 负责加载、校验与提交</li> weight/:标准格式解析与生命周期;模型专属部分只做命名 / shape 适配</li> </ul> 2. 依赖规则(强制的方向)</h2> runtime::prefill</code> 等通用调度不依赖具体模型或具体 backend</li> model_spec</code> 只含架构常量,不依赖 crate 内任何模块;runtime 与 weight 都依赖它,彼此之间不互相依赖</li> runtime/<model>/mod.rs</code> 平台无关算法只依赖 capability trait;同目录 <backend>_*.rs</code> 才允许依赖具体平台</li> backend/</code> 与 kernel/</code> 不依赖、命名或分支到具体模型；双卡 cooperative MoE、Metal replay 等优化只能表达设备能力，不能把 GLM 层号写进 kernel</li> 领域层(attention/moe/kv_cache)只存规格/算法/reference;具体存储、kernel、同步在 backend</li> weight/ 只做格式解析与加载;算法不进权重目录,平台资源不进格式解析</li> </ol> 违反方向通常意味着依赖倒挂。例外必须是明确的平台组合文件或可测量的真实执行路径，不能为了“将来也许复用”增加空 flow、factory 或多层协议。 3. 解耦的三个交界面</h2> 交界面</th> 上游表达</th> 下游承担</th> 当前约束</th></tr></thead> A · 模型 × 领域</td> layer 数据流、完整 prefill/decode 顺序</td> attention、MoE、KV 等数学语义与 reference</td> 新语义先有可验证定义，再写设备加速</td></tr> B · 领域 × 后端</td> where</code> 子句声明所需 capability</td> tensor/cache/权重驻留、提交和迁移</td> runtime 不接触 HIP event 或 Metal command buffer</td></tr> C · 能力 × 实现</td> capability 与资源生命周期契约</td> 并列的平台 backend 和参数化 kernel</td> 两条轨道共同实现能力；kernel 无模型名和模型常量</td></tr> </tbody></table> 交界面 A:模型 × 领域。模型编排层调用领域层纯函数(如 attention::dsa::select_rows</code>、moe::topk_moe::decode_shared_experts</code>),并把 backend 作为泛型参数传入——领域算法描述"做什么",backend 决定"怎么做"。新算子(如 kpool)先进领域层钉语义 + 单测,后端的 GPU kernel 只是 reference 的加速替身;跨后端一致性(CPU oracle,atol=rtol=1e-2)保证语义不漂移。 交界面 B:领域 × 后端(capability trait)。Backend</code> 基础 trait 只放全模型共用算子;领域能力拆成独立 trait(KdaKernel、HyperConnectionKernel、 DsaPrefillBackend、ExpertPrefillBackend...),模型层的 where 子句精确声明所需能力集。新能力以默认拒绝进入——如 append_dsa_keys_gated</code> 默认返回 "backend 未实现 kpool 打包追加"错误——不强迫既有后端同步实现。 交界面 C：能力 × 设备实现。backend/<platform></code> 与 kernel/<platform></code> 位于边界的同一侧且彼此并列。backend 持有资源、resident 表示、shape/format 分派和提交语义；kernel 持有参数化的局部计算。权重经 LinearWeight</code> 枚举 (F32 / F16 / Bf16Bytes / Quantized，后者覆盖 FP8、MXFP8、MXFP4、NVFP4、 W4A16、W8A16、GGUF 等量化族)进入设备实现，backend 的 linear()</code> 选择同平台 kernel；量化路径在 kernel 内解码，不展开 F32。这里是协作关系，不是架构层级。 4. 关键决策与依据</h2> 决策</th> 依据</th></tr></thead> 不设行为型薄 model 层;Config 作为纯常量收敛进 model_spec/</td> 编排(runtime)与装配(weight)共同依赖单一规格定义,二者因此不互相依赖;model_spec 只有数据没有行为,不是旧"薄 model 层"的复活。LayerSpec 展开与编排仍在 runtime/<model>,定义靠近使用点</td></tr> associated types(Tensor/Weight/Cache)而非统一对象</td> 后端间 tensor 形态差异是本质的(CPU 值/Metal 句柄/ROCm 双态);统一对象必然 Arc<dyn>+最低公分母</td></tr> capability trait 按领域拆分</td> 模型依赖面可读;新领域能力渐进进入不破坏存量</td></tr> CPU 是 oracle,reference 先行</td> 跨后端一致性可测(atol=rtol=1e-2);GPU kernel 可疑时退化 reference 继续跑,正确性不阻塞工程</td></tr> 唯一执行流程在 runtime,平台组合在模型目录内</td> 避免 N 模型 × M 平台的复制;glm53_flash 的 rocm_node.rs 是"组合"而非"另一份流程"</td></tr> 无模型专属 binary,一切 --config yaml 驱动</td> 入口收敛;验证/profiling 归 zllm-bench 项目</td></tr> </tbody></table> 5. 优势</h2> 组合扩展线性化:新模型 × 既有算子 = 零后端代码;新算子 × 新后端 = 一个 kernel 文件 + 一个 trait 实现。GLM-5.3-Flash(mHC + KDA + kpool 三个新领域件)从零到 Amd-1 八卡真机 prefill 数日,再扩到双机 16 卡持续 stage,是这条曲线的直接验证。</li> 正确性有锚:reference 与单测先行;ROCm kpool 第一版"全量注意力退化"能上真机先跑通,语义由 CPU reference 钉死,性能后补。</li> 平台演进互不阻塞:Metal 的优化(minicpm5 异步流水、q6k 向量化)、 ROCm 的 stage 流水、CUDA 与华为 NPU AscendC 算子的接入并行推进,互不污染。</li> 审计边界清晰:依赖规则使"谁该改哪"几乎唯一确定,评审成本随规模增长慢。</li> </ol> 6. 代价与劣势(诚实清单)</h2> kernel 语义 N 份实现:Rust reference + MSL + HIP + CUDA + AscendC, 热门路径每个后端都要高性能版,绝对工作量不小。</li> 泛型实例化膨胀:每模型编排对每后端实例化;capability 叠加后 where 子句变长,编译时间与二进制体积付出代价。</li> trait 蔓延需要自律:每个新架构概念都倾向往共享 trait 加方法,"基础 Backend 保持最小"靠 AGENTS.md 纪律维持而非机制保证。</li> 跨后端行为差异要文档化:同一算子退化路径不同(如 nope-MLA 零宽 split,CPU 通过、ROCm 拒绝),散在实现注释,集中索引依赖本系列文档。</li> </ol> 7. 系列导航</h2> 02 模型层:格式支持 / Config / 权重装配 / 量化</li> 03 算法层：attention 家族 / MoE / KV cache / prefill / decode 编排</a></li> 04 backend:设备抽象 / 资源与提交 / 各平台特性</li> 05 算子:基础与融合算子 / 精度选择 / 硬件映射 / 并行基础</li> 06 服务层:围栏 / 协议 / 输入输出;§6 嵌入式库形态 (zllm::Engine</code>,进程内 generate(json))</li> 07 多节点:scheduler / 负载均衡 / 跨节点 KV 与 stage 流水 / iroh</li> 08 投机解码:事务化 verify / MTP 与 DSpark 形态 / 围栏交互 / 实证纪律</li> </ul> 为什么我只输入了一句话，却消耗了数十万 Token？ 2026-08-30T00:00:00+00:00 一句简短输入背后，是系统指令、工具定义、项目上下文和历史组成的巨大 token 流。热状态留在显存，淘汰时备份到 SSD，需要时再恢复回显存。 你明明只输入了一句话，账单或用量统计里为什么会出现数万、十几万甚至数十万 input token？ 因为 Claude Code、Codex 这类 Agent 调用后台大模型时，发送的从来不只有输入框里那句话。在真正请求模型之前，客户端会先组装一份完整的“工作上下文”：系统指令、开发者规则、工具说明、JSON Schema、当前目录和项目约束、对话历史、之前的工具调用与结果，以及为了继续任务而保留的文件片段或摘要。你的话可能只有 20 个 token，但它只是一个巨大 prompt 的最后一小段。 换句话说，Agent 每一轮都要先让后台模型知道三件事：你是谁、你能做什么、现在已经发生了什么。 这些知识不是写进模型参数的训练，也不会被模型永久记住；它们是本次推理请求中的上下文注入，下一轮通常还要再次携带。工具越多、规则越长、历史越深，请求的 input token 就越大。 这也是为什么前缀缓存如此重要。虽然客户端每轮看起来都重新发送了数十 K 的知识，但其中绝大部分与上一轮完全相同。如果服务端保存了这段 token 执行后的模型状态，就不必每次从第一个字重新计算。 大模型服务表面上很像一个普通的 HTTP JSON 服务：客户端发来消息，服务端不断返回 token。但真正开始兼容不同客户端、复用长对话、支持工具调用以后，问题很快就不再是“加几个路由”那么简单。 我们在 zLLM 中实现了三套当前最常见的接口：OpenAI Chat Completions、OpenAI Responses 和 Anthropic Messages；在执行层实现了显存与 SSD 两级前缀缓存；在生成层又为 DeepSeek DSML 工具调用加入了 token 级围栏。它们表面上是三个功能，实际都在解决同一个问题：协议状态、模型看到的 token，以及设备中保存的计算状态必须严格对齐。 这篇文章不只介绍最终设计，也会把过程中踩过的坑讲明白。 一句话背后的数十 K 上下文</h2> 一次典型的 Claude Code 或 Codex 请求，可以粗略拆成下面几部分： 上下文组成</th> 里面有什么</th> 为什么每轮可能重复出现</th></tr></thead> 系统与开发者指令</td> 身份、安全边界、回答格式、编码规范、工作流程</td> 模型本身不会跨 HTTP 请求记住这些规则</td></tr> 工具定义</td> shell、文件、搜索、浏览器等工具的名称、描述和参数 Schema</td> 模型必须知道有哪些动作以及怎样合法调用</td></tr> 工作区知识</td> 当前目录、仓库规则、AGENTS.md、环境与权限信息</td> Agent 需要在正确项目和约束下行动</td></tr> 对话历史</td> 用户要求、模型分析、已完成步骤与中间结论</td> 保持多轮任务连续性</td></tr> 工具调用和结果</td> 执行过的命令、读取的文件、错误日志和返回数据</td> 后续判断依赖这些观察结果</td></tr> 当前输入</td> 你刚刚键入的那一句话</td> 通常只是整个 prompt 的尾部</td></tr> </tbody></table> “数十 K 的知识先灌输给模型”说的就是这个过程。这里的 K 是千 token：10K 约等于一万个 token。它不等于一万个汉字，因为 tokenizer 会把文本、标点、路径、代码和 JSON 按各自规则切分。尤其是工具 Schema，字段名、描述、枚举、嵌套对象和协议样板都会计入 input token；同时启用几十个工具时，仅工具说明就可能占据非常可观的上下文。 客户端界面往往只展示用户消息和最终回答，所以这部分成本很容易被误解为“模型偷偷生成了几十万 token”。实际上，用量通常至少分成三类： input_tokens</code>：本轮送进模型的完整上下文，不只是用户新输入；</li> cached_tokens</code>：input 中已由服务端复用计算状态的前缀；</li> output_tokens</code>：模型本轮新生成的 reasoning、正文或工具调用。</li> </ul> 不同服务商如何计费要以各自规则为准，但在计算语义上，cached_tokens</code> 仍然属于输入上下文。它表示这些 token 确实在 prompt 中，只是服务端没有重新完成同样的 prefill 计算。于是会出现一个看似矛盾、其实完全合理的现象：本轮 input token 仍有十万，但真正重新计算的输入可能只有最后几百个 token。 如果缓存没有命中，这十万 token 就要重新经过完整模型的每一层，首 token 延迟会明显增加；如果缓存命中，服务端恢复旧状态，只对新追加的用户消息和 assistant 起始部分做 append prefill。这正是本文后半部分显存与 SSD 两级前缀缓存要解决的问题。 三种主流接口，差异不只是 JSON 字段名</h2> zLLM 对外提供三个主要入口： 接口</th> 典型客户端</th> 输入核心</th> 流式输出</th> 会话续接</th></tr></thead> POST /v1/chat/completions</code></td> OpenAI SDK、通用聊天前端</td> messages</code></td> Chat chunk SSE</td> 客户端重传完整历史，可携带 cache 标识</td></tr> POST/GET /v1/responses</code></td> Codex、ZCode、新版 Agent 客户端</td> input</code> item</td> Responses SSE 或 WebSocket event</td> previous_response_id</code></td></tr> POST /v1/messages</code></td> Claude Code、Anthropic SDK</td> system</code> + messages</code></td> Anthropic event SSE</td> 客户端重传历史</td></tr> </tbody></table> 三者最终都会变成同一种内部任务：结构化消息经过模型自己的 chat template 变成 token，随后执行 NewPrefill</code>、AppendPrefill</code> 和 DecodeRound</code>。但协议适配层不能只做字段重命名。 Chat Completions：最直接，也最容易成为内部公共形态</h3> Chat Completions 的核心是有序 messages</code>。工具统一采用 OpenAI function tool 形态： { "model": "deepseek-v4", "messages": [{"role": "user", "content": "查一下上海天气"}], "tools": [{ "type": "function", "function": { "name": "get_weather", "parameters": { "type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"] } } }], "stream": true } </code></pre> 非流式响应把文本和 tool_calls</code> 收拢到一个 assistant message；流式响应则要保持 tool call 的 index</code>、id</code>、函数名和参数增量稳定。这里有一个容易忽略的问题：工具调用 ID 不能只由工具名生成，否则同一工具在不同请求或同一响应中多次调用会发生碰撞。我们的做法是把请求级 scope、调用序号和工具名一起哈希。 Chat Completions 很适合作为服务内部的规范形态，因为角色消息、工具定义和采样参数都比较直接。Responses 和 Anthropic 请求进入服务后，会先严谨地转换成这一公共结构，再交给 scheduler 和 runtime。 Responses：它是事件协议，不是换皮的 Chat</h3> Responses 的输入不是单纯的消息数组，而是 input</code> item 流。它可以包含普通 message、function_call</code>、function_call_output</code>、图片输入，以及 Codex Responses Lite 放在输入前缀中的 additional_tools</code>。后者还可能用 namespace 包裹真正可执行的 function，因此转换时要展开 namespace，同时跳过当前无法本地执行的托管工具类型。 输出同样不是一个不断增长的 delta.content</code>。文本、reasoning 和 function call 是不同的 output item，各自有生命周期事件：创建、增量、完成，最后才是整个 response 的 completed 或 failed。尤其是 reasoning，必须作为独立的 output[type=reasoning]</code> 暴露，不能混进正文，否则 Codex 一类客户端无法正确渲染和恢复状态。 我们同时支持两种传输： HTTP POST + SSE，适合普通 SDK；</li> GET /v1/responses</code> 升级为 WebSocket，一条连接串行复用多次 response.create</code>，适合长时间运行的 Agent 客户端。</li> </ul> previous_response_id</code> 也值得单独说明。zLLM 会持久化上一轮的协议消息和 cache key，因此进程重启后仍能恢复对话链；但它本身不持有模型 KV。协议历史恢复成功，只代表我们能重建完整输入，不代表设备缓存一定还在。随后是否命中显存或 SSD cache，仍由 runtime 独立判断。 Anthropic Messages：内容块和事件顺序必须原样成立</h3> Anthropic Messages 把 system</code> 放在顶层，正文由 content block 组成。工具定义使用 name</code>、description</code>、input_schema</code>，工具调用和结果则分别是 tool_use</code> 与 tool_result</code> block。适配层需要把它们双向转换成内部 function tool，而不是把 block 粗暴拼成字符串。 流式响应的事件顺序也有严格语义：先 message_start</code>，再打开一个 content_block_start</code>，发送对应 delta，关闭 block，最终发送 message_delta</code> 和 message_stop</code>。文本与多个工具调用可能占据不同 block index；如果只把 Chat SSE 的字段名改掉，客户端会得到顺序错误或无法闭合的内容块。 Claude CLI 还会调用 /v1/messages/count_tokens</code> 判断何时自动压缩上下文。这个接口即使只是估算，也必须读入 system、messages 和 tools，而不能只数用户正文，否则压缩触发点会严重偏后。 cache hit 到底意味着什么</h2> 在推理服务里，cache hit 不是“找到了相似问题”，也不是“直接返回上次答案”。它的精确定义是： 新请求 token 序列的开头，与某个已保存会话的 token 序列逐 token 完全相同，因此可以恢复这一前缀执行完后各层的 KV、DSA/MTP 等模型状态，从前缀末尾继续计算。 </blockquote> 假设上一轮终点状态对应： [system][tools][user-1][assistant-1] </code></pre> 新一轮输入是： [system][tools][user-1][assistant-1][user-2][assistant-prefix] |<----------- cached_tokens ----------->|<-- append prefill --> </code></pre> 命中后，前面 cached_tokens</code> 个 token 不再重新通过完整 Transformer；只对新增后缀执行 append prefill，再进入 decode。它降低的是 TTFT 和重复 prefill 计算，不会消除新问题的 decode，也不会缓存答案。 这一定义有几个重要后果： 必须是 token 前缀相等，不是文本“看起来一样”。 空格、JSON 序列化方式、工具 schema 顺序、thinking 开关、chat template 或特殊 token 变化，都可能让前缀分叉。</li> cache ID 是定位提示，不是正确性凭证。 即使客户端给出精确 ID，runtime 仍要检查 token 前缀与 namespace；不匹配就回退到最长前缀或冷启动。</li> 命中长度必须小于新 prompt 长度。 如果直接把一个完整终点当成待执行输入，却没有新增 token，模型没有合法的 append 边界。</li> cache hit 不是 cache resident。 命中的状态可能在显存，也可能已经换出到 SSD。二者节省的计算相同，但恢复延迟完全不同。</li> </ol> 我们为 terminal cache 计算稳定身份时，不只包含用户消息，也包含模型、模板相关请求、assistant 输出和结构化 tool calls。否则“屏幕上看起来相同”的两轮请求可能错误共享不兼容的模型状态。 为什么要做显存与 SSD 两级存储</h2> 长上下文 KV 很贵。以数万到数十万 token 的 Agent 对话为例，保留每个历史分支的设备状态能显著减少重复 prefill，但显存不可能无限增长。只做 LRU 删除又意味着刚淘汰的长对话下一轮要从头算起。 我们的两级机制可以概括为： 请求到达 ├─ 精确 cache_id 命中显存 ────────┐ ├─ 显存中搜索最长 token 前缀 ─────┤ ├─ 精确 cache_id 命中 SSD ────────┤→ append prefill → decode ├─ SSD 中搜索最长 token 前缀 ─────┤ └─ 都未命中 → new prefill ────────┘ 显存层：可直接继续计算，容量小，延迟最低 SSD 层：保存压缩快照，容量大，需要读盘和 H2D/设备恢复 </code></pre> 一级：显存中的 resident terminal cache</h3> 每次请求成功结束后，引擎保留终点 session，其中包括 token 序列、namespace、父节点/轮次关系和模型私有执行状态。公共 cache 层只负责所有权、前缀图和淘汰；具体有哪些 KV、压缩环、DSpark target cache，由模型 runtime 自己定义。 这里必须有真实的驻留预算，而不能只限制“最多保存 N 个会话”。两个 token 数接近的会话，占用也可能相差数倍：除线性 KV 外，还有 recent/compressed 环、batch scratch、推测解码 block 和 target cache 等固定或阶梯式开销。我们最终按真实 allocated_bytes</code> 做 admission 和诊断，并在请求开始前预留后续 decode 仍会增长的容量。 缓存还不是一条简单 LRU 链。Agent 对话会从同一个历史点分叉，因此内存层维护共享前缀 block graph：父状态可以被多个后继复用，只有不再需要的分支才真正释放。terminal_cache_prefix_rounds</code> 控制保留多少轮祖先，避免每个中间终点永久占据设备。 二级：SSD 上的可恢复快照</h3> 显存淘汰一个值得保留的终点时，runtime 下载模型状态，按模型版本编码成快照，写入 SSD。索引中保存 cache ID、完整 token 序列、namespace、轮次、head 标志、设备驻留字节数和 blob generation；大块 KV 数据采用分块存储。 写入必须具有提交边界。manifest 只能在数据 blob 完整落盘后切换到新 generation，这样进程崩溃时不会留下“索引存在、内容不完整”的半份缓存。读取端把磁盘内容当作不可信输入：所有长度、计数、版本和剩余字节都要检查，不能让损坏快照触发越界或巨量分配。 SSD 命中后，引擎优先复用已经分配过的空 session buffer，把各 stage cache 上传回设备，并恢复 DSpark 等附属状态。恢复完成后设置 next_prefill = cached_tokens.len()</code>，只计算新增部分。 SSD 层也支持最长前缀搜索，而不是只能依赖 ID。搜索条件仍然是严格的 tokens.starts_with(snapshot.tokens)</code>，并且要隔离 namespace。为了排查“几乎命中却没命中”的线上问题，我们会记录公共前缀超过 1024 token 且覆盖旧快照 90% 以上的 near miss；这种日志通常能直接暴露模板、工具回显或序列化分叉。 两级缓存实现中真正棘手的问题</h2> 1. 淘汰顺序与 admission 死锁</h3> 最早的实现先为新请求申请显存，再淘汰旧 cache。结果是明明有可淘汰状态，却因为预算不足拒绝新请求。正确顺序是先识别可牺牲的 resident cache，完成必要的换出和释放，再做 admission；同时为 decode 增长预留空间，避免 prefill 恢复成功后在生成中途耗尽显存。 2. 异步恢复并不等于可以提前开始计算</h3> SSD 读取、CPU 解码和多 GPU H2D 可以并行，但依赖关系不能省略。我们遇到过 restore 任务仍在写设备 cache，计算流已经开始读取的情况；也遇到 cache open 命令没有 drain 就复用资源。修复不是“多加一个全局同步”，而是为每个 stage 明确 restore 完成事件，只让互不依赖的 I/O 与上传并行，在第一次消费前等待对应依赖。 3. reusable pool 也会泄漏</h3> 如果每次 SSD 恢复都新建 session，旧设备 buffer 虽然进入 reusable pool，却长期没有机会被拿出来，显存仍然越堆越高。恢复路径必须优先从 pool 取一个 session 并覆盖其 cache；失败和取消路径也必须 reset 后归还，而不是只处理成功请求。 4. 工具回显是缓存链最常见的断点</h3> 工具调用经历“模型原生文本 → API 结构化 tool call → 客户端执行 → 下一轮历史重新编码”。只要正向解析和历史重放不互为逆操作，下一轮 token 就会在工具位置分叉。我们曾遇到 DSML terminal cache 续接失败，根因正是工具标签、参数字符串/JSON 类型或大小写规范化后的回显不一致。 解决方法是让每种 ToolDialect</code> 同时拥有四个能力：注入 instructions、渲染历史 tool call、渲染 tool result、解析模型输出。它们必须来自同一个协议实现，不能散落在 HTTP 层和各个 backend 中。 工具调用围栏：为什么事后解析还不够</h2> 仅靠 prompt 告诉模型“请输出合法 JSON”并不可靠。模型可能生成不存在的工具名、重复参数、漏掉 required 字段、在 JSON 中提前输出闭合标签，或在长推理后陷入重复。等整段文本生成完再解析，只能宣布失败，无法挽回已经浪费的 decode。 因此我们把工具支持分成三层： 协议提示与历史渲染：把统一 function schema 编码为模型训练时熟悉的 GLM XML、ChatML JSON 或 DeepSeek DSML。</li> 增量解析：流式识别正文和工具区域，把合法调用转换成统一 tool_calls</code>，同时避免把半个标签提前泄露给客户端。</li> token 级生成围栏：在采样之前，根据当前语法状态强制或排除候选 token，使结构化区域只能沿合法路径生成。</li> </ol> 第三层才是“围栏”的核心。以一个指定的 DeepSeek DSML 工具为例，状态机依次经过： 固定 tool_calls/invoke 前缀 ↓ 选择一个尚未出现的参数 ↓ 按该参数 JSON Schema 生成值 ↓ 参数闭合；required 是否齐全？ ├─ 否：只能继续选择参数 └─ 是：允许闭合 invoke/tool_calls </code></pre> 固定标签、工具名和参数名由围栏强制下一个 token；参数值由 JsonSchemaFence</code> 给出允许集合；每个参数只能出现一次；required 未齐全时，结束标签根本不会进入候选集。字符串参数还要排除会意外打开 markup 的 token，终止 token 在结构未完成时同样被禁止。 tool_choice=auto</code> 更复杂：模型在普通正文阶段应保持自由，只有检测到 DSML trigger 后围栏才激活。激活时可能仍有多个候选工具，状态机并行推进所有仍与已生成 token 相容的分支；候选收敛到一个后，再使用该工具的参数 schema。这里不能一开始就强迫模型调用工具，否则 auto</code> 会被错误实现成 required</code>。 围栏位于 output head 与采样之间。普通 decode、batch 中的每一行、MTP/DSpark draft 和 speculative verify 都必须应用同一份请求级围栏状态。漏掉任何一条路径，就会出现“不开推测解码时正常，一开就偶发非法工具 JSON”的问题。 围栏实现中踩过的坑</h2> tokenizer 边界不是字符串边界</h3> 标签 </...></code> 在 tokenizer 中可能跨 token，也可能共享一个 </</code> token。围栏不能假设每个字符或标签都是独立 token。初始化时要用当前模型 tokenizer 编码所有 literal，并验证闭合片段的首 token 与预期边界一致；不一致就拒绝启用，而不是在生成中途进入不可达状态。 auto 分支不能取错误的交集</h3> 多个候选工具的下一 token 可能不同。正确的允许集合是所有仍合法分支的并集；只有所有分支都禁止某 token 时才能排除它。如果把排除集合简单合并，就会过早杀死仍然合法的工具分支。每生成一个 token 后，还要淘汰与它不相容的候选状态机。 draft token 也要逐个推进临时状态</h3> 推测解码一次提出多个 token。不能只拿当前围栏验证整段，也不能让草稿直接推进正式状态。正确做法是 clone 一份 guard，逐 token 计算该位置的 fence 并推进 probe；target verify 通过的前缀提交后，再推进正式状态。若围栏已经强制某些 token，还可以直接构造这些位置，避免无意义的 logits 计算。 协议修复不能只靠 parser 打补丁</h3> 我们处理过大小写不一致、转义的 DSML 标签和游离闭合标签。parser 的容错能兼容已有模型输出，但如果问题属于可预知的结构错误，更根本的修复仍然是采样前围栏。否则非流式看似“被修好了”，流式过程中却可能已经把错误片段发给客户端。 围栏还要与失控循环保护组合</h3> 工具语法约束解决“结构非法”，不解决模型在 thinking 中重复同一段内容。zLLM 的 GenerationGuard</code> 会检测重复 token、重复模式和带证据的语义重启，在下一次采样时排除已知会继续循环的 token；若 speculative batch 内已经发现循环，则截断已验证行，必要时用 reasoning-end token 收口。工具围栏和循环保护最终合并成同一个 TokenFence</code>，但两者保持独立状态机，避免协议逻辑污染通用生成层。 一条请求最终如何穿过整个系统</h2> 把三套接口、两级缓存和工具围栏放在一起，一条真实请求的路径是： Chat / Responses / Anthropic request ↓ 协议校验与规范化 统一 messages + function tools ↓ 模型 dialect/template/tokenizer 完整 prompt tokens + cache identity ↓ 显存精确/最长前缀 → SSD 精确/最长前缀 → 冷启动 ↓ NewPrefill 或 AppendPrefill ↓ output head → 请求级 token fence → sampling/speculative verify ↓ 原生工具流增量解析 ↓ Chat chunks / Responses events / Anthropic content blocks ↓ 成功终点写入 resident cache，淘汰时持久化到 SSD </code></pre> 这条链路中，HTTP 层不拥有 KV，cache 层不理解模型协议，backend 不认识工具名，模型 runtime 也不负责某一种外部 SSE 格式。每一层都只保存自己必须知道的语义，但边界上传递的是可验证的真实状态，而不是一个含糊的“会话 ID”。 最后的判断标准</h2> 前缀缓存是否正确，不看日志里有没有打印 hit=true</code>，而要验证恢复后的 token、position、各层 KV 和附属状态与完整 prefill 一致；收益则看真实 TTFT，而不是只算跳过了多少 token。 工具调用是否正确，也不看最终字符串能否被一次 JSON parser 接受，而要验证流式事件顺序、历史回放、下一轮 cache 续接，以及普通 decode、batch、speculative 路径是否都执行了同一语法约束。 我们最终得到的经验很朴素：接口兼容的终点不是 JSON 长得像，缓存命中的终点不是 ID 对得上，结构化生成的终点也不是事后能修。 真正可靠的实现，必须一直落到模型实际看到的 token 和设备实际保存的状态上。 MacBook Air M5：零依赖运行多模态大模型！ 2026-08-29T00:00:00+00:00 不安装 Python、PyTorch、Conda、Docker，也不启动常驻模型服务：一个 Rust 对象、一份 GGUF 权重，就能把原生多模态推理放进自己的进程。 </blockquote> 这篇文章在一台 24 GB 内存、10 核 Apple M5 的 MacBook Air 上完成。当前 release 版 zllm-metal</code> 是 8.1 MB；配合 Gemma 4 E4B 的 Q4_K_M 主模型和视觉投影，它可以直接通过 Metal 完成多轮对话和图像理解。 先说明标题中的“零依赖”：它指的是交付和运行时不依赖第三方推理框架。最终用户不需要 Python 环境、PyTorch 动态库、CUDA 工具包或单独管理的 C++ runtime；模型权重仍然是推理所需的数据，macOS 自带的 Metal 与系统框架也仍然存在。从源码构建时，Cargo 会正常编译 zLLM 使用的 Rust crates，并把它们链接进原生程序。 库模式是怎样工作的</h2> zLLM 不是对另一个本地服务的 HTTP 包装。zllm::embedded::Engine</code> 直接持有模型、Metal backend、KV Cache 和生成状态，在调用方进程内走完整推理路径： Rust 应用 └─ Engine::from_config（装载一次） ├─ GGUF 权重与 chat template ├─ Metal backend / kernels └─ terminal KV Cache ↓ Engine::generate（重复调用） ├─ OpenAI Chat JSON → template → tokenize ├─ 可选 image_url → mmproj → 视觉 embedding ├─ prefill / append prefill / decode └─ 每个 token 通过 Rust 回调返回 </code></pre> 这条路径与 zLLM 的 Metal node 共用模型 runtime、权重装配和生成状态机，只是没有启动 HTTP、Scheduler 或 iroh。 接口</th> 用途</th></tr></thead> Engine::from_config(path)</code></td> 从 kind: standalone</code> YAML 装载模型和 backend，但不启动服务</td></tr> Engine::load(...)</code></td> 已经解析配置时直接装载</td></tr> Engine::generate(...)</code></td> 接受结构化 Chat JSON，通过回调流式返回 token</td></tr> Engine::cancellation()</code></td> 创建可复制到 UI 或控制线程的取消句柄</td></tr> Engine::kv_resources()</code></td> 查看 KV capacity、active、resident、available 和单会话占用</td></tr> GenerationResult</code></td> 返回结束原因、输入/输出 token 数和后续轮次可复用的 cache_id</code></td></tr> </tbody></table> 回调返回 false</code>，或从另一线程调用 Cancellation::cancel()</code>，生成就会结束。引擎释放时还会执行优雅关闭；调用方不需要管理 Metal command buffer，也不会接触平台 KV 对象。 在任意 Rust 程序中嵌入</h2> zLLM 源码已在 GitHub</a> 公开。 可以直接使用 Git 依赖，也可以 clone 后改成本地 path</code>。 </blockquote> 在现有项目的 Cargo.toml</code> 中加入： [dependencies] serde_json = "1" zllm = { git = "https://github.com/zllm-lab/zllm" } </code></pre> 把路径换成 zLLM 源码在本机的实际位置。下面是一个完整的最小程序：引擎只加载一次，之后可以反复调用 generate</code>。 use std::io::{self, Write}; use serde_json::json; use zllm::embedded::Engine; fn main() -> Result<(), String> { let mut engine = Engine::from_config("gemma4-metal.yaml")?; let cancellation = engine.cancellation(); let result = engine.generate( &json!({ "model": "gemma4", "messages": [{ "role": "user", "content": "用一句话解释为什么推理引擎适合嵌入应用" }], "max_completion_tokens": 128 }), &cancellation, |_token, text| { print!("{text}"); io::stdout().flush().is_ok() }, )?; println!( "\nfinish={} prompt={} completion={} cache={:?}", result.finish_reason, result.prompt_tokens, result.completion_tokens, result.cache_id ); Ok(()) } </code></pre> 后续轮次继续传完整的 messages</code>。Runtime 会校验 cache identity 和真实 token 前缀；匹配时恢复 terminal session，只为新增后缀执行 append prefill，不匹配时安全回退到最长公共前缀或完整 prefill。 图像输入仍然使用同一个接口，只需把 user content 改成有序的图文 part： let cancellation = engine.cancellation(); let result = engine.generate( &json!({ "model": "gemma4", "messages": [{ "role": "user", "content": [ {"type": "text", "text": "请描述这张图片"}, {"type": "image_url", "image_url": { "url": "/absolute/path/to/photo.png" }} ] }], "max_completion_tokens": 256 }), &cancellation, |_token, text| { print!("{text}"); io::stdout().flush().is_ok() }, )?; </code></pre> 本地路径、HTTP(S) URL 和 data:</code> URL 会进入同一套图像物化与视觉编码路径。Gemma 4 E4B 的 mmproj</code> 在第一次图像请求时懒加载；只做文字对话时不必先装载视觉塔。 准备 Gemma 4 E4B</h2> 本文使用 instruction-tuned 的 Gemma 4 E4B GGUF： Hugging Face：unsloth/gemma-4-E4B-it-GGUF</a></li> 魔搭 ModelScope：unsloth/gemma-4-E4B-it-GGUF</a></li> </ul> 下载下面两个文件，并放在同一个目录： models/gemma-4-E4B-it-GGUF/ ├── gemma-4-E4B-it-Q4_K_M.gguf # 主模型，4.98 GB └── mmproj-F16.gguf # 视觉编码器/投影，990 MB </code></pre> 可以在上面的文件页直接下载，也可以临时使用 Hugging Face CLI；这个下载工具不是 zLLM 的运行时依赖： hf download unsloth/gemma-4-E4B-it-GGUF \ gemma-4-E4B-it-Q4_K_M.gguf mmproj-F16.gguf \ --local-dir ./models/gemma-4-E4B-it-GGUF </code></pre> 国内网络可以从魔搭页面选择同名文件。Q4_K_M 在 24 GB MacBook Air 上兼顾体积和质量；视觉投影约 1 GB，保留 F16 可以避免再引入一层视觉量化误差。 库模式使用的最小 gemma4-metal.yaml</code> 如下： version: 1 kind: standalone http: listen: 127.0.0.1:8000 public_base_url: http://127.0.0.1:8000 artifacts: directory: ./artifacts node: cache_directory: ./cache/gemma4 persist_kv_cache: false max_concurrency: 1 model: architecture: gemma4 weights_directory: ./models/gemma-4-E4B-it-GGUF/gemma-4-E4B-it-Q4_K_M.gguf lm_head_quantization: native max_sequence_length: 49152 execution: prefill_chunk_size: 2048 backend: kind: metal device: default </code></pre> 配置里保留 http</code> 和 artifacts</code> 是为了与 standalone 配置结构兼容；Engine::from_config</code> 不会监听端口。 一个 8 MB 的 Metal 命令行程序</h2> 只想在终端里马上对话时，不需要写 YAML。直接从 GitHub 获取源码并构建： git clone https://github.com/zllm-lab/zllm.git cd zllm cargo build --release --bin zllm-metal </code></pre> 然后把主模型路径直接传给 8.1 MB 的 release 程序： ./target/release/zllm-metal \ ./models/gemma-4-E4B-it-GGUF/gemma-4-E4B-it-Q4_K_M.gguf </code></pre> zllm-metal</code> 会自动完成这些工作： 从 GGUF metadata 识别 Gemma 4 架构；</li> 发现同目录的 mmproj-*.gguf</code>；</li> 如果存在匹配的 mtp-*.gguf</code>，自动启用 MTP 投机解码；</li> 根据统一内存、权重和安全余量推导 KV 预算与上下文；</li> 装载 Metal runtime，进入多轮终端对话并复用 terminal KV Cache。</li> </ol> 这台机器的一次实际启动输出是： [zllm-metal] gemma4 (hybrid GQA, KV f16) | 权重 4.64 GiB | KV 预算 7.96 GiB | ≈172032 B/token | 上下文 49152 (模型上限 131072) [zllm-metal] 模型加载完成(1.4s),直接输入消息开始对话 </code></pre> 直接输入文字即可对话： > 请用一句话介绍你自己，并说明你正在本地 Mac 上运行。 </code></pre> 识别本地图片时，把路径和问题放在同一条消息里即可；裸路径、引号、反引号和带空格路径都支持，路径本身不会进入模型提示词： > 请用两句话描述这张图片 `/Users/me/Pictures/demo.png` </code></pre> 也可以先复制图片，再输入： > /paste 请描述剪贴板中的图片 </code></pre> 常用命令如下： /stats 查看上下文与 KV 内存 /reset 清空当前对话 /compact 压缩较早的对话历史 /paste 读取 macOS 剪贴板中的 PNG 图片 /exit 退出 </code></pre> 真机结果与视频演示</h2> 下面的数据均来自这台 MacBook Air M5（24 GB）和同一份 Q4_K_M 权重，不是理论估算： 项目</th> 实测结果</th></tr></thead> zllm-metal</code> release 文件</td> 8.1 MB</td></tr> CLI 自动上下文</td> 49,152 token</td></tr> 模型加载（本地热文件缓存，多次启动）</td> 0.9–1.6 秒</td></tr> 文本 tg50</code>，三次冷启动均值</td> 40.47 token/s</td></tr> 同一 115-token 回复的全段 decode</td> 38.1–38.5 token/s</td></tr> 323-token 图文请求 prefill</td> 6.469 秒</td></tr> 同一图文请求 TTFT</td> 7.312 秒</td></tr> </tbody></table> 下面的 23 秒短片把同一次终端流程排成更易阅读的画面：启动 zllm-metal</code>、进行文字对话、把刚才那张本地图片路径交给模型、查看 KV 状态并退出。命令、启动数据、token 数和回答文字均取自实机终端输出；画面只做了换行和节奏编排。 当前浏览器不支持内嵌视频，请直接下载演示文件。 </video> 这段视频验证的是从模型装载、文字对话到视觉输入的完整调用链，不是模型精度评测。速度会随模型版本、上下文、采样参数、文件缓存和机器散热状态变化。 </blockquote> 最后的边界</h2> zLLM 的目标不是把 Python 环境换成另一套庞大 runtime，而是让模型执行真正成为应用的一部分：一个 Rust 对象、一份模型、一个原生 backend。应用拥有自己的线程、取消、缓存和生命周期，不必把核心能力委托给另一个进程。 对 Rust 开发者来说，“给现有程序增加本地 AI”因此不再是一次服务部署，而是一次普通的库调用；对终端用户来说，它就是一个 8 MB 级原生程序，在 MacBook Air 上完成文字与图像推理。 为什么我们要用 Rust 重新写一个推理引擎 2026-08-29T00:00:00+00:00 zLLM 的定位不是给既有框架增加一个 Rust 外壳，而是以 Rust 为主体、以最少且必要的第三方依赖，从模型执行、数据生命周期和硬件资源出发，重新设计一个原生推理引擎。 </blockquote> 这篇文章回答三个问题：zLLM 为什么必须拥有自己的引擎边界，为什么 Rust 恰好适合表达这些边界，以及这种选择如何落实到真实代码与完整推理路径中。 今天再写一个大模型推理引擎，很容易被问到两个问题：为什么不用已经成熟的引擎？为什么偏偏选择 Rust？ 如果目标只是尽快让一个模型跑起来，复用现有框架通常是更经济的选择。但 zLLM 要解决的不是“把模型跑起来”这一件事。我们希望同一套引擎能够面对 Apple UMA、CPU、CUDA、ROCm、Vulkan、NPU、本地 SSD、大模型 MoE 权重、长上下文 KV Cache，以及未来多机分层执行。这些资源有不同的存储位置、同步方式、带宽、生命周期和失败边界。真正困难的部分，不是再封装一次算子 API，而是让整个推理过程的资源关系足够清楚，清楚到可以被验证、优化和长期演进。 因此，zLLM 选择从头设计。不是因为现有项目不够好，也不是为了追求“自研”本身，而是因为我们想要的边界与许多现有系统的历史边界不同。 我们所说的“从头写”是什么</h2> 从头写不等于拒绝标准，也不等于重复制造所有基础设施。 zLLM 继续读取 Safetensors、GGUF/GGML、compressed-tensors 和 ModelOpt 等标准权重格式，继续使用 Metal、CUDA、ROCm、Vulkan 等平台能力，也会采用经过验证的通用 Rust 库。我们不重新发明文件格式、网络协议或操作系统接口。 我们重新设计的是推理引擎本身： 模型规格如何表达；</li> 模型算法如何只写一份；</li> backend 应该提供哪些能力；</li> kernel 如何保持参数化而不绑定模型；</li> 权重、KV Cache、activation、expert 和 scratch 分别由谁拥有；</li> prefill、append prefill 和 decode 的完整执行路径如何调度；</li> 单机、嵌入式服务和多机分层如何共享同一套语义；</li> 正确性如何由 CPU reference 和跨后端一致性验证锚定。</li> </ul> 换句话说，zLLM 复用开放标准与平台能力，但自己拥有模型执行和资源语义： 复用</th> 自己拥有</th></tr></thead> Safetensors、GGUF/GGML、compressed-tensors、ModelOpt</td> 模型规格、算法编排与权重装配</td></tr> Metal、CUDA、ROCm、Vulkan、NPU 平台接口</td> backend capability、资源驻留与同步</td></tr> 成熟的序列化、网络和异步 Rust 库</td> KV、Expert、Activation、Scratch 的生命周期</td></tr> 平台原生 GPU kernel 语言</td> 完整 Prefill、Append Prefill 与 Decode Round</td></tr> </tbody></table> 这也是“重新设计”与“重写”的区别。重写容易把旧结构换一种语言再实现一次；重新设计则要求回到数据依赖、资源位置和真实任务，重新判断每一个模块是否有存在的必要。 最小引擎，不是最少功能</h2> zLLM 追求的“最小”，不是做一个只能演示的小程序，而是让系统中的概念数量保持最小。 我们的长期准则是 Simple / Short / Straight： Simple：能由一个清楚模块解决的问题，不拆成多层抽象；</li> Short：代码、作用域和对象生命周期都尽可能短；</li> Straight：定义靠近使用点，控制流和依赖方向可以顺着代码直接读懂。</li> </ul> 目录、文件、trait、wrapper、manager、registry 和 context 都不是免费的。每增加一个实体，读代码的人就要多记住一个名字、多理解一层转发、多追踪一段生命周期。只有当一个实体确实拥有独立的数据、行为、生命周期或依赖边界时，它才值得存在。 所以 zLLM 不建立没有真实实现的通用 flow，不为了“未来可能有用”提前设计抽象工厂，也不保留只做转发的空壳 facade。模型执行流程只有一份；平台差异由 capability trait 和具体 backend 承接；kernel 只表达算子，不知道模型名字。 最小化的对象不是能力，而是理解系统所需的心智负担。 最少且必要的第三方依赖</h2> “最小第三方依赖”同样不意味着零依赖。密码哈希、序列化、异步运行时、HTTP、标准格式解析等成熟能力，没有理由为了形式上的纯粹重新实现。 我们的原则是：依赖可以提供通用能力，但不能替我们拥有推理引擎的核心语义。 模型执行、资源驻留、KV 生命周期、权重装配、调度策略和跨后端能力边界，应当在 zLLM 自己的代码中清晰可见。第三方库不应在不透明的内部替我们决定张量放在哪里、什么时候复制、什么时候同步、如何回收，或者某个模型如何执行。 这带来三个直接收益： 第一，依赖图更容易审计。升级一个网络库，不应改变模型数值；增加一种权重格式，不应侵入 runtime；替换某个平台绑定，不应迫使模型算法重写。 第二，性能成本更可见。推理系统最怕“方便的抽象”背后出现一次隐式拷贝、一次设备同步或一次临时反量化。核心路径由自己拥有，才能追踪每一份大数据的来源、去向和生命周期。 第三，长期演进不受上游框架结构限制。zLLM 可以复用标准和通用库，但不会把自己的架构方向交给某个大型运行时、张量框架或 Python 扩展体系决定。 为什么 Rust 适合这件事</h2> Rust 的价值不只是“没有 GC”或“比 Python 快”。对于推理引擎，Rust 最重要的优势是：它能把资源关系写进程序结构，并在编译阶段消灭大量不合法状态。 1. 所有权与生命周期正好对应推理资源</h3> 推理引擎处理的不是抽象数字，而是一组昂贵资源：mmap 权重、设备 buffer、KV page、command buffer、异步 I/O、跨节点 session、临时 scratch。它们都在回答相同的问题：谁拥有、谁可以借用、什么时候能够释放、异步任务结束前是否仍然有效。 Rust 的所有权、借用和生命周期不是额外约束，而是这类问题的直接语言表达。一个异步预取任务不能引用已经释放的目标 buffer；一份 cache 不能在仍被执行队列使用时被回收；共享状态必须明确同步边界。这些错误在 C/C++ 中往往依赖约定和审查，在带 GC 的语言中又容易被延迟释放或外部资源生命周期绕开。Rust 让其中相当一部分成为编译问题。 2. 无 GC 的可预测执行</h3> decode 是持续、细粒度、对尾延迟敏感的循环。不可预测的暂停、隐式对象分配和延迟析构会让性能分析变得困难。 Rust 没有垃圾回收器，值的生命周期通常由作用域决定。配合预分配和 scratch 复用，我们可以让热路径中的分配、释放和同步更可预测。这并不自动保证高性能，但它提供了构建可预测系统所需要的基础。 3. 零成本抽象适合表达 backend 能力</h3> 不同 backend 的差异是真实存在的。CPU tensor 可以是普通内存，Metal tensor 是设备资源句柄，ROCm 可能有完全不同的驻留与提交模型。把它们强行塞进统一的动态对象，往往只会得到最低公分母，以及遍布热路径的间接调用和运行时检查。 zLLM 使用 trait 和 associated type 表达能力：模型 runtime 声明自己需要什么，具体 backend 在编译期提供实现。泛型会带来编译时间和二进制体积成本，但换来的是静态组合、可读的能力集合，以及热路径上更少的动态分派。 4. 枚举与模式匹配让格式状态显式</h3> 权重可能是 F32、F16、BF16，也可能保持 FP8、FP4、W4A16 或 GGUF block 编码直到 kernel。用明确的 enum 表达这些状态，可以要求每个 backend 对每种合法输入作出处理或明确拒绝，而不是在字符串、指针和隐式约定之间猜测。 这对量化尤其重要：量化不是“加载时先转成浮点”的附属功能，而是与模型规格、平台 kernel 正交的一条数据路径。状态越显式，隐式展开和错误分派就越难混入系统。 5. Rust 同时覆盖底层与服务层</h3> 许多推理系统天然分裂为两部分：底层由 C/C++ 或 GPU 语言实现，上层由 Python、Go 或另一套服务框架组织。边界两侧各自合理，但组合后往往出现重复的数据模型、跨语言 FFI、两套错误处理和难以统一的生命周期。 Rust 可以同时承担权重解析、CPU reference、backend 绑定、runtime、调度器、HTTP/SSE 服务和嵌入式库接口。GPU kernel 仍然使用平台原生语言——Metal Shading Language、HIP/CUDA、WGSL 或 AscendC——但 kernel 之外的引擎主体由一套类型系统、一套错误模型和一套资源语义贯穿。 这才是 zLLM 所说的“纯 Rust”：不是否认平台原生 kernel 的存在，而是不依赖 Python 控制面、不把核心执行委托给另一个大型张量运行时，Rust 直接拥有整个推理引擎。 6. 工具链让跨平台工程保持一致</h3> Cargo 的构建、feature、测试和依赖管理，使 CPU、Metal、CUDA、ROCm、Vulkan 等路径可以在同一个工程中保持清晰边界。平台能力按 feature 和目标系统启用，CPU 单元测试不依赖真实权重，GPU 路径则由 CPU oracle 做数值锚定。 Rust 不能替代真机测试，也不能在编译期发现运行时编译的 MSL/HIP kernel ABI 错误。但它能把平台相关的不安全边界压缩在较小范围内，让其余绝大部分系统继续享受静态检查。 zLLM 的架构如何体现这些选择</h2> zLLM 把系统分成几个职责明确、依赖单向的区域： 这里最关键的不是目录长什么样，而是依赖方向： 模型规格不依赖平台；</li> 模型算法只写一份，不复制到各个 backend；</li> backend 和 kernel 不知道具体模型；</li> attention、MoE、KV Cache 等领域层保存设备无关语义和 reference；</li> 权重层只负责标准格式、命名、shape 和生命周期，不接管模型算法；</li> CPU 是正确性 oracle，GPU kernel 是经过一致性验证的加速实现。</li> </ul> 这种设计避免了最常见的组合爆炸：不是每增加一个模型，就为每个平台复制一套执行流程；也不是每增加一个后端，就重新理解所有模型。新增模型主要增加规格、编排和权重适配；新增 backend 主要实现已有 capability；只有出现新的通用算子语义时，才扩展领域能力。 从数据流，而不是语义标签出发</h2> 从头设计给了我们一个重要机会：按真实数据依赖组织系统，而不是照搬论文章节或模型名词。 如果 A 的输出是 B 的输入，它们就是必须串行的 pipeline，应当靠近并共同管理中间状态。如果 A 和 B 独立读取 hidden，它们就应当分开，让 backend 有机会并行调度。权重的结构、kernel 的融合和资源的生命周期都遵循同一原则。 同样，生产推理只承认三类完整任务：新会话 prefill、已有会话 append prefill，以及完整 decode round。截断到某一层、只跑一个 kernel、只比较局部输出，都可以是诊断手段，但不能替代端到端任务。优化必须最终回到 TTFT、decode latency、吞吐、内存峰值、SSD 等待和设备利用率。 这让系统不容易被漂亮但无关的局部数字带偏。 Rust 不会自动带来正确性和性能</h2> 选择 Rust 不是宣称语言可以替代工程纪律。 Rust 无法证明 GPU kernel 的数值正确，无法阻止错误的算法设计，也无法保证一个看起来优雅的抽象没有性能代价。多 backend 意味着同一 kernel 语义可能需要 Rust reference、MSL、HIP、CUDA、WGSL 或 AscendC 多份高性能实现；泛型会增加编译成本；capability trait 也可能在缺乏约束时不断膨胀。 所以 zLLM 把以下纪律与语言能力放在一起： 新算子先有 reference 语义和单元测试；</li> CPU 与设备 backend 做一致性验证；</li> kernel 维度全部参数化，不写入模型常量；</li> 不用孤立 kernel benchmark 代替完整路径指标；</li> 没有测量证据，不为性能增加复杂度；</li> 源码、编译通过、oracle 通过和真机端到端验证必须明确区分；</li> 只做完成当前任务所需的最小改动，不借机重构无关代码。</li> </ul> Rust 提供的是一块坚实地基。真正决定引擎质量的，仍然是清楚的边界、可复现的验证和对复杂度的持续克制。 为什么值得从头开始</h2> 从头写的代价很高。权重格式要自己理解，kernel 要逐个平台优化，服务与调度要自己打磨，错误也没有上游框架替我们兜底。短期看，这条路一定比接入一个成熟运行时更慢。 但它换来了一个长期价值：系统中的每一个关键决定都有明确所有者。 当模型变了，我们知道应该修改规格、编排还是领域能力；当平台变了，我们知道应该修改 backend 还是 kernel；当性能下降，我们能够沿着权重、activation、KV、expert、scratch 和同步点逐一追踪；当系统扩展到多机，我们传输的是层边界 activation，而不是把模型内部状态和远端 RPC 混成新的热路径。 这就是 zLLM 的目标：不是成为依赖最庞大、抽象最完整的通用 AI 框架，而是成为一个足够小、足够直接、能够真正拥有硬件资源和模型执行的原生推理引擎。 我们选择 Rust，因为它与这套目标一致：安全，但不放弃底层控制；抽象，但不必支付运行时成本；跨平台，但不抹平平台差异；能写 kernel 周围最靠近硬件的代码，也能一路写到服务和分布式调度。 我们选择从头设计，因为只有这样，Simple、Short、Straight 才不是对旧系统的局部修补，而能成为整个引擎从第一行代码开始遵守的结构原则。

从总共 1M 到 15+ 路 × 1M：GLM-5.3 KV Cache 换出的容量突破

古董机器也能跑顶尖大模型

来自阿布扎比的 K2-Horizon 到底怎么样？M5 实测：会做题，写中文却翻车

双8卡(AMD W7900D)机器如何跑 GLM5.3

算法层：从注意力、KV Cache 到 FFN 与 MoE

量化不是压缩包：从模型分层到 4-bit 推理的工程真相

八、工程中最容易踩的坑</h2>

用 Rust 统一管理内存与显存所有权：从 Arc 到 GPU Completion

生命周期从约定变成类型关系</h3>
`RocmTensor → Arc<DeviceBuffer></code>、View → Arc<Owner></code>、 Completion → Vec<Arc<DeviceBuffer>></code> 都可以直接从字段看出来。开发者不再依赖 “调用者应该记得晚一点 free”这样的口头约定。</p>`

解耦：让模型、算法、后端与算子独立演进

为什么我只输入了一句话，却消耗了数十万 Token？

MacBook Air M5：零依赖运行多模态大模型！

为什么我们要用 Rust 重新写一个推理引擎

为什么 Rust 适合这件事</h2>
Rust 的价值不只是“没有 GC”或“比 Python 快”。对于推理引擎，Rust 最重要的优势是：它能把资源关系写进程序结构，并在编译阶段消灭大量不合法状态。</p>

zLLM · 努力成为最好的推理引擎

DeepSeek V4.1 Flash 工程实践（四）：长 Prefill 与最后一公里优化

最新 prefill 路径：不重复解码同一份索引数据</h2>
修正候选语义后，profiler 指向前级 FP4 索引评分。朴素实现会在每个评分 tile 中反复解码相同的 query 和 key。上下文越长，这部分重复工作越明显。</p>
最终路径分成四步。</p>

DeepSeek V4.1 Flash 工程实践（三）：接入图像——用中间张量找差异

DeepSeek V4.1 Flash 工程实践（二）：从权重装配到八卡文本链路

第一步：把文件里的张量装成模型需要的权重</h2>
权重装配首先回答三个问题：张量叫什么、逻辑形状是什么、字节该怎样解释。</p>

DeepSeek V4.1 Flash 的 Engram：让知识不必每次重新算

`后续预告</h2> 接下来按每天一篇的节奏，继续展开其他工程环节：</p> 第二篇：从权重装配到八卡文本链路</li> 第三篇：接入图像——用中间张量找差异</li> 第四篇：性能实测——prefill、decode 与优化前后对比</li> </ul>`

穿越者必备：一台手机装下现代文明，在古代直接开挂

zLLM · 努力成为最好的推理引擎

DeepSeek V4.1 Flash 工程实践（四）：长 Prefill 与最后一公里优化

最新 prefill 路径：不重复解码同一份索引数据</h2> 修正候选语义后，profiler 指向前级 FP4 索引评分。朴素实现会在每个评分 tile 中反复解码相同的 query 和 key。上下文越长，这部分重复工作越明显。</p> 最终路径分成四步。</p>

DeepSeek V4.1 Flash 工程实践（三）：接入图像——用中间张量找差异

DeepSeek V4.1 Flash 工程实践（二）：从权重装配到八卡文本链路

第一步：把文件里的张量装成模型需要的权重</h2> 权重装配首先回答三个问题：张量叫什么、逻辑形状是什么、字节该怎样解释。</p>

DeepSeek V4.1 Flash 的 Engram：让知识不必每次重新算

后续预告</h2> 接下来按每天一篇的节奏，继续展开其他工程环节：</p> 第二篇：从权重装配到八卡文本链路</li> 第三篇：接入图像——用中间张量找差异</li> 第四篇：性能实测——prefill、decode 与优化前后对比</li> </ul>

穿越者必备：一台手机装下现代文明，在古代直接开挂

从总共 1M 到 15+ 路 × 1M：GLM-5.3 KV Cache 换出的容量突破

古董机器也能跑顶尖大模型

来自阿布扎比的 K2-Horizon 到底怎么样？M5 实测：会做题，写中文却翻车

双8卡(AMD W7900D)机器 如何跑 GLM5.3

算法层：从注意力、KV Cache 到 FFN 与 MoE

量化不是压缩包：从模型分层到 4-bit 推理的工程真相

最新 prefill 路径：不重复解码同一份索引数据</h2>
修正候选语义后，profiler 指向前级 FP4 索引评分。朴素实现会在每个评分 tile 中反复解码相同的 query 和 key。上下文越长，这部分重复工作越明显。</p>
最终路径分成四步。</p>

第一步：把文件里的张量装成模型需要的权重</h2>
权重装配首先回答三个问题：张量叫什么、逻辑形状是什么、字节该怎样解释。</p>

`后续预告</h2> 接下来按每天一篇的节奏，继续展开其他工程环节：</p> 第二篇：从权重装配到八卡文本链路</li> 第三篇：接入图像——用中间张量找差异</li> 第四篇：性能实测——prefill、decode 与优化前后对比</li> </ul>`

双8卡(AMD W7900D)机器如何跑 GLM5.3