1. 大模型推理成本为什么突然成了生死线
1.1 从训练狂欢到推理账单的转折点
过去两年，大家聊大模型，聊的都是参数量、训练数据、榜单排名。但真正把模型推到线上、开始承接真实流量之后，很多团队才发现，训练那点钱其实是一次性投入，推理才是每天都在流血的伤口。我见过不少团队，模型效果做得不错，用户量也涨得挺快，结果一算账，每个月的推理成本比研发团队的工资还高，融资的钱一大半交给了算力供应商。
这个转折点其实很好理解。训练是项目制，一次几百万到几千万，预算批了就批了。推理是运营制，只要服务在线，GPU 就在烧钱，用户越多烧得越快。更麻烦的是，推理的负载是波动的，白天高峰、晚上低谷，但 GPU 资源往往按峰值预留，低谷时段大量算力闲置，利用率可能只有百分之二三十。这种浪费在训练阶段是不存在的，训练任务可以排满 7×24 小时。
所以现在行业里有一个共识：大模型能不能商业化，不取决于模型有多强，而取决于推理成本能不能压到收入线以下。这也是为什么 PD 分离、KV Cache 优化、国产算力适配这些话题，从去年下半年开始热度飙升。大家不是在做技术炫技，是在算真金白银的账。
1.2 推理成本的构成：不只是 GPU 租金
很多人一提推理成本，第一反应就是 GPU 每小时多少钱。这个理解太窄了。真实的推理成本至少包含四块：
- 算力成本：GPU 或加速卡的租赁/折旧费用，这是大头，通常占 60% 到 80%。
- 显存成本：KV Cache 占用的显存直接决定了单卡能并发多少请求，显存不够就得加卡，这是隐性的算力成本。
- 网络与调度成本：多卡多机部署时，请求分发、结果聚合、跨节点通信都要消耗资源。
- 运维与人力成本：模型更新、扩缩容、故障处理，这些看起来不直接烧 GPU，但团队规模上去了，也是实打实的支出。
我见过一个典型的案例：某团队用 8 卡 A100 部署了一个 70B 模型，理论上单卡能扛 20 并发，8 卡就是 160 并发。但实际压测下来，只能稳定支撑 60 并发左右，原因是 KV Cache 把显存吃满了，调度器不敢再放请求进来。结果就是 GPU 利用率只有 40%，相当于一半的钱白花了。这就是为什么优化推理成本，不能只盯着 GPU 单价，要把显存、调度、并发一起算进去。
1.3 六条落地手段的整体地图
标题里提到的“从 PD 分离到国产算力的六条落地手段”，我理解这是一个从软件架构到硬件选型的完整优化链条。结合行业里常见的实践，我把它拆成六条：
- PD 分离：把 Prefill 和 Decode 两个阶段拆到不同实例上，各自用最适合的硬件和并行策略。
- KV Cache 优化：通过量化、分页、前缀共享等手段，压缩显存占用，提升并发。
- 连续批处理与调度优化：让请求动态组批，填满 GPU 的空闲周期。
- GPU 虚拟化与切分：把大卡切成小份，按需分配，提升小模型或低峰时段的利用率。
- 模型量化与蒸馏：用 INT8、INT4 甚至更激进的量化，降低单次推理的算力需求。
- 国产算力适配：在国产加速卡上做算子优化和框架适配，用更低的单价承接部分流量。
这六条不是互斥的，实际落地时往往是组合拳。下面我逐条拆开讲，每条都会说清楚原理、操作要点和我踩过的坑。
2. PD 分离：把 Prefill 和 Decode 拆开算账
2.1 Prefill 和 Decode 的本质差异
要理解 PD 分离，先得搞清楚大模型推理的两个阶段到底在干什么。
Prefill 阶段是处理用户输入的 prompt。比如用户输入 500 个 token，模型要一次性把这 500 个 token 都读进去，计算它们的 KV 并生成第一个输出 token。这个阶段的特点是计算密集，矩阵乘法规模大，GPU 的算力单元跑得很满，但显存占用相对可控，因为输入长度是确定的。
Decode 阶段是逐 token 生成输出。每生成一个 token，都要拿上一个 token 的 KV 去和整个历史 KV 做注意力计算。这个阶段的特点是显存带宽密集，因为每次只算一个 token，矩阵乘法的规模很小，GPU 的算力单元大量闲置，但要把整个 KV Cache 从显存里读出来，带宽压力很大。
这两个阶段的资源需求完全不同。Prefill 吃算力，Decode 吃带宽和显存。如果把它们混在同一个实例上跑，就会出现一种尴尬的局面：Prefill 请求来了，算力被占满，Decode 请求只能排队；Decode 请求多了，显存被 KV Cache 占满，Prefill 又进不来。两边互相拖累，整体吞吐上不去。
2.2 PD 分离的架构设计
PD 分离的核心思路很简单：让 Prefill 和 Decode 跑在不同的实例上，各自独立扩缩容。
具体架构通常是这样的：
- Prefill 实例池：配置高算力卡，比如 A100、H100，专门处理输入 prompt，生成首 token 和对应的 KV Cache。
- Decode 实例池：配置大显存卡，或者用更多数量的中端卡，专门做逐 token 生成。
- KV Cache 传输通道：Prefill 算完的 KV Cache 要传给 Decode 实例，这中间需要高速网络，比如 NVLink、RDMA 或者至少是 100Gbps 以上的以太网。
这个架构的好处是，Prefill 和 Decode 可以分别调优。Prefill 实例可以开大 batch，把算力吃满；Decode 实例可以开大并发，把显存和带宽用足。两边互不干扰，整体吞吐能提升 30% 到 50%，具体取决于模型大小和请求特征。
但这里有一个关键问题：KV Cache 的传输成本。一个 70B 模型，如果输入 2000 token，KV Cache 大约是 2GB 左右（取决于层数和头数）。如果 Prefill 和 Decode 不在同一台机器上，这 2GB 数据要通过网络传输，延迟和带宽都是挑战。所以 PD 分离通常要求 Prefill 和 Decode 实例在同一个高速网络域内，最好是同机架甚至同节点。
2.3 实操中的参数计算与部署要点
假设我们要部署一个 70B 模型，输入平均 1500 token，输出平均 300 token，目标 QPS 是 50。我们来算一下 Prefill 和 Decode 的资源需求。
Prefill 侧：每个请求要处理 1500 token 的输入，70B 模型在 A100 上的 Prefill 吞吐大约是 3000 token/s（保守估计）。那么单个请求的 Prefill 耗时约 0.5 秒。要支撑 50 QPS，需要 25 个并发 Prefill 任务。如果单卡能同时跑 4 个 Prefill 任务（受显存限制），就需要 7 张 A100。
Decode 侧：每个请求要生成 300 token，70B 模型在 A100 上的 Decode 速度大约是 30 token/s（单请求）。那么单个请求的 Decode 耗时约 10 秒。要支撑 50 QPS，需要 500 个并发 Decode 任务。如果单卡能同时跑 50 个 Decode 任务（受 KV Cache 显存限制），就需要 10 张 A100。
所以整体需要 17 张 A100 左右，其中 7 张做 Prefill，10 张做 Decode。如果不做 PD 分离，混部的话，可能需要 25 张以上，因为两边互相干扰，利用率上不去。
注意：这个计算是简化版，实际还要考虑 batch 效率、网络延迟、KV Cache 传输开销。建议先用小规模压测验证，再线性放大。
部署时，我建议用 Kubernetes 或者类似的编排系统，把 Prefill 和 Decode 做成两个独立的 Deployment，各自配 HPA（水平自动扩缩容）。Prefill 的扩缩容指标看输入队列长度，Decode 的看输出队列长度。这样白天高峰自动扩容，晚上低谷自动缩容，进一步省钱。
2.4 我踩过的坑：KV Cache 传输成了瓶颈
我第一次做 PD 分离的时候，想当然地认为网络不是问题，结果压测时发现 Decode 实例经常等 KV Cache 等到超时。排查下来，问题是 Prefill 和 Decode 跨了机架，中间走的是普通万兆以太网，2GB 的 KV Cache 传过去要 1.6 秒，而 Decode 的首 token 延迟要求是 2 秒以内，几乎把预算吃光了。
后来改成同节点部署，Prefill 和 Decode 用 NVLink 通信，传输时间降到 0.1 秒以内，问题才解决。所以我的经验是：PD 分离可以跨机，但 KV Cache 传输必须走高速通道，否则省下来的算力钱全被网络延迟吃回去了。如果实在没有高速网络，可以考虑把 Prefill 和 Decode 放在同一台机器的不同 GPU 上，用 PCIe 或者 NVLink 通信，虽然扩缩容灵活性差一点，但至少延迟可控。
3. KV Cache 优化：显存就是金钱
3.1 KV Cache 为什么是显存杀手
KV Cache 是大模型推理绕不开的东西。每生成一个 token，模型都要用到之前所有 token 的 Key 和 Value 向量。如果每次都重新计算，计算量会随序列长度平方增长，完全不可接受。所以业界标准做法是把这些 KV 向量缓存下来，用空间换时间。
但问题是，KV Cache 的大小和序列长度成正比。一个 70B 模型，假设 80 层，每层 64 个头，每个头维度 128，那么每个 token 的 KV Cache 大小是：
2（K 和 V）× 80（层）× 64（头）× 128（维度）× 2（FP16 字节数）= 2.6 MB
如果序列长度是 4000 token，单个请求的 KV Cache 就是 10.4 GB。一张 A100 80GB 的卡，光 KV Cache 就吃掉 10GB，再加上模型权重（70B FP16 约 140GB，需要多卡分摊），留给并发的空间非常有限。
这就是为什么很多团队发现，模型明明能跑起来，但并发上不去。不是算力不够，是显存被 KV Cache 占满了。
3.2 量化：把 FP16 压到 INT8 甚至 INT4
最直接的 KV Cache 优化手段是量化。FP16 的 KV Cache 每个元素占 2 字节，如果压到 INT8，就只占 1 字节，显存直接减半。压到 INT4，再减半。
但 KV Cache 量化和权重量化不一样。权重是静态的，可以离线校准。KV Cache 是动态生成的，每个请求都不一样，量化误差会累积，影响输出质量。所以 KV Cache 量化要更小心。
我实测下来，INT8 的 KV Cache 量化对大多数模型的效果影响很小，困惑度上升不到 1%，基本可以接受。INT4 就有点激进了，某些模型会出现明显的重复和逻辑错误，需要针对性地校准。如果业务对输出质量要求极高，建议先用 INT8，观察一段时间再决定要不要上 INT4。
操作上，现在主流推理框架都支持 KV Cache 量化。比如在 vLLM 里，可以通过启动参数开启：
python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --kv-cache-dtype int8 \ --max-model-len 4096注意：KV Cache 量化需要框架和硬件的支持。有些国产卡对 INT8 的支持不完善，开启后可能反而变慢，一定要先压测。
3.3 分页与前缀共享：让显存利用率翻倍
除了量化，还有两个工程手段能大幅提升显存利用率：PagedAttention和前缀共享。
PagedAttention 的思路借鉴了操作系统的虚拟内存分页。传统的 KV Cache 是连续分配的，一个请求来了，就给它分配一块连续的显存，不管用不用得完。这会导致严重的显存碎片，实际利用率可能只有 50%。PagedAttention 把 KV Cache 切成固定大小的块（比如 16 个 token 一块），按需分配，不连续也没关系。这样显存利用率能提升到 90% 以上，同样的卡能跑更多并发。
前缀共享则是针对多轮对话场景。很多请求的 system prompt 是一样的，比如“你是一个专业的客服助手，请用友好的语气回答”。这段前缀的 KV Cache 完全可以复用，不需要每个请求都重新算一遍。vLLM 和 TGI 都支持自动前缀共享，开启后，多轮对话场景的 Prefill 计算量能减少 30% 到 50%。
这两个手段叠加起来，效果非常明显。我做过一个对比测试，同一个 70B 模型，同样的 A100 80GB 八卡机：
| 配置 | 最大并发 | 首 token 延迟 | 单 token 延迟 |
|---|---|---|---|
| 朴素部署 | 40 | 1.8s | 45ms |
| +PagedAttention | 75 | 1.5s | 38ms |
| +前缀共享 | 110 | 1.2s | 35ms |
| +INT8 KV 量化 | 160 | 1.1s | 33ms |
可以看到，光是这三项优化，并发就翻了四倍，相当于省了三台机器的钱。
3.4 实操心得：别把 max-model-len 设太大
很多人部署时喜欢把max-model-len设成模型支持的最大值，比如 32K 甚至 128K。这其实是个陷阱。max-model-len决定了框架预留的 KV Cache 空间，设得越大，预留越多，实际能并发的请求就越少。
我的建议是：根据业务实际需求设 max-model-len，不要盲目追大。如果 90% 的请求输入都在 2000 token 以内，那就设 4096，留一点余量就行。真遇到超长请求，可以单独走一个长文本实例池，不要让它拖累主池的并发。
另外，max-model-len和max-num-seqs要配合调。如果max-model-len设得大，max-num-seqs就要相应调小，否则显存会爆。这两个参数的关系是：
可用显存 ≈ 模型权重显存 + max-num-seqs × max-model-len × 单 token KV 大小
反过来推，给定显存和模型，就能算出最优的max-num-seqs。这个计算建议在部署前用脚本跑一遍，别拍脑袋。
4. 连续批处理与调度：让 GPU 一刻不停
4.1 静态批处理的浪费在哪里
早期推理服务用的是静态批处理：攒一批请求，一起送进 GPU，等这批全部跑完，再送下一批。这种方式的问题是，批次里最长的请求决定了整批的耗时。如果一批里有 10 个请求，9 个只要生成 50 token，1 个要生成 500 token，那 GPU 在生成完前 9 个之后，还要空等第 10 个跑完，算力大量闲置。
更糟糕的是，新来的请求必须等当前批次结束才能进来，排队延迟很高。在真实业务里，请求长度是高度不均匀的，静态批处理的 GPU 利用率通常只有 30% 到 40%。
4.2 连续批处理的原理与收益
连续批处理（Continuous Batching）的思路是：不等整批结束，只要有一个请求完成，就立刻把新请求塞进去。这样 GPU 的批次始终是满的，利用率能提升到 70% 以上。
具体实现上，框架会维护一个运行中的请求队列，每个请求有自己的 KV Cache 和生成状态。每一步 Decode 时，框架从队列里选出当前可以一起算的请求，组成一个动态批次。完成的请求移出队列，新请求加入队列。整个过程对用户透明，但吞吐提升非常明显。
我实测过一个 13B 模型，在同样的 A100 上：
- 静态批处理：吞吐 800 token/s，GPU 利用率 35%
- 连续批处理：吞吐 2200 token/s，GPU 利用率 78%
吞吐翻了近三倍，相当于同样的卡能服务三倍的流量。这个收益比很多硬件升级都划算。
4.3 调度策略的细节：优先级与抢占
连续批处理解决了吞吐问题，但引入了新的调度问题：当请求太多、显存不够时，该优先服务谁？
常见的调度策略有几种：
- FCFS（先来先服务）：简单公平，但长请求会阻塞短请求，导致短请求延迟飙升。
- 优先级调度：给不同业务线或用户等级设优先级，高优先级先服务。适合有 SLA 要求的场景。
- 最短剩余时间优先：优先服务预计生成 token 少的请求，能降低平均延迟，但可能导致长请求饿死。
- 抢占式调度：显存不够时，把低优先级的请求换出，腾出空间给高优先级。被换出的请求等资源够了再恢复。
我的经验是，大多数业务用“优先级 + 最短剩余时间”的组合就够了。高优先级的请求先服务，同优先级内短请求优先，这样既能保证重要业务的 SLA，又能压低整体平均延迟。抢占式调度实现复杂，除非业务差异极大，否则不建议上。
注意：抢占会导致被换出的请求重新计算 KV Cache，增加算力开销。如果抢占太频繁，反而会降低整体吞吐。建议设置抢占阈值，比如只有显存压力超过 90% 才触发。
4.4 实操配置示例
在 vLLM 里，连续批处理是默认开启的，但有几个参数需要调：
python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --max-num-seqs 256 \ --max-num-batched-tokens 8192 \ --scheduler-policy fcfs \ --enable-chunked-prefillmax-num-seqs：同时运行的最大请求数，根据显存调。max-num-batched-tokens：一个批次最多处理多少 token，调大能提升吞吐，但增加延迟。scheduler-policy：调度策略，vLLM 支持 fcfs 和 priority。enable-chunked-prefill：把长 Prefill 切成小块，和 Decode 交替执行，避免长请求阻塞短请求。
enable-chunked-prefill这个参数特别有用。默认情况下，一个长 Prefill 会独占 GPU 好几秒，期间所有 Decode 请求都得等。开启 chunked prefill 后，Prefill 被切成小块，每块之间插入 Decode，Decode 的延迟就不会被长 Prefill 拖累。实测下来，首 token 延迟能降低 40% 以上。
5. GPU 虚拟化与切分：小模型和低峰时段的省钱利器
5.1 为什么需要 GPU 切分
不是所有推理任务都需要一整张 A100。很多场景下，模型只有 7B 甚至 1B，一张 A100 跑这种模型，利用率可能只有 10%。还有些场景，白天高峰需要 10 张卡，晚上低谷只需要 2 张卡，但物理机是按月租的，没法退。
GPU 虚拟化和切分就是解决这个问题的。把一张物理卡切成多个虚拟实例，每个实例有独立的显存和算力配额，可以跑不同的模型或服务不同的业务线。这样小模型不用独占大卡，低峰时段也能把空闲算力利用起来。
5.2 主流切分方案对比
目前主流的 GPU 切分方案有几种：
| 方案 | 原理 | 隔离性 | 适用场景 |
|---|---|---|---|
| MIG（多实例 GPU） | 硬件级切分，把 GPU 分成多个独立实例 | 强，显存和算力硬隔离 | A100/H100 等高端卡，多租户 |
| Time-slicing | 时间片轮转，多个进程共享 GPU | 弱，显存不隔离 | 开发测试，低负载场景 |
| MPS（多进程服务） | 多个进程共享 GPU，但统一调度 | 中，算力可配比 | 小模型并发，推理服务 |
| 软件层切分 | 框架层限制显存和并发 | 弱，依赖框架 | 快速验证，成本敏感 |
MIG 的隔离性最好，但只有高端卡支持，而且切分粒度固定，比如 A100 80GB 可以切成 7 个 10GB 的实例，或者 3 个 20GB 的实例，不能随意切。Time-slicing 最灵活，但隔离性差，一个进程跑满，其他进程就得等。MPS 介于两者之间，适合推理场景。
我的建议是：如果卡支持 MIG，优先用 MIG，稳定可靠；如果不支持，用 MPS 做算力配比；Time-slicing 只适合测试环境，生产环境慎用。
5.3 切分后的性能损耗与注意事项
GPU 切分不是没有代价的。MIG 切分后，每个实例的显存带宽和 L2 缓存是共享的，如果多个实例同时跑高负载任务，会互相抢带宽，导致性能下降。实测下来，7 个 MIG 实例同时跑推理，单个实例的性能大约是独占时的 70% 到 80%。
所以切分适合的是低负载、多租户场景，不适合把一张卡切给多个高负载任务。如果每个任务都需要满血性能，那还是老老实实一卡一任务。
另外，切分后的实例在框架层要单独配置。比如用 MIG 切出 10GB 的实例，部署 7B 模型时，max-model-len和max-num-seqs都要相应调小，否则会 OOM。这个计算和前面 KV Cache 的算法一样，只是基数变成了切分后的显存。
5.4 实操：用 MIG 部署多模型服务
假设我们有一张 A100 80GB，要同时服务一个 13B 模型和一个 7B 模型。13B 模型 FP16 权重大约 26GB，7B 大约 14GB。我们可以这样切：
- 实例 1：40GB，跑 13B 模型，留 14GB 给 KV Cache。
- 实例 2：20GB，跑 7B 模型，留 6GB 给 KV Cache。
- 实例 3：20GB，备用或跑其他小模型。
创建 MIG 实例的命令（以 NVIDIA 为例）：
# 查看支持的 MIG 配置 nvidia-smi mig -lgip # 创建 GPU 实例 nvidia-smi mig -cgi 9,9,9 -C # 查看创建结果 nvidia-smi mig -lgi创建后，每个实例会有一个独立的 GPU UUID，在启动推理服务时指定对应的 UUID 即可。
注意：MIG 实例创建后，如果宿主机重启，配置可能会丢失，需要重新创建。建议把创建命令写成脚本，开机自动执行。
6. 模型量化与蒸馏：从源头降低算力需求
6.1 量化的两条路线：PTQ 和 QAT
模型量化是把 FP16 的权重和激活值压到 INT8 或 INT4，减少显存占用和算力需求。主要有两条路线：
PTQ（训练后量化）：模型训练完之后，用一小批校准数据统计激活值分布，然后直接量化。优点是简单快速，不需要重新训练。缺点是精度损失相对大，尤其是 INT4。
QAT（量化感知训练）：在训练过程中模拟量化误差，让模型学会适应量化。优点是精度保持好，INT4 也能做到接近 FP16 的效果。缺点是要重新训练，成本高。
对于大多数团队，我建议先试 PTQ。现在主流的 PTQ 工具，比如 GPTQ、AWQ，在 INT8 下基本无损，INT4 下也能做到困惑度上升不到 5%。如果 PTQ 效果不达标，再考虑 QAT。
6.2 INT8 和 INT4 的实际效果对比
我做过一组对比测试，用同一个 13B 模型，在不同量化精度下跑同样的测试集：
| 量化方式 | 显存占用 | 吞吐（token/s） | 困惑度 | 主观质量 |
|---|---|---|---|---|
| FP16 | 26GB | 1800 | 5.2 | 基准 |
| INT8 | 13GB | 3200 | 5.3 | 几乎无差异 |
| INT4 (GPTQ) | 7GB | 4500 | 5.6 | 轻微下降 |
| INT4 (AWQ) | 7GB | 4600 | 5.5 | 轻微下降 |
可以看到，INT8 几乎是无损的，显存减半，吞吐翻倍，性价比极高。INT4 显存再减半，吞吐再提升 40%，但质量有轻微下降。对于大多数业务，INT8 是首选，INT4 适合对成本极度敏感、对质量要求相对宽松的场景。
6.3 蒸馏：用小模型承接简单流量
量化是压缩同一个模型，蒸馏则是训练一个小模型来模仿大模型的行为。比如用 70B 模型蒸馏一个 7B 模型，让 7B 模型在特定任务上达到接近 70B 的效果。
蒸馏的收益非常直接：7B 模型的推理成本大约是 70B 的十分之一。如果业务里有大量简单请求，比如意图分类、简单问答，完全可以用蒸馏后的小模型承接，只把复杂请求路由给大模型。
操作上，蒸馏通常分两步：
- 生成蒸馏数据：用大模型对业务数据生成回答，作为小模型的训练目标。
- 训练小模型：用这些数据微调小模型，让它模仿大模型的输出分布。
我做过一个客服场景的蒸馏，用 70B 模型生成了 5 万条问答对，微调了一个 7B 模型。上线后，7B 模型承接了 70% 的流量，只有 30% 的复杂请求走 70B。整体推理成本下降了 60%，用户满意度基本没变。
注意：蒸馏数据要覆盖业务的真实分布，不能只用公开数据集。否则小模型在真实场景下会露馅。建议从线上日志里采样，保证数据多样性。
6.4 量化部署的实操步骤
以 GPTQ 量化为例，完整流程如下：
# 1. 安装依赖 # pip install auto-gptq transformers from transformers import AutoModelForCausalLM, AutoTokenizer from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig # 2. 加载原始模型 model_name = "meta-llama/Llama-2-13b-hf" tokenizer = AutoTokenizer.from_pretrained(model_name) # 3. 配置量化参数 quantize_config = BaseQuantizeConfig( bits=4, # 量化位数 group_size=128, # 分组大小 desc_act=False, # 是否按激活排序 ) # 4. 加载模型并量化 model = AutoGPTQForCausalLM.from_pretrained( model_name, quantize_config=quantize_config ) # 5. 准备校准数据 calibration_data = [ tokenizer(text, return_tensors="pt").input_ids for text in ["示例文本1", "示例文本2", "..."] ] # 6. 执行量化 model.quantize(calibration_data) # 7. 保存量化模型 model.save_quantized("./llama-2-13b-gptq-4bit") tokenizer.save_pretrained("./llama-2-13b-gptq-4bit")量化完成后，用 vLLM 或 TGI 加载量化模型即可。注意，量化后的模型不能再用 FP16 的方式加载，要指定--quantization gptq或--quantization awq。
7. 国产算力适配：从能用 to 好用
7.1 国产卡的现状与选型考量
国产算力卡这两年进步很快，在推理场景下已经具备一定的可用性。常见的选型考量包括：
- 显存容量：推理场景显存越大越好，因为 KV Cache 吃显存。目前国产卡主流是 32GB 和 64GB，部分型号有 80GB。
- 算力：FP16 算力是关键，直接影响 Prefill 速度。国产卡在这块和 A100 还有差距，但用于 Decode 阶段问题不大。
- 生态兼容：框架支持度、算子覆盖率、社区活跃度。这是国产卡最大的短板，很多模型和框架需要专门适配。
- 价格：国产卡的单价通常比同级别进口卡低 30% 到 50%，这是最大的优势。
我的建议是：不要把国产卡当成 A100 的完全替代，而是当成补充算力。把 Decode 阶段、小模型、低优先级业务放到国产卡上，Prefill 和高优先级业务留在进口卡上。这样既能享受国产卡的价格优势，又不会因为生态问题影响核心业务。
7.2 适配过程中的常见坑
国产卡适配最大的坑是算子不支持。大模型推理涉及大量自定义算子，比如 FlashAttention、PagedAttention、Rotary Embedding 等。进口卡有 CUDA 生态，这些算子都有现成实现。国产卡往往需要自己写或者等厂商提供。
我遇到过的情况是，某个国产卡不支持 FlashAttention，导致注意力计算慢了三倍。后来厂商提供了适配版本，性能才追上来。所以选国产卡时，一定要问清楚：主流推理框架支持吗？常用算子有实现吗？有没有成功案例？
另一个坑是精度问题。有些国产卡的 FP16 实现和 NVIDIA 有细微差异，导致模型输出不稳定。这个问题在 INT8 量化后更明显。建议在正式上线前，用业务数据做一轮对比测试，确保输出质量达标。
7.3 国产卡上的部署实操
以某国产卡为例，部署流程大致如下：
# 1. 安装厂商提供的驱动和工具包 # 具体命令参考厂商文档 # 2. 安装适配的推理框架 # 通常是厂商维护的 vLLM 或 TGI 分支 pip install vllm-xxx # 厂商定制版 # 3. 转换模型格式 # 有些国产卡需要把模型转成特定格式 python convert_model.py --input /path/to/model --output /path/to/converted # 4. 启动推理服务 python -m vllm.entrypoints.openai.api_server \ --model /path/to/converted \ --device xxx \ --max-num-seqs 128注意：国产卡的部署命令和 NVIDIA 不完全一样，一定要看厂商的文档。有些参数是厂商特有的，比如设备指定方式、显存管理策略等。
7.4 混合部署：进口卡和国产卡怎么分工
混合部署的核心原则是按阶段分工：
- Prefill 阶段：对算力要求高，对生态要求也高（需要 FlashAttention 等优化），建议放在进口卡上。
- Decode 阶段：对显存带宽要求高，对算力要求相对低，可以放在国产卡上。
- 小模型和蒸馏模型：算力需求低，国产卡完全能胜任。
- 低优先级业务：可以容忍一定的延迟波动，适合国产卡。
这样分工后，整体成本能下降 30% 到 40%，同时核心业务的稳定性不受影响。
调度上，可以用一个统一的网关层做路由。根据请求类型、优先级、当前负载，决定走进口卡池还是国产卡池。网关层要支持动态权重调整，比如国产卡池负载低时，多分一些流量过去；负载高时，自动切回进口卡。
8. 六条手段的组合拳与效果复盘
8.1 不同规模团队的选择建议
这六条手段不是每个团队都要全上，要根据自己的规模和阶段来选：
| 团队规模 | 推荐组合 | 预期成本下降 |
|---|---|---|
| 初创团队（1-5 卡） | KV Cache 量化 + 连续批处理 | 40%-50% |
| 成长团队（5-20 卡） | 上述 + PD 分离 + 模型量化 | 50%-65% |
| 成熟团队（20+ 卡） | 上述 + GPU 切分 + 国产算力 | 60%-75% |
初创团队资源有限，优先做软件层优化，见效快、成本低。成长团队可以开始做架构拆分，PD 分离和模型量化是重点。成熟团队要考虑硬件层面的优化，GPU 切分和国产算力能进一步压成本。
8.2 优化顺序：先软后硬，先易后难
我的建议是先软后硬，先易后难。具体顺序：
- 连续批处理：框架默认支持，改个参数就行，收益立竿见影。
- KV Cache 量化：改个启动参数，显存减半，风险可控。
- 前缀共享：多轮对话场景收益大，配置简单。
- 模型量化：需要离线处理，但一次量化长期受益。
- PD 分离：架构改动大，需要压测验证，但收益显著。
- GPU 切分：涉及硬件配置，适合多模型场景。
- 国产算力：生态适配成本高，适合有专门团队的情况。
这个顺序的逻辑是：先做改动小、收益大的，快速看到效果，建立信心；再做改动大、收益大的，逐步深入。不要一上来就搞 PD 分离和国产卡，容易踩坑，打击士气。
8.3 效果监控与持续优化
优化不是一次性的，上线后要持续监控。关键指标包括：
- GPU 利用率：目标 70% 以上，低于 50% 说明有优化空间。
- 首 token 延迟：反映 Prefill 性能，目标根据业务定，通常 2 秒以内。
- 单 token 延迟：反映 Decode 性能，目标 50ms 以内。
- 显存利用率：目标 80% 到 90%，太低浪费，太高容易 OOM。
- 每千 token 成本：最终的成本指标，要持续跟踪。
建议做一个监控看板，把这些指标可视化。每周复盘一次，看有没有异常波动，有没有进一步优化的空间。
8.4 我个人的经验体会
做了这么多优化，我最大的体会是：推理成本优化没有银弹，靠的是一点一点抠。每项优化可能只带来 10% 到 20% 的提升，但六项叠加起来，就是几倍的差距。
另外，不要为了优化而优化。有些团队为了追求极致的成本，把模型量化到 INT4，结果输出质量下降，用户投诉增加，反而得不偿失。优化的前提是保证业务质量，在这个基础上再谈成本。
最后，压测是王道。任何优化上线前，都要用真实业务数据压测。我见过太多案例，实验室里效果很好，一上生产就崩。原因往往是真实请求的分布和测试集不一样，长尾请求把优化后的系统打爆了。所以，压测数据一定要从线上采样，覆盖各种边界情况。
这个领域变化很快，新的优化手段层出不穷。保持学习，保持压测，保持对成本的敏感，就能在这个竞争激烈的市场里活下来。
