1. 大模型推理成本为什么突然成了生死线1.1 从能跑通到跑得起的转折点去年这个时候大家聊大模型推理话题还停留在怎么把模型部署起来显存够不够装下权重。今年画风完全变了我接触的团队十个里有八个在问同一个问题单次推理成本怎么压下来。这个转变不是偶然的。原因很直接。模型参数从7B涨到70B再到几百B单次请求的算力消耗翻了几十倍用户量从内测几百人涨到日活几十万QPS压力上来了而最要命的是推理是持续性支出——训练是一次性投入推理是每天每时每刻都在烧钱。我见过一个中等规模的对话产品上线三个月后推理账单超过了训练成本的总和团队直接被迫做架构重构。所以现在讨论推理成本优化不是锦上添花是生死存亡。这篇文章我想把过去一年多踩过的坑、验证过的方案系统梳理一遍从PD分离到国产算力一共六条落地手段每条都讲清楚原理、适用场景和实操细节。1.2 成本到底花在哪先算清楚账再谈优化优化之前必须知道钱花在哪。大模型推理的成本结构大致分四块成本项占比典型值主要影响因素GPU算力租用/折旧55%-70%卡型、利用率、并发策略显存占用带来的卡数15%-25%模型大小、KV Cache、批处理网络与存储5%-10%跨节点通信、模型加载运维与调度5%-10%集群管理、弹性伸缩看这张表就明白了算力和显存占了八成以上。所以所有优化手段本质上都在做两件事要么让同样的卡干更多的活提升利用率要么让同样的活少占卡降低资源需求。后面讲的六条手段你都可以往这两个筐里归。提示先跑一周的监控把prefill和decode的耗时、GPU利用率、显存峰值、batch size分布都拉出来。没有数据支撑的优化都是瞎猜我见过太多团队上来就换框架结果瓶颈根本不在那。2. 第一条手段PD分离把两种截然不同的负载拆开2.1 为什么prefill和decode必须分开这是我认为性价比最高的一条优化也是最容易被忽视的。要理解它先得搞清楚大模型推理的两个阶段在干什么。Prefill阶段预填充把用户输入的整段prompt一次性喂进去计算所有token的KV Cache。这个阶段是计算密集型矩阵乘法拉满GPU算力单元吃得很饱但显存带宽用得少。Decode阶段解码一个token一个token往外吐每生成一个token都要读取全部KV Cache。这个阶段是访存密集型算力单元大量闲置瓶颈在显存带宽。问题来了如果这两个阶段跑在同一张卡上会发生什么prefill来的时候算力打满decode的请求就得排队decode在跑的时候算力闲着prefill又插不进来。两种负载互相干扰GPU利用率经常卡在30%-40%上不去。PD分离的核心思路就是用不同的机器分别跑prefill和decode各干各的。prefill集群专门堆算力decode集群专门优化显存带宽和并发。中间通过KV Cache的传输把两个阶段串起来。2.2 PD分离的实操架构与KV Cache传输落地PD分离架构上大概是这个链路请求进来先到调度器Router调度器把prompt发给prefill节点prefill节点算完KV Cache把Cache传给对应的decode节点decode节点拿着Cache逐token生成流式返回这里最关键的技术点是KV Cache怎么传。KV Cache体积不小一个70B模型、8K上下文单请求的KV Cache能到几个GB。传输方案主要有三种RDMA直传延迟最低但需要专门的网络硬件成本高共享存储中转prefill写、decode读实现简单但有额外延迟P2P显存直传通过NVLink或类似高速互联适合同机架部署我实测下来中小规模集群用共享存储中转就够了延迟增加在可接受范围内大规模集群上RDMA的收益才明显。注意PD分离不是银弹。如果你的请求prompt都很短比如平均几十个tokenprefill占比很小分离的收益有限反而增加了传输开销。prompt长度超过500token、decode输出较长的场景PD分离收益最明显。2.3 PD分离的配比计算与调优经验prefill节点和decode节点的数量配比是PD分离调优的核心。配比错了要么prefill排队要么decode闲置。一个粗略的计算方法统计一段时间内prefill总耗时和decode总耗时的比值。假设prefill总耗时是decode的1/3那prefill节点数大致是decode的1/3还要考虑单卡性能差异。但实际中这个比值是动态的所以更推荐弹性配比用统一的资源池根据实时负载动态调整prefill和decode的实例数。我见过做得好的团队白天decode压力大就多分decode实例晚上批量任务多就多分prefill实例整体利用率能到70%以上。踩过的坑早期我们固定配比结果高峰期decode严重排队prefill却闲着。后来改成按队列长度动态调度问题才解决。PD分离一定要配动态调度静态配比只适合负载非常稳定的场景。3. 第二条手段KV Cache优化省显存就是省钱3.1 KV Cache为什么是显存杀手KV Cache这个东西理解它就能理解大模型推理一半的成本。简单说decode阶段每生成一个token都要用到之前所有token的Key和Value向量这些向量必须存在显存里随时读取。序列越长Cache越大。算笔账一个70B模型假设32层、64个注意力头、head dim 128用FP16存储。单个token的KV Cache大小是 2K和V× 32层 × 64头 × 128 × 2字节 约1MB。听起来不大但8K上下文就是8GB一个请求8GB一张80G的卡光KV Cache就只能放不到10个并发请求。这就是为什么长上下文场景显存爆炸。KV Cache优化直接决定了你能塞多少并发也就直接决定了单位成本。3.2 四种KV Cache压缩手段对比手段原理压缩比精度损失实现难度量化FP16→INT8/INT4降低存储精度2-4倍小到中低分页管理PagedAttention按块分配消除碎片1.5-2倍有效容量无中稀疏化/淘汰丢弃不重要的token2-5倍中到大高多头共享MQA/GQA多查询头共享KV4-8倍小需改模型我的建议是组合使用PagedAttention打底几乎无损失必做加上INT8量化损失可控如果模型支持GQA那更好。稀疏化要谨慎我见过为了省显存把关键上下文丢了的回答质量断崖式下跌。3.3 PagedAttention的落地细节PagedAttention是现在主流推理框架的标配思路借鉴了操作系统的虚拟内存分页。传统KV Cache要求连续显存一个长序列就得占一大块连续空间碎片严重。PagedAttention把Cache切成固定大小的block物理上不连续逻辑上通过页表映射。落地时要注意几个参数block size一般16或32个token一块。太小页表开销大太大碎片多。16是常用值。GPU显存预留给Cache的比例一般留70%-80%给KV Cache剩下的给模型权重和中间激活。最大并发数根据Cache总量和平均序列长度反推。实测下来PagedAttention能把有效并发提升50%以上而且几乎不影响输出质量属于闭眼上的优化。实操心得开启PagedAttention后一定要监控block的利用率。如果发现大量block只填了一半说明block size设大了或者序列长度分布很分散可以调小block size。4. 第三条手段批处理与连续批处理榨干每一分算力4.1 静态批处理的致命缺陷早期推理服务用静态批处理攒一批请求一起送进模型等这批全部生成完再返回。问题很明显——短请求被长请求拖死。一个请求要生成10个token另一个要生成500个静态批处理下前者得等后者全部完成GPU在等长请求的时候大量闲置。这个缺陷在真实场景里是致命的因为用户请求长度分布极不均匀。我统计过一个对话产品输出长度从几个token到上千token都有静态批处理下GPU利用率经常掉到20%以下。4.2 连续批处理的调度逻辑连续批处理Continuous Batching解决了这个问题。核心思想是不等整批完成任何一个请求生成结束就立刻把它踢出去腾出的位置马上塞新请求进来。这样GPU永远在处理当前还活着的请求利用率大幅提升。调度逻辑大致是维护一个运行队列和一个等待队列每生成一个token检查哪些请求已经结束遇到结束符或达到长度上限结束的请求移出等待队列的请求补进来每步都对当前所有活跃请求做一次前向这个机制让GPU的batch size始终保持在较高水平实测吞吐能提升2-5倍。4.3 批处理调优的关键参数连续批处理有几个参数直接影响效果最大batch size受显存限制要结合KV Cache占用算。设太大容易OOM设太小浪费算力。调度粒度每步调度还是每几步调度。每步调度最灵活但开销大实际中每步调度是主流。抢占策略显存不够时是拒绝新请求还是抢占老请求。一般优先拒绝新请求避免影响已开始的生成。我踩过的一个坑早期把最大batch size设得很大结果长请求一多就OOM服务直接崩。后来改成动态batch size根据当前显存余量实时调整稳定性好了很多。批处理参数一定要留安全余量宁可少塞几个请求也别让服务挂掉。5. 第四条手段GPU虚拟化与算力切分提升小模型利用率5.1 什么场景需要GPU虚拟化不是所有推理任务都需要一整张卡。很多场景下模型小、并发低一张卡跑一个实例利用率极低。比如7B以下的小模型单卡能跑好几个实例低频调用的专用模型一天没几个请求开发和测试环境不需要独占整卡这时候GPU虚拟化就派上用场了。它把一张物理卡切成多个虚拟实例每个实例独立跑一个模型或服务把闲置的算力利用起来。5.2 算力切分的两种路线GPU虚拟化主要有两条技术路线时间片切分多个实例分时复用同一张卡类似CPU的时间片轮转。实现简单但延迟不稳定适合对延迟不敏感的场景。空间切分MIG等把GPU的SM、显存等硬件资源物理隔离成多个实例。隔离性好、延迟稳定但切分粒度受硬件限制且需要特定卡型支持。路线隔离性延迟稳定性硬件要求适用场景时间片切分弱差低测试、低频任务空间切分强好高生产、多租户我的经验是生产环境优先空间切分测试环境时间片切分够用。空间切分虽然硬件要求高但隔离性带来的稳定性在生产环境太重要了一个实例出问题不会影响其他实例。5.3 虚拟化的成本账怎么算虚拟化不是免费的它本身有开销。切分后每个实例的算力有损耗显存也有管理开销。所以要不要上虚拟化得算账假设一张卡租用成本是X元/小时跑一个大模型利用率60%那有效成本是X/0.6。如果切成4个小实例每个利用率80%总利用率可能到85%有效成本降到X/0.85。利用率提升带来的收益要大于切分本身的开销才值得做。我见过反面案例为了虚拟化而虚拟化把一个大模型硬切成几份结果通信开销和调度开销把收益全吃掉了。虚拟化适合小模型和多租户大模型单实例跑满更划算。6. 第五条手段模型量化与蒸馏从源头减少计算量6.1 量化用精度换成本量化是最直接的降本手段——把模型权重和计算从FP16降到INT8甚至INT4显存占用和算力需求都大幅下降。INT8量化通常能省一半显存INT4能省到四分之一。但量化有精度损失关键是怎么把损失控制在可接受范围。现在主流的量化方法有训练后量化PTQ直接对训练好的模型量化简单快速但精度损失相对大量化感知训练QAT训练时就模拟量化精度保持好但需要重新训练GPTQ/AWQ等针对大模型的专门量化算法精度和速度平衡得不错我的建议优先试GPTQ或AWQ这类专门算法PTQ作为快速验证手段。实测下来70B模型用INT4量化在大多数任务上精度损失在1-2个百分点内但成本直接砍到四分之一非常划算。6.2 蒸馏让小模型干大模型的活蒸馏的思路是用大模型教师的输出训练小模型学生让小模型在特定任务上逼近大模型的效果。推理时只跑小模型成本自然低。蒸馏的关键是任务要聚焦。通用蒸馏很难小模型学不会大模型的全部能力。但如果你的场景是固定的比如只做意图分类、只做摘要那蒸馏效果会很好。我见过一个团队把70B的摘要能力蒸馏到7B模型上效果达到原模型的95%成本降到十分之一。注意蒸馏需要大量高质量的教师输出数据数据准备成本不低。而且蒸馏出的小模型泛化能力弱场景一变可能就得重新蒸。蒸馏适合场景稳定、量大的业务。6.3 量化与蒸馏的组合策略这两条手段可以组合。常见做法是先蒸馏出小模型再对小模型量化。这样既减小了模型规模又降低了单次计算精度双重降本。但要注意量化和蒸馏的误差会叠加。蒸馏本身有精度损失量化再加一层可能就超出可接受范围了。所以组合使用时每一环的精度损失都要留余量最后做端到端的质量评估。7. 第六条手段国产算力适配把成本结构彻底改写7.1 为什么国产算力值得认真考虑前面五条都是在用同样的卡前提下优化国产算力是换一个成本结构。当前高端算力卡供应紧张、价格高企而国产算力卡在政策支持和产能爬坡下性价比优势越来越明显。从成本角度看国产卡的单卡算力可能不如顶级卡但单位算力成本往往更低而且供应稳定。对于推理这种对绝对性能要求没那么极致、但对成本极度敏感的场景国产算力是很有竞争力的选项。7.2 国产算力适配的实操难点适配国产算力不是换个卡就完事难点主要在软件栈算子库差异不同厂商的算子库接口不同模型代码要改框架支持主流推理框架对国产卡的适配程度参差不齐精度对齐同样的模型不同硬件上数值精度可能有差异要重新验证性能调优国产卡的性能特性不同原来的调优参数不一定适用我的实操建议是分阶段迁移先跑通一个简单模型验证链路再迁移核心模型最后做性能调优。不要一上来就全量迁移容易踩坑踩到怀疑人生。7.3 混合算力调度不把鸡蛋放一个篮子最稳妥的方案是混合算力一部分跑在国产卡上一部分跑在原有卡上通过统一调度层做流量分配。这样既能享受国产算力的成本优势又能保证供应稳定性和峰值弹性。调度层要做的关键决策是哪些请求走国产卡哪些走原有卡。一般按模型和SLA分对延迟敏感的核心业务走原有卡对成本敏感的批量业务走国产卡。我见过做得好的团队用这套混合方案把整体推理成本压了40%以上。维度国产算力原有算力混合策略单位成本低高按业务分层供应稳定性好紧张互为备份生态成熟度追赶中成熟核心业务用成熟生态性能中高高峰值弹性用高性能8. 六条手段怎么组合一份可落地的优先级清单8.1 按投入产出比排序六条手段不是并列的有先后。按我的经验投入产出比从高到低大致是连续批处理改动小、收益大几乎必做PagedAttention框架自带开启即用KV Cache量化收益明显实现不难PD分离收益大但架构改动大适合中大规模模型量化/蒸馏从源头降本但需要模型侧配合国产算力适配成本结构改写但迁移成本高建议从1、2、3开始这三条基本不需要改架构几天就能见效。等这些吃透了再考虑PD分离和国产算力这种大动作。8.2 不同规模团队的选择小团队日请求10万重点做连续批处理KV Cache优化用云上弹性算力别自己搞集群中团队日请求10万-100万加上PD分离和模型量化考虑混合算力大团队日请求100万六条全上自建集群国产算力精细化调度8.3 一个真实的优化案例复盘最后分享一个我参与过的案例。某对话产品优化前单次推理成本约0.02元日请求50万日成本1万元。优化过程第一步上连续批处理PagedAttention成本降到0.012元日成本6000元第二步KV Cache INT8量化降到0.009元日成本4500元第三步PD分离降到0.007元日成本3500元第四步部分流量迁到国产算力降到0.005元日成本2500元整体降本75%而且响应质量没有明显下降。这个案例说明六条手段组合起来效果是叠加的。实操心得优化是个持续过程不是一锤子买卖。每次优化后都要重新监控、重新找瓶颈。我见过团队优化一轮就停了结果新瓶颈出现后成本又涨回去。建立成本监控看板把单位推理成本作为核心指标持续跟踪这比任何单次优化都重要。8.4 几个容易踩的坑最后列几个我踩过或见过的坑帮你省点时间只优化不监控没有基线数据优化效果无法量化容易自嗨过度追求极致压缩把精度压到临界点线上流量一波动就出问题忽视长尾请求平均值好看但P99延迟爆炸用户体验崩盘一次性大改所有优化一起上出问题不知道是哪个引起的要小步快跑忽略运维成本架构越复杂运维越重省下的算力钱可能被运维人力吃掉我个人在实际操作中的体会是推理成本优化七分靠工程三分靠算法。大部分收益来自把现有资源用得更充分而不是换更牛的模型或硬件。把连续批处理、KV Cache、PD分离这些工程手段做扎实成本自然就下来了。国产算力是锦上添花但前提是你的软件栈已经足够高效否则换什么卡都是浪费。