Kimi K3‑in‑C：2.78万亿参数大模型，仅8GB内存就能在CPU上跑

一、大模型部署的固有逻辑被打破

很多人一直有一个固化认知：参数量越大的大模型，就必须要更大显存、更高配置硬件才能运行。想要跑通万亿参数级模型，就得组建 GPU 集群，普通笔记本、消费级 CPU 根本没有机会接触前沿大模型。

这个开源项目kimi‑k3‑in‑C直接推翻这套固有逻辑。完整 Kimi K3 模型磁盘权重文件达到 1.56TB，总参数量 2.78 万亿，原生支持接近 100 万 token 上下文窗口，属于当前第一梯队 MoE 稀疏大模型。但这套 C 语言编写的推理引擎，在普通 CPU 环境下，峰值内存占用仅仅 8.24GB。

项目采用可移植 C99 标准开发，编译之后程序本体大小仅 176KB，核心思路不再要求把全部模型权重加载进内存，而是直接从硬盘流式读取模型数据。

项目现状：完全开源免费开放，项目发布之后受到技术圈广泛关注。

这一突破价值非常直观：过去普通开发者想调试万亿参数大模型，硬件门槛直接把绝大多数人挡在门外。现在普通消费级硬件就可以完成架构验证、路由逻辑调试、正确性测试。但我们也要理性看待，它不等于可以直接拿来做流畅对话，实际生成速度依旧存在短板。

这就引出一个值得所有人思考的问题：评判大模型部署能力，到底要看磁盘总参数量，还是实际运行时的内存工作集？

过去行业几乎全部盯着显存总量做文章，拼命量化压缩权重、多卡分片部署。而这个项目告诉我们，对于 MoE 稀疏模型，磁盘模型大小和运行实际占用内存，完全可以相差上千倍。

二、核心拆解：技术原理与实操部署步骤 2.1 Kimi K3 模型基础架构

Kimi K3 属于原生支持智能 Agent 能力的多模态 MoE 混合专家模型。

• 总参数：2.78T
• 每个 token 实际激活参数：104B
• 网络层数：93 层，其中 69 层 KDA 层，24 层门控 MLA 层
• 每一层 MoE 专家池 896 个专家，每一次运算只选中 16 个专家，附带 2 个共享专家
• 隐藏维度 7168，原生上下文窗口 1048576 token
• 专家权重原生 MXFP4 格式存储

稠密大模型每一轮运算，需要加载全部权重矩阵。但是稀疏 MoE 模型只需要可以访问全部专家，仅读取被路由选中的一小部分专家权重。 “可访问” 和 “常驻内存”，就是整套方案最核心的突破口。

推理引擎把 1.56TB 模型文件划分成三类：

1. 路由专家库约 1.45TB：存放在 NVMe 硬盘，按需读取，不用常驻内存
2. 稠密主干网络约 108.8GB：根据机器内存大小，尽可能多驻留，剩余部分流式读取
3. 极小常驻状态：词嵌入、循环状态、临时计算空间

内存不再是 “能跑或者不能跑” 的硬性门槛，而是一个可调旋钮。内存越大，驻留的主干网络越多，重复读取硬盘的数据越少，推理延迟越低；内存越小，硬盘读取次数增加，生成速度变慢，但是模型输出结果不会发生改变。

这套推理引擎运行逻辑，和数据库系统高度相似：

• 路由模块等价查询规划器
• 系统内存等价缓冲池
• NVMe 固态硬盘等价底层存储
• 预加载机制等价预测 IO
• 模型架构直接决定缓存命中效率

项目也实测发现：传统 LRU 缓存对于这套模型收益很低。K3 使用分位数均衡算法，专家调用分布十分平均，不存在高频热点专家。把有限内存分配给稠密主干网络，远比拿来做专家缓存效果更好。同时引擎直接读取 MXFP4 压缩权重做矩阵运算，不在内存中解压放大，避免带来巨大带宽开销。

在注意力机制层面，KDA 层采用循环状态，状态大小不会跟随上下文长度膨胀，解决长会话 Agent 越跑越吃内存的痛点。当前限制是提示词上限 32768 token，分块预填充功能还在开发计划中。

2.2 实操部署流程

运行前提：仅支持 Linux x86‑64 平台，CPU 必须支持 AVX2、FMA 指令集，GCC9 以上或者 Clang10 以上编译器

优先测试引擎正确性，不需要下载 1.56TB 完整权重文件，项目自带小型测试张量图，可以验证内核、路由、解码逻辑正确性。

git clone kimi-k3-in-ccd kimi-k3-in-cmake -jmake test

测试全部通过之后，可以查看内置硬件预设方案，不同预设对应不同内存分配策略

./bin/k3 --list-presets

预设

主干内存

专家缓存

峰值内存占用

laptop 笔记本

3GB

1GB

约 8.2GB

desktop 台式机

16GB

10GB

约 31.9GB

workstation 工作站

60GB

30GB

约 95.5GB

server 服务器

110GB

13GB

约 128GB

执行环境检测脚本，工具会自动评估硬件给出推荐预设

./scripts/k3-doctor.sh

