Agent 上线前，先把推理账算清楚

上周四，一个做电商客服 Agent 的团队在群里晒了新到的服务器：两台 8 卡 L20，总价逼近 40 万。

他们原本以为，这套机器能撑住日均 50 万次对话。上线第三天，结果有点尴尬：GPU 利用率没超过 15%，P99 延迟却冲到 3 秒以上。财务总监只在群里回了一句：

把机器退了，先给我一份推理算力账单。

这句话现在很现实。

虎嗅最近在一篇文章里提到，AI 行业正在告别“烧钱造梦”的阶段，开始低头算账。Agent 被塞进微信对话框、电脑桌面和企业业务流之后，模型 API 调用量暴涨，大厂终于看到了按 Token 收费的稳定生意。但用户也开始变得挑剔：看起来聪明、会写几句漂亮话的通用模型，很难再让企业 CXO 直接掏预算。来源：虎嗅

《科创板日报》6 月 6 日的报道也给了类似判断：AI 基础设施需求正在从单一训练算力，扩展到训练、推理、Neocloud、企业部署和数据中心建设共同驱动的长期资本开支周期。报道同时提到，算力成本、商业价值度量、垂直场景适配，都是 Agent 规模化落地前绕不开的门槛。来源：财联社

对小团队来说，问题往往不是“卡够不够”，而是没人先把推理账拆开看。

推理账单不是训练账单

训练像一次大额采购，烧完一轮至少知道钱花在哪里。推理更像水电费，每天都在走，每条链路都可能多出一截成本。

一个电商客服 Agent，用户只问一句“我的订单到哪了”，后台可能已经跑了几步：意图识别、参数提取、RAG 检索、工具调用、API 结果总结、最终回复。用户看到的是一条回答，账单上记的是整条调用链。

当前稿件中的测试环境是两台配置相同的 A100-80G，推理框架为 vLLM v0.6.3，BF16 精度，场景是多工具调用 Agent，包含意图分类、参数提取、API 调用结果总结三个环节。

这里的“单次对话”，不是用户在前端看到的一问一答，而是 Agent 完成任务时消耗的 Token 总量。

按日均 10 万次对话算，只看推理 API 成本，Llama 3-70B 每月约 7,080 美元，Qwen 2.5-72B 约 5,760 美元。如果使用按 Token 计费的云端 API，还要考虑平台侧的溢价。

这也是很多团队第一次踩坑的地方：产品经理按“对话次数”估算成本，工程侧实际付的是“Token × 调用次数 × 并发波动”的钱。

自建便宜不便宜，要看利用率

开头那个团队的两台 8 卡 L20，理论上看起来很充足。按原稿测算，vLLM 部署 Llama 3-70B 时，单卡在 BF16 下可稳定承载 14 个并发请求，两台机器理论并发能到 224。

但他们的业务流量并不平滑。

上午 10 点到 11 点、下午 3 点到 5 点是高峰，其他时间请求量明显回落。结果是，GPU 在大部分时间里吃不饱；但服务器折旧、电费、托管、运维不会因为低峰暂停计费。

原账本是这样算的：

• 两台 8 卡 L20 服务器采购成本约 38 万元，按 3 年折旧，每月硬件成本约 10,556 元；
• 机房托管和电费，每台每月约 2,500 元，两台 5,000 元；
• 兼职运维人力分摊约 3,000 元/月。

固定支出合计 18,556 元/月。

如果日均处理 8 万次对话，单次对话推理成本折算约 0.0077 元。表面看，这比云端 API 便宜。按 Qwen 2.5-72B 每百万 Token 约 $0.48、单次对话 3,800 Token 估算，云端单次约 0.013 元。

但这个结论有前提：GPU 利用率要撑得起来。

一旦利用率长期停在 15% 左右，折旧、电费、托管费会被摊到更少的请求上，单次推理成本可能超过 0.03 元。也就是说，机器已经买了，单次成本反而比云端更贵。

这类亏损通常不是出在采购价，而是出在采购逻辑：按峰值并发买硬件，再按全天平均流量消化成本。

先让推理服务能伸缩

这个团队后来没有继续加机器，也没有完全退回云端 API，而是在推理服务层做了弹性调度。

架构是 Kubernetes + KEDA（Kubernetes Event-driven Autoscaling），核心目标很朴素：高峰时多拉起推理实例，低峰时缩回去，别让 GPU 长时间空转。

模型先预热，不要每次临时加载

70B 级模型的权重很大。Llama 3-70B 权重约 140GB，如果每次 Pod 启动后再从存储拉取和加载，冷启动会非常明显。

原方案把模型权重打入镜像，或通过共享内存挂载点预热到 /tmp/model。打包后镜像约 145GB，推送到私有 Harbor 仓库。这样做不优雅，但对低延迟推理服务很实用。

