大模型算力成本治理：从容量估算到推理降本实践

美国AI巨头大手笔发债扩张资源新闻里最抓眼球的是发债规模和对近2万亿美元表外风险的担忧。对做AI工程和模型部署的团队来说这则消息并不是遥远的宏观叙事而是一面镜子当模型参数规模扩大、推理请求量上升GPU采购和云资源账单同样会以惊人的速度膨胀。真正危险的不是今天花掉的钱而是那些当前没有体现在账单里、等到扩容或月底结算时才会出现的“成本炸弹”——未规划的GPU配额、不加限制的Token调用、没有监控的推理服务、只为验证想法而保留的高配实例。这篇文章把这类问题落到工程实操层面。会先分析大模型算力成本来自哪里再给出上线前容量估算、推理链路降本、成本观测和预算治理的具体做法最后整理一套从“成本异常现象”反推根因的排查链路。适合已经在做模型部署、AI应用开发或AI Agent服务的工程师也适合准备从Demo进入生产环境的技术负责人。1. AI算力成本不是“买显卡”而是一整套资源账单大模型项目投入的不仅是模型权重还有训练任务、推理服务、评测任务、数据预处理、日志采集、可观测系统和偶尔被忘记的实验环境。理解成本结构才能判断该从哪里降本。1.1 训练、推理、实验三种负载的成本结构完全不同训练阶段的主要开销是GPU集群持续占用。一个大模型的训练通常持续数天到数周期间节点故障、数据加载变慢、通信瓶颈都会让有效算力利用率下降。训练任务结束后集群下线成本停止但失败重跑会让同样的费用翻倍。推理阶段的开销是持续且与流量成正比的。每一次用户请求都会触发模型前向计算而且请求到达时间随机。为了保障延迟目标推理服务需要预留足够GPU和服务副本即使没有请求副本也在产生固定费用。更麻烦的是推理负载通常在白天高、凌晨低如果集群无法动态缩容低峰成本会白白浪费。实验和评测阶段最容易被忽略。工程师开发Prompt、调超参数、做数据清洗、跑Agent链路时往往随手开一个带GPU的容器用完忘记销毁。多人并行实验时这类“影子资源”甚至能超过正式训练开销。成本治理的第一步就是把这三类负载拆开看分别设置独立预算和生命周期。1.2 表外风险在工程里的对应物看不到的资源请求和隐藏配额新闻里提到的表外负债指企业当前没有列入资产负债表但未来需要真金白银支付的承诺。工程团队内部同样存在大量类似的“成本盲区”团队成员申请了一台16卡GPU开发机实际只跑了一个小批量验证机器闲置率超过90%但月底统一计费Kubernetes集群里某个Model服务没有配置资源上限突发流量到来时把节点内存打满触发整机驱逐其他应用跟着受影响云厂商开通了按需GPU实例但多个项目共用同一个账号没有拆分标签月底看到一张大账单无法区分是训练还是推理花掉的费用模型服务已接入降级方案但在代码里没有关闭旧版本Pod旧版请求仍源源不断产生双重Token费用。这些成本不会在功能开发时暴露却在账单分析时集中“引爆”。工程化的目标就是把隐形成本变成可观测、可归因、可回收的指标。1.3 成本估算为什么经常失准不少团队做容量规划只根据模型参数量和单次请求预估显存忽略了三个变量上下文长度、并发度和Token实际生成量。上下文越长KV Cache占用线性增长并发越高需要保存的推理中间状态越多流式对话中每个请求反复携带历史消息Token数不是用户输入一句话就结束而是完整消息拼包后的长度。只按峰值显存买机器却没有按吞吐量设计副本数最终要么GPU空闲浪费要么服务超时频繁。下面是理解成本结构的参考框架负载类型主要资源成本特征典型计费模式降本重点训练任务大规模GPU集群短期极高时间依赖性强按占用时长、按节点规格检查点恢复、通信优化、失败自动重试推理服务GPU 内存 网络持续发生随流量波动按实例、按Token、按并发动态批处理、量化、弹性伸缩实验评测GPU、CPU、存储离散且容易失控按实例时长自动销毁、配额限制、共享环境实际项目中更推荐按“资源占用时长 × 单价”来估算而不是只算某次请求需要多少显存。只有把时间维度纳入成本模型才接近真实账单。2. 上线前先做容量估算把预算写进需求在写业务代码前先回答“一次请求需要多少GPU算力、每秒能处理多少请求、并发上来后需要多少副本”。这一步没有做好后面所有降本手段都只是修补。2.1 先从参数规模和结构推导显存与吞吐预期模型加载本身需要权重显存推理过程中还需要保存中间激活值当请求数增加时KV Cache会占用大量额外显存。下面这段Python代码用于做工程估算不追求精确值只帮助团队在选型前对齐量级。def estimate_inference_memory_gb( params_b: float, hidden_size: int, layers: int, seq_len: int, batch_size: int, kv_heads: int 8, head_dim: int 128, bytes_per_param: int 2, ) - dict: weights_gb params_b * 1e9 * bytes_per_param / (1024 ** 3) kv_per_token_bytes 2 * layers * kv_heads * head_dim * bytes_per_param kv_cache_gb kv_per_token_bytes * seq_len * batch_size / (1024 ** 3) # 激活内存按前向过程粗略估算实际还受张量并行、序列并行等因素影响 activation_gb ( hidden_size * layers * batch_size * seq_len * 2 * bytes_per_param / (1024 ** 3) ) return { weights_gb: round(weights_gb, 1), kv_cache_gb: round(kv_cache_gb, 1), activation_gb: round(activation_gb, 1), rough_total_gb: round(weights_gb kv_cache_gb activation_gb, 1), }以一个70B模型、序列长度4096、batch_size为8、hidden_size为8192、80层、8个KV头为例运行python estimate_memory.py输出大致为weights_gb: 130.2 kv_cache_gb: 3.9 activation_gb: 9.8 rough_total_gb: 143.9这里并没有考虑计算图多余内存、CUDA context、框架额外预留所以生产中实际显存占用会略高于粗略值。重点是确认结论单张80GB显卡无法直接承载一个70B模型必须用多卡张量并行或量化。2.2 用压测修正容量模型显存估算只解决了“放不放得下”没有解决“跑得快不快”。通过压测采集三个核心指标吞吐量每秒完成的请求数或生成的Token数TTFTTime To First Token从发出请求到第一个Token返回的延迟TPOTTime Per Output Token后续每个输出Token的平均间隔时间。压测时先固定一份典型Prompt把输入长度定在业务常见长度再逐步提高并发。记录不同并发下的GPU利用率、排队时间和Token输出速度。只有当GPU利用率稳定在较高水平且延迟达标时当前副本配置才是合理的。2.3 成本预算表示例容量估算结果可以汇成一张成本预算表作为资源申请和后续治理的依据。项目请求量/日输入Token/请求输出Token/请求并发峰值推理副本数单副本GPU预估月成本参考币种在线客服Agent50万1200300804A100 40GB中文档摘要服务10万4000500202A100 80GB较高内部代码助手100万300080020012H100 80GB很高这类数据上线前就应该明确。等账单出来再反推“为什么花了这么多”往往已经错过了控制窗口。2.4 三个容量规划常见坑这里的坑在真实项目中反复出现。第一只按模型参数选卡没有考虑KV Cache和并发。70B模型理论上可以被INT8量化到单卡承载但并发一旦上升到几十路KV Cache会迅速占满显存导致OOM或频繁回收。第二把压测并发等同于生产并发忽略流量突发。压测是持续稳定压生产流量是忽高忽低如果只用平均值配置副本数流量尖峰时服务必然超时。第三没有设计缩容策略。为了应对白天的峰值申请了大量GPU夜间却继续保留同样副本成本直接翻倍。3. 推理链路降本从模型层、服务层到计费层算力永远存在瓶颈但模型部署团队可以通过多个层次的优化让同样的GPU处理更多业务请求。3.1 模型层量化、蒸馏和路由是最直接的杠杆量化是最常用手段。把权重从FP16降到INT8或INT4显存占用减少推理速度提升。代价是精度可能下降。对于一般内容生成、摘要、分类场景影响通常可控对于数学、代码、推理任务需要先跑评测集确认。蒸馏是训练一个更小模型去模仿大模型输出。小模型推理快、占用少适合高频低复杂度请求。路由层则可以在请求进入模型前判断简单问题走小模型复杂问题走大模型。实现时可以用一个分类模型或规则层完成路由。3.2 服务层连续批处理、投机解码和结果缓存传统批处理会等一批请求全部到齐再执行导致第一个请求等待时间长。连续批处理机制会动态插入新请求请求结束后立即释放资源给下一批能显著提高GPU吞吐。投机解码用一个小模型快速起草多个后续Token大模型并行验证。验证通过后一次接受多个Token解码步数减少端到端延迟下降。这套机制对解码节奏稳定的大模型效果较好但需要额外部署草稿模型会增加显存开销要在收益和成本之间做压测。结果缓存的收益更直接。会话级问答对个性化要求很高不适合缓存但FAQ、商品知识库、摘要等请求可以按模型版本和目标文本的向量指纹缓存结果。Cache命中后不再调用模型Token成本和延迟都归零。3.3 资源编排给Pod设置合理的request和limit在Kubernetes部署推理服务时很多团队只设置GPU实例规格却不配置CPU和内存的request与limit。这样调度器无法准确分配节点资源极端情况下会出现同节点多个推理Pod争抢CPU导致推理延迟上升。下面是一个基础Deployment资源片段实际项目需要按压测结果调整resources: requests: cpu: 8 memory: 64Gi nvidia.com/gpu: 1 limits: cpu: 12 memory: 80Gi nvidia.com/gpu: 1设置GPU limit是为了让Pod在调度时绑定到一张GPU卡。设置CPU request是为了让调度器为该Pod预留节点CPU设置memory和CPU的limit是为了避免业务异常时打爆节点。这里的数值应该来自压测不应照抄。推理服务如果支持无状态水平扩展还可以加HPA。以下HPA按Pod内的排队指标扩缩容目标平均排队值超过5时扩容apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: llm-inference-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: llm-inference minReplicas: 2 maxReplicas: 10 metrics: - type: Pods pods: metric: name: llm_queue_depth target: type: AverageValue averageValue: 5这个配置依赖Prometheus Adapter将llm_queue_depth指标暴露给HPA。如果没有配套指标链路HPA不会生效。3.4 计费模式怎么选不同业务的流量特征决定了不同的计费策略。场景推荐计费方式原因稳定流量推理服务预留实例或包年包月单价更低避免价格波动突发实验或短时评测任务抢占式实例成本低但实例可能被回收开发测试环境定时开关机或共享GPU池不需要24小时运行成本敏感且允许延迟的批量任务排队执行、错峰运行利用低峰价格减少峰值带宽压力需要注意用抢占式实例跑推理服务时要做好容灾。实例被回收后应由Kubernetes快速补副本且应用启动时间不能过长否则会在回收瞬间出现服务不可用。4. 建立成本观测体系比账单早一步发现问题没有观测的成本治理等于盲人摸象。成本观测不能只在月底看账单而要把Token消耗、GPU利用率、服务副本数、业务调用量变成实时指标。4.1 先统一资源标签和业务成本归属一切成本数据都需要归属维度。在Kubernetes中给命名空间打标签在云资源上给实例打标签在应用日志中记录模型名、业务线、用户分组。推荐最少包含以下标签team负责团队project所属项目service服务名environmentdev、test、prodmodel_name实际调用的模型feature业务功能如agent_chat、doc_summary。只有做到资源归属清晰月底才能把账单分摊到具体团队否则成本优化会议会变成互相推诿。4.2 用拦截器记录Token用量和调用成本以大模型应用服务为例。调用入口通常只关心Prompt和返回结果但如果顺手把模型名称、Token用量、业务标签写入监控指标就能为后续成本分析提供核心数据。下面代码展示的是记录逻辑的核心思路。因为Spring AI的API在不同版本中有调整实际实现需要按依赖版本调整具体方法签名Component public class LlmCostRecorder { private final MeterRegistry meterRegistry; public LlmCostRecorder(MeterRegistry meterRegistry) { this.meterRegistry meterRegistry; } public void record(String model, String tenant, int promptTokens, int completionTokens) { int totalTokens promptTokens completionTokens; meterRegistry.counter( llm_token_total, model, model, tenant, tenant ).increment(totalTokens); // 按模型单价估算成本单价由配置中心维护 double cost estimateCost(model, promptTokens, completionTokens); meterRegistry.counter( llm_cost_usd, model, model, tenant, tenant ).increment(cost); } private double estimateCost(String model, int promptTokens, int completionTokens) { // 例如: 按输入Token和输出Token不同单价计算 return 0.0; } }调用路径正确接入后Prometheus会定期采集llm_token_total和llm_cost_usd指标。这样每次Agent多轮对话消耗了多少Token都能按租户和模型拆分。如果使用了Spring AI的ChatModel可以在调用返回的响应中读取TokenUsage再调用上面的record方法。注意不要在每个业务代码里塞埋点最好封装一个公共的调用服务或AOP切面否则埋点逻辑会污染业务。4.3 成本告警、配额和预算治理监控指标到位后需要设置告警。下面这条PromQL统计最近5分钟内各服务和模型的Token新增速率sum(rate(llm_token_total[5m])) by (model, tenant)告警规则可以按业务预期设定。比如某个租户1小时Token增长超过100万或者某服务的成本估算超过设定阈值就触发告警。Prometheus告警规则示例groups: - name: llm-cost-alerts rules: - alert: HighLlmTokenUsage expr: sum(increase(llm_token_total[1h])) by (tenant, model) 1000000 for: 10m labels: severity: warning annotations: summary: 租户 {{ $labels.tenant }} 在模型 {{ $labels.model }} 上的Token消耗过高指标和告警只是第一步真正的治理还需要“配额-审批-回收”机制每个项目设置月度Token或成本配额超阈值的增量需求需要申请说明理由非生产环境配额用完后自动暂停而不是继续扣费。5. 降本不能降智用评测和灰度守住效果底线成本优化容易走向另一个极端量化后回答错误率升高路由后复杂问题被错误分给小模型缓存命中后返回过期结果。成本可以降但模型质量必须通过线上数据证明没有回退。5.1 离线评测先跑稳定指标每次模型替换前至少准备一份覆盖主要业务场景的评测集。常见指标包括是否包含正确答案、格式是否合法、关键实体是否完整、有害内容是否被拦截。评测集必须包含边界用例超长文本、多轮对话、空输入、高难度数学题等。离线评测结果差异在可接受范围内才允许上线灰度。如果用量化模型还要用与生产相同格式的请求测试避免离线用FP16、线上用了量化后表现不一致。5.2 在线对比需要A/B分流和日志跟踪线上灰度阶段把部分流量切到新模型或新优化版本与旧版本同时运行。每条请求记录模型版本、业务结果、Token消耗、耗时和用户是否明确给出负面反馈。对比不能只看Token成本还要看单位成本对应多少有效业务产出。例如新版本成本降低30%但对话被用户手动终止率上升10%整体收益可能是负数。5.3 模型发布前检查清单模型或推理管线变更不是简单替换权重了事。发布前可以按这张表检查检查项操作评测集结果新模型在关键场景是否达到旧模型基线异常输入空输入、超长输入、多模态非法输入是否处理成本评估单位请求价格与时延是否与预算一致灰度策略是否配置可回滚的流量分流监控告警是否已有Token、延迟、错误率告警缓存策略缓存键是否包含模型版本避免新旧模型结果串用配额保护是否限制了单账号调用频次和Token上限6. 成本失控排查链路先看现象再查资源最后回到计费当系统出现成本异常或资源紧张不要凭直觉重启服务。按照现象定位根因能节省大量时间。6.1 从四个高频现象反推根因问题现象常见原因检查方式处理建议账单金额突然翻倍新增高并发调用或某个服务未限制副本数查看各服务副本数、Token总量、调用方来源定位高消耗服务下调配额或改用路由策略GPU利用率低但延迟高模型配置过大或批处理未生效查看GPU利用率、请求排队长度、批处理日志启用动态批处理调小batch或升级模型推理框架模型输出变慢且成本升高KV Cache缓存未命中率过高或超长文本重复发送查看平均输入Token长度、缓存命中率压缩历史消息、做文本摘要、增加结果缓存多个应用互相挤占资源Pod未设置CPU/内存request与limit查看kubectl describe pod中的资源字段为所有工作负载补齐资源声明适当调整副本数6.2 排查顺序和关键命令按优先级从资源层向应用层推进看节点资源kubectl top nodes确认CPU、内存、GPU是否被打满。看Pod资源kubectl top pods -n namespace找出资源占用最高的Pod。看Pod调度状态kubectl describe pod pod-name确认是否因资源不足Pending或Evicted。看应用转发指标查询Prometheus中llm_token_total、llm_cost_usd、http_server_requests_seconds_count等指标。看调用方流量分析调用日志或网关数据确认是否有异常重试、爬虫流量或未授权调用。对Spring AI这类应用如果在链路中加入请求ID和Token用量字段可以到日志平台按请求ID纵向展开一次调用的完整链路判断是模型单次调用贵还是调用次数异常多。6.3 预防机制与兜底策略发现问题后要同时做止损和预防在网关或业务入口加入限流单用户QPS、单租户Token上限都应有配额对非生产命名空间执行定时缩容夜间关闭开发测试环境需要时再拉起在推理框架层配置最大批量大小和超时时间避免积压导致雪崩为训练任务设置健康检查和自动失败恢复防止死机后GPU空转费用继续累积。7. 工程化收尾把成本治理变成日常能力一个AI模型服务的成本问题单靠“少调用几次模型”解决不了。需要在每个环节建立机制。7.1 最小成本治理启动清单如果项目刚刚开始不必一次做完全部工作。可以先从下面清单入手[ ] 给所有工作负载打上团队、项目、环境标签[ ] 所有训练和评测任务设置最大超时时间和自动清理时间[ ] 推理服务补齐CPU和内存的request与limit[ ] 部署指标采集记录Token消耗和推理延迟[ ] 按项目和模型分别设置月度成本预算与告警[ ] 对模型替换和量化设置评测基线与A/B灰度流程[ ] 每周查看一次成本账单和GPU利用率报告。7.2 预算驱动的团队协作方式成本治理不应该只由运维或财务驱动。推荐由模型负责人、平台工程和业务开发共同维护一份“成本预算与用量周报”。周报包含三个部分上周总成本与预算对比、成本最高的TOP 10服务或调用方列表、每个高成本项对应的优化动作。优化动作要落到具体人例如“下周把文档摘要服务切换到INT8量化并重新压测”。7.3 值得继续深入的方向如果已经完成了基础的成本观测下一步可以从三个方向继续深入推理框架优化调研vLLM、TensorRT-LLM、SGLang等框架的连续批处理和PagedAttention实现理解不同框架在长上下文、高并发下的差异。Agent成本建模在AI Agent场景里一次业务需求可能触发几十次工具调用和多轮模型推断必须在Agent层面建立“一次业务成功目标消耗多少Token”的单位经济模型。容量与调度一体化把GPU资源池化结合训练、推理、评测任务的不同优先级实现混部调度让空闲资源在任务之间流转。回到开头的问题外部AI巨头通过发债扩张基础设施建设新闻关注的是资产负债表上的风险对工程团队而言真正的“表外负担”是那些看不见的资源碎片、没有配额限制的Token调用和无人维护的实验集群。把这些成本变成实时指标把每一次模型调用纳入预算治理把每次优化都压到评测线上团队才能在算力成本波动中掌握主动权。