📢 本文是 「108张AI知识卡片·大模型通关手册」 系列第 12 篇。上一篇讲了怎么微调模型，这篇讲微调完了怎么上线——从 Demo 到生产，每一步都有坑。

目录

• TL;DR 太长不看
• 一、模型部署：从"能跑"到"能扛"
• 二、模型推理：一次前向传播到底在干嘛
• 三、级联推理：小模型先挡，大模型兜底
• 四、量化：FP16压成INT8，显存省一半
• 五、推理加速：KV缓存+算子融合+并行推理
• 六、私有化部署：数据不出域
• 七、一张图串起部署链路
• 八、代码：量化 + KV缓存简化实现
• 写到最后
• 系列导航 & 持续更新

---

TL;DR 太长不看

⚡ 30 秒版：先记这 6 条，细节往下翻。

• 🔴 模型部署：从"能跑"到"能扛"——服务化（API封装）、容器化（Docker打包）、弹性伸缩（流量高峰扩容、低谷缩容）。
• 🟠 模型推理：一次前向传播=所有层的矩阵乘法+激活函数，7B模型一次推理约14GFLOPs。
• 🟡 级联推理：小模型先挡一轮→搞不定的再交大模型→用最少的算力解决最多的问题。
• 🟢 量化：FP16→INT8/INT4，显存省一半、速度快一倍，精度损失可控就值。
• 🔵 推理加速：KV缓存（避免重复计算）、算子融合（减少内存访问）、并行推理（充分利用GPU）。
• 🟣 私有化部署：数据不出域、模型不下云，金融医疗等敏感场景的必选项。
• 🎁 部署口诀：部署先服务化→推理算清楚→量化先做性价比最高→加速再叠加→级联省算力→私有化看合规。

---

一、模型部署：从"能跑"到"能扛"

Jupyter Notebook 里跑通了，发个链接给同事——这就是 Demo。但生产不是 Demo：100 个用户同时请求怎么办？服务器挂了怎么办？模型更新怎么不停服？模型部署就是解决"从能跑到能扛"的问题。

模型部署解决的核心问题：Demo 是单机单用户，生产是多机多用户高可用。模型部署把"一个模型文件"变成"一个稳定的服务"——能扛并发、能自动恢复、能弹性伸缩。

它到底在干嘛（机制层）：模型部署分三层。服务化：把模型封装成 API 服务——用户发 HTTP 请求，服务返回推理结果。常见框架：vLLM（高吞吐推理服务）、Triton Inference Server（NVIDIA 出品，支持多框架）、TGI（HuggingFace 出品，开箱即用）。容器化：把模型+依赖+运行环境打包成 Docker 镜像——保证"在我机器上能跑"变成"在任何机器上都能跑"。Kubernetes 编排容器，实现自动部署和负载均衡。弹性伸缩：流量高峰自动扩容（多起几个 Pod），低谷自动缩容（释放资源）——用最少的资源扛住最大的流量。关键指标：QPS（每秒请求数）、延迟 P99（99% 请求的响应时间）、可用性（SLA 99.9% 意味着每月停机不超过 43 分钟）。

你能感受到什么（体感层）：Demo：一个 Python 脚本，python inference.py，一次处理一个请求，挂了就挂了。生产：Docker 容器自动部署→K8s 管理 10 个副本→Nginx 负载均衡→健康检查自动重启→流量高峰扩到 20 个副本→低谷缩回 5 个。差距：Demo 是"能用"，生产是"能用、能用得住、能用得省"。

🎛️ 动手感受：单进程 vs 服务化部署

操作：同一个模型，分别用单进程 Python 和 vLLM 服务化部署，用压测工具模拟 100 并发。
你会看到：

• 单进程：一次只能处理 1 个请求，其余 99 个排队，平均延迟 10 秒+，大量超时。
• vLLM 服务化：连续批处理+PagedAttention，100 并发下平均延迟 2 秒，QPS 提升 5-10 倍。
• 变化说明了什么：服务化不只是"包装 API"，核心是"批处理+显存管理"——vLLM 的 continuous batching 让多个请求共享一次前向计算，吞吐量质的飞跃。

🤔 想一想

