《本地大模型部署实战》写到第 16 篇，收官。前 15 篇从显存账一路讲到监控报表，每篇都在解决一个具体问题；但真到动手部署时，没人会按系列顺序重读 15 篇——你面对的永远是一个具体处境：手里几张什么卡、要扛多少并发、模型选哪个、从哪个引擎起步。参照《上下文工程》第 18 篇与《评测驱动开发》第 14 篇的手册化收官，本篇不再引入新知识，把 15 篇浓缩成一套可随身查阅的选型手册。
手册六件套：一条主线回顾、一棵按需求问答走的总决策树、一张迁移路径图、一张 16 篇知识地图、一幅四系列版图，外加本地与云的路由心法和三件立刻可做的事。可以通读一遍，更建议把决策树与知识地图收进书签，选型时按图索骥。本文按"主线 → 决策树 → 迁移路径 → 知识地图 → 版图 → 路由心法 → 行动 → 总结"组织全文。
1、系列主线回顾
先回答总问题：这 15 篇到底在讲什么？一句话——把"模型能不能在我这台机器上稳定地跑起来、跑得省、跑得快"变成可计算的工程问题。全系列是一条环环相扣的链，全貌如下：
这张图自上而下也是依赖顺序。算账是一切的前提——第 2 篇的三项分解（权重、KV Cache（键值缓存）、激活缓冲）决定模型能不能装进卡，装不进，后面全是空谈；选引擎决定用什么形态跑；压资源在显存与速度的双重约束里榨容量；兼容层把服务接进业务代码；多机解决单卡装不下或扛不住；监控让这一切可持续运营。第 1 篇的去留判断（隐私合规、成本、可控三大动机）罩在整条链外面：先确认该本地，再进这条链。
反过来，跳步是最常见的返工原因。没算显存就买卡（第 2 篇）、没压测就定并发参数（第 6 篇）、不走兼容层就把引擎细节直接写进业务代码（第 13 篇），都会在几周后以推倒重来的方式收费。
2、选型总决策树
第一个随身工具回答"该用哪个引擎"。选型的正确姿势不是背榜单，而是按自己的需求逐问作答，每一问的答案都出自第 8 篇横评与各引擎的实操篇。决策树如下：
用这棵树三句话划重点。第一，Ollama 的甜区是单机单人：它的调度器面向交互设计，并发一高排队明显，拿 Ollama 撑线上服务是跟它的设计初衷作对。第二，生产默认 vLLM，例外恰好一条——Agent 多轮负载的 prompt 是不断变长的共享前缀，SGLang 的 RadixAttention 让首 token 延迟（TTFT，Time To First Token）显著占优。第三，模型装不下先想量化再想加卡：Q4 档位解决大多数"买卡焦虑"，真到要多卡时再回第 14 篇。
3、迁移路径与触发信号
决策树是空间维度的选型，迁移路径是时间维度的演进。健康的部署通常不是一步到位，而是沿四个阶段逐级推进，每一级该不该走，看的是指标而不是感觉：
四个阶段的形态与触发信号展开成表：
| 阶段 | 典型形态 | 该迁移的信号 | 出处 |
|---|---|---|---|
| 原型 | Ollama 起在开发机 | 无——验证期就该待在这里 | 第 4 篇 |
| 试点 | vLLM 单卡生产部署 | 多用户并发、排队、P95 上涨 | 第 6 篇 |
| 规模化 | tensor parallel 多卡再到多机 | 压测拐点并发低于峰值需求 | 第 14 篇 |
| 优化 | 量化、投机解码、KV 配额 | 显存告警、单流太慢、成本超标 | 第 9～12 篇 |
用这张表两条纪律。其一，迁移的依据永远是自己的压测数字：第 6 篇的拐点判读——并发翻倍而吞吐不再上涨、P95 陡增——给出的是这张卡在此配置下的真实容量，比任何公开 benchmark 可信，硬件、驱动、模型、参数任一不同，别人的数字就失效。其二，迁移成本已被第 13 篇压到最低：业务代码只认 base_url 与虚拟模型名，从 Ollama 换到 vLLM 是一次环境变量变更，不是一次代码发布。所以设计期不必纠结选型完美——先跑起来，让指标说话，该迁移时再迁移。
4、十六篇知识地图
第二个随身工具是全系列索引：每篇一行，第三列写"何时回头查"。用法不是通读，是定位。
| 篇 | 主题 | 何时回头查 |
|---|---|---|
| 1 | 本地化全景与去留判断 | 决定要不要本地、给团队定调时 |
| 2 | 硬件与显存计算 | 买卡前、换模型前算显存时 |
| 3 | llama.cpp 与 GGUF | 要精确控制层卸载、跑分复现时 |
| 4 | Ollama 快速上手 | 搭本地开发环境、接本地模型时 |
| 5 | PagedAttention 原理 | 想搞懂吞吐从哪里来时 |
| 6 | vLLM 生产部署与调优 | 上线、调参、压测定容量时 |
| 7 | SGLang 与 RadixAttention | Agent 多轮、TTFT 压不下来时 |
| 8 | 六家引擎横评 | 引擎选型摇摆、要一句结论时 |
| 9 | GGUF 量化与精度损失 | 挑量化档位、评估掉精度时 |
| 10 | GPTQ、AWQ 与 FP8 | 服务端量化选型时 |
| 11 | KV Cache 深度 | 长上下文、并发一开就 OOM 时 |
| 12 | 投机解码与推理加速 | 单流延迟高、decode 太慢时 |
| 13 | OpenAI 兼容层与网关 | 接业务代码、切后端、配路由时 |
| 14 | 多机与弹性 | 单卡拐点扛不住峰值时 |
| 15 | 监控与成本 | 上线后看指标、算成本账时 |
| 16 | 本篇决策树 | 不知道从哪开始、翻哪篇时 |
5、四系列知识版图
收官时把四个系列放回一张图。至此本站的 Agent 工程知识体系 78 篇，四层各管一段：
| 系列 | 篇数 | 层 | 核心问题 |
|---|---|---|---|
| AI Agent 开发 | 30 | 应用层 | 系统怎么搭：规划、工具、RAG、多 Agent |
| 上下文工程 | 18 | 信息层 | 每步喂给模型什么：窗口账、压缩、缓存 |
| 评测驱动开发 | 14 | 质量层 | 到底好不好：数据集、门禁、监控、红队 |
| 本地大模型部署 | 16 | 基础设施层 | 模型在哪跑：显存、引擎、量化、多机 |
四层的咬合点在原文里都有接口。上下文工程的缓存经济学落到底层，就是本系列第 11 篇的 KV Cache 实占与命中率；EDD 的评测门禁对本地模型同样生效——换模型、换量化档位就是一次变更，该过门禁的别豁免；本系列第 13 篇的 LiteLLM 网关则是基础设施层向应用层递出的接口，Agent 系列的代码经它一行不改地跑在本地。合起来一句判断：应用层定能力，信息层定质量下限，评测层定可信度，基础设施层定成本与可控——四层缺一，系统都能跑，但跑不远。
6、本地与云的路由心法
系列最后校正一个容易被带偏的叙事：本地部署不是对云的背叛，云 API 也不是本地失败后的退路。本地与云是同一条路由表里的两个后端，按请求特征分流——这是第 13 篇混合路由的结论，也是 2026 年的常态。
分流逻辑在应用侧就是一次模型名选择：分类、抽取、改写这类高频轻任务指向本地 8B，边际成本是电费；深度推理、长文综合这类难任务指向云旗舰，按 token 付费买能力上限。网关配置示意：
model_list:
- model_name: cheap # 高频轻任务 → 本地 vLLM
litellm_params:
model: openai/Qwen/Qwen3-8B
api_base: http://10.0.0.5:8000/v1
api_key: EMPTY
- model_name: smart # 难任务 → 云旗舰
litellm_params:
model: anthropic/claude-sonnet-5
api_key: os.environ/ANTHROPIC_API_KEY
litellm_settings:
fallbacks: [{"cheap": ["smart"]}] # 本地重启窗口期自动上云
解读三点。其一，应用代码里只有 cheap 与 smart 两个名字，后端是什么、在哪跑，应用一无所知。其二，fallbacks 让本地服务重启的窗口期流量自动上云，用户无感——"本地优先、云兜底"从架构口号落成一行配置。其三，成本还能再进一步：同一虚拟名下挂本地与云两个条目，配 cost-based-routing 并给本地条目定价为零，网关自动先用零成本后端，本地被冷却才碰云（详见 LiteLLM 路由文档）。
别问"该本地还是该云"，问"这个请求该走哪边"。
7、三件立刻可做的事
手册的最后是行动清单。三件事按顺序做，每件半天以内，分别对应第 4、2、6 篇。
**第一件：用 Ollama 跑起一个模型，10 分钟。**安装后两条命令：
ollama pull qwen3:8b # 8B 是多数开发机的甜区
ollama run qwen3:8b # 进交互对话，Ctrl-D 退出
验收标准：curl http://localhost:11434/v1/models 能列出模型——此刻你的机器已经是一个 OpenAI 兼容端点，第 13 篇的一切接法即刻可用。
**第二件：算一次显存账，半小时。**把目标模型的三项分解写成一个函数，对每个想跑的模型都过一遍：
def vram_gb(params_b: float, bits: int, kv_gb: float = 1.0) -> float:
weights = params_b * bits / 8 # 速算：FP16 ×2 / INT4 ×0.5
file = weights * 1.2 # 量化元数据多占 15%～20%
return round(file + kv_gb + 2.0, 1) # +2 GB 激活与缓冲
print(vram_gb(32, 4)) # 22.2：32B Q4，24 GB 显卡甜点区
print(vram_gb(70, 4)) # 45.0：70B Q4，双 24 GB 起步
解读：权重按实际文件尺寸上浮，KV Cache 与开销按第 2 篇口径粗估，结论再对照手上的卡——装不下先降量化档，而不是直接换思路。算完这三个数，买卡与选型的第一道关就过了。
**第三件：压测一次自己的负载，半天。**拿第 6 篇第 7 节的异步脚本，从并发 1 逐档加压到拐点，记下三个数：拐点并发、峰值吞吐、P95 延迟。压测的两个前提别丢：prompt 长度要贴近真实业务的输入分布（拿线上日志采样最准），输出统一加 max_tokens 上限。这三个数是此后所有扩容与限流决策的基准——单卡需求量就是代数题 N×L/T 向上取整再留三成余量，输入全部来自自己的机器。
8、总结
16 篇收束成一句话：显存先算账（第 2 篇）；引擎按场景选——单机 Ollama、生产 vLLM、Agent 用 SGLang（第 3～8 篇）；装不下先量化，不够快再投机解码（第 9～12 篇）；业务代码只认 base_url（第 13 篇）；扛不住上多机（第 14 篇）；上线后让监控接管（第 15 篇）。选型看决策树，演进看触发信号，本地与云按请求路由——这三张图就是整个系列留给你的行囊。
本系列之后，博客的下一个系列是《TypeScript Agent 开发（Mastra）》14 篇：从 Python 栈走向 TS 栈，Mastra 的 workflows、类型安全工具与内置 evals 都在射程里；更远处，多模态开发实战 12 篇与后训练入门 8 篇已经排队。对于跟着走完全程的读者，建议今天就把第 7 节的第一件事做掉——ollama run 回车的那一刻，你已经站在自己的算力上了。
