S23-B05 · 部署形态：从单卡到集群

模型能跑起来，和模型能被一个团队长期养着，是两件不同的事。前者取决于显存够不够，后者取决于形态选得对不对：选错了，后面每一次扩缩容、每一次故障、每一笔账单都会比该有的贵。

这篇按"装得下 → 怎么切 → 怎么复制 → 怎么对外 → 怎么算钱"的顺序讲五个判断，每个都给核对方法，不引用别人的实测数字。

1. 四种部署形态与适用边界

形态	一句话	适用模型规模	对团队的要求
单卡单进程	一张卡一个进程，最简单	权重 + KV 装进一张卡	会装依赖、会看日志
单机多卡	一台机器内多卡切分或复制	单卡装不下，或要更高吞吐	懂并行配置与卡间拓扑
多机多卡	跨机器组成一个推理实例	单机装不下（超大模型）	有集群运维与高速网络
托管 API	按 token 付费调外部服务	任意（由供应商负责）	只要能管好调用侧

判断顺序是固定的：先问"一张卡装不装得下"，装得下且吞吐够就停在第一档；装不下才往切分走，切分仍不够才往多机走。托管 API 不是最后一档，而是另一条平行的路——数据不出域、成本可预测、延迟可控这三条满足不了时才会被排除。

2. 单卡能跑多大的判定

可行条件：权重显存 + KV 显存(峰值并发×上下文) + 激活峰值 + 框架预留 ≤ 卡显存 × 利用率目标

权重显存 ≈ 参数量 × 位宽 / 8
KV 显存 ≈ 层数 × 2 × KV头数 × 头维度 × 每token字节 × 上下文 × 并发

检查项	从哪儿拿	常见错误
参数量	权重文件 / config	用名字里的数字猜
位宽	实际部署精度	量化后仍按 FP16 算
层数、KV 头数	config（注意 GQA）	用注意力头数代替 KV 头数
上下文与并发	业务峰值	用平均值代替 P99
利用率目标	留余量，通常不到 1.0	按 100% 算，必 OOM

所有数字都要按模型 config 与卡规格核对。这一步做扎实，后面三档的选择基本就自动确定了。

3. 单机多卡的两种切分

方式	一句话说清"切什么"	通信特征	适合
张量并行（TP）	把同一层的矩阵按列/行切开，分到多张卡，每层算完都要汇总	每层都要通信，量大且频繁	单机内、卡间带宽高
流水并行（PP）	把不同的层分到不同卡，像流水线一样一段一段过	只在段边界通信，量小	跨机也能用，但会有流水气泡

两条入门推论：TP 尽量不跨机——它每层都要 all-reduce，跨网络会成为瓶颈，所以常见做法是"机内 TP、机间 PP"；PP 会有空泡——前段在算后段在等，批越大越容易填满，所以 PP 常配较大的在飞批。

# 概念示意，参数名与支持情况按引擎版本核对
# vLLM：tensor_parallel_size 走机内；pipeline_parallel_size 需引擎/后端支持
# TensorRT-LLM：tp_size / pp_size 在 build 或运行时配置

4. 多机多卡为什么更难

难点	具体表现	影响
通信带宽	跨机走 IB/RoCE 或普通以太网，带宽与延迟都低于 NVLink	张量并行收益骤降，甚至变慢
故障域扩大	一台机器、一根线、一个交换机端口出问题，整个实例挂	可用性随节点数下降
启动时间	每台机器都要加载权重、建通信组、同步	冷启动从分钟级变成长分钟级
配置一致性	镜像、驱动、库版本、并行度必须完全一致	一处不一致就起不来或结果异常
调度与编排	需要一次性拿到多台机器（gang scheduling）	资源碎片导致排队
可观测性	指标要跨节点聚合，日志分散	排障成本显著上升

一句话：多机不是"更多的卡"，是"更多失败点 + 更强耦合"。能用单机解决，就别上多机。

5. 副本与并行的区别

这两个词经常被混用，但它们解决的是完全不同的问题：

副本（replica）：把同一个完整模型复制多份，每份独立服务  → 提吞吐、提可用性
并行（parallel）：把一个模型切开，多卡协作服务同一个请求 → 装下更大的模型

副本数 × 单副本吞吐 ≈ 总吞吐（需负载均衡配合）
并行度 ↑ 不必然带来吞吐 ↑（通信开销会吃掉收益）

维度	副本	并行
目的	提高总吞吐与冗余	让单个模型装得下
单请求延迟	不变（负载被分摊）	通常变差（多了通信）
显存	每份都要完整装一遍	分摊到多卡
扩展性	近似线性（到瓶颈前）	收益递减，且受拓扑限制
故障影响	挂一份，其余仍可服务	挂一卡，整个实例不可用

新手最常犯的错是用并行去解决吞吐问题：模型明明一张卡装得下，却配了 4 卡张量并行，结果单请求更慢、总吞吐还不如 4 个副本。装得下就用副本，装不下才用并行。

6. 对外形态与运维负担

对外形态	你要负责	你不用负责	适合
自建网关	鉴权、限流、路由、重试、指标、灰度	—	多模型、多副本、有平台团队
K8s 部署	编排、探针、HPA、存储、网络策略	机器本身	已有集群、需要弹性
托管 API	调用侧的重试、超时、预算、降级	模型、卡、扩容、驱动	小团队、流量波动大