部署不是"把模型放到服务器上"就完了——模型会更新、依赖会升级、流量会波动。部署是一个持续运维问题：CI/CD（模型更新怎么不停服？）、监控（延迟突增怎么发现？）、降级（模型挂了怎么兜底？）。这些工程问题比模型本身更复杂。

🔗 顺着他想：部署好了，但一次推理到底在干嘛？搞清楚才能优化——这就是模型推理的事。

---

二、模型推理：一次前向传播到底在干嘛

你发了一个请求，0.5 秒后收到回复——这 0.5 秒里模型在干嘛？32 层 Transformer，每层做 Self-Attention + FFN，最后一层输出概率分布，选概率最高的 Token——这就是一次"推理"。

模型推理解决的核心问题：理解推理的计算过程，才能找到优化点。不知道一次推理要过多少层、算多少 FLOPs，就无法判断"慢在哪里"和"怎么加速"。

它到底在干嘛（机制层）：一次推理的完整流程。① Tokenization：文本→Token ID→Embedding 向量。② 逐层前向传播：每一层做 Self-Attention（QKV 计算+注意力加权+输出投影）+ FFN（两层线性变换+激活函数）。③ 输出层：最后一层的输出经过 LM Head（线性层+Softmax），得到词表大小的概率分布。④ 采样：从概率分布中选下一个 Token（贪心选最大概率 / Top-K / Top-P 采样）。⑤ 自回归：把选出的 Token 拼到输入后面，重复 ①-④，直到生成结束符或达到最大长度。关键计算量：Prefill 阶段（处理输入 Prompt）：所有 Token 并行计算，计算量 = 2 × 参数量 × 输入长度。Decode 阶段（逐 Token 生成）：每次只算 1 个 Token，计算量 = 2 × 参数量 × 1。7B 模型一次 Decode 约 14 GFLOPs——看起来不多，但生成 500 个 Token 就要重复 500 次。

你能感受到什么（体感层）：短输入短输出（Prompt 50 Token，输出 100 Token）：Prefill 很快，Decode 也不慢，总延迟 <1 秒。长输入短输出（Prompt 2000 Token，输出 100 Token）：Prefill 慢（2000 Token 并行计算），Decode 快，总延迟主要在 Prefill。长输入长输出（Prompt 2000 Token，输出 1000 Token）：Prefill 慢+Decode 重复 1000 次，总延迟可能 30 秒+。优化方向不同：短输出优化 Prefill（算子融合），长输出优化 Decode（KV 缓存）。

🎛️ 动手感受：不同输入/输出长度的推理延迟分解

操作：同一个 7B 模型，分别测试短输入短输出 / 长输入短输出 / 长输入长输出的延迟，分解 Prefill 和 Decode 时间。
你会看到：

• 短输入短输出（50+100）：Prefill 0.1s + Decode 1.5s = 1.6s。
• 长输入短输出（2000+100）：Prefill 2.0s + Decode 1.5s = 3.5s——Prefill 占 57%。
• 长输入长输出（2000+1000）：Prefill 2.0s + Decode 15s = 17s——Decode 占 88%。
• 变化说明了什么：优化策略取决于瓶颈在哪——Prefill 瓶颈做算子融合，Decode 瓶颈做 KV 缓存和量化。

🤔 想一想

自回归推理的"逐 Token 生成"是根本性瓶颈——无法并行，每次只产出一个 Token。Speculative Decoding（投机解码）试图打破这个瓶颈：用小模型猜多个 Token，大模型并行验证——猜对了就一次产出多个 Token，猜错了就回退。这是目前最有前景的推理加速方向之一。

🔗 顺着他想：推理慢的另一个解法是"别什么请求都给大模型"——级联推理让小模型先挡一轮。

---

三、级联推理：小模型先挡，大模型兜底

每个请求都扔给 70B 大模型——太贵了。级联推理的思路：小模型（7B）先挡一轮，简单的自己搞定，搞不定的再交给大模型（70B）。就像医院分诊：小病社区医院看，大病转三甲。

级联推理解决的核心问题：大模型推理太贵。70B 模型一次推理的算力是 7B 的 10 倍——但很多请求其实很简单，7B 就能搞定。级联推理用小模型处理简单请求，只在必要时调用大模型，大幅降低平均推理成本。