设置 HuggingFace 读取令牌，下载模型、打包主干网络，打包操作把网络层整理成固定偏移，实现单次 IO 读取完整网络层。

export HF_TOKEN=你的读取令牌./scripts/download-model.sh ~/k3model./scripts/pack-trunk.sh ~/k3model ~/k3trunk

启动模型推理，务必带上--incremental开启增量解码，复用循环状态，否则每生成一个 token 就要重新计算全部前缀内容，速度会急剧恶化。

./bin/k3 ~/k3model \  --trunk ~/k3trunk \  --preset laptop \  --tok ~/k3model \  --prompt "The capital of France is" \  --gen 8 \  --incremental

做回归测试，直接输入 token ID，剥离分词器带来变量，方便对比不同版本内核输出差异，输出结构化 JSON 日志。

./bin/k3 ~/k3model \  --trunk ~/k3trunk \  --preset desktop \  --ids 1008,10484,318,15383,387 \  --gen 8 \  --incremental \  --out run.json

对外接口非常简洁，核心就两个头文件k3.h、k3_cfg.h，权重加载、内存分配全部对外显式可控，没有黑盒抽象封装。

项目当前短板：只支持贪婪解码，没有对话模板，多模态视觉链路尚未实现，不支持 HTTP 接口，不支持多并发推理。

这套开源方案的价值毋庸置疑，它撕开大模型部署全新思路，证明稀疏模型可以把运行工作集压到极低水平，普通硬件也可以开展前沿模型研究。但我们不能把它神话，它有无法回避的现实约束。

首先是推理速度。笔记本预设配置下测试，每生成一个 token 耗时大约 26.5 秒；即便内存充足把稠密主干网络全部驻留内存，单 token 也要 5.6 秒。这个速度完全达不到日常交互使用标准。Agent 智能体执行一次任务会生成数百 token，还要调用工具，整套流程跑完成会耗费大量时间。

硬盘性能直接决定体验。整套引擎重度依赖 NVMe 随机读取，普通 SATA 固态硬盘、网络存储会进一步拖慢生成速度。这套方案本质就是用硬盘 IO 换取内存资源。

这里就产生一个辩证思考：我们实现小内存跑万亿大模型，到底解决的是什么问题？它并不能拿来替代云端 Agent 服务，它真正的定位偏向科研、架构验证、正确性比对。

很多开源推理框架为了速度，悄悄改动计算逻辑，微小 logit 输出偏差，在普通对话感知不强。但是对于 Agent 应用，一点点输出偏移，就会造成工具调用出错，后续全部上下文、决策链路全部跑偏。这个项目把正确性放在性能前面，提供逐层比对校验工具，这才是它很大的价值。

这里留给大家思考：未来本地 AI 的取舍，我们愿意牺牲多少速度，换取更低的硬件门槛？当内存不够的时候，用硬盘换算力，到底是不是一条可以走向产品化的路线？

四、现实意义：给 Agent 与本地大模型行业带来哪些改变

这项技术突破，并不是拿来直接做家用聊天机器人，而是给整个行业带来五个重要启发，实实在在改变开发者做技术选型思路。

第一，稀疏大模型诞生全新部署范式。模型总大小不再是部署的硬门槛，权重 “可以被访问” 比权重 “常驻显存内存” 更加重要。对于离线、私有化 Agent 场景，这个思路未来会越来越关键。

第二，区分清楚技术适用边界。硬盘流式推理适合架构研究、小规模批量任务、模型正确性校验，不适合高并发实时交互产品。不能脱离场景盲目吹捧技术。

第三，改变大模型观测指标。对于 MoE 混合专家模型，总参数量参考价值越来越低。开发者需要重点观测：单 token 激活参数、每 token 硬盘读取字节数、专家复用率、KV 缓存膨胀、预填充和解码开销这些真实运行指标。

第四，Agent 系统必须设置正确性校验闸门。所有推理引擎切换、量化方案、缓存策略更新，第一件事情做输出一致性校验，再去调优性能。Agent 链式调用会放大每一处微小计算错误。

第五，大模型服务重新回归系统工程。想要做好稀疏模型推理，不再只懂深度学习就足够，内存分级、文件布局、IO 预取、缓存策略、量化内核、循环状态管理，需要数据库、操作系统、编译领域知识交叉。AI 应用开发团队，需要补齐系统方向人才储备。

未来硬件架构会走向多层存储组合：高速 HBM 显存、系统内存、本地高速 NVMe 硬盘、远端对象存储协同工作，运行时自动判断权重存放位置，按需搬运数据。数据库几十年沉淀的分层存储思路，正在大规模迁移到大模型推理领域。

五、互动话题

过去两年，本地大模型圈子，大家拼的都是 “多少显存可以跑多大模型”，kimi‑k3‑in‑C 把这套游戏规则改写。

1、你觉得未来两三年，硬盘流式加载稀疏 MoE 模型，有没有机会走进普通用户的电脑？ 2、如果牺牲部分速度，就能在普通电脑运行万亿参数 Agent 模型，你愿意接受这种取舍吗？ 3、比起模型总参数量，你平时做本地大模型，会更关心哪些真实运行指标？

欢迎在评论区聊聊你的看法。