本站此前几大系列有一个共同的默认前提：模型在云端，代码在本地，中间靠一根 API 网线相连。《AI Agent 开发》如此，《上下文工程》与《评测驱动开发》也一样——调的是各家旗舰的 API，按 token 付费。这套模式到 2026 年已经足够成熟，但它不是唯一解：把模型权重下载到自己的机器上推理，已经从极客玩具变成了严肃的工程选项。
《本地大模型部署实战》是六大新系列里的第四部，共 16 篇，讲的就是这件事的工程学：模型怎么选、显存怎么算、引擎怎么挑、服务怎么稳。作为系列第 1 篇全景文，本文回答两个入门问题——为什么要把模型搬到本地，以及你的场景到底适不适合；顺带给出 2026 年 10 月的硬件门槛速查、六家推理引擎的版图、开源模型家族速览与全系列路线图。
1、本地化的三大动机
1.1、隐私与合规
第一类动机是数据不能出门。医疗问诊记录、客户的交易流水、没开源的核心代码——这三类数据在任何受监管的公司里都要过安全评审。走云端 API 意味着数据要离开你的网络边界，哪怕供应商承诺不留存，合规部门要的往往是物理上不可泄露，而不是"合同上承诺不泄露"。
本地推理把这道题直接消灭：prompt 与输出全程不离开你的机器，日志就落在你自己的磁盘上，审计路径一目了然。国内团队还要叠加一道数据出境评估：个人信息与重要数据出境有专门的安全评估流程，本地部署可以直接绕开这条审批链路。2026 年这已经不是小众需求——医疗与金融行业把模型本地化写进采购标准，是行业常态。
1.2、成本
第二类动机是账单。云 API 按 token 计费，单价看着便宜，架不住高频场景的乘法：一个全天迭代编码的 Agent，一天烧掉几十万 token 很轻松，旗舰模型下每月账单到四位数美元并不罕见。
本地跑的边际成本是电费。一台 RTX 4090 主机满载约 600 W，每天跑 8 小时约 4.8 度电，按 1 元/度算一个月不到 150 元——同样的任务量，两端成本差着约两个数量级。中间还有一类最适合本地的负载：批量离线任务。语料清洗、文档抽取、历史数据打标，这类活不赶时间，让机器晚上跑通宵，电费口径的成本几乎可以忽略。当然，电费不是全部，买卡的钱要折旧，这是第 2 节要泼的冷水。
1.3、可控
第三类动机写在每一次供应商事故里：模型静默更新导致行为漂移、限流让高峰期请求排队、价格说调就调。《评测驱动开发》系列把这类风险的对策做成回归门禁，本地部署则更彻底——权重在你手里，版本就锁死了：今天的模型和三个月后的模型是同一个文件，跑分不会漂移，接口不会变更，容量上限就是你显卡的算力，不随任何人的商业决策波动。对要跑多年的生产系统，这份确定性本身就有价。
数据敏感、调用高频、任务模式化——三条占两条，本地化才进入收益区。
2、什么时候不该本地
本地化不是银弹，三种情况建议继续用云 API。
第一，模型质量差距真实存在。本地能跑的 70B 级模型（Q4 量化后约 42 GB 权重），在复杂推理与长程 Agent 任务上，与云端闭源旗舰仍有可感知的差距。以 2026 年的开源旗舰为参照，32B 级模型在日常代码与写作上已经够用，但放到多步规划、复杂数学这类压轴题上，差距立刻显形。本地模型的天花板是开源旗舰，不是闭源旗舰——这个差距在 2026 年缩小了很多，但没有闭合。越靠近能力边界的产品，越依赖最强那一档模型。
第二，隐性成本常被低估。显卡按三年折旧，一张 1.3 万元的 RTX 4090 摊下来每天约 12 元，这还没算整机、电费，以及最贵的一项——运维人力。引擎升级、量化格式换代、驱动冲突，总有琐事要人管；没有 GPU 运维经验的团队，人力成本很可能吃掉省下的 API 账单。
第三，场景错配。流量突发的在线服务（本地容量固定，云 API 随手弹性扩容）、依赖最强多模态能力的应用、每周只调几百次的低频内部工具——这三类场景的收益撑不起本地化的门槛。
3、2026 硬件门槛速查
先给一个值得背下来的估算公式。推理时的显存占用大致是：显存 ≈ 参数量 × 每参数字节数 + KV cache（键值缓存）+ 框架开销。每参数字节数由精度决定：FP16 是 2 字节，FP8 与 INT8 是 1 字节，4-bit 量化（Q4）约 0.5 字节。写成代码更直观：
def vram_gb(params_b: float, bits: int, kv_gb: float = 1.0) -> float:
weights = params_b * bits / 8 # 权重：参数量 × 每参数比特数
return round(weights + kv_gb + 1.0, 1) # +1 GB 框架与激活开销
print(vram_gb(7, 4)) # 5.5：7B Q4，8 GB 显卡从容
print(vram_gb(32, 4)) # 18.0：32B Q4，24 GB 显卡的甜点区
print(vram_gb(70, 16)) # 142.0：70B 不量化就得多卡
解读：KV cache 随上下文长度与并发数线性增长，这里按 32B 级模型、8K 上下文粗估 1 GB，高并发场景要放大数倍（第 11 篇专门拆解）。按这个口径，2026 年 10 月的消费级与准专业级门槛如下：
| 模型规模 | Q4 权重 | 含 KV 与开销 | 典型硬件 |
|---|---|---|---|
| 7B | ~4.5 GB | ~6 GB | 8 GB 显卡，或 16 GB 内存纯 CPU |
| 14B | ~9 GB | ~11 GB | 12 GB 显卡（RTX 4070 级） |
| 32B | ~18 GB | ~20 GB | 24 GB 显卡（RTX 3090/4090） |
| 70B | ~42 GB | ~45 GB | 双 24 GB 显卡，或单张 48 GB |
| 600B+ MoE | FP8 权重 600 GB 起 | 极限量化 130～240 GB | 512 GB 统一内存，或多卡服务器 |
MoE（Mixture of Experts，混合专家）模型有一条反直觉规律：显存按总参数算，速度按激活参数算。以 Kimi K2 为例，总参数 1 T、每 token 仅激活约 32B，生成速度接近 32B 稠密模型，但权重文件仍要整个装进显存——Unsloth 的动态量化实践给出的数字是：压到 1-bit 也要 240 GB 以上的内存。
4、推理引擎版图
模型有了，用什么跑？2026 年的推理引擎已经分层清晰，六家各占一个生态位：
| 引擎 | 一句话生态位 |
|---|---|
| llama.cpp | 底座：GGUF 格式作者，CPU 与消费级 GPU 推理 |
| Ollama | 本地开发事实标准：封装 llama.cpp，一行命令拉模型起服务 |
| vLLM | 生产高吞吐标准：NVIDIA GPU 连续批处理，利用率 85%～92% |
| SGLang | Agent 负载之王：RadixAttention 复用前缀 KV cache |
| TGI | Hugging Face 官方：Docker 优先的企业部署 |
| LMDeploy | InternLM 系：TurboMind 引擎，昇腾等国产加速卡适配积极 |
版图为什么长这样？分水岭在并发。单请求场景拼的是量化与算子优化，这是 llama.cpp 的主场；多请求并发拼的是调度——怎么把几十路请求塞满一张 GPU，怎么让共享前缀的系统提示不重复计算，vLLM 的 PagedAttention 与 SGLang 的 RadixAttention 各自回答了其中一个问题。选型的第一刀切在场景：个人开发机上 Ollama 的体验无可替代；对外提供服务、追求吞吐，在 vLLM 与 SGLang 之间二选一；跑在昇腾或想贴 InternLM 生态，看 LMDeploy。本站《云原生》系列第 10 篇已经在容器里跑通过 vLLM，本系列从那里继续向纵深展开：原理、调优、量化、多机，逐一拆开。
5、模型与权重从哪来
权重的两大集散地：Hugging Face 是事实上的全球主站，几乎所有开源模型第一时间上线；国内网络受限或合规需要时用魔搭 ModelScope，主流模型同步很勤，对 Qwen 系最友好。注意格式差异：Hugging Face 下来的通常是 safetensors 原始权重，FP16 精度，直接喂给 vLLM 没问题；要在 llama.cpp 与 Ollama 上跑，得先转成 GGUF 并做量化，ollama pull 帮你跳过了这一步——自动拉取量化好的 GGUF 文件，转换与量化的细节在第 3 篇展开。
2026 年 10 月这一刻，值得记住的开源家族如下（可对照 Fireworks 的开源模型年度盘点）：
| 家族 | 2026-10 主力 | 一句话定位 |
|---|---|---|
| Qwen（阿里） | Qwen3 / Qwen3-Coder | 尺寸全覆盖，中文最强，选型省心 |
| DeepSeek | DeepSeek V4 | 推理与代码旗舰，MoE 性价比标杆 |
| Kimi（月之暗面） | K2 系列 | 1 T 参数 MoE，Agent 与工具调用特化 |
| GLM（智谱） | GLM-4.6 | Agent 与代码向，国内生态活跃 |
| Llama（Meta） | Llama 4 | 许可宽松、生态最广，势头放缓 |
| Mistral | Mistral 系列 | 紧凑高效，欧洲合规场景常客 |
务实的起点：通用与中文任务从 Qwen3 的 7B 或 32B 起步，代码任务试 Qwen3-Coder 与 DeepSeek，追旗舰能力看 Kimi K2——前提是第 3 节那张表里的显存你出得起。
6、OpenAI 兼容层预览
本地化最大的工程红利藏在最后一公里：主流引擎都实现了 OpenAI 兼容 API。本地服务在 localhost 上"伪装"成 OpenAI 的接口，业务代码从云端切到本地，改的只是一个 base_url：
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:11434/v1", # Ollama 的兼容端点
api_key="ollama", # 本地不校验，占位即可
)
resp = client.chat.completions.create(
model="qwen3:32b",
messages=[{"role": "user", "content": "用一句话解释 KV cache"}],
)
print(resp.choices[0].message.content)
除了 base_url 与模型名，这段代码与调用云端 API 的版本逐字相同——流式、工具调用、JSON 结构化输出的接口形状都沿用 OpenAI 约定。换句话说，前面几个系列写下的 Agent 代码，理论上换个环境变量就能在本地模型上跑起来；理论与现实的差距（工具调用质量、流式细节、参数差异）正是本系列第 13 篇的主题。
7、系列路线图
全系列 16 篇按四段推进：
- 第 2～4 篇，地基：硬件计算方法、llama.cpp 与 GGUF、Ollama 实战
- 第 5～7 篇，服务化：vLLM 上篇与下篇、SGLang 与 RadixAttention
- 第 8～12 篇，深水区：四引擎横评、量化上下篇、KV cache 深度、投机解码
- 第 13～16 篇，生产化：OpenAI 兼容层、多机与 K8s、监控与成本、总结
每篇可以独立查阅，但第 2 篇的显存与带宽计算是全系列的地基，建议按序读完前四篇，再跳去自己关心的分支。
8、总结
本地化的决策框架一句话就能说完：数据敏感、调用高频、任务模式化，三条占两条就值得进坑；追求最强推理、流量突发、没人运维 GPU，就继续安心用云 API。硬件上，8 GB 显卡试 7B、24 GB 显卡跑 32B 是 2026 年的两个甜点；软件上，开发用 Ollama、服务用 vLLM 与 SGLang、兼容层保证代码不锁死在任何一边。
行动建议：对于想入门的工程师，建议找一台 24 GB 显卡的机器（自己的或公司闲置的 4090），花一个下午跑通从 ollama pull 到兼容层替换 base_url 的完整链路，再用一周真实用量决定要不要走到 vLLM 服务化那一步；对于数据合规驱动的团队，建议直接从本系列第 5 篇 vLLM 起步，并把显卡折旧与运维人力一并打进预算。下一篇，我们从第一块基石讲起：GPU、显存与带宽到底怎么算。
