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 tokenKV 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 token70B 模型在 A100 上的 Decode 速度大约是 30 token/s单请求。那么单个请求的 Decode 耗时约 10 秒。要支撑 50 QPS需要 500 个并发 Decode 任务。如果单卡能同时跑 50 个 Decode 任务受 KV Cache 显存限制就需要 10 张 A100。所以整体需要 17 张 A100 左右其中 7 张做 Prefill10 张做 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 大小是2K 和 V× 80层× 64头× 128维度× 2FP16 字节数 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 延迟朴素部署401.8s45msPagedAttention751.5s38ms前缀共享1101.2s35msINT8 KV 量化1601.1s33ms可以看到光是这三项优化并发就翻了四倍相当于省了三台机器的钱。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 token1 个要生成 500 token那 GPU 在生成完前 9 个之后还要空等第 10 个跑完算力大量闲置。更糟糕的是新来的请求必须等当前批次结束才能进来排队延迟很高。在真实业务里请求长度是高度不均匀的静态批处理的 GPU 利用率通常只有 30% 到 40%。4.2 连续批处理的原理与收益连续批处理Continuous Batching的思路是不等整批结束只要有一个请求完成就立刻把新请求塞进去。这样 GPU 的批次始终是满的利用率能提升到 70% 以上。具体实现上框架会维护一个运行中的请求队列每个请求有自己的 KV Cache 和生成状态。每一步 Decode 时框架从队列里选出当前可以一起算的请求组成一个动态批次。完成的请求移出队列新请求加入队列。整个过程对用户透明但吞吐提升非常明显。我实测过一个 13B 模型在同样的 A100 上静态批处理吞吐 800 token/sGPU 利用率 35%连续批处理吞吐 2200 token/sGPU 利用率 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 被切成小块每块之间插入 DecodeDecode 的延迟就不会被长 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 权重大约 26GB7B 大约 14GB。我们可以这样切实例 140GB跑 13B 模型留 14GB 给 KV Cache。实例 220GB跑 7B 模型留 6GB 给 KV Cache。实例 320GB备用或跑其他小模型。创建 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困惑度主观质量FP1626GB18005.2基准INT813GB32005.3几乎无差异INT4 (GPTQ)7GB45005.6轻微下降INT4 (AWQ)7GB46005.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( bits4, # 量化位数 group_size128, # 分组大小 desc_actFalse, # 是否按激活排序 ) # 4. 加载模型并量化 model AutoGPTQForCausalLM.from_pretrained( model_name, quantize_configquantize_config ) # 5. 准备校准数据 calibration_data [ tokenizer(text, return_tensorspt).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结果输出质量下降用户投诉增加反而得不偿失。优化的前提是保证业务质量在这个基础上再谈成本。最后压测是王道。任何优化上线前都要用真实业务数据压测。我见过太多案例实验室里效果很好一上生产就崩。原因往往是真实请求的分布和测试集不一样长尾请求把优化后的系统打爆了。所以压测数据一定要从线上采样覆盖各种边界情况。这个领域变化很快新的优化手段层出不穷。保持学习保持压测保持对成本的敏感就能在这个竞争激烈的市场里活下来。
