kimi-k3-in-c 量化实测为什么拒绝量化 Trunkint8 损失1%、int4 损失17%的完整数据解析【免费下载链接】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-ckimi-k3-in-c是一个用纯 C99 编写的推理引擎让 2.78 万亿参数的 Kimi K3 大模型在单 CPU、仅8.24 GB 内存下完成推理——无 BLAS、无框架、无 GPU。围绕这个引擎一个反直觉的设计决策是它拒绝量化 Trunk稠密主干实测数据显示 int8 量化损失约 1% 精度、int4 损失 17%而这份舍入误差无法用更多内存换回。git clone https://gitcode.com/gh_mirrors/ki/kimi-k3-in-c cd kimi-k3-in-c make -j make test # 无需下载模型一分钟验证引擎下面把这份拒绝量化的完整证据链拆开讲。先说结论误差不是免费午餐在模型部署领域量化是压缩内存的标准答案bf16 权重砍到 int8内存减半再砍到 int4内存减到四分之一。但 kimi-k3-in-c 的整套设计建立在一个关键对比上速度损失可以买回来用内存精度损失买不回来任何预算都不行。引擎的内存阶梯实测见 docs/PERFORMANCE.md显示同一个模型从 8 GB 内存32.69 s/token加到 224 GB19.21 s/token输出逐字节完全相同——28 倍的内存只改变时钟不改变答案。而量化是另一回事一旦权重被舍入误差就写死在模型里加多少内存、跑多快的机器都取不回原来的精度。这正是引擎宁可让 Trunk 保持 bf16 原样、走磁盘流式读取的原因。Trunk 是什么Kimi K3 的常驻部分要理解这个决策先看 1.56 TB 检查点里到底装了什么82,432 个路由专家896 个/层 × 92 个 MoE 层共1.447 TB占检查点的 93%。每个 token 每层只激活 16/896 个专家其余 96.3% 的参数睡在磁盘上按 4 位打包格式流式读取从不常驻内存剩下的7%才是常驻集108.81 GB 的稠密主干Trunk 4.70 GB 的嵌入表与输出头合计 113.49 GBbf16。Trunk 就是 93 个稠密层里的注意力投影、路由器、归一化等每个 token 都要跑的部分。量化 Trunk就是把这 108.81 GB 从 bf16 压成 int8 的 54 GB 或 int4 的 27 GB——听起来能省下一大截内存这正是引擎选择实测它、而不是直接拍脑袋拒绝的原因。实测方法真实权重不碰完整下载数据文件 docs/data/trunk-quantisation.txt 记录了测量过程相当克制通过 HTTP 范围读取从正式发布的检查点中抽样31 个注意力投影张量覆盖 KDA 层与 MLA 层每个取 384 行真实权重无需下载 1.56 TB每个张量分别往返转换 int8 与 int4量化方式为业界标准的对称缩放每 32 个元素共享 1 个 fp32 缩放因子记录平均相对重建误差。这种后训练量化PTQ的假设是模型训练时没见过 4 位/8 位舍入只能靠缩放因子硬凑。结果如何看表。核心数据int8 约 1%int4 约 17%差距恒定 18 倍31 个张量的实测均值层级类型张量数int8 平均相对误差int4 平均相对误差int4/int8KDA 层投影20.01046≈1%0.18746≈19%17.9×MLA 层投影180.009480.17154≈17%18.1×全部抽样张量310.00961≈1%0.17383≈17%18.1×两个关键观察int8 ≈ 1%误差可测但小。int4 ≈ 17%每 6 个权重里约有 1 个偏差达到自身量级的六分之一这已经不是精度略有下降而是权重本身被明显改写了。更糟的是长尾——int4 下最坏的单行相对误差达到45%、56% 和 65%最坏张量 L11.o_proj 达 24.6%。还有一个细节值得注意这个 18 倍差距在每一种层类型上都成立。KDA 层、MLA 层的注意力投影没有哪一类更能扛 4 位量化——不存在某个局部能单独降精度的侥幸空间。为什么引擎零量化四个理由1. 模型作者亲手画了这条线Kimi K3 技术报告docs/kimi-k3-tech-report.pdf明确写道专家是MXFP4 量化感知训练QAT而所有非专家组件保持高精度。非专家组件这份名单恰好就是 Trunk——它从设计上就没被量化过也从未被训练去容忍 4 位舍入。引擎的实测只是验证了这一点在真实权重上成立。2. 专家已经是 4 位但没有人为它挨过打引擎里其实只有两种权重类型enum { K3_WF32 0, K3_WBF16 1 };路由专家以 MXFP4 形式直接参与乘法——但那是训练时就按 4 位优化过的QAT 权重不是事后硬压的。引擎没有提供 int8/int4 位宽旋钮因为唯一安全的 4 位专家已经原生存在唯一不安全的 4 位Trunk被实测否决。3. 流式方案的代价是时间而时间可以被 RAM 赎回不量化 Trunk 的代价是每个 token 都要从磁盘重读 108.81 GB 主干慢。但慢是可赎回的——内存阶梯实测中给 Trunk 钉层越多每 token 读盘越少速度线性改善且任何预算下输出与 8 GB 时逐字节一致内存预算s/token每 token 读盘输出8 GB32.6925.83 GB17374, 20829, 10, 427, …32 GB31.4425.83 GB逐字节相同96 GB24.4018.11 GB逐字节相同224 GB19.2114.53 GB逐字节相同零重建误差的流式读取换来内存只是一个拨盘的自由——这也是整套架构的立身之本。量化则相反省下的是内存付出的是任何预算都赎不回的精度的永久损失。4. int8 唯一的合法位置只许提议不许出答案有意思的是int8 在项目中并非被全面封杀——它有一个严格受限的岗位草稿模型。引擎实现了 int8 派生的 draft trunktools/int8_trunk.py 生成 54.47 GB 容器比 bf16 主干小一半草稿只提议token最终的 bf16 精确模型负责验证输出 token 由精确模型说了算实测草稿 teacher-forcing 一致率 94.2%天花板 96.2%真实检查点上 66.7% 的草稿被接受输出与精确模型逐字节相同。也就是说int8 的 1% 误差被关在可丢弃的提议这个笼子里一旦越界直接由 bf16 模型驳回。这是量化误差与可丢弃计算共存的安全范式也反过来说明为什么主干本尊绝不能用 int8——那里没有验证者。完整实验记录见 docs/notes/int8-draft-container.md。诚实的边界这些数字不能过度解读研究者在数据文件里主动标注了局限写得很清楚测的是权重重建误差不是输出质量。17% 的权重误差不等于模型质量差 17%没有任何人应该这么读每个张量只抽样了384 行不是整张量只覆盖注意力投影不含 MoE、嵌入和 lm_head未做下游 logit/token 级对比int4 的真实质量代价是被界定而非被测量。补齐它的起点是 tools/ref_forward.py 的--int8模式。但即便是界定而非测量结论的方向也足够清楚在 1% 与 17% 之间且误差恒定跨 18 倍、长尾最高 65% 的情况下把从未为量化训练过的组件压到 int4 是不可辩护的。总结一份可以抄走的工程判断方案内存精度代价能否赎回Trunk 保持 bf16 流式高108.81 GB 走盘零—Trunk int8省约一半≈1% 权重误差❌ 任何预算下不可逆Trunk int4省到 1/4≈17% 权重误差长尾 65%❌ 任何预算下不可逆kimi-k3-in-c 用实测数据回答了一个很多项目凭信仰回答的问题量化前先测且用真实权重测——31 个张量、HTTP 范围读零下载成本区分可赎回的代价时间与不可赎回的代价精度前者用资源换后者碰都不碰量化误差不是不能存在而是要被关进笼子draft-only 模式 精确模型验证把诚实的局限写进数据文件让后来者知道边界在哪。 想自己复现或深挖入口在这里量化原始数据docs/data/trunk-quantisation.txt性能与内存阶梯docs/PERFORMANCE.md流式主干 I/O 实现src/io/k3_trunk.c全部数值内核含 MXFP4 乘法src/core/k3_ops.cint8 草稿容器设计docs/notes/int8-draft-container.mdTrunk 打包工具scripts/pack-trunk.sh【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 kimi-k3-in-c 量化实测：为什么拒绝量化 Trunk？int8 损失1%、int4 损失17%的完整数据解析
kimi-k3-in-c 量化实测为什么拒绝量化 Trunkint8 损失1%、int4 损失17%的完整数据解析【免费下载链接】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-ckimi-k3-in-c是一个用纯 C99 编写的推理引擎让 2.78 万亿参数的 Kimi K3 大模型在单 CPU、仅8.24 GB 内存下完成推理——无 BLAS、无框架、无 GPU。围绕这个引擎一个反直觉的设计决策是它拒绝量化 Trunk稠密主干实测数据显示 int8 量化损失约 1% 精度、int4 损失 17%而这份舍入误差无法用更多内存换回。git clone https://gitcode.com/gh_mirrors/ki/kimi-k3-in-c cd kimi-k3-in-c make -j make test # 无需下载模型一分钟验证引擎下面把这份拒绝量化的完整证据链拆开讲。先说结论误差不是免费午餐在模型部署领域量化是压缩内存的标准答案bf16 权重砍到 int8内存减半再砍到 int4内存减到四分之一。但 kimi-k3-in-c 的整套设计建立在一个关键对比上速度损失可以买回来用内存精度损失买不回来任何预算都不行。引擎的内存阶梯实测见 docs/PERFORMANCE.md显示同一个模型从 8 GB 内存32.69 s/token加到 224 GB19.21 s/token输出逐字节完全相同——28 倍的内存只改变时钟不改变答案。而量化是另一回事一旦权重被舍入误差就写死在模型里加多少内存、跑多快的机器都取不回原来的精度。这正是引擎宁可让 Trunk 保持 bf16 原样、走磁盘流式读取的原因。Trunk 是什么Kimi K3 的常驻部分要理解这个决策先看 1.56 TB 检查点里到底装了什么82,432 个路由专家896 个/层 × 92 个 MoE 层共1.447 TB占检查点的 93%。每个 token 每层只激活 16/896 个专家其余 96.3% 的参数睡在磁盘上按 4 位打包格式流式读取从不常驻内存剩下的7%才是常驻集108.81 GB 的稠密主干Trunk 4.70 GB 的嵌入表与输出头合计 113.49 GBbf16。Trunk 就是 93 个稠密层里的注意力投影、路由器、归一化等每个 token 都要跑的部分。量化 Trunk就是把这 108.81 GB 从 bf16 压成 int8 的 54 GB 或 int4 的 27 GB——听起来能省下一大截内存这正是引擎选择实测它、而不是直接拍脑袋拒绝的原因。实测方法真实权重不碰完整下载数据文件 docs/data/trunk-quantisation.txt 记录了测量过程相当克制通过 HTTP 范围读取从正式发布的检查点中抽样31 个注意力投影张量覆盖 KDA 层与 MLA 层每个取 384 行真实权重无需下载 1.56 TB每个张量分别往返转换 int8 与 int4量化方式为业界标准的对称缩放每 32 个元素共享 1 个 fp32 缩放因子记录平均相对重建误差。这种后训练量化PTQ的假设是模型训练时没见过 4 位/8 位舍入只能靠缩放因子硬凑。结果如何看表。核心数据int8 约 1%int4 约 17%差距恒定 18 倍31 个张量的实测均值层级类型张量数int8 平均相对误差int4 平均相对误差int4/int8KDA 层投影20.01046≈1%0.18746≈19%17.9×MLA 层投影180.009480.17154≈17%18.1×全部抽样张量310.00961≈1%0.17383≈17%18.1×两个关键观察int8 ≈ 1%误差可测但小。int4 ≈ 17%每 6 个权重里约有 1 个偏差达到自身量级的六分之一这已经不是精度略有下降而是权重本身被明显改写了。更糟的是长尾——int4 下最坏的单行相对误差达到45%、56% 和 65%最坏张量 L11.o_proj 达 24.6%。还有一个细节值得注意这个 18 倍差距在每一种层类型上都成立。KDA 层、MLA 层的注意力投影没有哪一类更能扛 4 位量化——不存在某个局部能单独降精度的侥幸空间。为什么引擎零量化四个理由1. 模型作者亲手画了这条线Kimi K3 技术报告docs/kimi-k3-tech-report.pdf明确写道专家是MXFP4 量化感知训练QAT而所有非专家组件保持高精度。非专家组件这份名单恰好就是 Trunk——它从设计上就没被量化过也从未被训练去容忍 4 位舍入。引擎的实测只是验证了这一点在真实权重上成立。2. 专家已经是 4 位但没有人为它挨过打引擎里其实只有两种权重类型enum { K3_WF32 0, K3_WBF16 1 };路由专家以 MXFP4 形式直接参与乘法——但那是训练时就按 4 位优化过的QAT 权重不是事后硬压的。引擎没有提供 int8/int4 位宽旋钮因为唯一安全的 4 位专家已经原生存在唯一不安全的 4 位Trunk被实测否决。3. 流式方案的代价是时间而时间可以被 RAM 赎回不量化 Trunk 的代价是每个 token 都要从磁盘重读 108.81 GB 主干慢。但慢是可赎回的——内存阶梯实测中给 Trunk 钉层越多每 token 读盘越少速度线性改善且任何预算下输出与 8 GB 时逐字节一致内存预算s/token每 token 读盘输出8 GB32.6925.83 GB17374, 20829, 10, 427, …32 GB31.4425.83 GB逐字节相同96 GB24.4018.11 GB逐字节相同224 GB19.2114.53 GB逐字节相同零重建误差的流式读取换来内存只是一个拨盘的自由——这也是整套架构的立身之本。量化则相反省下的是内存付出的是任何预算都赎不回的精度的永久损失。4. int8 唯一的合法位置只许提议不许出答案有意思的是int8 在项目中并非被全面封杀——它有一个严格受限的岗位草稿模型。引擎实现了 int8 派生的 draft trunktools/int8_trunk.py 生成 54.47 GB 容器比 bf16 主干小一半草稿只提议token最终的 bf16 精确模型负责验证输出 token 由精确模型说了算实测草稿 teacher-forcing 一致率 94.2%天花板 96.2%真实检查点上 66.7% 的草稿被接受输出与精确模型逐字节相同。也就是说int8 的 1% 误差被关在可丢弃的提议这个笼子里一旦越界直接由 bf16 模型驳回。这是量化误差与可丢弃计算共存的安全范式也反过来说明为什么主干本尊绝不能用 int8——那里没有验证者。完整实验记录见 docs/notes/int8-draft-container.md。诚实的边界这些数字不能过度解读研究者在数据文件里主动标注了局限写得很清楚测的是权重重建误差不是输出质量。17% 的权重误差不等于模型质量差 17%没有任何人应该这么读每个张量只抽样了384 行不是整张量只覆盖注意力投影不含 MoE、嵌入和 lm_head未做下游 logit/token 级对比int4 的真实质量代价是被界定而非被测量。补齐它的起点是 tools/ref_forward.py 的--int8模式。但即便是界定而非测量结论的方向也足够清楚在 1% 与 17% 之间且误差恒定跨 18 倍、长尾最高 65% 的情况下把从未为量化训练过的组件压到 int4 是不可辩护的。总结一份可以抄走的工程判断方案内存精度代价能否赎回Trunk 保持 bf16 流式高108.81 GB 走盘零—Trunk int8省约一半≈1% 权重误差❌ 任何预算下不可逆Trunk int4省到 1/4≈17% 权重误差长尾 65%❌ 任何预算下不可逆kimi-k3-in-c 用实测数据回答了一个很多项目凭信仰回答的问题量化前先测且用真实权重测——31 个张量、HTTP 范围读零下载成本区分可赎回的代价时间与不可赎回的代价精度前者用资源换后者碰都不碰量化误差不是不能存在而是要被关进笼子draft-only 模式 精确模型验证把诚实的局限写进数据文件让后来者知道边界在哪。 想自己复现或深挖入口在这里量化原始数据docs/data/trunk-quantisation.txt性能与内存阶梯docs/PERFORMANCE.md流式主干 I/O 实现src/io/k3_trunk.c全部数值内核含 MXFP4 乘法src/core/k3_ops.cint8 草稿容器设计docs/notes/int8-draft-container.mdTrunk 打包工具scripts/pack-trunk.sh【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考