三者差别不在"能不能跑"，而在"出问题时谁半夜起来"：自建网关所有链路都是你的；K8s 把机器问题交给平台，编排问题留给你；托管把两者都交出去，代价是成本更高、可控性更低。

7. 冷启动与预热

阶段	做什么	耗时受什么影响	可优化点
拉镜像/拉权重	从仓库或对象存储取文件	文件大小、网络带宽	镜像分层、权重预置到本地盘
加载权重到显存	反序列化、量化反量化、搬上卡	权重体积、磁盘读速	本地 NVMe、权重缓存、并行加载
引擎初始化	建 CUDA context、编译/加载 kernel、建通信组	引擎与并行度	预热脚本、固定 kernel 缓存
首次推理	首次触发的 lazy 初始化	输入长度	用真实长度做 warmup
就绪	探针通过、开始接流量	—	readiness 用真实推理探针

# 探针的关键区别：readiness 必须真的跑一次推理，liveness 只看进程活着
readinessProbe:
  httpGet: { path: /health/ready, port: 8000 }
  initialDelaySeconds: 60      # 要大于权重加载时间
  periodSeconds: 10
livenessProbe:
  httpGet: { path: /health/live, port: 8000 }
  initialDelaySeconds: 120
  failureThreshold: 3

冷启动对弹性的影响很直接：要几分钟才能就绪，"流量突增时扩容"基本无效——新副本没好，峰值已经把老副本打挂。对策是保留最小副本、提前扩容、或用托管兜突发。

8. 成本构成的三块

成本块	来源	降低方向
卡时	按小时计费的 GPU 占用	提高单卡吞吐（批处理、量化）、选更合适的卡型
闲置	低峰期仍占着的副本、为峰值预留的余量	弹性伸缩、按流量分时段调副本、混部
运维人力	部署、升级、排障、容量规划	减少自建组件、托管、自动化

月成本 ≈ 卡时单价 × 卡数 × 730 小时 × 平均利用率倒数
       + 闲置成本（低峰仍占的卡）
       + 人力成本（按人月折算）
单位成本 ≈ 月成本 / 月成功产出 token 数

入门最容易被忽略的是第二块：为了扛峰值而常年开着 4 个副本，平均利用率可能只有个位数，闲置成本远大于卡时成本。先量利用率，再谈优化。

9. 选型的五个问题

#	问题	决定什么
1	模型多大（参数量/精度）	单卡 / 单机多卡 / 多机
2	QPS 或峰值并发多少	副本数量
3	延迟目标（TTFT/TPOT，P99 口径）	是否流式、批上限、卡型
4	有没有 GPU 运维能力	自建 / K8s / 托管
5	预算是固定额度还是按量付费	预留 vs 弹性，是否量化

# 一页纸选型
单卡装得下 & 吞吐够          → 单卡单进程 + 多副本
单卡装不下 & 单机装得下      → 机内张量并行（尽量不跨机）
单机装不下                   → 机内 TP + 机间 PP，接受更多故障域
没有运维能力 / 流量波动大    → 托管 API，把可变成本换成单价

10. 四个常见误解

误解	实际
多卡一定更快	装得下时多卡并行常因通信变慢；加速要看瓶颈在哪
忽略跨机通信	TP 跨机会把每层 all-reduce 打到网络上，收益可能为负
用单副本扛所有流量	单点故障 + 无法滚动升级，一次重启就是一次全站故障
忽略冷启动对弹性的影响	扩容如果慢于流量上升速度，弹性等于不存在

11. 排错：五种部署形态相关故障

现象	原因	处理
单卡能跑，多卡反而变慢	用了 TP 但模型本就装得下	改多副本，去掉并行
多机启动卡住不动	通信组建立失败、版本不一致	逐机核对镜像/驱动/端口，先跑通最小通信测试
扩容后流量仍打挂	冷启动慢于流量上升	保留最小副本、预热池、或托管兜底
滚动升级期间大量 5xx	探针未就绪就接流量	readiness 用真实推理探针，配好优雅停机
账单远高于预期	闲置副本多、利用率低	看平均利用率，按分时段伸缩

12. 边界：这些判断什么时候不适用

场景	说明
模型极小（单卡绰绰有余）	并行不需要，甚至 CPU 就够
研究/离线实验	可用性、冷启动、成本结构都不重要
强合规、数据不出域	托管 API 直接排除，只能自建
超大模型（单机装不下）	多机是唯一选择，难点从"要不要"变成"怎么稳"
流量极低（每天几十次）	自建的经济性很差，托管通常更省

13. 自测

判断"单卡能不能跑"要核对哪几项？最容易算错的是哪一项？
张量并行和流水并行各切的是什么？为什么 TP 尽量不跨机？
多机多卡难在哪里？至少说出三个难点及其影响。
副本和并行解决的是同一个问题吗？模型装得下但吞吐不够，该选哪个？
冷启动为什么会破坏弹性？readiness 探针应该怎么配？
成本的三块构成里，哪一块最容易被忽略？为什么？