它到底在干嘛（机制层）：级联推理的核心是置信度路由。① 小模型推理：请求先过小模型（7B），得到输出+置信度分数。② 置信度判断：如果置信度高于阈值（如 0.9），直接返回小模型结果——省钱省时。如果置信度低于阈值，转发给大模型（70B）重新推理——保证质量。③ 大模型兜底：大模型推理后返回结果，同时可以把结果反馈给小模型做"在线学习"——让小模型下次能处理类似的请求。关键参数：置信度阈值——阈值越高，转发给大模型的请求越多，质量越高但成本也越高；阈值越低，省钱但质量下降。实测：在对话场景中，约 60-70% 的请求置信度够高，小模型直接搞定——平均推理成本降低 50-60%。

你能感受到什么（体感层）：无级联：100 个请求全给 70B 模型→总成本 100 单位。有级联：65 个请求小模型搞定（7B 成本 1 单位），35 个请求转大模型（70B 成本 10 单位）→总成本 65×1+35×10=415→平均 4.15 单位/请求，比全用大模型省 58%。代价：小模型搞不定的请求多了一次"白跑"的推理——转发延迟增加了约 0.5 秒（小模型推理时间）。额外收益：小模型的"失败案例"是最有价值的训练数据——用这些数据微调小模型，它的"搞定率"会持续提升。

🎛️ 动手感受：不同置信度阈值的效果-成本权衡

操作：同一个请求集，分别用阈值 0.7/0.8/0.9/0.95，对比质量和成本。
你会看到：

• 0.7：小模型搞定 80% 请求，成本最低，但质量下降约 5%。
• 0.8：小模型搞定 70%，成本适中，质量下降约 2%。
• 0.9：小模型搞定 60%，成本稍高，质量下降<1%——推荐值。
• 0.95：小模型搞定 40%，成本接近全用大模型，质量几乎无损——阈值太高，级联意义不大。
• 变化说明了什么：0.9 是"质量-成本"的甜点——再提高阈值，成本节省递减。

🤔 想一想

级联推理有个隐含假设：小模型和大模型的"能力边界"是清晰的。但实际中，小模型的"自信错误"（高置信度但答案错误）是最危险的——它不会转发给大模型，直接返回错误结果。如何检测小模型的"自信错误"是级联推理的开放问题。

🔗 顺着他想：级联推理用"架构"省算力，量化用"精度"省算力——把 FP16 压成 INT8，显存省一半。

---

四、量化：FP16压成INT8，显存省一半

7B 模型用 FP16 要 14GB 显存——一张 4090 刚好装下。但如果用 INT8 呢？7GB，一张 3060 就能跑。量化就是把模型参数从高精度（FP16）压成低精度（INT8/INT4），用精度损失换显存和速度。

量化解决的核心问题：模型太大，显存不够。7B 模型 FP16 要 14GB，70B 要 140GB——量化让模型"瘦身"，装进更小的显存，跑得更快。

它到底在干嘛（机制层）：量化的核心是降低参数精度。FP16：每个参数用 16 位浮点数表示——7B 模型 = 7B × 2 字节 = 14GB。INT8：每个参数用 8 位整数表示——7B 模型 = 7B × 1 字节 = 7GB，显存省 50%。INT4：每个参数用 4 位表示——7B 模型 = 7B × 0.5 字节 = 3.5GB，显存省 75%。量化方法分两种。训练后量化（PTQ）：模型训练完直接量化——简单快速，不需要重新训练。GPTQ、AWQ、SmoothQuant 都是 PTQ 方法。量化感知训练（QAT）：训练时就模拟量化误差——效果更好，但需要重新训练，成本高。关键挑战：精度损失——INT8 通常损失 1-3%，INT4 损失 3-8%。异常值——大模型的权重中有少量"极端值"（outlier），直接量化会严重失真。SmoothQuant 的思路是把这些异常值从权重转移到激活上，让权重分布更均匀。

你能感受到什么（体感层）：FP16：7B 模型 14GB 显存，推理速度基准，效果基准。INT8（GPTQ）：7GB 显存，推理速度提升 30-50%，效果损失 1-2%——大多数场景的最佳选择。INT4（GPTQ）：3.5GB 显存，推理速度提升 50-80%，效果损失 3-5%——资源极度受限时的选择。INT4（AWQ）：3.5GB 显存，效果比 GPTQ-INT4 好 1-2%（AWQ 保护了重要权重），推荐 INT4 首选。

	FP16	INT8	INT4(GPTQ)	INT4(AWQ)