用请求队列触发扩缩容

KEDA 监控 vLLM 暴露的 /metrics，抓取 vllm:num_requests_running 指标。排队请求超过 5 个时扩容，低于 2 个时缩容。测试中设置最小副本数 1，最大副本数 8，对应 8 张 GPU。

minReplicaCount: 1
maxReplicaCount: 8
pollingInterval: 15
triggers:
  - type: prometheus
    metadata:
      serverAddress: http://vllm-metrics:8000
      metricName: vllm_num_requests_running
      threshold: '5'

这个阈值不应该照抄。客服、办公助理、代码 Agent 的输入长度和工具调用次数差异很大，最好用自己的 Trace 数据压一轮。

留一个预热池，别让用户等模型启动

大模型推理最怕冷启动。原稿中的 70B 模型 Pod，从调度到 Ready 通常需要 90 到 120 秒。对客服场景来说，两分钟已经足够让用户重复点击、反复追问，账单也会被重试请求继续放大。

改造时设置了 standbyPoolSize: 2，保留两个已经加载模型、但暂时不接流量的预热 Pod。扩容触发后，预热 Pod 可在 10 秒内接管请求。

这会占用一部分 GPU，但比高峰时临时加载模型更可控。

竞价实例只能放在边缘位置

如果底层用云服务器，例如阿里云 ECS，可以把缩容阈值以下的弹性 Pod 放到竞价实例上，常驻 Pod 和预热 Pod 放在更稳定的实例上。

原方案里还配置了 PodDisruptionBudget 和 terminationGracePeriodSeconds: 120，尽量在实例被回收前排空请求。竞价实例便宜，但不能把核心流量全部压上去。

改造后的账本

同一个电商客服 Agent，日均 8 万次对话，弹性调度前后的基础设施成本如下：

账面变化很直接：固定支出从 18,556 元降到 7,420 元，P99 延迟也从 2.8 秒降到 2.4 秒。

真正有用的不是“容器化”这个词，而是两个动作：把闲置卡数降下来，把冷启动风险提前处理掉。

买机器前，先问供应商三个问题

如果最后还是要自建推理集群，签采购单前至少问清楚三件事。

第一，显存带宽是多少？

推理场景经常卡在显存带宽，而不只是 FLOPS。CSDN 智能体开发者社区一篇关于 AI Agent 算力需求的文章提到，英伟达 Blackwell Ultra（GB300）采用 12 层 HBM3e，内存容量 288GB、带宽 8TB/s；其 NVL72 超节点架构运行 DeepSeekR1 模型时，token 生成速度可达 1000 个/秒，较前代提升 10 倍。来源：CSDN 智能体开发者社区

这类参数至少说明一件事：只看 TFLOPS 很容易误判推理能力。Agent 是长链路、多轮次、多工具调用场景，显存、带宽、KV Cache 管理都会影响最终吞吐。

第二，并发上限是实验室数据还是生产数据？

很多并发测试是在固定输入长度、无工具调用、请求分布均匀的条件下跑出来的。真实 Agent 不这么工作。用户可能粘贴一段物流信息，也可能连续追问；工具调用返回的数据长度也不稳定。

采购前最好拿自己的 Trace 数据压测，不要只看供应商 PPT 上的峰值数字。

第三，缩容后模型重加载多久？

如果回答是“看情况”，就要谨慎。推理服务可以扩缩容，但大模型加载时间不可控的话，高峰期会直接变成排队。

至少要问清楚：是否支持模型预热，是否能保留 standby Pod，扩容到可接流量需要多少秒。

账单失控，常常不是卡太少

很多团队看到 Agent 慢，第一反应是加卡。但月度账单冲高时，真正该先查的通常是这些地方：死循环重试、上下文膨胀、多 Agent 无效转发、工具调用重复、Prompt 太长。

硬件采购也是同一套逻辑。问题被简单归因成“算力不够”，预算就会先流向机器；但账单上的损耗，可能藏在推理框架配置、调用链设计和流量调度里。

华尔街见闻援引巴克莱 3 月研报称，现有 AI 算力似乎足以支持大规模 Agent 部署，低推理成本对 Agent 产品盈利至关重要。来源：华尔街见闻

另一边，算力价格也在变化。21 经济网报道，3 月 18 日，阿里云官网宣布因全球 AI 需求爆发、供应链成本上涨，将对 AI 算力、CPFS 等服务价格进行调整；几乎同一时间，百度智能云也发布了 AI 算力产品服务价格上调公告。来源：21 经济网

所以，Agent 上线前别急着问“买几张卡”。更该先问：一次任务到底消耗多少 Token，峰谷流量差多少，GPU 会空转多久，冷启动要不要用户买单。

机器会发出风扇声，账单不会。可最后决定项目能不能跑下去的，往往是后者。