人工智能大模型推理引擎本地部署【免费下载链接】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/data/是 kimi-k3-in-c 仓库中所有性能数字的原始出处docs/PERFORMANCE.md 与 docs/TUNING.md 中的每一张表都引用了这里的某个文件。读完本篇你将掌握这套测量体系的完整脉络——实验机环境、噪声地板单次运行间 33% 的离散度、12 档硬 cgroup 内存预算下的阶梯数据、固定预算下 trunk/专家缓存的切分实验、专家缓存容量回放、trunk 量化敏感性研究以及每条结论的确切证据边界与复现方式。数据来源与实验机环境所有数据来自同一台机器上的同一轮测量one campaign, one machine完整环境记录在 docs/data/environment.txt 中包括测量前应用的测量卫生措施。README 给出的环境摘要为AMD EPYC 7763124 vCPU2×62 核无 SMT228 GiB RAM3.2 TB NVMe 以 O_DIRECT 达到 3.2 GB/sUbuntu 24.04.3GCC 13.3支持 AVX2 但没有AVX-512。environment.txt 中还有几条对解读数据至关重要的细节实例形态4×L40 GPU 实例但 GPU 全程空闲0% 占用。这是一台纯 CPU 推理引擎实例是冲着 228 GiB 内存和 3.2 TB NVMe 选的。存储带宽实测O_DIRECT 冷读 3.2 GB/sbuffered 热读 2.3 GB/s——这里 O_DIRECT 反而比 buffered 快与通常预期相反这正是引擎选择以 O_DIRECT 打开 trunk 的原因实际运行中 trunk 持续读取速率在 5373–6064 MB/s。README 也提醒换目标设备前值得重新验证这一结论。测量卫生测量前停止了unattended-upgrades冒烟测试期间它占用了约 63% 的单核那次计时因此被污染且未被引用并禁用了apt-daily.timer/apt-daily-upgrade.timer。七个数据文件各支撑什么结论文件内容支撑的结论memory-ladder.tsv12 个内存预算每档都在硬 cgroup 上限下运行阶梯表ladder table、两种缓存two-cache发现trunk-cache-split.tsv两个固定预算32 GB、128 GB下各 6 种切分内存分配建议allocation recommendationreplication.tsv同一配置运行 3 次噪声地板noise floorexpert-cache-capacity.txt从记录 trace 重放的 LRU / Belady / pinned 命中率专家缓存为什么弱trunk-quantisation.txt真实权重上 int8 与 int4 的重建误差trunk 为什么走流式streamed而不是量化generations.txt模型实际生成内容已解码回文本输出声明environment.txt机器环境以上全部目录里另有一份 speed-2026-08.md是 2026 年 8 月在另一台机器124 核、720 GB RAM、4.6 GB/s 本地 NVMe上的第二批速度记录其中明确注明磁盘快于公开环境3.2 GB/s因此流式行不能当作纯代码对比——这体现了该目录一贯的标注纪律每个数字都带上它依赖的硬件前提。先读噪声地板33% 是单次样本的固有离散replication.tsv 是最小但最关键的文件同一二进制、同一 prompt、同一参数、同一分钟内连续运行 3 次结果完全相同的配置给出——run s/token 1 14.7760 2 14.6655 3 20.1408均值 16.53标准差 3.13极差比 33.1%。也就是说三分之一的测量是噪声。这套数据里每一个单样本比较都受它约束两个单次运行之间小于约 33% 的差异不构成已确立的效应。README 把这一点放在最前面因为它曾推翻了本轮测量早期的一些结论——包括一个所谓128 GB 异常点事后看只是离散度的产物。这个噪声地板直接决定了仓库基准脚本的设计benchmarks/memory-ladder.sh 与 benchmarks/split-sweep.sh 都默认每档跑 3 次重复reps参数因为单样本无法区分效应与噪声。内存阶梯数据12 档预算下每 token 读多少字节memory-ladder.tsv 的列为total_gb, pin_layers, pin_gb, cache_gb, cache_slots, s_per_tok, expert_hit_true, expert_hit_naive, trunk_hit, gb_read, peak_rss_gb, io_share, ids。从 8 GB 到 224 GB 共 12 档每档都在 systemd cgroup 硬上限下运行MemoryMax加MemorySwapMax0防止超限后走 swap 污染计时。几个可直接读出的事实最低档8 GBpeak RSS 正好是 8.24 GBgb_read为 25.83 GB/token——即每个 token 几乎要把整个专家工作集从盘上读一遍。预算加大后gb_read阶梯式下降192 GB 档降到 16.65224 GB 档 14.53 GB/tokenio_share从 57.3% 起伏到 40.9%说明中低预算下速度受磁盘 I/O 与计算叠加约束。trunk_hit从 0%8 GB 档完全不驻留 trunk升到 84.7%192 GB 档而s_per_tok并非随预算单调下降32.69 → 19.21 之间有波动这再次呼应噪声地板的警告。阶梯的测量方式硬 cgroup 上限与确定性断言benchmarks/memory-ladder.sh 的做法值得单独看它展示了让内存预算有意义的完整机制Linux only用systemd-run --scope --user -p MemoryMax${TOT}G -p MemorySwapMax0施加真实上限见 benchmarks/memory-ladder.sh#L80-L84。脚本注释明确指出没有真上限时每一档都会想要多少内存就有多少阶梯测不出任何东西却仍会产出完整的表。MemorySwapMax0保证超限的档是被 OOM 杀掉而不是慢慢 swap——后者会测出swap 带宽这种穿着正确形状的错数。OOM 与故障的区分退出码 137SIGKILL内核终止超 MemoryMax cgroup 的方式或日志含 OOM 字样才记为装不下这本身是一个结果其他失败则中止实验防止把故障伪装成数据点。确定性断言harness 的核心目的是验证每个内存预算下输出 token 序列完全相同。脚本会先确认generated_ids确实读到了空串对空串的比较会虚证通过再逐档与首档比对任何分歧都以非零码结束。机器出处运行结果旁写一份machine.txt内核、CPU、核数、内存、trunk 所在文件系统、k3 --version让不同机器的阶梯可以互相比较。预算到切分的映射规则先喂 trunk因为它每 token 全量重读而专家只动约 25.8 GB见 benchmarks/memory-ladder.sh#L63-L65。trunk/专家缓存切分固定预算下给 trunk 更划算以及它的确切边界trunk-cache-split.tsv 固定总预算、只变 trunk 与专家缓存的比例共 12 个切分点。这是 README 中强调值得精确表述的部分原始数据比朴素读法强、比粗心读法弱。128 GB六个切分trunk GB → s/token12.3 → 28.38 30.8 → 25.20 49.2 → 25.69 73.8 → 18.37 98.4 → 19.46 110.0 → 16.80端点比1.689×——这就是 1.69× 这个数字的出处。并非单调有两处反转30.8→49.2 处 1.9%73.8→98.4 处 5.9%。六个点上的 Spearman 秩相关 ρ −0.886。32 GB六个切分以四分之一内存独立复现同一问题2.7 → 31.23 6.8 → 30.58 10.8 → 31.25 16.2 → 30.88 21.6 → 29.13 25.6 → 28.06端点比1.113×。一处反转2.2%。Spearman ρ −0.714。结论的承载方式跨两个独立预算的 12 个点都呈现强负秩相关trunk 份额越大、每 token 时间越短每一处反转都远在 33% 噪声地板之内既不能证伪趋势单点之间的步长也不能作为趋势的正向证据。真正支撑结论的是 12 点秩相关加机制本身——trunk 每 token 全量重读108.81 GB而专家只动约 25.8 GB。这组数据没有确立的1.69× 不是被复制验证过的效应量。它只是单样本的端点比较——方向被充分支持幅度没有被重复验证。仓库给出的下一步是 benchmarks/split-sweep.sh它带重复次数重跑该实验固定总预算按 trunk 占比 0.10 / 0.25 / 0.60 / 0.86 四个分数扫描benchmarks/split-sweep.sh#L57-L66且刻意让 cache-heavy 的切分先跑——让扫描针对假说运行而不是顺着假说运行。与阶梯不同这里的 OOM 被定义为 harness 缺陷而非结果既然所有切分都按同一固定总预算配好装不下就说明切分配置错了必须中止而不是记成数据点。专家缓存容量秒级可复现的那条曲线expert-cache-capacity.txt 回答专家缓存到底需要多少 RAM方法是重放 tracetests/fixtures/expert_trace.bin800,768 字节、100,096 次专家请求随仓库分发回放工具是 tools/sim_cache.pypython3 tools/sim_cache.py tests/fixtures/expert_trace.bin这是全部数据中任何人几秒内都能重新推导的一条而且它解释了两种缓存的发现。其动机在文件里说得很直白本轮测到的其他缓存命中率都是被混淆的200 GB arena 永不淘汰的 96.15%、刚起步的 39.31%、比一个 token 还小的缓存的 0.00%没有一个能回答定容问题而路由决策不依赖缓存所以一次运行记录下来的 trace 可以在任意容量下重放代价为零。trace 画像100,096 次请求、10,010 个不同专家82,432 池的 12.14%、约 68 个 token若什么都不缓存则每 token 读 25.83 GB。容量-命中率表节选缓存槽数LRUBeladyPINLRUGB/tokens/token8–64 GB455–364736.24%全程持平39.42–61.74%37.82–48.66%16.4713.35128 GB729449.19%84.59%62.86%13.1210.64192 GB 及以上1094190.00%90.00%90.00%2.582.09文件给出的四条解读LRU 从 8 GB 到 64 GB 完全持平36.24%——8 倍容量范围内加内存买不到任何东西。拐点在 64→128 GB 之间完全受益需要 192 GB。杠杆在策略而非容量同样 64 GBBelady 达到 61.74% 而 LRU 只有 36.24%。这 25.5 个百分点的空间比买内存更有前途的方向。90.00% 是硬天花板trace 触到 10,010 个不同专家每个至少必读一次强制缺失任何策略在任何容量下都打不破 90%。K3 的路由器从设计上就让这更难技术报告 2.3.3 节用 Quantile Balancing 训练路由目的就是抹平专家使用分布使用分布平坦恰好是击垮 LRU 缓存的条件所以缓存表现弱是模型性质不是引擎缺陷。实现上tools/sim_cache.py 内置三种策略LRU引擎实际实现tools/sim_cache.py#L36-L48、Belady最优离线策略需要整个 trace 的未来知识只能当上限、PinnedLRU最热 N 个专家常驻、其余 LRU同样带未来知识、只能当上限。每个专家大小取实测值 17,547,264 字节默认盘速 1234 MB/s实测随机冷读速率s/token 列只算专家 I/O不含真实服务循环中与之重叠的计算。重要的保留这条 trace 记录于每步重做整个前缀 re-prefill 的运行所以同一批专家被合法地触到约 68 次稳态增量解码的重用远低于此实际命中率会比这条曲线更低。这些数字应视为缓存能做到什么的上界而不是预测。trunk 量化敏感性为什么 trunk 走流式而不是量化trunk-quantisation.txt 是引擎核心设计决策的测量依据驻留 trunk 逐字节流式读取而不是量化。量化 trunk 是把 113 GB 驻留集合塞进更小内存的显然方法但也是错误的方法——技术报告 4.1.4 节说明专家是带 QAT 的 MXFP4其余非专家组件保持高精度而这个其余就是 trunk它从未被训练去容忍 4-bit。这份研究在真实权重上验证了这一点。方法从发布 checkpoint 通过HTTP range read 抽样31 个注意力投影张量不下载全量每张量 384 行round-trip 过 int8 与 int4每 32 元素一个 fp32 scale记录平均相对重建误差。结果高度一致类型 int8 均值 int4 均值 比值 KDA 层张量 (n2) 0.01046 0.18746 17.9x MLA 层张量 (n18) 0.00948 0.17154 18.1x 全部 31 张量 0.00961 0.17383 18.1xint8 约 1% 平均相对误差int4 约 17%~18× 的差距在每种层类型上都稳定存在——没有任何层类型能明显更好地容忍 int4。因此引擎不量化任何东西路由专家在 checkpoint 里本来就是 MXFP4按原格式相乘trunk 逐字节拷贝。流式的重建误差为零这正是内存可以做成旋钮而不附带任何精度声明的原因。文件同时给出诚实的限制这是权重重建误差不是输出质量17% 权重误差不会直接变成 17% 的模型退化每张量只抽了 384 行而非整张量只覆盖注意力投影不含 MoE、embeddings、lm_head没有在 int4 下跑过任何下游 logit/token 对比真实质量代价未被测量。要补上这个缺口起点是tools/ref_forward.py的--int8模式。模型实际生成了什么generations.txtgenerations.txt 的原则是token id 本身不携带质量信号所以所有 id 都通过 C tokenizer 解码回文本并逐字复现——包括不好看的部分promptThe capital of France isids 1008,10484,318,15383,387生成Paris.,~ The Eiffelids 17374,20829,10,427,414,1008,606,142957~标记换行。前两个 token 是 Paris和.,——回答正确后面看起来钻进 diff 或 JSON 上下文里是因为这是基座模型、没有 chat template、没有指令微调纯续写是预期行为。同一答案在 8 倍内存跨度上成立7 个 cgroup 硬上限档位96 GB 到 12 GB每档都输出17374,20829,10——不只是每档相同而是从 96 GB 到 12 GB 同一个正确的答案。O_DIRECT 档也一致。该表的 s/token 列来自更早更慢的配置这张表的看点是输出列而非计时列。对 logit 对齐 fixture 的诚实保留与参考实现逐元素 logit 对比用的 prompt ids 是 3,4,5,6,7解码出来是$%(——合成垃圾不是文本。它建立的一致性真实且精确是项目最强的正确性证据但那是对一个无意义 prompt 的一个位置的一致性与输出质量无关。复现路径三条门槛不同的路README 把复现分成几档门槛依次降低阶梯与切分表memory-ladder.tsv、trunk-cache-split.tsv分别由 benchmarks/memory-ladder.sh 和 benchmarks/split-sweep.sh 再生。两者都需要 1.56 TB checkpoint、打包好的 trunk用 scripts/pack-trunk.sh和带 systemd 的 Linux 主机cgroup 上限是让内存预算有意义的唯一手段。两个脚本都会在结果旁写一份machine.txt使新运行可以与本仓库这份直接对比。专家缓存容量不需要权重也不需要 GPU只重放随仓库分发的tests/fixtures/expert_trace.binpython3 tools/sim_cache.py tests/fixtures/expert_trace.bin一条命令即可——这是任何人在几秒内就能重新推导、并解释两种缓存发现的那条结果。trunk 量化当时的脚本走的是 HTTP range read 抽样而非完整下载脚本未随仓库分发结果文件本身记录了方法与局限。范围引擎测量不是质量基准这套数据是引擎测量速度、内存、移动的字节数、缓存行为、以及模型吐出了什么。它们不是质量基准——没有 perplexity、没有任务评测、没有与任何别的实现的输出质量对比。正确性证据是另一套且更硬的见 docs/TESTING.md以及tests/fixtures/gates/与tests/fixtures/golden/里的日志。引用这套数据时应当像仓库自己那样区分两件事方向性的结论trunk 优先分配、缓存策略比容量更值得投入有 12 点秩相关与机制支撑而具体倍数如 1.69×在重复实验落地前只是端点单样本比较。赞分享人工智能大模型推理引擎本地部署【免费下载链接】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 调优指南:trunk 优先的内存分配、preset 选择与噪声下限Kimi K3 in C 调优指南:trunk 优先的内存分配、preset 选择与噪声下限 本文围绕 docs/TUNING.md https://link.人工智能大模型推理引擎本地部署kimi-k3-in-c 性能剖析内存预算阶梯、双缓存行为与 33% 噪声底线下的调优方法论kimi k3 in c 性能剖析内存预算阶梯、双缓存行为与 33% 噪声底线下的调优方法论 本文基于 docs/PERFORMANCE.md https:/人工智能大模型推理引擎本地部署kimi-k3-in-c 的 CPU 推理基准测试方法论33% 噪声地板、污染因子清单与基于计数的可复现度量kimi k3 in c 的 CPU 推理基准测试方法论33% 噪声地板、污染因子清单与基于计数的可复现度量 ! 同一配置三次运行的 s/token 波动1人工智能大模型推理引擎本地部署上一篇dograh STT 评测基准详解WebSocket 流式转写下的说话人分离与关键词增强对比实践下一篇WrenAI完全指南如何为AI智能体构建数据上下文层的终极解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 kimi-k3-in-c 测量数据目录指南：性能声明背后的噪声地板、内存阶梯与 trunk/专家缓存分配证据
人工智能大模型推理引擎本地部署【免费下载链接】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/data/是 kimi-k3-in-c 仓库中所有性能数字的原始出处docs/PERFORMANCE.md 与 docs/TUNING.md 中的每一张表都引用了这里的某个文件。读完本篇你将掌握这套测量体系的完整脉络——实验机环境、噪声地板单次运行间 33% 的离散度、12 档硬 cgroup 内存预算下的阶梯数据、固定预算下 trunk/专家缓存的切分实验、专家缓存容量回放、trunk 量化敏感性研究以及每条结论的确切证据边界与复现方式。数据来源与实验机环境所有数据来自同一台机器上的同一轮测量one campaign, one machine完整环境记录在 docs/data/environment.txt 中包括测量前应用的测量卫生措施。README 给出的环境摘要为AMD EPYC 7763124 vCPU2×62 核无 SMT228 GiB RAM3.2 TB NVMe 以 O_DIRECT 达到 3.2 GB/sUbuntu 24.04.3GCC 13.3支持 AVX2 但没有AVX-512。environment.txt 中还有几条对解读数据至关重要的细节实例形态4×L40 GPU 实例但 GPU 全程空闲0% 占用。这是一台纯 CPU 推理引擎实例是冲着 228 GiB 内存和 3.2 TB NVMe 选的。存储带宽实测O_DIRECT 冷读 3.2 GB/sbuffered 热读 2.3 GB/s——这里 O_DIRECT 反而比 buffered 快与通常预期相反这正是引擎选择以 O_DIRECT 打开 trunk 的原因实际运行中 trunk 持续读取速率在 5373–6064 MB/s。README 也提醒换目标设备前值得重新验证这一结论。测量卫生测量前停止了unattended-upgrades冒烟测试期间它占用了约 63% 的单核那次计时因此被污染且未被引用并禁用了apt-daily.timer/apt-daily-upgrade.timer。七个数据文件各支撑什么结论文件内容支撑的结论memory-ladder.tsv12 个内存预算每档都在硬 cgroup 上限下运行阶梯表ladder table、两种缓存two-cache发现trunk-cache-split.tsv两个固定预算32 GB、128 GB下各 6 种切分内存分配建议allocation recommendationreplication.tsv同一配置运行 3 次噪声地板noise floorexpert-cache-capacity.txt从记录 trace 重放的 LRU / Belady / pinned 命中率专家缓存为什么弱trunk-quantisation.txt真实权重上 int8 与 int4 的重建误差trunk 为什么走流式streamed而不是量化generations.txt模型实际生成内容已解码回文本输出声明environment.txt机器环境以上全部目录里另有一份 speed-2026-08.md是 2026 年 8 月在另一台机器124 核、720 GB RAM、4.6 GB/s 本地 NVMe上的第二批速度记录其中明确注明磁盘快于公开环境3.2 GB/s因此流式行不能当作纯代码对比——这体现了该目录一贯的标注纪律每个数字都带上它依赖的硬件前提。先读噪声地板33% 是单次样本的固有离散replication.tsv 是最小但最关键的文件同一二进制、同一 prompt、同一参数、同一分钟内连续运行 3 次结果完全相同的配置给出——run s/token 1 14.7760 2 14.6655 3 20.1408均值 16.53标准差 3.13极差比 33.1%。也就是说三分之一的测量是噪声。这套数据里每一个单样本比较都受它约束两个单次运行之间小于约 33% 的差异不构成已确立的效应。README 把这一点放在最前面因为它曾推翻了本轮测量早期的一些结论——包括一个所谓128 GB 异常点事后看只是离散度的产物。这个噪声地板直接决定了仓库基准脚本的设计benchmarks/memory-ladder.sh 与 benchmarks/split-sweep.sh 都默认每档跑 3 次重复reps参数因为单样本无法区分效应与噪声。内存阶梯数据12 档预算下每 token 读多少字节memory-ladder.tsv 的列为total_gb, pin_layers, pin_gb, cache_gb, cache_slots, s_per_tok, expert_hit_true, expert_hit_naive, trunk_hit, gb_read, peak_rss_gb, io_share, ids。从 8 GB 到 224 GB 共 12 档每档都在 systemd cgroup 硬上限下运行MemoryMax加MemorySwapMax0防止超限后走 swap 污染计时。几个可直接读出的事实最低档8 GBpeak RSS 正好是 8.24 GBgb_read为 25.83 GB/token——即每个 token 几乎要把整个专家工作集从盘上读一遍。预算加大后gb_read阶梯式下降192 GB 档降到 16.65224 GB 档 14.53 GB/tokenio_share从 57.3% 起伏到 40.9%说明中低预算下速度受磁盘 I/O 与计算叠加约束。trunk_hit从 0%8 GB 档完全不驻留 trunk升到 84.7%192 GB 档而s_per_tok并非随预算单调下降32.69 → 19.21 之间有波动这再次呼应噪声地板的警告。阶梯的测量方式硬 cgroup 上限与确定性断言benchmarks/memory-ladder.sh 的做法值得单独看它展示了让内存预算有意义的完整机制Linux only用systemd-run --scope --user -p MemoryMax${TOT}G -p MemorySwapMax0施加真实上限见 benchmarks/memory-ladder.sh#L80-L84。脚本注释明确指出没有真上限时每一档都会想要多少内存就有多少阶梯测不出任何东西却仍会产出完整的表。MemorySwapMax0保证超限的档是被 OOM 杀掉而不是慢慢 swap——后者会测出swap 带宽这种穿着正确形状的错数。OOM 与故障的区分退出码 137SIGKILL内核终止超 MemoryMax cgroup 的方式或日志含 OOM 字样才记为装不下这本身是一个结果其他失败则中止实验防止把故障伪装成数据点。确定性断言harness 的核心目的是验证每个内存预算下输出 token 序列完全相同。脚本会先确认generated_ids确实读到了空串对空串的比较会虚证通过再逐档与首档比对任何分歧都以非零码结束。机器出处运行结果旁写一份machine.txt内核、CPU、核数、内存、trunk 所在文件系统、k3 --version让不同机器的阶梯可以互相比较。预算到切分的映射规则先喂 trunk因为它每 token 全量重读而专家只动约 25.8 GB见 benchmarks/memory-ladder.sh#L63-L65。trunk/专家缓存切分固定预算下给 trunk 更划算以及它的确切边界trunk-cache-split.tsv 固定总预算、只变 trunk 与专家缓存的比例共 12 个切分点。这是 README 中强调值得精确表述的部分原始数据比朴素读法强、比粗心读法弱。128 GB六个切分trunk GB → s/token12.3 → 28.38 30.8 → 25.20 49.2 → 25.69 73.8 → 18.37 98.4 → 19.46 110.0 → 16.80端点比1.689×——这就是 1.69× 这个数字的出处。并非单调有两处反转30.8→49.2 处 1.9%73.8→98.4 处 5.9%。六个点上的 Spearman 秩相关 ρ −0.886。32 GB六个切分以四分之一内存独立复现同一问题2.7 → 31.23 6.8 → 30.58 10.8 → 31.25 16.2 → 30.88 21.6 → 29.13 25.6 → 28.06端点比1.113×。一处反转2.2%。Spearman ρ −0.714。结论的承载方式跨两个独立预算的 12 个点都呈现强负秩相关trunk 份额越大、每 token 时间越短每一处反转都远在 33% 噪声地板之内既不能证伪趋势单点之间的步长也不能作为趋势的正向证据。真正支撑结论的是 12 点秩相关加机制本身——trunk 每 token 全量重读108.81 GB而专家只动约 25.8 GB。这组数据没有确立的1.69× 不是被复制验证过的效应量。它只是单样本的端点比较——方向被充分支持幅度没有被重复验证。仓库给出的下一步是 benchmarks/split-sweep.sh它带重复次数重跑该实验固定总预算按 trunk 占比 0.10 / 0.25 / 0.60 / 0.86 四个分数扫描benchmarks/split-sweep.sh#L57-L66且刻意让 cache-heavy 的切分先跑——让扫描针对假说运行而不是顺着假说运行。与阶梯不同这里的 OOM 被定义为 harness 缺陷而非结果既然所有切分都按同一固定总预算配好装不下就说明切分配置错了必须中止而不是记成数据点。专家缓存容量秒级可复现的那条曲线expert-cache-capacity.txt 回答专家缓存到底需要多少 RAM方法是重放 tracetests/fixtures/expert_trace.bin800,768 字节、100,096 次专家请求随仓库分发回放工具是 tools/sim_cache.pypython3 tools/sim_cache.py tests/fixtures/expert_trace.bin这是全部数据中任何人几秒内都能重新推导的一条而且它解释了两种缓存的发现。其动机在文件里说得很直白本轮测到的其他缓存命中率都是被混淆的200 GB arena 永不淘汰的 96.15%、刚起步的 39.31%、比一个 token 还小的缓存的 0.00%没有一个能回答定容问题而路由决策不依赖缓存所以一次运行记录下来的 trace 可以在任意容量下重放代价为零。trace 画像100,096 次请求、10,010 个不同专家82,432 池的 12.14%、约 68 个 token若什么都不缓存则每 token 读 25.83 GB。容量-命中率表节选缓存槽数LRUBeladyPINLRUGB/tokens/token8–64 GB455–364736.24%全程持平39.42–61.74%37.82–48.66%16.4713.35128 GB729449.19%84.59%62.86%13.1210.64192 GB 及以上1094190.00%90.00%90.00%2.582.09文件给出的四条解读LRU 从 8 GB 到 64 GB 完全持平36.24%——8 倍容量范围内加内存买不到任何东西。拐点在 64→128 GB 之间完全受益需要 192 GB。杠杆在策略而非容量同样 64 GBBelady 达到 61.74% 而 LRU 只有 36.24%。这 25.5 个百分点的空间比买内存更有前途的方向。90.00% 是硬天花板trace 触到 10,010 个不同专家每个至少必读一次强制缺失任何策略在任何容量下都打不破 90%。K3 的路由器从设计上就让这更难技术报告 2.3.3 节用 Quantile Balancing 训练路由目的就是抹平专家使用分布使用分布平坦恰好是击垮 LRU 缓存的条件所以缓存表现弱是模型性质不是引擎缺陷。实现上tools/sim_cache.py 内置三种策略LRU引擎实际实现tools/sim_cache.py#L36-L48、Belady最优离线策略需要整个 trace 的未来知识只能当上限、PinnedLRU最热 N 个专家常驻、其余 LRU同样带未来知识、只能当上限。每个专家大小取实测值 17,547,264 字节默认盘速 1234 MB/s实测随机冷读速率s/token 列只算专家 I/O不含真实服务循环中与之重叠的计算。重要的保留这条 trace 记录于每步重做整个前缀 re-prefill 的运行所以同一批专家被合法地触到约 68 次稳态增量解码的重用远低于此实际命中率会比这条曲线更低。这些数字应视为缓存能做到什么的上界而不是预测。trunk 量化敏感性为什么 trunk 走流式而不是量化trunk-quantisation.txt 是引擎核心设计决策的测量依据驻留 trunk 逐字节流式读取而不是量化。量化 trunk 是把 113 GB 驻留集合塞进更小内存的显然方法但也是错误的方法——技术报告 4.1.4 节说明专家是带 QAT 的 MXFP4其余非专家组件保持高精度而这个其余就是 trunk它从未被训练去容忍 4-bit。这份研究在真实权重上验证了这一点。方法从发布 checkpoint 通过HTTP range read 抽样31 个注意力投影张量不下载全量每张量 384 行round-trip 过 int8 与 int4每 32 元素一个 fp32 scale记录平均相对重建误差。结果高度一致类型 int8 均值 int4 均值 比值 KDA 层张量 (n2) 0.01046 0.18746 17.9x MLA 层张量 (n18) 0.00948 0.17154 18.1x 全部 31 张量 0.00961 0.17383 18.1xint8 约 1% 平均相对误差int4 约 17%~18× 的差距在每种层类型上都稳定存在——没有任何层类型能明显更好地容忍 int4。因此引擎不量化任何东西路由专家在 checkpoint 里本来就是 MXFP4按原格式相乘trunk 逐字节拷贝。流式的重建误差为零这正是内存可以做成旋钮而不附带任何精度声明的原因。文件同时给出诚实的限制这是权重重建误差不是输出质量17% 权重误差不会直接变成 17% 的模型退化每张量只抽了 384 行而非整张量只覆盖注意力投影不含 MoE、embeddings、lm_head没有在 int4 下跑过任何下游 logit/token 对比真实质量代价未被测量。要补上这个缺口起点是tools/ref_forward.py的--int8模式。模型实际生成了什么generations.txtgenerations.txt 的原则是token id 本身不携带质量信号所以所有 id 都通过 C tokenizer 解码回文本并逐字复现——包括不好看的部分promptThe capital of France isids 1008,10484,318,15383,387生成Paris.,~ The Eiffelids 17374,20829,10,427,414,1008,606,142957~标记换行。前两个 token 是 Paris和.,——回答正确后面看起来钻进 diff 或 JSON 上下文里是因为这是基座模型、没有 chat template、没有指令微调纯续写是预期行为。同一答案在 8 倍内存跨度上成立7 个 cgroup 硬上限档位96 GB 到 12 GB每档都输出17374,20829,10——不只是每档相同而是从 96 GB 到 12 GB 同一个正确的答案。O_DIRECT 档也一致。该表的 s/token 列来自更早更慢的配置这张表的看点是输出列而非计时列。对 logit 对齐 fixture 的诚实保留与参考实现逐元素 logit 对比用的 prompt ids 是 3,4,5,6,7解码出来是$%(——合成垃圾不是文本。它建立的一致性真实且精确是项目最强的正确性证据但那是对一个无意义 prompt 的一个位置的一致性与输出质量无关。复现路径三条门槛不同的路README 把复现分成几档门槛依次降低阶梯与切分表memory-ladder.tsv、trunk-cache-split.tsv分别由 benchmarks/memory-ladder.sh 和 benchmarks/split-sweep.sh 再生。两者都需要 1.56 TB checkpoint、打包好的 trunk用 scripts/pack-trunk.sh和带 systemd 的 Linux 主机cgroup 上限是让内存预算有意义的唯一手段。两个脚本都会在结果旁写一份machine.txt使新运行可以与本仓库这份直接对比。专家缓存容量不需要权重也不需要 GPU只重放随仓库分发的tests/fixtures/expert_trace.binpython3 tools/sim_cache.py tests/fixtures/expert_trace.bin一条命令即可——这是任何人在几秒内就能重新推导、并解释两种缓存发现的那条结果。trunk 量化当时的脚本走的是 HTTP range read 抽样而非完整下载脚本未随仓库分发结果文件本身记录了方法与局限。范围引擎测量不是质量基准这套数据是引擎测量速度、内存、移动的字节数、缓存行为、以及模型吐出了什么。它们不是质量基准——没有 perplexity、没有任务评测、没有与任何别的实现的输出质量对比。正确性证据是另一套且更硬的见 docs/TESTING.md以及tests/fixtures/gates/与tests/fixtures/golden/里的日志。引用这套数据时应当像仓库自己那样区分两件事方向性的结论trunk 优先分配、缓存策略比容量更值得投入有 12 点秩相关与机制支撑而具体倍数如 1.69×在重复实验落地前只是端点单样本比较。赞分享人工智能大模型推理引擎本地部署【免费下载链接】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 调优指南:trunk 优先的内存分配、preset 选择与噪声下限Kimi K3 in C 调优指南:trunk 优先的内存分配、preset 选择与噪声下限 本文围绕 docs/TUNING.md https://link.人工智能大模型推理引擎本地部署kimi-k3-in-c 性能剖析内存预算阶梯、双缓存行为与 33% 噪声底线下的调优方法论kimi k3 in c 性能剖析内存预算阶梯、双缓存行为与 33% 噪声底线下的调优方法论 本文基于 docs/PERFORMANCE.md https:/人工智能大模型推理引擎本地部署kimi-k3-in-c 的 CPU 推理基准测试方法论33% 噪声地板、污染因子清单与基于计数的可复现度量kimi k3 in c 的 CPU 推理基准测试方法论33% 噪声地板、污染因子清单与基于计数的可复现度量 ! 同一配置三次运行的 s/token 波动1人工智能大模型推理引擎本地部署上一篇dograh STT 评测基准详解WebSocket 流式转写下的说话人分离与关键词增强对比实践下一篇WrenAI完全指南如何为AI智能体构建数据上下文层的终极解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考