8GB 内存也能跑 Kimi K3？2026 本地部署大模型配置全指南

一块 8.24GB 内存的 CPU，一个 2.78 万亿参数的大模型，甚至不需要显卡，Kimi K3 就这么水灵灵地跑起来了。 而满血版的 DeepSeek V4 Flash，也只需要用一台老黄的 DGX Spark，或者配备 128GB 运行内存的 Mac 电脑就可以运行。 从 2025 年初横空出世的 DeepSeek R1 掀起了一大波本地部署的潮流，各种密集的攻略教大家如何避开 DeepSeek 的「服务器繁忙，请稍后再试」，用手边的电脑，就能自己搭建一个不受限制的 DeepSeek R1。 到了今年，大模型的参数几乎都从千亿到了万亿， 671B 的 R1 对比现在 2.78T 的 Kimi K3 和 2.4 T 的 Qwen3.8-Max，看起来是格格不入。 快速问答版本的 DeepSeek V4 Flash 维持在 284B，但 V4 Pro 预览版的总参数也达到了 1.6T。 硬件上的变化同样如此，内存大涨价和本地 Agent 工具爆发的背景下，让 Mac Mini 等产品直接断货，苹果上调 Mac 等产品线起售价。黄仁勋去年年底推出的 DGX Spark，都从建议零售价 3999 美元涨到了 4699 美元起。 AI 一天，人间一年。当时的本地部署教程放到眼下的万亿参数大模型上，都有了新的变化。 如何在 2026 年部署一个本地大模型？需要什么配置？什么样的工作流适合自己部署一个大模型？部署哪个大模型？我们用这篇文章给大家讲清楚。 太长不看总结版 8GB 能跑 Kimi K3，但要 1.7TB 固态，一个 Token 等半分钟。 本地部署先看显存容量，再看内存带宽。 8GB 显存适合 4B—7B；16GB 可跑 9B—14B；24GB 进入 24B—27B；120B 模型通常需要 80GB 以上显存或大容量统一内存。 DeepSeek V4 Flash 正把前沿模型带上个人桌面。 Kimi K3 是怎么跑起来的 输入「The capital of France is」，程序输出「Paris」。 这个名为 kimi-k3-in-c 的 GitHub 项目，用不到 200KB 的 C 语言代码，完成了 Kimi K3 的 CPU 推理。没有 PyTorch，没有 CUDA，整个程序只依赖编译器、OpenMP 和系统数学库。 但 2.78 万亿参数并没有被塞进这 8GB 内存里。完整权重仍然占据约 1.56TB 硬盘空间，项目真正压缩的，是模型在任意时刻必须停留在内存中的部分。 简单来说，就是开发者将模型的其他的权重全放到一块固态硬盘上。根据 Kimi K3 官方模型卡，模型共有 2.8 万亿参数，但每处理一个 Token，只会激活其中约 1040 亿参数，占总量的 3.7%。 Kimi K3 一共有 93 层，其中 92 层使用 MoE。每一层都准备了 896 个不同的专家，路由器会根据当前 Token 的内容，从中选出 16 个参与计算。 剩下的 880 个专家，当前这一轮完全用不上。 既然每层只用 16 个专家，程序只需要根据路由结果，从硬盘读取这 16 个专家。但把路由专家留在硬盘后，模型还有 113.49GB 无法绕开的稠密权重。 这里包括注意力层、路由器、归一化、共享专家、Embedding 和输出层。它们几乎每生成一个 Token 都要参与计算，普通的 MoE 卸载方案通常会把这一部分完整放进内存。 kimi-k3-in-c 又做了一次流式处理，原始 Kimi K3 权重被分成 96 个模型权重文件，同一层里的权重散落在体积巨大的分片中。项目先运行一个打包脚本，把 93 层的稠密权重重新整理成一个约 109GB 的连续文件，每一层都对应一个固定的磁盘位置。 开始推理后，程序会根据内存预算，尽可能固定一部分层。放不下的部分，则通过一个循环缓冲区逐层读取：当前层进来、完成计算、腾出缓冲区，下一层继续覆盖。 最终，整个内存缩减过程变成了四个数字： 5.56TB：所有参数采用 BF16 时的理论体积； 1.56TB：官方发布的 MXFP4 权重； 113.49GB：专家权重留在磁盘后，需要持续参与计算的部分； 8.24GB：连稠密主干也改成逐层读取后，实际测得的峰值内存。 Kimi K3 的 69 个 KDA 层也帮了很大忙。KDA 不需要为每个历史 Token 保存一份完整 KV Cache，只维护固定大小的递归状态；另外 24 个 MLA 层则通过低维表示压缩注意力缓存。 ▲ Kimi K3 框架，KDA 是 Kimi Delta Attention，一种注意力机制 配合增量解码，第一轮先处理完整 Prompt，之后每一轮只需要处理刚刚生成的新 Token。内存不会随着生成长度迅速失控，程序才有机会把更多空间留给权重调度。 8 GB 的代价，是每个 Token 等半分钟 8 个 Token 总共花了 261.5 秒，内存占用降到了 8.24GB，真正的成本转移到了硬盘和时间上。 在最低内存配置下，Kimi K3 每生成一个 Token，需要读取约 25.83GB 专家权重。由于没有空间固定稠密层，约 108.81GB 的主干权重也会被重新扫描一遍。 这意味着一个 Token 背后，可能对应超过 130GB 的磁盘数据搬运。 作者测得，8GB 档位平均需要 32.69 秒才能生成一个 Token，速度约为 0.03 Token/s。「The capital of France is」后面的 8 个 Token，总共等了四分多钟。 在另一组统一条件的内存阶梯测试中，从 8GB 一路增加到 224GB，内存扩大了 28 倍，速度只提高约 1.7 倍。整个运行过程中，约四成到六成时间都花在等待硬盘。 所以这套方案的关键硬件已经从 GPU 转向 NVMe。普通机械硬盘很难承担这样的随机读取，网络存储也会明显拖慢速度。项目要求至少准备约 1.7TB 空间，用来放置 1.56TB 原始权重和重新整理后的 109GB 主干文件。 如果硬盘每秒只能稳定读取 1GB，生成一个 Token 光搬运数据就可能超过两分钟。 整个项目最抓眼球的描述，也就是首页写着的「One CPU，8GB RAM」。但继续查看测试环境，会发现这句话还需要补充一些条件。 作者的全部数据都来自一台双路 AMD EPYC 7763 工作站，共有 124 个 CPU 核心、228GB 内存和 3.2TB NVMe 固态硬盘。机器上还装了四张 NVIDIA L40，不过整个测试过程没有使用 GPU。 所谓 8GB，是作者通过 Linux cgroup（一种 Linux 的资源管理机制）将进程限制在 8GB 内存，然后测得 8.24GB 的峰值 RSS（Resident Set Size 的缩写，指进程实际占用的物理内存大小）。 它证明了推理引擎可以在这一内存预算下完成计算，但并没有在一台普通的 8GB 笔记本上进行实测。 或许项目中的「One CPU」更适合理解为 CPU-only。124 个服务器核心与普通笔记本处理器之间，仍然隔着巨大的计算能力差距。 虽然整个实验看到这感觉就是个噱头，因为它根本无法让一台旧笔记本直接获得完整的 Kimi K3，也很难替代现有 API 服务；但也有网友说，从工程验证的角度看，这个项目做得相当认真。 而且它还证明了一件事：模型的总参数量，已经无法直接等同于部署时的内存门槛。 那 8GB 内存的电脑就可以做什么 要选择合适的硬件，必须先搞懂本地部署的两大核心瓶颈：显存容量和内存带宽。 对显存来说，模型运行需要的显存不仅包含模型权重本身，还必须预留 KV Cache（上下文缓存） 和激活值空间：模型权重（GB）≈ 参数量（B）× 量化位数 ÷ 8 × 1.15，接着模型运行时还要加上 KV Cache，因此总内存需求 ≈ 模型权重 + KV Cache + 1～3GB 运行缓冲。 举个例子，FP16（半精度无损）：1B 参数需要约 2GB 显存。 INT8（8-bit 量化）：1B 参数需要约 1GB 显存。INT4/Q4_K_M（4-bit 常用量化）：1B 参数需要约 0.5～0.6GB 显存（最主流的选择）。 像 DeepSeek V4 / Kimi 这类 MoE（混合专家）架构模型，虽然每次 Token 推理只激活部分专家参数，但全部专家权重都必须先完整加载到内存/显存中。 按照 Q4 量化，8K—16K 上下文估算，可用的显存和对应的模型规模对应大概如下。 具体到显卡的选择上，RTX 5060 Ti 16GB 市价约为 5100—5300 元，适合 9B—14B 模型；二手 RTX 3090 24GB 约为 5000—8000 元，可以进入 24B—27B，但要承担 350W 功耗、矿卡历史和显存维修风险。 如果模型完整放进显卡，6—8 个现代 CPU 核心通常够用。8GB—16GB 显卡建议搭配 32GB 系统内存，24GB—32GB 显卡搭配 64GB；想通过混合卸载运行 70B，则要准备 128GB 内存。 关于硬件主要还是显卡，内存、CPU、硬盘都是够用就行，但硬盘最好从 1TB 固态起步，长期使用更推荐 2TB。 没有独立显卡，也可以考虑 Mac Studio、Ryzen AI Max+ 395 和 DGX Spark 这类大容量统一内存设备。96GB—128GB 内存可以装下 70B、109B 甚至部分 120B Q4 模型，代价是更高的整机价格和有限的升级空间。 如果直接要