本地万亿参数模型还能再快多少WARP 路由前瞻、专家缓存与多盘分片性能调优实战【免费下载链接】warpRun the full 2.78-trillion-parameter Kimi K3 model, DeepSeek V4.1 Flash or GLM-5.3-Flash beyond available RAM by streaming activated weights directly from NVMe. A dependency-free, embeddable C inference engine.项目地址: https://gitcode.com/gh_mirrors/was/warpWARP 是一个无第三方依赖的嵌入式 C 语言推理引擎让 2.78 万亿参数的 Kimi K3、DeepSeek V4.1 Flash 和 GLM-5.3-Flash 这类超大规模 MoE 模型突破内存限制直接把激活权重从 NVMe 磁盘流式读入。本文面向新手用实测数据讲清楚三个关键性能调优点路由前瞻router lookahead、专家缓存expert cache与多盘分片bank sharding帮你在本机把速度榨到极限。 先搞懂原理为什么磁盘能喂饱万亿参数模型Kimi K3 有 2.78 万亿参数但每个 token 只激活约 4% 的专家。WARP 的做法是常驻部分放内存注意力、路由器等主干常驻 RAMK3 约 27 GB激活专家从盘上流式读容器布局保证一个专家 一次对齐读取空闲内存当缓存用有界的专家缓存存热专家避免重复读盘。官方实测64 GB M5 Pro MacBook Pro模型容器体积最低内存实测解码速度Kimi K32.78T982 GB29.19 GB0.45–0.62 tok/sDeepSeek-V4.1-Flash552B299 GB4.86 GB3.77 tok/sGLM-5.3-Flash313B112 GB5.14 GB3.86 tok/sKimi-Linear48B19 GB1.32 GB17.22 tok/s完整设计见 docs/ENGINE.md性能剖析见 docs/EFFICIENCY.md。 调优点一路由前瞻——已默认开启的免费加速这是项目里最值得关注的新特性。核心问题每一层要读哪些专家其实可以在上一层就知道。WARP 的做法是让下一层的路由器提前跑一遍当前隐藏状态预测出下一层 top 6 专家在层边界处提前读盘。注意真正做决定的仍是本层路由器本身所以输出与关闭前瞻时逐位一致只改变读取时机不改变结果。实测数据K3单进程对照前瞻解码速度命中提升读取量关闭0.506 tok/s7.2–7.7%204–205 GBtop 6 前瞻0.541 tok/s38.0–38.2%191 GB更妙的是前瞻把缓存记录的存活周期从跨 token缩短到跨 attention使得仅 3.32 GB 的小缓存也能拿到 29.1% 命中率逼近 17.32 GB 大缓存的水平。可用环境变量WASTE_LOOKAHEAD0关闭docs/EFFICIENCY.md §4F 有完整推导。新手建议保持默认开启即可它同时降低了磁盘流量和等待时间。 调优点二专家缓存——给更多内存 ≠ 更快的坑专家缓存是唯一直接买速度的内存旋钮但项目文档记录了一个反直觉的页错误悬崖专家缓存命中率解码速度3.32 GB29.1%0.56–0.58 tok/s17.32 GB36.2%0.63 tok/s✅23.32 GB38.4%0.07–0.09 tok/s ⚠️29.32 GB41.3%0.07–0.08 tok/s ⚠️注意最后两行命中率还在涨、读盘字节还在降速度却掉了 8 倍。原因是缓存吃掉了本可留给操作系统的内存命中变成了页错误。三条实战结论别手动设--budget。默认解析器会以一个 token 的工作集为步长向下取整并停留在物理内存 3/4 上限之下——这正是曲线上最快的一档详见 docs/ENGINE.md 与 docs/GATES.md Gate 7。小容器模型如 Kimi-Linear现在会自动获得全量驻留缓存19 GB 容器拿到 18.48 GB 缓存后200 token 从 12.67 提升到14.81 tok/s读盘从 66.3 GB 降到 17.7 GBdocs/LEARNED.md §66。如果非要超大--budget可开WASTE_PURGEABLE1逃生——把 6 倍灾难降级为 2 倍减速。另外--learn会把工作负载实际触碰的热专家写入usage.waste下次启动从温态开始而非冷启动同一 prompt 二次运行命中率 61% → 72%。 调优点三多盘分片——把专家分散到多块 NVMe单盘瓶颈下一个 token 路由到的 16 个专家会排队等一块盘。自 0.7.2 起WARP 支持把专家银行expert bank按e % N轮询散列到多块盘WASTE_BANK_SHARDS/mnt/a,/mnt/b ./waste run ~/models/k3.waste 你的问题配套工具 tools/split_banks.py 负责按引擎真实的读盘规则拆分并逐字节校验分片集保证 logits 与单盘完全一致python3 tools/split_banks.py container.waste --dirs /mnt/a,/mnt/b --mode split python3 tools/split_banks.py container.waste --dirs /mnt/a,/mnt/b --mode verify⚠️ 诚实提示官方也这么说目前未声明提速数字。收益的前提是两块速度相当的盘拿内部 SSD 配 USB 盒做条带测到的是 USB 盒的速度。机制已发布测量留给你。顺带提醒容器必须放在内部 NVMe。实测内部 SSD 随机读 12.78 GB/sUSB 桥接盒只有 0.94 GB/s——差 13.6 倍docs/GATES.md Gate H。 调优点四线程数与 CPU 亲和性一个容易被忽略的旋钮--threads。x86 上--threads 0默认按逻辑 CPU含超线程起线程实测 16 线程比 6–8 线程慢约 1.6 倍——专家展开是依赖型load→address→load链同核双线程只抢 L1 不增加并行度docs/ENGINE.md 线程放置章节。对多 CCD 的 Ryzen如 9900X用--cpus 0-5把线程钉在同一 die 内可比跨 die 快 25%./waste run model.waste hello --threads 6 --cpus 0-5⚙️ 调优参数速查表参数作用建议WASTE_LOOKAHEAD路由前瞻默认开保持默认--budget内存预算上限不特殊原因别设WASTE_IO_THREADS/WASTE_IO_DEPTH异步读盘线程/深度默认即可0 恢复同步路径WASTE_BANK_SHARDS多盘分片目录有多块同速 NVMe 时再试--threads/--cpus线程数 / CPU 绑定x86 建议 6–8 线程多 CCD 钉同一 dieWASTE_PURGEABLE1超大预算时的降级保护逃生用默认关--learn写热专家清单二次启动温态固定工作负载推荐所有机制都通过了位级一致性测试缓存、前瞻、异步预读只改变字节移动的时刻不改变输出内容make check共 42 项检查。 性能还能再快多少一个诚实的答案项目文档反复测量后给出的结论是K3 在 64 GB 机器上约 0.56–0.63 tok/s 已接近该硬件极限——解码步骤中专家 I/O 仍占 54.8%读盘时间是算力的两倍剩下的空间属于更快的盘或更大的内存而非软件调度docs/EFFICIENCY.md §4E/§5。但对大多数用户更实用的路线是选对模型GLM-5.3-Flash 在 16 GB 内存机器上就能跑到 64 GB 机器 90% 的速度DeepSeek-V4.1-Flash 以 2.97 GB 的 token 工作集提供本仓库最快的大模型体验docs/GLM.md、docs/DS41.md。✅ 总结三步调优清单保持路由前瞻默认开启并加--learn获得温态启动不要手动设--budget让默认解析器避开页错误悬崖小容器模型已能自动全量驻留容器放内部 NVMe有多块同速盘再用WASTE_BANK_SHARDS分片x86 上把线程数降到 6–8 并按 die 绑定。按这三步操作你拿到的就是这个引擎在 64 GB 笔记本上跑 2.78 万亿参数完整模型的最终形态——没有蒸馏、没有剪枝只有 NVMe 在全力工作。【免费下载链接】warpRun the full 2.78-trillion-parameter Kimi K3 model, DeepSeek V4.1 Flash or GLM-5.3-Flash beyond available RAM by streaming activated weights directly from NVMe. A dependency-free, embeddable C inference engine.项目地址: https://gitcode.com/gh_mirrors/was/warp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
本地万亿参数模型还能再快多少：WARP 路由前瞻、专家缓存与多盘分片性能调优实战
本地万亿参数模型还能再快多少WARP 路由前瞻、专家缓存与多盘分片性能调优实战【免费下载链接】warpRun the full 2.78-trillion-parameter Kimi K3 model, DeepSeek V4.1 Flash or GLM-5.3-Flash beyond available RAM by streaming activated weights directly from NVMe. A dependency-free, embeddable C inference engine.项目地址: https://gitcode.com/gh_mirrors/was/warpWARP 是一个无第三方依赖的嵌入式 C 语言推理引擎让 2.78 万亿参数的 Kimi K3、DeepSeek V4.1 Flash 和 GLM-5.3-Flash 这类超大规模 MoE 模型突破内存限制直接把激活权重从 NVMe 磁盘流式读入。本文面向新手用实测数据讲清楚三个关键性能调优点路由前瞻router lookahead、专家缓存expert cache与多盘分片bank sharding帮你在本机把速度榨到极限。 先搞懂原理为什么磁盘能喂饱万亿参数模型Kimi K3 有 2.78 万亿参数但每个 token 只激活约 4% 的专家。WARP 的做法是常驻部分放内存注意力、路由器等主干常驻 RAMK3 约 27 GB激活专家从盘上流式读容器布局保证一个专家 一次对齐读取空闲内存当缓存用有界的专家缓存存热专家避免重复读盘。官方实测64 GB M5 Pro MacBook Pro模型容器体积最低内存实测解码速度Kimi K32.78T982 GB29.19 GB0.45–0.62 tok/sDeepSeek-V4.1-Flash552B299 GB4.86 GB3.77 tok/sGLM-5.3-Flash313B112 GB5.14 GB3.86 tok/sKimi-Linear48B19 GB1.32 GB17.22 tok/s完整设计见 docs/ENGINE.md性能剖析见 docs/EFFICIENCY.md。 调优点一路由前瞻——已默认开启的免费加速这是项目里最值得关注的新特性。核心问题每一层要读哪些专家其实可以在上一层就知道。WARP 的做法是让下一层的路由器提前跑一遍当前隐藏状态预测出下一层 top 6 专家在层边界处提前读盘。注意真正做决定的仍是本层路由器本身所以输出与关闭前瞻时逐位一致只改变读取时机不改变结果。实测数据K3单进程对照前瞻解码速度命中提升读取量关闭0.506 tok/s7.2–7.7%204–205 GBtop 6 前瞻0.541 tok/s38.0–38.2%191 GB更妙的是前瞻把缓存记录的存活周期从跨 token缩短到跨 attention使得仅 3.32 GB 的小缓存也能拿到 29.1% 命中率逼近 17.32 GB 大缓存的水平。可用环境变量WASTE_LOOKAHEAD0关闭docs/EFFICIENCY.md §4F 有完整推导。新手建议保持默认开启即可它同时降低了磁盘流量和等待时间。 调优点二专家缓存——给更多内存 ≠ 更快的坑专家缓存是唯一直接买速度的内存旋钮但项目文档记录了一个反直觉的页错误悬崖专家缓存命中率解码速度3.32 GB29.1%0.56–0.58 tok/s17.32 GB36.2%0.63 tok/s✅23.32 GB38.4%0.07–0.09 tok/s ⚠️29.32 GB41.3%0.07–0.08 tok/s ⚠️注意最后两行命中率还在涨、读盘字节还在降速度却掉了 8 倍。原因是缓存吃掉了本可留给操作系统的内存命中变成了页错误。三条实战结论别手动设--budget。默认解析器会以一个 token 的工作集为步长向下取整并停留在物理内存 3/4 上限之下——这正是曲线上最快的一档详见 docs/ENGINE.md 与 docs/GATES.md Gate 7。小容器模型如 Kimi-Linear现在会自动获得全量驻留缓存19 GB 容器拿到 18.48 GB 缓存后200 token 从 12.67 提升到14.81 tok/s读盘从 66.3 GB 降到 17.7 GBdocs/LEARNED.md §66。如果非要超大--budget可开WASTE_PURGEABLE1逃生——把 6 倍灾难降级为 2 倍减速。另外--learn会把工作负载实际触碰的热专家写入usage.waste下次启动从温态开始而非冷启动同一 prompt 二次运行命中率 61% → 72%。 调优点三多盘分片——把专家分散到多块 NVMe单盘瓶颈下一个 token 路由到的 16 个专家会排队等一块盘。自 0.7.2 起WARP 支持把专家银行expert bank按e % N轮询散列到多块盘WASTE_BANK_SHARDS/mnt/a,/mnt/b ./waste run ~/models/k3.waste 你的问题配套工具 tools/split_banks.py 负责按引擎真实的读盘规则拆分并逐字节校验分片集保证 logits 与单盘完全一致python3 tools/split_banks.py container.waste --dirs /mnt/a,/mnt/b --mode split python3 tools/split_banks.py container.waste --dirs /mnt/a,/mnt/b --mode verify⚠️ 诚实提示官方也这么说目前未声明提速数字。收益的前提是两块速度相当的盘拿内部 SSD 配 USB 盒做条带测到的是 USB 盒的速度。机制已发布测量留给你。顺带提醒容器必须放在内部 NVMe。实测内部 SSD 随机读 12.78 GB/sUSB 桥接盒只有 0.94 GB/s——差 13.6 倍docs/GATES.md Gate H。 调优点四线程数与 CPU 亲和性一个容易被忽略的旋钮--threads。x86 上--threads 0默认按逻辑 CPU含超线程起线程实测 16 线程比 6–8 线程慢约 1.6 倍——专家展开是依赖型load→address→load链同核双线程只抢 L1 不增加并行度docs/ENGINE.md 线程放置章节。对多 CCD 的 Ryzen如 9900X用--cpus 0-5把线程钉在同一 die 内可比跨 die 快 25%./waste run model.waste hello --threads 6 --cpus 0-5⚙️ 调优参数速查表参数作用建议WASTE_LOOKAHEAD路由前瞻默认开保持默认--budget内存预算上限不特殊原因别设WASTE_IO_THREADS/WASTE_IO_DEPTH异步读盘线程/深度默认即可0 恢复同步路径WASTE_BANK_SHARDS多盘分片目录有多块同速 NVMe 时再试--threads/--cpus线程数 / CPU 绑定x86 建议 6–8 线程多 CCD 钉同一 dieWASTE_PURGEABLE1超大预算时的降级保护逃生用默认关--learn写热专家清单二次启动温态固定工作负载推荐所有机制都通过了位级一致性测试缓存、前瞻、异步预读只改变字节移动的时刻不改变输出内容make check共 42 项检查。 性能还能再快多少一个诚实的答案项目文档反复测量后给出的结论是K3 在 64 GB 机器上约 0.56–0.63 tok/s 已接近该硬件极限——解码步骤中专家 I/O 仍占 54.8%读盘时间是算力的两倍剩下的空间属于更快的盘或更大的内存而非软件调度docs/EFFICIENCY.md §4E/§5。但对大多数用户更实用的路线是选对模型GLM-5.3-Flash 在 16 GB 内存机器上就能跑到 64 GB 机器 90% 的速度DeepSeek-V4.1-Flash 以 2.97 GB 的 token 工作集提供本仓库最快的大模型体验docs/GLM.md、docs/DS41.md。✅ 总结三步调优清单保持路由前瞻默认开启并加--learn获得温态启动不要手动设--budget让默认解析器避开页错误悬崖小容器模型已能自动全量驻留容器放内部 NVMe有多块同速盘再用WASTE_BANK_SHARDS分片x86 上把线程数降到 6–8 并按 die 绑定。按这三步操作你拿到的就是这个引擎在 64 GB 笔记本上跑 2.78 万亿参数完整模型的最终形态——没有蒸馏、没有剪枝只有 NVMe 在全力工作。【免费下载链接】warpRun the full 2.78-trillion-parameter Kimi K3 model, DeepSeek V4.1 Flash or GLM-5.3-Flash beyond available RAM by streaming activated weights directly from NVMe. A dependency-free, embeddable C inference engine.项目地址: https://gitcode.com/gh_mirrors/was/warp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考