显存(7B)	14GB	7GB	3.5GB	3.5GB
速度	基准	+30-50%	+50-80%	+50-80%
效果损失	0	1-2%	3-5%	2-3%

🎛️ 动手感受：不同量化精度的效果-显存权衡

操作：同一个 7B 模型，分别用 FP16/INT8/INT4 加载，对比显存占用和生成质量。
你会看到：

• FP16：14GB 显存，生成质量最好。
• INT8：7GB 显存，生成质量几乎无损，肉眼看不出差别。
• INT4：3.5GB 显存，偶尔有措辞不自然，但整体可接受。
• 变化说明了什么：INT8 是"无感量化"——省一半显存，效果几乎不变。INT4 是"有感但可接受"——省 75% 显存，效果略有下降。

🤔 想一想

量化不是"免费的午餐"——INT4 量化在数学推理、代码生成等"精确性要求高"的任务上效果损失更大（5-10%），因为低精度会放大计算误差。但在对话、摘要等"容错性高"的任务上，INT4 的损失几乎可以忽略。量化的适用性取决于任务类型——不是所有场景都适合激进量化。

🔗 顺着他想：量化省显存，推理加速省时间——KV 缓存、算子融合、并行推理，把延迟打下来。

---

五、推理加速：KV缓存+算子融合+并行推理

7B 模型一次 Decode 只要 14 GFLOPs——但为什么生成 500 个 Token 要 15 秒？因为瓶颈不在计算，在内存访问。推理加速就是用各种手段把延迟打下来、吞吐提上去。

推理加速解决的核心问题：推理慢的瓶颈不是"算得慢"，是"访存慢"。GPU 的计算速度远快于内存带宽——模型推理时大量时间花在"把权重从显存搬到计算单元"，而不是"做计算"。

它到底在干嘛（机制层）：推理加速的三大手段。① KV 缓存（KV Cache）：自回归生成时，之前 Token 的 Key 和 Value 不变——缓存起来，下次只算新 Token 的 KV，避免重复计算。KV 缓存让 Decode 阶段从 O(N²) 降到 O(N)。② 算子融合（Kernel Fusion）：把多个小算子合并成一个大算子——减少中间结果的显存读写。例如把 QKV 投影+Softmax+Attention 合并成一个 kernel，中间结果不写回显存，直接在寄存器里传递。③ 并行推理：多个请求的 Token 拼在一起做 batch 推理——充分利用 GPU 的并行计算能力。vLLM 的 continuous batching：请求动态加入/退出 batch，不需要等所有请求同时完成。进阶技术：PagedAttention（vLLM）：把 KV 缓存分页管理，像操作系统的虚拟内存一样——避免显存碎片，支持更大的 batch size。Flash Attention：重写 Attention 的计算顺序，减少 HBM（高带宽内存）访问次数——Prefill 阶段加速 2-4 倍。Speculative Decoding：小模型猜多个 Token，大模型并行验证——Decode 阶段加速 2-3 倍。

你能感受到什么（体感层）：无加速：7B 模型生成 500 Token 约 15 秒。+KV 缓存：约 8 秒（Decode 阶段不再重复计算已有 Token 的 KV）。+算子融合：约 5 秒（减少显存读写）。+continuous batching：吞吐量提升 5-10 倍（多请求共享一次前向计算）。+Flash Attention：Prefill 阶段加速 2-4 倍。组合效果：vLLM（KV 缓存+PagedAttention+continuous batching）vs 原生 HuggingFace：吞吐量提升 10-24 倍。

🎛️ 动手感受：逐步叠加加速技术的效果

操作：同一个 7B 模型，逐步叠加 KV 缓存/算子融合/continuous batching，对比延迟和吞吐。
你会看到：

• 原生 HF：生成 500 Token 约 15 秒，吞吐 2 QPS。
• +KV 缓存：约 8 秒，吞吐 4 QPS。
• +算子融合：约 5 秒，吞吐 6 QPS。
• +continuous batching（vLLM）：单请求延迟不变，但吞吐提升到 20-50 QPS。
• 变化说明了什么：单请求延迟优化靠 KV 缓存+算子融合，多请求吞吐优化靠 continuous batching——两者叠加效果最大。

