Kimi K3 纯 CPU 推理中的无损 Trunk 压缩：一次被解码速度判死刑的 Huffman 压缩实验

人工智能大模型推理引擎本地部署【免费下载链接】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仓库中一份调查笔记 compressed-trunk.md 展开该项目曾尝试对 bf16 稠密主干trunk做无损熵压缩把 108 GB 级文件压到约 67%以在流式读取预算下直接换取每 token 耗时压缩方案完整实现并通过了字节级往返验证却因标量解码器只有约 0.31 GB/s 每核的吞吐而最终被搁置。读完本文你会理解熵压缩在 I/O 受限推理管线中的适用边界以及压缩率不是唯一变量解码速度才是这一用真实测量数据得出的工程结论。背景为什么 trunk 的字节数直接等于延迟要理解这次实验先看它作用的对象。Kimi K3 的 2.78T 参数中MoE 专家是 MXFP4而所有非专家组件注意力投影、latent MoE 投影、共享专家、路由器保持高精度——这部分正是trunk。官方技术报告中明确列出了这些未量化组件事后 4-bit 量化在真实 K3 权重上会引入 12% 输出误差int8 为 0.54%所以 trunk 必须按字节原样搬运这也是 tools/pack_trunk.py 开头注释反复强调流式是无损的的原因。在低内存预算下引擎每个 token 都要按固定层序layer 0..92重读整个 108.81 GB 的 trunk。TUNING.md 给出的算术很直白给 trunk 多 1 GB 预算就能钉住pin约一层永远不再读它约等于消除 1.17 GB/token 的确定性流量而引擎在低预算下每 token 要搬运约 135 GB 数据存储带宽通常是天花板而非 CPU。于是压缩 trunk的诱惑非常自然在流式预算下trunk 少几个字节就是每 token 少几秒。压缩比越高SSD 读取时间越短。这个思路的逻辑链完整、无损、且与引擎输出零冲突——问题出在解码侧这正是本文的主角。核心思想bf16 高字节的熵结构实验的出发点是一个测量事实trunk 是 bf16 格式而 bf16 值的高字节符号位 指数位在这个 checkpoint 上只携带约 2.8 bit 的真实信息——粗略地说十几个不同的字节取值就覆盖了 99.9% 的所有权重。换句话说指数平面是一个极端偏斜的分布香农熵远低于 8 bit。由此得到方案的核心设计见 compressed-trunk.md 的 The idea 一节只对高字节平面做熵编码Huffman把偏斜分布换成变长码低字节尾数平面按噪声处理原样存储——测量表明它不具备可利用的统计结构解码出来的字节就是 checkpoint 自己的字节因此整个方案是无损的引擎输出一个 token 都不会改变整体效果打包后的 trunk 缩小到约67%的体积。为什么不做整块 LZ 类压缩搁置原型头的注释里给出了已测量的答案见 k3_huf.h.shelvedLZ 家族编解码器的解码速度慢了一个数量级追不上硬盘读取速度所以只选纯 Huffman。这是一个典型的先用测量排除一条路线的决策。已实现的部分规范限长 Huffman 编解码器容器格式编码器是打包时的一次性 Python 工具huf_encode.py.shelved解码器是引擎侧的纯 C 头文件k3_huf.h.shelved只解码、不编码。格式按 k3_huf.h.shelved 的定义组织[ K3HufLayerHdr ] 字节平面字母表的规范码长codelen[256] stripe 0: [K3HufStripeHdr][奇字节平面的 Huffman 位流][偶字节平面原样] stripe 1: ...关键设计点stripe 并行每个 stripe 覆盖 64 MiB 原始数据K3_HUF_STRIPEk3_huf.h.shelved各 stripe 独立解码天然可按 stripe 并行奇偶平面分离bf16 小端存储下奇数偏移正是高字节指数平面——只有这一半被 Huffman 编码偶数偏移的尾数字节逐字节原样复制码长限制在 12 bitK3_HUF_MAXLEN编码器把更深的树压平于是解码器只需一张1 12项的表一次加载即得符号与码长sym_len打包为(symbol 4) | code_length见 k3_huf.h.shelved。规范码分配与 Kraft 校验解码器建表函数 k3_huf_build 做了两件事两者都是格式正确性的基石Kraft 校验sum(count[l] (MAXLEN - l))必须恰好满或不满 12-bit 码空间超满over-subscribed或为空都判定为损坏的 trunk 而非继续解码垃圾数据最长优先的规范码分配先算出每个码长的起始码first[l] code; code (code count[l]) 1再按符号序填充把每个码在 12-bit 表中展开为其覆盖的全部前缀区间。头文件特别警告这套最长优先规范分配必须与 Python 编码器完全一致改一方必须改另一方。Python 侧的 canonical_codes 实现了同一套规范分配code_lengths 用标准 Huffman 树累积深度生成码长并带有 BZip2 风格的限长修正_limit在 Kraft 超满时反复加长最低频码。对一个约 12 个高频符号、12 bit 上限的字母表限长修正实际上几乎不会触发但正确性被要求触发时也必须对。解码循环 k3_huf_decode_stripe 经过两轮手写优化位累加器把流的首部对齐到窗口顶端一次 refill 约服务 8 个符号而非每符号一次偶平面拷贝在奇平面解码完成后以独立循环完成。验证结果在真实 trunk 字节上Python 编码、C 解码字节级精确往返在 4 MB 样本上实测1.45 倍压缩比率 0.689与理论预期的 ~67% 一致。格式、Kraft 校验、规范码分配全部验证通过。至此压缩这一半是完成且正确的。让方案被搁置的测量解码速度标量解码器的天花板手写的标量 Huffman 解码器经过两轮优化只达到~0.31 GB/s 每核。把这个数字代入真实场景目标设备是3 GB/s 的笔记本 SSDtrunk 流式读取的带宽来源要在这个速度下持续喂饱压缩 trunk需要约10 个核专职解码——笔记本没有这么多核。由此得出笔记中最锋利的一句话compressed-trunk.md 原文这样建成的压缩帮助的是那些有 RAM 到根本不需要它的多核机器却饿死了真正需要的笔记本。这与目标背道而驰。注意这个悖论的结构压缩收益与解码成本发生在同一批机器上但两者与核数/内存的关系是反的。内存充裕的机器本来就把 trunk 钉进 RAM零读取、零压缩开销核少的笔记本才被迫流式读盘、才最需要少读 33% 的字节——却也正是它们解不动这个码流。快速熵解码器也不行是否存在足够快的熵解码器存在——FSE/Huff0 在同一批指数平面字节上实测 1724 MB/s。但两笔账依然不划算即便以 1724 MB/s 计追上一块笔记本 SSD 仍需2 个专职解码核占走笔记本核心资源vendoring 它约需2000 行代码而本项目的立身之本是一个 176 KB 的零依赖二进制无 BLAS、无框架、无 GPU。收益配不上重量至少对在乎的那些机器如此。这是全文最可迁移的工程教训对 I/O 受限管线做无损压缩必须同时给压缩后字节数 × 磁盘带宽和解码吞吐 × 可用核数两张账只看第一张会把方案带进死胡同。如果将来重启解锁条件笔记的 If revisited 一节给出了明确的重启判据compressed-trunk.md 原文解锁条件是一个落在1~1.5 GB/s 每核区间、同时保持体积小的解码器。达到这个区间单核即可逼近甚至超过笔记本 SSD 的喂数速度压缩收益立刻成立标准路线有两条且都能让现有编码器原样保留格式不变每个 stripe 用4 条交错位流用指令级并行ILP打满流水线双符号表double-symbol table每步解码两个符号、摊薄查表开销仓库里的两个原型是正确的起点格式今天就能往返——缺的只是一个足够快的解码核。换言之这个方案的死亡证明只针对当前解码实现数据特征2.8 bit 熵、格式stripe 奇偶平面分离 12-bit 规范表与编码器都仍然有效。结论今天真正生效的 lever 是什么在快速解码器到手之前笔记给出的替代结论是流式 trunk 的速度杠杆是钉层pinning即 RAM 优先的--preset auto与驻留式 int8 草稿模型而不是压缩。这与仓库其他文档的测量互相印证TUNING.md 的预设表显示server档110 GB trunk 全钉 13 GB cache约 17 s/token且给 trunk 的 1 GB 比给专家 cache 的 1 GB 边际价值高约 70 倍见 speed-2026-08.md 中--preset auto的说明ARCHITECTURE.md 也描述了 trunk 流式环形缓冲 钉住前缀的实现与压缩方案最终竞争的正是这条路线int8 草稿路线的完整账本见 int8-draft-container.md容器、q8 内核、cache-only 路由都建好且位精确但驻留混合解码实测 53 s/token 不敌精确解码的 19.8 s/token——因为草稿仍要流式读 25.8 GB/ token 的 MXFP4 专家。两条非压缩路线同样经历了建出来、测出来、按数据取舍的过程与本文的 Huffman 实验构成同一套方法论的两次实例。对读者的三点直接启发无损压缩的价值 少读的字节 × 存储带宽 ÷ 解码代价三者缺一不可本例中 33% 的字节削减被 0.31 GB/s 的解码核完全抵消先测数据分布再选编码2.8 bit 的指数平面熵让 Huffman 一步逼近理论极限1.45x vs 理论 1/0.689 ≈ 1.45x而尾数平面测出是噪声就果断放弃搁置不等于删除.shelved原型保留了完整格式与双端实现Kraft 校验、规范码分配的改一方必改另一方警告都写在头文件里——一旦 1~1.5 GB/s 每核的解码器出现4 交错位流或双符号表都是公开的标准手段这个方案可以直接从正确起点重启。赞分享人工智能大模型推理引擎本地部署【免费下载链接】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点击查看免费下载相关推荐gh_mirrors/di/directory背后的技术GitHub数据抓取与评分算法实现gh_mirrors/di/directory背后的技术GitHub数据抓取与评分算法实现 GitHub 加速计划di/directory是一个可搜索、可抖音批量下载去水印用 douyin-downloader 把一位作者的作品完整存下来抖音批量下载去水印用 douyin downloader 把一位作者的作品完整存下来 跑完之后你会得到一批井井有条的本地文件某位作者全部作品的无水印视频网页爬虫CLIHuffman 编码基于贪婪策略的无损压缩原理与 cosmos 多语言实现剖析Huffman 编码基于贪婪策略的无损压缩原理与 cosmos 多语言实现剖析 Huffman 编码是信息论与数据压缩领域最经典的无损压缩算法之一其核心思想教程示例工程上一篇Sokol缓冲区管理优化GPU数据传输下一篇AceGPT-13B-chat模型量化与优化降低部署成本的5种方法创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考