Kimi K3 在 8GB 内存上跑通，2026 本地部署大模型要考虑什么

事件概述

一个名为 kimi-k3-in-c 的 GitHub 项目，用不到 200KB 的 C 语言代码，在仅约 8.24GB 峰值内存的情况下完成了 Kimi K3 的 CPU 推理。项目不依赖 PyTorch、CUDA，仅使用编译器、OpenMP 和系统数学库，过程完全在 CPU 上完成。

但这一结果并非“把 2.78 万亿参数塞进 8GB 内存”。Kimi K3 完整权重约 1.56TB，仍存放在硬盘上；项目做的是将模型运行时不需要的专家权重留在磁盘，并将必须参与计算的稠密权重改为逐层流式读取，从而把内存占用压到 8GB 级别。

关键事实

• Kimi K3 总参数 2.78 万亿，每处理一个 Token 只激活约 1040 亿参数，约占总量的 3.7%。
• 模型共 93 层，其中 92 层为 MoE 结构，每层有 896 个专家，路由器只选择其中 16 个参与计算。
• 专家权重留在磁盘后，仍约有 113.49GB 稠密权重需要持续参与计算。项目通过打包脚本将其整理成约 109GB 的连续文件，再按层循环读取。
• 实际测试峰值内存为 8.24GB，对应全部参数 BF16 理论体积 5.56TB、官方 MXFP4 权重 1.56TB、稠密主干 113.49GB 的逐步压缩过程。
• 8GB 档位下平均生成一个 Token 需 32.69 秒，约 0.03 Token/s；生成 8 个 Token 共耗时 261.5 秒。
• 从 8GB 内存增至 224GB，内存扩大 28 倍，速度仅提升约 1.7 倍，运行中约四成到六成时间在等待磁盘读取。
• 项目要求至少约 1.7TB 固态硬盘空间，普通机械硬盘难以承担这种随机读取负载。

需要特别说明的是，所谓“8GB 内存”来自作者在双路 AMD EPYC 7763 工作站上通过 Linux cgroup 将进程限制在 8GB 内存后的测试结果。该机器有 124 个 CPU 核心、228GB 内存和 3.2TB NVMe 固态硬盘，并装有四张未参与计算的 NVIDIA L40 显卡。因此，这更像是 CPU-only 推理引擎的工程验证，不代表普通 8GB 笔记本能直接获得完整 Kimi K3。

本地部署硬件配置要点

本地部署的两大核心瓶颈是显存容量和内存带宽。

模型权重大致可按公式估算：

模型权重(GB) ≈ 参数量(B) × 量化位数 ÷ 8 × 1.15，运行时还需预留 KV Cache 和 1–3GB 缓冲。

不同精度下，1B 参数大约需要：

• FP16：约 2GB
• INT8：约 1GB
• INT4/Q4_K_M：约 0.5–0.6GB，也是目前主流选择

MoE 模型虽然每次只激活部分专家，但全部专家权重必须完整加载到内存或显存中。按 Q4 量化估算：

• 8GB 显存适合 4B–7B 模型；16GB 可跑 9B–14B；24GB 可进入 24B–27B；120B 级别通常需要 80GB 以上显存或大容量统一内存。
• 显卡方面，RTX 5060 Ti 16GB 适合 9B–14B；二手 RTX 3090 24GB 可跑 24B–27B，但要考虑功耗、矿卡和维修风险。
• 没有独立显卡时，可考虑 Mac Studio、Ryzen AI Max+ 395、DGX Spark 等大容量统一内存设备，96GB–128GB 内存可装下 70B、109B 甚至部分 120B Q4 模型。
• 系统内存建议：8GB–16GB 显存搭配 32GB，24GB–32GB 显存搭配 64GB；混合卸载运行 70B 模型需要 128GB。

具体模型选择参考：

• 8GB 显存或 16GB 普通内存：Phi-4 Mini 3.8B、Qwen3.5 4B，适合摘要、翻译、格式整理和简单工具调用。
• 16GB 显存：Qwen3.5 9B、Gemma 4 12B，后者支持文本、图片、音频和视频输入。
• 24GB 显存：Devstral Small 2 24B，主打编程和软件工程；也可等即将开源的 Qwen3.8 27B，中文能力更有优势。
• 32GB 显存：Qwen3.5-35B-A3B，总参数 35B，每次激活约 3B，计算负担更轻。
• 80GB–128GB：gpt-oss-120b 官方称可放入单张 80GB GPU，或使用大容量统一内存工作站和多卡系统。

软件工具如何选

• LM Studio：适合新手，提供图形界面，可用 lms load --estimate-only 预估内存占用。
• Ollama：适合开发者，支持命令行和 OpenAI 兼容 API。需注意带有 cloud 标记的模型会走云端，对隐私和离线有要求时应确认模型完全本地执行。
• llama.cpp：提供更细的控制，可设置 GPU 卸载层数、上下文、KV Cache 量化和线程数，支持 CUDA、ROCm、Metal、Vulkan、SYCL 和纯 CPU。
• MLX-LM：面向 Apple Silicon 和统一内存设计，支持推理、量化、微调和分布式运行。
• vLLM、SGLang：适合多人服务或正式内部 API，吞吐和并发能力更强，通常部署在 Linux 服务器上。
• Open WebUI、Cherry Studio 属于前端界面，需要连接 Ollama、llama.cpp 或 vLLM 等推理后端。

趋势与结论

DeepSeek V4 Flash 被认为正把前沿模型带上个人桌面。它拥有接近前沿闭源模型的能力，社区量化方案可在 110GB RAM 上以 3 位精度、168GB RAM 上以 4 位精度运行，也能进入 128GB 统一内存的 Mac 或 DGX Spark。官方公开验证较完整的配置是配备 4 张 GB300 的服务器，合计约 1.15TB 显存。

受内存涨价和本地 Agent 工具爆发影响，Mac Mini 等设备一度断货，DGX Spark 起售价也从 3999 美元涨至 4699 美元。但相比之下，DeepSeek V4 Flash 让最强模型与个人桌面之间的距离明显缩短。

2026 年看待“本地运行”需要区分三层：能跑，是权重能装进显存或从硬盘逐层读取；能用，是速度和上下文足以完成任务；值得部署，则是省下的 API 费用或换来的隐私、稳定性、控制权覆盖硬件与维护成本。MoE、低比特量化、稀疏注意力和权重流式加载等技术的推进，预计还会继续降低本地部署门槛。