🤔 想一想

推理加速的"天花板"在哪里？理论上下限是"纯计算时间"（不考虑访存延迟）——7B 模型一次 Decode 约 14 GFLOPs，A100 算力 312 TFLOPS，纯计算时间约 0.045ms。实际一次 Decode 约 30ms——差了 660 倍，全是访存开销。推理加速的本质是"减少访存"，不是"增加算力"。

🔗 顺着他想：加速和量化都讲了，还有一种部署方式不考虑速度——私有化部署，数据安全第一。

---

六、私有化部署：数据不出域

用 GPT-4 的 API 很方便——但你的数据要发到 OpenAI 的服务器。金融、医疗、政务场景，数据出域就是合规红线。私有化部署就是让模型跑在你自己的服务器上，数据不出域、模型不下云。

私有化部署解决的核心问题：数据安全和合规要求。金融（客户交易数据）、医疗（患者病历数据）、政务（公民信息数据）——这些场景的数据不能发到第三方 API，必须在本地处理。

它到底在干嘛（机制层）：私有化部署分三种模式。① 本地部署（On-Premise）：模型直接装在客户自己的服务器上——数据完全不出域，安全性最高。但需要客户自己买 GPU、运维服务器、处理故障——成本高、运维难。② 私有云部署（Private Cloud）：模型部署在客户租的云服务器上（如阿里云 ECS）——数据在客户的虚拟网络内，不出域。比本地部署省运维，但仍有云服务商"能看到"数据的风险。③ 混合部署（Hybrid）：敏感数据在本地处理，非敏感数据走 API——平衡安全性和成本。关键挑战：成本：7B 模型需要 1×A100（约 2 万/月），70B 需要 4×A100（约 8 万/月）——比 API 贵 5-10 倍。运维：模型更新、故障恢复、性能监控——需要专业的 MLOps 团队。模型选择：不是所有模型都开放权重——GPT-4 无法私有化部署，只能选开源模型（LLaMA、Qwen、DeepSeek 等）。

你能感受到什么（体感层）：API 调用：0.002 美元/1K Token，零运维，数据出域。私有化部署（7B）：约 2 万/月（含服务器+运维），数据不出域，需要 MLOps 团队。盈亏平衡点：如果每月调用量超过 10 亿 Token，私有化部署才比 API 便宜——但需要前期投入和运维能力。合规价值：对于金融医疗场景，合规不是"值不值"的问题，是"必须"——不私有化就不能用。

🎛️ 动手感受：API vs 私有化的成本对比

操作：按不同月调用量，对比 API 调用和私有化部署（7B）的总成本。
你会看到：

• 100 万 Token/月：API 约 2 美元，私有化约 2 万人民币——API 便宜得多。
• 1 亿 Token/月：API 约 200 美元（~1400 元），私有化约 2 万——API 仍便宜。
• 10 亿 Token/月：API 约 2000 美元（~1.4 万），私有化约 2 万——接近持平。
• 变化说明了什么：纯看成本，API 在绝大多数场景下更便宜——私有化的价值不在省钱，在合规和数据安全。

🤔 想一想

私有化部署的"数据不出域"只对模型推理成立——但如果用开源模型，模型权重本身就是公开的。真正的"数据安全"不只是"数据不出域"，还包括"模型不会泄露训练数据"（成员推理攻击）、“模型不会生成敏感信息”（数据提取攻击）。私有化部署是必要条件，不是充分条件。

🔗 顺着他想：6 个概念串起来，就是大模型从 Demo 到生产的完整部署链路。

---

七、一张图串起部署链路

6 个概念串成一条从"部署"到"优化"到"合规"的完整链路：

大模型部署链路
   │
   ① 模型部署          ← 服务化+容器化+弹性伸缩，从能跑到能扛
   │
   ② 模型推理          ← 理解前向传播，找到优化瓶颈
   │
   ③ 量化              ← FP16→INT8/INT4，省显存+提速（性价比最高）
   │
   ④ 推理加速          ← KV缓存+算子融合+并行推理，把延迟打下来
   │
   ⑤ 级联推理          ← 小模型先挡+大模型兜底，省算力
   │
   ⑥ 私有化部署        ← 数据不出域，合规必选项

