人工智能大模型推理引擎本地部署【免费下载链接】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 是一个纯 C99 实现的 Kimi K3 推理引擎2.78 万亿参数、单 CPU、8.24 GB 内存即可运行无 BLAS、无框架、无 GPU 依赖。本文以仓库 CHANGELOG.md 为骨架逐条解读Unreleased、1.0.0、0.1.0三个版本块中每一项变更背后的动机与实现证据并结合 CLI 入口、流式主干读取器 与 跨平台 I/O 垫片 的源码说明这些命令行参数和内部机制是如何落地的。读完本文你可以准确使用--chat、--trunk-ring、--stop-id、--gen 0 --save-state等全部新特性理解主干层并行读取与前缀固定pin策略的取舍并掌握项目在 Linux/Darwin/Windows 三平台上的移植要点。Kimi K3 推理引擎的整体架构与内存层级概览图见 docs/images/big-picture.png版本规范与三个版本块CHANGELOG.md 开头声明了格式规范条目格式遵循Keep a ChangelogAdded/Changed/Fixed等小节版本号遵循Semantic VersioningSemVer。当前仓库处于三个版本块的叠加状态版本块日期定位[Unreleased]未发布--chatREPL、--trunk-ring、--stop-id、--gen 0prefill、Windows 支持、主干并行读取、最大优先 pin、输入健壮性修复[1.0.0]2026-08-07在完整发布 checkpoint 上端到端验证并大幅提速全程保持逐字节一致输出--preset auto、chunk-union prefill、会话续接、--spec投机解码、融合 matmul kernel[0.1.0]2026-07-31首次公开版本完整 93 层推理、主干流式、MXFP4 matmul、C 语言 BPE 分词器、记忆档位预设、无权重测试套件与 CI文档尾部保留了版本比较链接[Unreleased]指向 v1.0.0...HEAD 的 compare 视图等方便读者对照 diff 验证每条记录。Unreleased新增特性--chat终端 REPL 与官方 XTML 聊天格式这是 Unreleased 块最重量级的新增。CHANGELOG 原文指出没有聊天模板时引擎会把聊天形状的 prompt 当成文档中段来完成而不是在回答它complete a chat-shaped prompt as if it were mid document rather than answering it。--chat补齐了这一环实现 K3 官方XTML 聊天格式消息信封envelopes、thinking_effort系统前言以及对先前 assistant 回合中reasoning_content的渲染与 checkpoint 自带的编码器逐 token 一致提供JSONL 历史文件与单个 assistant 完成片段的解析器默认贪心解码--temperature、--top-p、--seed三者任传其一即开启采样--top-p默认 0.95--greedy可强制 argmax--no-think与--thinking-effort low|high|max跳过或调节 think 通道——对短回答而言think 通道往往是主要成本来源。源码印证src/cli/k3_run.c 的 usage 文本给出了完整的参数契约与默认值chat (text-only Kimi K3 XTML): --chat terminal REPL; uses the official XTML template --system TEXT initial system message (stored in --history) --history PATH portable JSONL transcript; rebuilt on restart --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 --greedy force argmax even when a sampling flag was given --no-think answer in the response channel directly: no think channel and no thinking-effort message (the encoders thinkingFalse) --thinking-effort E low, high or max (default max, as the checkpoints tokenizer sets)实现侧还有若干防御性约束从 src/cli/k3_run.c 的参数解析段可以确认--chat不允许与--ids、--prompt、--prompt-file同用也不允许与状态文件、投机/草稿模式、诊断项或--out同用k3_run.c--no-think与--thinking-effort互相矛盾时会直接报错退出而不是静默忽略其一k3_run.c——这正是编码器thinking 关闭时静默忽略 thinking_effort的行为在 CLI 层的显式化渲染出的会话转录超出引擎上下文上限K3_MAX_PROMPT时历史回滚、明确报错k3_run.cREPL 内支持/help、/reset、/exit三条命令k3_run.c。流式主干的三段式缓存工作流pin / 环形槽 / 未固定层图见 docs/images/cache-3phase.png--trunk-ring N可配置的预取队列深度CHANGELOG 记录流式主干的预取队列深度从固定 2 槽改为命令行参数默认仍为 2。usage 文本src/cli/k3_run.c解释了槽的语义--trunk-ring N streaming ring slots (default 2). One slot is the layer being computed on, the rest are reads in flight. A third slot lets the reader run a layer further ahead and costs one more slot of RAM; the budget still wins if it does not fit即一个槽放正在计算的层其余槽是在途读取。第三个槽让读取线程能再领先一层代价是一个槽的 RAM若内存预算装不下预算优先RING会在预算内自动降回 1。src/io/k3_trunk.c 中的降档逻辑与 CHANGELOG 描述一致while (RING 1 RING * rs budget_bytes) RING--;。--stop-id N按 token id 停机--stop-id可重复最多 8 个让生成在模型吐出指定 token id 时立即停止默认关闭——这样--gen N仍然严格意味着恰好 N 个 token所有基准测试与 oracle 门禁依赖这一点。CHANGELOG 列出的关键语义停机 id 保留在序列中因此--save-state之后的--load-state会从模型真实产出的内容继续检查发生在出字emit时刻因此--spec投机解码扫描也在同一位置截断行为与串行解码完全一致解析结果写入k3_run.json的新字段stopped_at命中的 id未命中为 -1解析用strtol拒绝非整数、负数和超出词表范围的 id——模型永远不可能吐出的停机 id与模型从未吐出任何 id 在效果上不可区分所以宁可在入口处拒绝。源码印证src/cli/k3_run.c发射循环内逐个emit[i]与 8 个stop_id比对命中即记录stopped_at并截断解析侧k3_run.c对超过 8 个的--stop-id直接报错。一个实战细节写在 usage 里src/cli/k3_run.c发布 checkpoint声明了两个互相矛盾的结束 id——config.json说是 163586|end_of_msg|tokenizer_config.json说是 163585[EOS]而模型实际吐出的是 163585。所以要停到自然结束应当两个都传k3 model_dir --tok tok_dir --ids 1,2,3 --gen 64 \ --stop-id 163586 --stop-id 163585--gen 0prefill预热共享前缀--gen 0 --incremental --save-state现在会执行 prompt 的 prefill并以零生成 token保存精确的 KV 与循环状态。用途共享前缀系统 prompt、长文档只需预热一次之后可被多次--load-state恢复。此前--gen 0直接跳过解码循环什么有用的都没存。这个修复与k3_run.json的另一个 bug 联动见下文 Fixed 小节以前 harness 驱动的--gen 0 --save-state恰好需要解析那次运行的 JSON结果拿到的是非法 JSON。Windows 支持MSYS2 MinGW-w64 原生构建CHANGELOG 明确构建通过 MSYS2 的 MinGW-w64 GCC 原生完成不需要 WSLmake、make test、make test-all全部门禁不改动通过包括对真实 Kimi K3 权重的完整模型 oracle 与分词器一致性45/45。移植清单与 src/io/k3_portable_io.h 头注释逐条对应POSIX 能力Windows 实现关键约束O_DIRECTFILE_FLAG_NO_BUFFERING与 Linux 一样只能在打开时设置与 Darwin 相反Darwin 的F_NOCACHE事后可加因此必须在open()层拦截并转CreateFile标志k3_portable_io.hpreadReadFile的OVERLAPPED偏移字段刻意不用SetFilePointerEx ReadFile那会跨线程共享可变文件指针而主干读取线程与 expert-cache 预取线程会并发pread()同一 fdposix_memalign_aligned_malloc注意参数顺序相反且释放必须用_aligned_free见 Fixed 小节的堆损坏getrusage/MemAvailableGetProcessMemoryInfo/GlobalMemoryStatusEx供k3-doctor.sh类诊断使用getlinechat REPL 依赖小型fgetc实现保持同一契约realloc 增长、保留分隔符、EOF 返回 -1rename原子替换MoveFileExMOVEFILE_REPLACE_EXISTINGCRT 的rename不覆盖已存在目标第一次之后的历史保存全部会失败另外Makefile 中make asan/make ubsan在 Windows 上切换到 ClangMinGW-w64 的 GCC 包完全没有sanitizer 运行时——CHANGELOG 特别强调这一点是直接确认过而不是想当然-lasan/-lubsan链接失败/mingw64下不存在对应文件而mingw-w64-clang-x86_64的 clang 包可用。这与 Makefile 中SANITIZER_CC ? clang的注释一致约 L92-L97。Unreleased行为变更主干层改为并行分块读取CHANGELOG 说明load_run()此前用单个顺序pread循环逐字节流式读取每一层设备看到的队列深度是 1。现在每层被切成64 MiB 块K3_TRUNK_CHUNK是K3_TRUNK_ALIGN4096src/io/k3_trunk.h的整数倍保证每个块的偏移与长度都满足O_DIRECT/F_NOCACHE的对齐要求块在OpenMPparallel for下并发发出与 expert 路径已有的做法对齐无 OpenMP 时退化为逐块串行功能不变任一块短读short read仍使整层失败解码输出与trunk_bytes_read统计保持不变。源码印证src/io/k3_trunk.c#define K3_TRUNK_CHUNK ((int64_t)64 20) /* per-request read size */ ... # pragma omp parallel for schedule(dynamic, 1) for (int ci 0; ci nchunk; ci) { if (failed) continue; const int64_t base (int64_t)ci * K3_TRUNK_CHUNK; ... ssize_t r pread(tr-fd, dst base got, (size_t)want, ...);文件头注释k3_trunk.c还给出了动机数据队列深度 1 在 NVMe 上只能达到额定速率的一半——实测 3.1 GB/s而已经并行的 expert 路径可达 6.7 GB/s。分块计时与字节数通过出参回传、在 io 互斥锁内归并避免多线程共享 double 的数据竞争。主干层改为最大优先固定pin前缀固定prefix pinning总是先固定 2.34 GB 的稠密层第 0 层模型中唯一带 33792 宽 MLP 的稠密层。问题在于流式环形槽是统一的必须能装下仍在流式传输的最大层——于是只要有任何层被固定环形槽就一直按那个早已不用槽的 2.34 GB 层来定尺寸在高于地板预算的每一档都白白多付约 1.17 GB 内存。新策略src/io/k3_trunk.c按大小降序做贪心选择某个大层装不下时继续尝试更小的层把预算填满而不是遇到第一个装不下就停前缀模式则必须停因为跳过会留下空洞环形尺寸与 pin 集合互相依赖更小的槽释放预算 → 多 pin 一层 → 槽可以更小因此整体会迭代到不动点至多 8 轮且选择对预算单调保证收敛不震荡平局按层索引升序打破保证两次运行固定同一组层K3_PIN_PREFIX1可在同一二进制上恢复旧顺序做 A/B 对比k3_trunk.c。对读量而言两种顺序中性任何合计 B 字节的 pin 集合每 token 恰好省 B 字节决定性差异在环形槽尺寸上——丢掉最大的幸存者才是缩小槽的关键。Unreleased缺陷修复恶意或损坏输入可触发未定义行为UBCHANGELOG 列出的四类 UB 全部改为显式拒绝形状/偏移算术整数溢出靠近INT64_MAX的恶意 shape 或data_offsets对会回绕绕过本应拦截它的边界检查空主干层数组越界读批式 MoE prefill 路径在 expert 加载失败时求和未初始化内存逐 token 路径早已按贡献零处理JSON 解析器与 shard 目录列举中的无检查分配可能穿透空指针崩溃而非干净失败。验证手段是新增的无权重测试test_st_faultstests/unit/test_st_faults.c它构造 fixture shard 的变异副本断言每种失败模式都被大声拒绝已合法输入的行为不变。测试夹具位于 tests/fixtures/ 目录safetensors 分片、expert_trace.bin等。CLI 解析与输出修复逐条--ids非数字片段静默变成 token id 0strtol失败与真正的 id 0 不检查解析停在哪就无法区分现在拒绝--layers 0或超过真实层数此前静默跑完整模型如同没传该参数现在按几乎必然是笔误处理而拒绝不可写的--out路径仍以 0 退出与结果确实已保存不可区分现在以退出码 3 结束k3_run.json在零生成时非法nout 0时seconds_per_token计算t_total / nout输出裸inf导致驱动--gen 0 --save-state的 harness 恰好在那次必须解析的运行上失败现在报告0Windows 堆损坏STATUS_HEAP_CORRUPTION_aligned_malloc支撑的posix_memalign垫片必须用_aligned_free释放而不是free。POSIX 的posix_memalign没有这个限制所以编译完全干净直到损坏的分配器元数据真正被使用才崩溃远晚于分配点。三处调用点需要修k3_cache.c的缓存 arena、k3_trunk.c的主干 arena 与每层 pin 缓冲。垫片侧的解决方案在 src/io/k3_portable_io.h定义k3_aligned_free()Windows 上映射到_aligned_freeLinux/Darwin 上映射到freeMakefile 中SHARD_DIR/TOK_FILES未加引号含空格的路径Windows 上很常见例如 AI LOCAL MODELS 文件夹会静默裂成多余 argv而test_expert/test_real_layer/test_tok/test_cfg读到的是恰好能解析成路径的那个截断 token而不是直接拒绝。1.0.02026-08-07端到端验证与提速版本摘要一句话在完整发布 checkpoint 上端到端验证、大幅提速且每一步保持逐字节一致输出干净克隆上的首次运行体验此前是坏的被修复。Added--preset auto从机器自身空闲 RAM 计算主干与 expert-cache 预算主干优先——给主干的一 GB 远贵于给 expert cache 的一 GB自动分配据此倾向主干并在一次重 pin 回归被实测后把 pin 上限压在 RAM 天花板之下。usage 中的完整预设列表为auto | ultra | laptop | desktop | workstation | server | maxsrc/cli/k3_run.c另有--list-presets查看各预设的切分与预期速度chunk-union prefill批式 prefill 的 MoE 每 chunk 只为每个被路由到的唯一 expert 抓取一次而非每 token 一次实测 prompt 上 expert 读取字节约减半生成 token 与逐 token 路径位级一致会话续接--save-state/--load-state把循环状态与 KV 缓存落盘第二回合不再重读整个 prompt实测 3.9 倍提速且输出一致从不同架构恢复状态会被拒绝--spec Nn-gram 草稿 批式贪心验证的投机解码输出按构造就是串行贪心解码。usage 补充了成本模型src/cli/k3_run.c主干流式时每个额外被验证的位置约耗一个串行 token 的 22%重复文本因此可快数倍--tf-check对一段 id 序列做单遍 teacher-forced 比对用于测量草稿质量配套 tools/qdq_trunk.py 与 tools/int8_trunk.py 用于推导量化主干。Changed融合 matmul kernelfp32、bf16、MXFP416 个分区累加器 显式融合乘积把主干 matmul 推到内存下限每 token 计算量约减 8 倍同时保持标量与 AVX2 路径位级一致KDA 递推按 head 并行与串行形式位级一致scripts/k3-doctor.sh 的每预设速度期望刷新到 v1.0.0 数字并注明流式档为磁盘受限disk-bound、常驻档为计算受限compute-bound。Fixed所有 shell 脚本以可执行位提交干净克隆上首条文档命令不再Permission deniedscripts/download-model.sh 改用当前hfCLIpin 不可变 revision 并做校验和验证不再尝试目标 OS 上不可能成功的 pip install空闲空间不够装 checkpoint 时拒绝启动——因为部分下载会静默产生错误输出scripts/k3-doctor.sh不再把能构建能测试的机器判死内存地板降为运行 checkpoint 的警告而非硬停文档描述的配置拒绝 fixture 现在真实存在并被make test、ctest 与 CI 门禁见 tests/fixtures/cfg/ 下的bad_layer_index.json、bad_topk.json、no_layermap.json分词器腿报告 NOT RUN 而非静默通过CI 跑完整make test而非手挑子集MLA KV 溢出与单槽主干读取器各有一条静默损坏路径可能吐出貌似合理的错误 token现在要么中止要么被预防MXFP4 打包对齐与 tiny-checkpoint 缩放规则。研究笔记未作为特性发布无损主干压缩与量化自草稿混合方案都被造出并测量结论是只惠及很窄的区间。发现与原型保留在 docs/notes/ 目录。0.1.02026-07-31首次公开版本Added完整继承 CHANGELOG完整 93 层 Kimi K3 推理69 层 KDA 24 层 Gated MLA896 个路由 expert、top-16 选择SiTU-GLU、Attention Residuals、原生 MXFP4 expert 权重主干流式Trunk streaming把内存预算从地板变成旋钮——模型在 8 GB 与 224 GB 下都能跑且所有实测中间预算下输出逐字节一致直接消费打包 nibble 的 MXFP4 matmul从不物化反量化后的 expertC 语言 BPE 分词器直接读取发布的tiktoken.model文本进文本出、无外部步骤配置读取器加载 checkpoint 自带的config.json拒绝无法完全理解的配置而不是给缺失字段填默认值带 KV 缓存与携带循环状态的增量解码已验证与全量重算产出相同 token命名内存预设--preset laptop|desktop|workstation|server|max源自实测内存阶梯scripts/k3-doctor.sh报告机器能否跑该模型、哪个预设装得下、存储多快scripts/download-model.sh拉取 checkpoint 并按发布总量逐字节校验完全不需要模型权重即可运行的测试套件op fixtures、expert cache、safetensors 读取器、配置读取器以及端到端 oracle 门禁teacher forcing、贪心解码、增量解码——对应 tests/unit/ 下的test_ops.c、test_expert.c、test_st.c、test_cfg.c等CIGCC 与 Clang 构建矩阵、warnings-as-errors、ASan/UBSan、Python 与 shell lint。分词器一致性被构建并报告但不能在干净 checkout 上门禁因为它需要随模型权重一起发布的词表需对下载好的 checkpoint 本地运行make tok。已知限制没有分块 prefillchunked prefill因此尽管有 32k 上下文上限长 prompt 仍不实用chunk-union prefill 在 1.0.0 补上了批式 MoE 侧的一半仅贪心解码无聊天模板--chat在未发布版补齐无服务层无视觉仅 CPU。后续路线见 docs/ROADMAP.md。与仓库其余部分的对照导航结合 CHANGELOG 提到的门禁与工具以下路径可直接深入关注点路径CLI 全参数与默认值src/cli/k3_run.cusage 文本约 L341-L419XTML 聊天渲染 / 历史 / 采样src/chat/k3_chat.c、src/chat/k3_sampler.c主干流式pin 选择、环形槽、分块并行读src/io/k3_trunk.c、src/io/k3_trunk.h三平台 I/O 垫片src/io/k3_portable_io.hexpert cache arenasrc/cache/k3_cache.c无权重测试与变异故障测试tests/unit/test_st_faults.c、tests/fixtures/内存档位与速度预期scripts/k3-doctor.sh、docs/data/memory-ladder.tsv量化主干推导工具tools/qdq_trunk.py、tools/int8_trunk.py构建入口为 Makefilemake、make test、make test-all、make asan/make ubsanApple Clang 无 OpenMP 运行时需 Homebrew libompWindows 走 MinGW-w64 GCCsanitizer 走 ClangCMake 侧见 CMakeLists.txt。适用前提提醒--tok因而也是--chat与make tok需要模型 checkpoint 目录中的tiktoken.model与tokenizer_config.json--trunk需要先用 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点击查看免费下载相关推荐CodeGraph 变更日志精读预索引代码知识图谱从 0.7.6 到 1.6.0 的完整演进CodeGraph 变更日志精读预索引代码知识图谱从 0.7.6 到 1.6.0 的完整演进 本文以 CodeGraph 仓库的 CHANGELOG.md h开发工具MCP 服务静态分析知识图谱代码智能体Linaria 官网子包演进史从版本变更日志解读 wyw-in-js 迁移与工程化改造Linaria 官网子包演进史从版本变更日志解读 wyw in js 迁移与工程化改造 本文以 Linaria 仓库中 website/CHANGELOG.m前端构建工具UI组件typescript-eslint 官方变更日志CHANGELOG解读从 8.70.0 到 v1.0.0 的完整演进路线typescript eslint 官方变更日志CHANGELOG解读从 8.70.0 到 v1.0.0 的完整演进路线 本文是一篇以 typescrip网络安全应用安全CLI漏洞扫描上一篇华为运动数据跨平台转换终极指南免费TCX格式转换器完整教程下一篇Midscene.js终极指南如何用AI视觉驱动实现零代码跨平台自动化测试创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考