kimi-k3-in-c 路线图深读：分块 prefill、测量复刻、KDA SIMD 与采样设计决策

人工智能大模型推理引擎本地部署【免费下载链接】kimi-k3-in-cA 2.78-trillion-parameter Kimi K3 running inference on a single CPU in 8.24 GB of RAM. Portable C99: no BLAS, no framework, no GPU.项目地址https://gitcode.com/gh_mirrors/ki/kimi-k3-in-c点击查看免费下载本文以 docs/ROADMAP.md 为骨架逐项展开这个 2.78 万亿参数、在单 CPU 上运行 Kimi K3 的 C99 推理引擎的后续路线每一项待办为什么排在这个位置、当前代码里已经做到什么程度、以及哪些事情被明确列为不做。读完你能掌握路线图背后的价值排序逻辑并能对照 benchmarks/ 下的复刻测试脚本与 src/ 下的内核实现独立评估每个待办的工程代价与收益。路线图的排序原则按价值且理由可被反驳docs/ROADMAP.md 开宗明义Ordered by value, with the reasoning stated so the order can be argued with.按价值排序并写明理由以便顺序可以被质疑。这八个条目不是功能清单而是一份带论证的优先级决策每一项都给出了为什么现在、为什么是它的判断依据。以下按原文顺序逐项展开并结合仓库源码标注每项的现状与差距。1. 分块 prefill价值最高的缺失件路线图把分块 prefillchunked prefill列为第 1 优先级理由是 prefill 目前是对整个 prompt 的一次性前向传播而 24 个 MLA 层的注意力计算对序列长度是二次方复杂度。实际后果上下文上限是 32k token但一个 21k token 的 prompt 无法在合理时间内完成。原文的判断很直接——Raising the ceiling was necessary and is done. This is the part that makes it usable.提高上限是必要且已完成的而分块 prefill 才是让它真正可用的部分。从源码结构看当前引擎的上下文限制来自 MLA KV 缓存容量而非模型结构。src/cli/k3_run.c 中 KV 缓存按位置主序position-major存放在每个 MLA 层切片内当历史长度超过kv_cap时引擎会明确拒绝REFUSING: %s holds %d positions, this runs KV cache is %d. Raise --gen or shorten the prompt.README.md 的 CLI 参数表也印证了这一上限--gen生成 token 数上限 4096prompt 最长 32768 tokenCHANGELOG.md 中则记录了当时的状态——No chunked prefill, so long prompts are impractical despite a 32k context ceiling没有分块 prefill因此尽管有 32k 上下文上限长 prompt 仍不实用。分块 prefill 的目标正是把这条能放下但跑不完的 32k 上限变成能跑完。2. 在复刻测试台架下重跑已发布的基准第 2 项待办直指本项目的测量纪律问题实测的噪声地板是 33%而几乎每个已发布的数字都是单样本。docs/BENCHMARKING.md 给出了这个 33% 的出处——同一二进制、同一 prompt、同一标志、同一分钟内连跑三次运行s/token114.78214.67320.14均值 16.53标准差 3.13极差 33.1%。文档的结论是If your A/B differs by less than that, you have measured nothing如果你的 A/B 测试差异小于这个值你什么都没测出来并且特别指出复刻测试在本项目中是最后才做的它撤回过已经写下并被论证过的结果。台架本身已经完成。benchmarks/memory-ladder.sh 与 benchmarks/split-sweep.sh 默认每个档位跑 3 次重复并用内嵌 Python 统计输出每档的 mean、sd 和 spread脚本开头还注明了单样本无法区分效应与噪声的原因。两个台架的关键工程细节值得留意仅支持 Linux通过systemd-run --scope --user -p MemoryMax...G -p MemorySwapMax0施加真实内存上限——benchmarks/memory-ladder.sh 强调关闭 swap 是为了避免超限时换页而不是死亡那样测出的是 swap 带宽而非被测配置只有 SIGKILL(137) 或日志中的 OOM 字样才记为装不下这一合法结果其他失败直接报错退出防止把故障伪装成数据点每次运行断言generated_ids与参考运行逐 token 一致且明确防御空字符串对比空字符串这种空转通过。剩下的工作是重跑 12 个内存阶梯档位和 12 个 trunk/cache 拆分组合替换 docs/data/ 中的单样本表。对照仓库数据可以确认这确实是单样本现状docs/data/memory-ladder.tsv 与 docs/data/trunk-cache-split.tsv 各含 12 行数据每个预算只有一条记录、没有重复列。报告模板见 docs/PERFORMANCE.md写明机器、写明噪声地板、把单样本行标注为单样本。3. 线程扩展性从未扫过 OMP_NUM_THREADS第 3 项是 src/core/k3_ops.c 中 OpenMP 并行度调优问题OMP_NUM_THREADS在这台引擎上从未被系统地 sweep 过。路线图给出的推断是——在低内存预算下负载是 I/O 瓶颈因此有用的线程数大概率远低于核心数而在内存受限负载上吞吐往往在超过某个线程数后下降。原文诚实地标注了Unknown here这里未知即这是一个待测量的经验问题而非已知结论。4. KDA 递推的 SIMD 化第 4 项指向具体的内核级差距。src/core/k3_ops.c 中已有两个手写 AVX2 路径bf16 trunk 矩阵乘和 MXFP4 expert 矩阵乘两者都逐位复现了标量归约顺序源码注释明确写了 THE AVX2 PATH IS BIT-IDENTICAL TO THE SCALAR PATH, not merely close并解释__m256d的 16 个独立 double 累加通道如何对应标量求和顺序。KDA 递推没有这条待遇k3_kda_decay、k3_kda_step、k3_kda_layer至今是纯标量 C且它是非 I/O 路径上最大的未向量化内核。路线图把它排在第 4 位的原因隐含在排序中它不改变 I/O 主导的慢路径但决定了 decode 阶段的算力上限。5. 采样greedy 是有意的约束第 5 项不是功能缺口而是一条保持现状的决策。批量生成只有 greedy聊天模式提供可选的温度、top-p 与种子参数三者任一给出才开启采样否则仍是 greedy。src/cli/k3_run.c 的用法说明与实现印证了这一点--temperature X turn chat sampling on, at this temperature (default: greedy) --top-p P nucleus probability for chat sampling (default 0.95) --seed N chat sampling seed; any of these three turns sampling on参数校验在 src/chat/k3_sampler.c 中--temperature必须有限且大于 0--top-p必须在 (0, 1] 区间--seed必须是无符号整数采样器是 PCG32 加确定性的 temperature/top-p 选择且--temperature/--top-p/--seed/--greedy都要求--chat。原文解释了为什么Keep it that way保持这样greedy 解码正是让不同内存预算下输出完全一致的机制而测试套件依赖这个性质。这与第 2 项的台架设计闭环——benchmarks/memory-ladder.sh 在每档结束时断言Output identical at every rung一旦某个预算下 token 流分叉就以 FAIL 退出。放宽默认采样会直接破坏这台一致性断言台架的前提。6. 聊天保留状态的等价性第 6 项描述了多轮聊天当前的状态与下一步边界。已完成的部分文本聊天实现了 K3 官方 XTML 格式、JSONL 历史重启、以及安全的完整历史重新 prefillsafe complete history re-prefill。实现位于 src/chat/k3_chat.c严格解析 JSONL transcript 并渲染官方 XTML 分段历史通过k3_chat_history_load/k3_chat_history_save做原子读写与校验。下一步优化是仅在进程内跨 REPL 轮次保留 KDA/MLA 状态但前提是等价性门禁equivalence gate先证明保留状态产生的 token 流与对同一 transcript 做完整重 prefill完全一致。这个门禁设计延续的是本项目的一贯纪律——性能优化不得悄悄改变输出先用可验证的等价断言锁住行为再谈加速。7. 视觉Vision路线图指出 K3 原生多模态而视觉塔规模足够小、足够自洽self-contained enough to be tractable自洽到可以处理27 层、约 0.4B 参数权重约 0.9 GB只占整个 checkpoint 的千分之几。从结构上看把这一塔移植到同一套无框架 C99 推理栈内的可行性显著高于主模型本身。8. 工具调用与服务端刻意后置第 8 项说明消息模型message model给工具调用留了结构空间但仓库中没有工具执行也没有 HTTP API。原文的态度是两者都deliberately late product surface刻意后置的产品面——这不是遗漏而是优先把推理引擎本身的正确性与可测量性做完之后的产品决策。README.md 的能力清单与此一致当前版本没有工具、图像、服务器或上下文压缩。明确不做的事路线图末尾专设 Explicitly not planned 一节把两条常见诉求挡在门外不给 trunk 做精度旋钮。trunk 走的是无损流式读取而非量化这是设计决策而非疏忽。原文给出的量化依据对 K3 注意力张量做事后 int4 量化平均相对权重误差约 17%而 int8 约 1%。其权衡逻辑是流式化的代价是时间而更多内存能把时间买回来舍入的代价是精度而没有任何东西能把精度买回来。GPU 支持不在范围内。项目定位就是单 CPU、可移植 C99、无 BLAS、无框架、无 GPU见 README.md 的项目描述GPU 路径与该定位冲突。小结路线图背后的工程纪律把这八项待办与两个不做并读可以看出 docs/ROADMAP.md 传递的是一条一致的方法论先让长上下文真正可用分块 prefill再让已发布的数字站得住复刻台架然后是纯算力项线程、KDA SIMD而采样与聊天状态保留的每一次放松都必须先过等价性门禁。配套入口材料可按需继续查阅docs/BENCHMARKING.md测量纪律与污染源清单、docs/PERFORMANCE.md内存阶梯与噪声地板、docs/TUNING.mdtrunk/cache 拆分调优。赞分享人工智能大模型推理引擎本地部署【免费下载链接】kimi-k3-in-cA 2.78-trillion-parameter Kimi K3 running inference on a single CPU in 8.24 GB of RAM. Portable C99: no BLAS, no framework, no GPU.项目地址https://gitcode.com/gh_mirrors/ki/kimi-k3-in-c点击查看免费下载相关推荐kimi-k3-in-c 深度解析8 GB 内存、单 CPU 跑通 2.78 万亿参数 Kimi K3 的流式推理全链路kimi k3 in c 深度解析8 GB 内存、单 CPU 跑通 2.78 万亿参数 Kimi K3 的流式推理全链路 本文基于开源仓库 kimi k3 i人工智能大模型推理引擎本地部署SGLang KDAKimi Delta Attention线性注意力测试覆盖矩阵深度解读SGLang KDAKimi Delta Attention线性注意力测试覆盖矩阵深度解读 导读 本文以 test/registered/attention模型推理服务推理引擎人工智能大模型本地部署多模态kimi-k3-in-c 快速上手从空机器到 8 GB 内存跑通 2.78 万亿参数 Kimi K3kimi k3 in c 快速上手从空机器到 8 GB 内存跑通 2.78 万亿参数 Kimi K3 本文基于仓库自带的 QUICKSTART.md http人工智能大模型推理引擎本地部署上一篇CANN多模态算子库快速安装指南下一篇WXT模块开发终极指南如何快速创建自定义浏览器扩展功能模块创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考