部署口诀：

• 部署先服务化——API 封装+容器化+弹性伸缩。
• 推理算清楚——Prefill 瓶颈做算子融合，Decode 瓶颈做 KV 缓存。
• 量化先做——INT8 性价比最高，INT4 资源受限时选 AWQ。
• 加速再叠加——KV 缓存+算子融合+continuous batching 组合拳。
• 级联省算力——小模型挡 60-70%，大模型兜底 30-40%。
• 私有化看合规——金融医疗必选，成本不是唯一考量。

---

八、代码：量化 + KV缓存简化实现

import torch
import torch.nn as nn

# ① 简化版INT8量化
def quantize_int8(tensor: torch.Tensor):
    """将FP16权重量化为INT8"""
    scale = tensor.abs().max() / 127
    quantized = (tensor / scale).round().clamp(-128, 127).to(torch.int8)
    return quantized, scale

def dequantize_int8(quantized: torch.Tensor, scale: float):
    """INT8反量化回FP16"""
    return quantized.float() * scale

# 演示
weight = torch.randn(4096, 4096, dtype=torch.float16)
q_weight, scale = quantize_int8(weight)
restored = dequantize_int8(q_weight, scale)
error = (weight - restored).abs().mean()
print(f"原始大小: {weight.numel() * 2 / 1024 / 1024:.1f} MB (FP16)")
print(f"量化大小: {q_weight.numel() * 1 / 1024 / 1024:.1f} MB (INT8)")
print(f"量化误差: {error:.6f}")

# ② 简化版KV缓存
class SimpleKVCache:
    def __init__(self):
        self.k_cache = {}
        self.v_cache = {}

    def update(self, layer_id, k, v):
        if layer_id in self.k_cache:
            self.k_cache[layer_id] = torch.cat([self.k_cache[layer_id], k], dim=1)
            self.v_cache[layer_id] = torch.cat([self.v_cache[layer_id], v], dim=1)
        else:
            self.k_cache[layer_id] = k
            self.v_cache[layer_id] = v
        return self.k_cache[layer_id], self.v_cache[layer_id]

    def clear(self):
        self.k_cache.clear()
        self.v_cache.clear()

# 演示KV缓存效果
cache = SimpleKVCache()
dim, n_layers = 64, 4
for step in range(5):
    new_k = torch.randn(1, 1, dim)
    new_v = torch.randn(1, 1, dim)
    for layer in range(n_layers):
        full_k, full_v = cache.update(layer, new_k, new_v)
    print(f"Step {step}: 缓存长度={full_k.shape[1]} Token")

cache.clear()
print("KV缓存已清空，下一轮对话重新开始")

这段代码实现了 INT8 量化和 KV 缓存的核心逻辑。生产环境推荐：量化用 AutoGPTQ/AutoAWQ 库（一行代码加载量化模型），推理用 vLLM 框架（内置 KV 缓存+PagedAttention+continuous batching）。

---

写到最后

6 个概念，从部署的服务化到推理的计算分解，从量化的精度换显存到加速的访存优化，从级联的算力节省到私有化的合规保障——串起来就是大模型从 Demo 到生产的完整链路。部署不是"把模型放到服务器上"，是"让模型在生产环境稳定、高效、安全地运行"。

下一篇讲大模型"瘦身术"——压缩、剪枝、蒸馏，让模型轻装上阵。

如果你读下来觉得真有用：

• 👍 点个赞，让我知道部署链路这种"工程师视角"的写法值得继续；
• ⭐ 收藏起来，量化/加速/级联这些概念在部署实战中回来翻的概率很高；
• 💬 关注一下，下一篇"模型压缩篇"会讲剪枝/蒸馏/分布式训练，关注了就不会错过。

有问题评论区直接说，我会逐条回。

---

系列导航 & 持续更新

📚 系列第 12 篇｜上一篇：一张卡也能微调大模型——4种PEFT方案对比 ｜下一篇预告：大模型瘦身术——压缩·剪枝·蒸馏

---

如果这篇对你有帮助，点个👍收藏，部署优化概念在实战中回来翻的概率很高。有问题欢迎在评论区交流，我会逐条回复。

---