一块 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 以上显存或大容量统一内存。
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 模型，代价是更高的整机价格和有限的升级空间。
如果直接要对应到模型，8GB 显存或 16GB 普通内存电脑，Phi-4 Mini 3.8B、Qwen3.5 4B 这类小模型最稳妥。它们适合摘要、翻译、格式整理和简单工具调用，也不会让整台电脑陷入内存不足。
来到 16GB 显存，Qwen3.5 9B、Gemma 4 12B 是更均衡的选择。Gemma 4 12B 支持文本、图片、音频和视频，Google 甚至展示过通过专用 AI Edge 运行时，在 16GB 普通笔记本上运行它。
24GB 显存开始进入本地 Agent 的实用区间。Devstral Small 2 24B 主打编程和软件工程，官方给出的本地硬件参考包括单张 RTX 4090 或 32GB 内存的 Mac。
同一档位还可以选择即将开源的 Qwen3.8 27B，它支持文本和视觉输入，中文能力更有优势。
32GB 显存则可以运行 Qwen3.5-35B-A3B。它拥有 35B 总参数，每次只激活约 3B，在模型完整装入显存后，可以得到比同等总参数稠密模型更轻的计算负担。
80GB—128GB 是另一条分界线。gpt-oss-120b 官方称可放入单张 80GB GPU；这些模型更适合大容量统一内存工作站、专业计算卡或多卡系统。
拿 DeepSeek V4 Flash 举例，目前公开验证较完整的一套方案，是一台配备 4 张 GB300 的服务器。每张 GB300 拥有 288GB 内存，四张卡合计约 1.15TB 显存。这样的配置远远超过模型权重本身，剩余空间将用于 KV Cache、DSpark、长上下文和并发请求。
而社区里一些经过量化的方案，也能做到在 168GB RAM 上运行 DeepSeek V4 Flash 无损 4 位，在 110GB RAM 上运行 3 位。
选择合适的本地 LLM 软件
硬件选好后，下一步才是运行工具。
LM Studio 更适合第一次接触本地模型的人。它提供完整的图形界面，可以直接搜索、下载和切换模型，还能在加载前使用专门的命令 lms load –estimate-only 估算模型、上下文、Flash Attention 和视觉组件需要多少内存。
Ollama 则更适合开发者。安装后通过 ollama run 就能启动模型，也可以提供 OpenAI 兼容 API，连接 Open WebUI、Cherry Studio、编辑器和各种 Agent 工具。
需要留意的是，Ollama 现在同时提供本地模型和云模型。带有 cloud 标记的模型会把计算转移到 Ollama Cloud；如果你对隐私和离线运行有明确要求时，应先检查模型是否完全在本地执行。
llama.cpp 提供更细的控制。用户可以精确设置 GPU 卸载层数、上下文、KV Cache 量化和线程数等参数，也可以在 CUDA、ROCm、Metal、Vulkan、SYCL 以及纯 CPU 之间切换。它适合需要压榨硬件、运行 GGUF 或处理非主流设备的人。
Mac 用户还可以选择 MLX-LM。它针对 Apple Silicon 和统一内存设计，除推理外，也支持量化、微调和分布式运行。
如果模型需要同时服务多人，或要做一个正式的内部 API，vLLM 和 SGLang 更合适。它们支持连续批处理和更高并发吞吐，但部署环境通常更偏向 Linux 服务器。
这里还有一个常见误区：Open WebUI 和 Cherry Studio 主要负责界面，它们通常还要连接 Ollama、llama.cpp 或 vLLM 等推理后端。
有人说，真正的数字自由，是在自己的设备上拥有一个不受平台限制的 AI。
没有每周额度，没有服务中断，也不用担心账号被封；模型厂商调整套餐、下架版本或者收紧权限时，本地模型仍然可以继续处理自己的文件、代码和数据。
但到了 2026 年，「本地运行」已经需要分成三个方面来看：
能跑，是权重可以被装进显存，或者从硬盘逐层读取；能用，是速度、上下文和模型能力足以完成任务；值得部署，则意味着省下的 API 费用，或者获得的隐私、稳定性和控制权，能够覆盖硬件、电费与维护成本。
DeepSeek V4 Flash 的出现，似乎开始把这个三角变得完整起来。
它已经拥有接近前沿闭源模型的能力，经过量化后，却可以进入 110GB—168GB 内存，甚至一台配备 128GB 统一内存的 Mac 或 DGX Spark 所能触及的范围。
这样的设备对普通用户依然昂贵，但相比过去必须依赖多张专业计算卡和服务器机柜，最强模型与个人桌面之间的距离，已经缩短了一大截。
接下来，MoE缓和专家模型、低比特量化、稀疏注意力和权重流式加载等技术的进步，大概还会继续降低部署成本，统一内存设备也会把更大的模型搬上桌面。
今天需要十几万元工作站才能运行的模型，几年后可能就会进入普通电脑。
#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。
from 爱范儿 https://ift.tt/tSHsOUh
via IFTTT
