AI架构评审算力成本优化：从Token成本到弹性调度的五个省钱技巧

1. 找了好久的成本窟窿，最后发现卡不是问题

先讲一次真实的评审经历。上个月我参加一个AI应用系统的架构评审，业务方报了一个相当吓人的算力预算，理由是“chat类功能并发高、模型大、需要稳定响应”。会上大家围绕需要多少张卡、要不要预留几十T的存储、弹性策略怎么做吵了两个多小时，最后发现预算里最贵的一项不是模型服务本身，而是某个数据预处理模块每5分钟全量跑一次向量化。每次都把整库重算，单次消耗的token量抵得上几万次用户问答。

这类问题在架构评审中太常见了。大家一提到算力成本，本能反应就是“卡贵、集群贵、IDC贵”，但真正让成本失控的往往是架构层的隐性浪费：重复计算、上下文膨胀、架构分层不匹配、算力资源与场景负载特征错配。所以我才想把这几年的评审经验整理出来，挑出5个在架构评审阶段就能用、并且能直接砍钱的技巧。

这篇文章主要写给三类人看：一是要负责系统架构方案评审的技术负责人，二是AI产品线的研发负责人，三是背算力成本指标的平台或infra团队。如果你只是刚开始接触AI系统，也能从中理解算力成本是怎么被“算”出来的，而不是被“感觉”出来的。

先说一个我在大量评审中反复确认过的现象：成本失控的架构，通常不是贵在“推理”本身，而是贵在那些看不见的设计选择里。后文的五个技巧，本质上是把“算力开支”从一个总数字，拆成可以逐项审计、逐项优化的工程设计问题。

2. 技巧一：把每张加速卡的成本翻译成“单Token成本”，让评审有共同语言

架构评审会上最容易出现的争吵，是业务方说“我要上大模型，需要高性能计算资源”，平台方说“你们这个业务用不着那么大的卡，太浪费了”。两边不在一个维度上说话，最后只能按一个拍脑袋的倍数互相妥协。要打破这种僵局，我会先在评审会上把账本换成同一个单位：单Token成本。

2.1 一张卡一个小时的算力，到底值多少钱

先普及一个概念：芯片厂商在宣传时习惯给标量性能，但在大模型场景里，真正决定系统吞吐的是模型推理引擎在特定并发、特定序列长度下的有效输出速度，单位通常是token/s。而你要评估的成本，核心就是让这个token/s和账号上的账单建立连接。

我自己习惯按这个公式来估算：

单Token成本 = 单卡每小时成本 ÷（单卡有效吞吐token/s × 3600秒）

举个例子。假设你在云上租了一张当前主流的商用推理加速卡，按量计费一小时假设是35元，实际跑某个中等规模模型时，推理引擎在稳定并发下能做到平均单卡产出1600 token/s。那么：

• 单卡一小时产出约 1600 × 3600 = 576万token
• 单Token成本约 35 ÷ 5760000 ≈ 0.000006元/Token

如果一次用户请求平均输入600 token、输出220 token，单次交互消耗约820 token，那么理论上单次成本大约是 0.005 元。听着很低对不对？但你再往下算一层：如果这个对话系统每天100万次调用，每天成本就约5000元，一个月就是15万元。加上非高峰期的闲置、每轮对话携带的历史上下文膨胀、失败重试，真实成本很容易翻到账面上的2到3倍。

2.2 把架构拆成“会算账”的模块

有了单Token成本这个标尺，评审时就不再看“整系统需要几张卡”，而是让方案负责人把架构拆开，每一层说明自己消耗token的链路。我通常要求按照这么几个模块报数：

• 用户请求预处理模块：改写、翻译、意图识别，是否调大模型，每次消耗多少token
• 主对话引擎：System、上下文、工具调用分别占多少token
• RAG检索模块：Query改写几次，召回的文档片段需要多少token才能拼进上下文
• 后处理与审核模块：是否每次都调用模型做摘要、标签、质量判断
• 异步批处理任务：离线任务多久跑一次，一次全量还是增量，用的是什么模型

有一次评审一个客服机器人，业务方坚持说模型调用量不大。按上述模块一拆，发现这个系统每收到一条用户消息，平均要产生6次模型调用：句子改写一次、向量化一次、回复生成一次、答案合规性判断一次、情绪安抚文案增强一次、话术质检一次。单次调用看着都便宜，但乘上6，再加上上下文越长模型算得越慢这个放大器，成本就非常可观了。那次的优化方向之一，就是把质检从大模型调用改成规则加小模型，成本瞬间砍掉了将近三分之一。

所以这个技巧的重点不在“算得准”，而在“把成本责任落实到架构模块”。只要每个模块的负责人能报出自己这部分大概消耗多少token、产出多少业务价值，评审会就有了可以讨论的锚点，而不是停留在“感觉贵”和“感觉不贵”之间。

3. 技巧二：算力选型不追顶配，按场景特征匹配推理引擎和卡型

很多技术团队在选型时，会下意识地把“参数量越大越需要大卡”理解为“所有AI模型都应该上最强卡”。我评审过的一个问答系统就是典型，业务本身只是一个垂直领域FAQ，模型参数不大，但方案里为了“保证未来扩展性”，一口气下单了一批顶配卡。这种浪费其实是算力支出里最大的一块隐性漏损。

3.1 不同任务对算力资源的诉求差异极大

把大模型拆开看，形态大致有几种：离线训练、在线推理、Embedding向量化、精调与小规模验证、批处理标注。它们的负载特征完全不同：

• 在线推理：对延迟敏感，需要尽可能压满吞吐的连续混合请求，且存在波峰波谷。
• 离线训练：对吞吐要求高，通信带宽和并行效率决定成本，不用太关心单次延迟。
• Embedding/向量化服务：模型很小，计算密度低，带宽瓶颈往往在数据加载和网络。
• 精调与小规模实验：不追求实时，很多时候用空闲资源就能跑。

这些任务对硬件的要求不一样。一个很常见的错配，是把离线向量化任务也放到高性能推理集群上跑。这种任务本来就不在乎一两秒的延迟，完全可以用低规格节点做错峰批处理。同一批任务换一个资源池，账单能差出好几倍，性能上用户还毫无感知。

3.2 先量化模型负载，再决定用多大资源

那评审时怎么判断方案方的选型有没有拍脑袋？我会让方案方按下面几个参数走一遍，再决定用什么档位的算力：

• 模型参数量与量化方式：是否支持INT8/INT4，精度变化能不能被业务接受
• 推理batch特性：请求是天然可批处理，还是零散的交互式请求
• 延迟容忍度：SLA要求是首字200ms，还是整体5秒可接受
• 并发模型与吞吐要求：平均QPS多少、峰值多少、峰值持续多久
• 是否需要上下文越长越强：长上下文对显存和attention计算的影响比想象中大

如果模型是6B~13B级别，且业务对于首token时延要求不高，那张主流消费级甚至中端推理卡做量化部署都可以扛住比较可观的QPS。没有必要所有模型都上满血顶配集群。我在实践里见过最极端的例子，是一个导购推荐模型用了顶配卡，但实测请求量每天只有几百次。那相当于每天花几千块租了一辆重卡运一瓶水。

3.3 推理引擎选型也会左右算力开销

同样一张卡，跑的推理引擎不一样，产出token的吞吐可以差出一大截。评审时我会专门问一句：方案里用的是哪个推理框架，有没有开显存优化、有没有做连续批处理。很多自研方案从训练框架直接套过来做推理，连续批处理和显存管理没做，吞吐可能只有成熟推理引擎的几分之一。这就导致一个很尴尬的局面：卡没有少买，但有效产出非常低。

有个对照可以感受下差异。同一个模型，在一个优化到位的推理引擎上能做到平均单卡1500 token/s；换成一个没做连续批处理的PyTorch原生态推理，吞吐可能掉到300~400 token/s。单位token成本直接差到4倍以上。架构评审不只是盯卡的数量，也要评审“同一张卡被榨出了多少汁”。

所以我在评审时的原则是：先问业务目标与负载特征，再谈卡型配比。再让性能团队给出目标模型在不同推理引擎、不同并发下的实测数据，最后再落到采购或扩容方案上。把“采购评审”变成“性能工程评审”，这部分节省通常比调代码更立竿见影。

4. 技巧三：上下文长度是隐蔽的算力放大器，务必在评审时逐项审计

如果说选型和模型分流是“看得见的成本”，那么上下文长度就是“看不见的水下冰山”。大模型在生成阶段，计算复杂度与序列长度不是线性关系，而是接近二次方增长。上下文越长，显存占用越高，每次推理的实际耗时和单位成本也随之上涨。最典型的表现是：你加进去几千字的产品文档作为系统提示，每次对话都要原样计算一遍，用户可能根本没问那部分内容。

4.1 你是怎么把单次成本悄悄放大十倍的

我们算一笔账。同样一个模型，单卡在256 token短上下文的情况下能做到2000 token/s的输出。但如果系统Prompt写得很长，每轮还要把历史聊天记录、业务数据库里检索到的几十个字段、多轮工具返回结果全塞进上下文，序列长度轻松破4000。此时，生成速度可能掉到四五百token/s，单卡吞吐直接降为原来的四分之一。打个比方，基座模型处理长上下文时，每增加一个token，所有已有的token都要重新“看一眼”，相当于一次会议多进一个人，在座所有人都得重新自我介绍一遍。

有个具体的评审案例我印象很深。某企业内部知识库助手，System Prompt里放了一万多字的制度说明，表面上是为了让模型“更懂业务”。实际上模型每次回答问题，都要先把这一万多字从头到尾算一遍。哪怕用户只问“会议室怎么订”，光读取这段超长Prompt的算力消耗就已经超过生成回答本身。后来我们把静态内容改造为按需检索注入，只把与问题相关的一两条制度拼进上下文，Prompt长度从一万多字降到几百字，用户实测回答质量几乎没有下降，但单次请求成本降了一个数量级，接口响应也明显变快。

4.2 在评审方案里逼出“上下文预算表”

我建议评审时要求每个方案附带一张上下文预算表，说清楚四个问题：

• System Prompt基线多长：是固定文案，还是动态注入
• 每轮用户输入平均多长、峰值多长
• 历史对话保留几轮：全部保留还是做摘要压缩
• 工具结果与RAG片段最大拼多少字符

然后定一个硬约束：单轮模型输入的总token上限。比如一个客服系统可以约定用户问题加关键上下文不超过1500 token，超过部分优先丢弃最不相关的历史消息，而不是让系统无限把内容往窗口里塞。模型不是仓库，不是塞进去的东西越多它就越聪明，多塞的那部分全都要变成账单。

4.3 优先把常驻上下文搬出模型窗口

作为评审委员，我还会鼓励业务方把“信息传递”和“语义计算”分开。很多信息本质上是状态数据或业务字段，不需要让模型逐字计算。业务系统有结构化状态，直接查库返回；要喂给模型的只是提炼后的摘要或按需检索的一段原文。这么做不仅能省算力，还能降低模型被无关信息干扰的概率，效果往往比把整库灌进Prompt更稳定。

另外有一点值得在评审清单里固化下来：所有多轮对话系统都要有上下文压缩机制。常见做法是历史消息超过N轮后，用上一轮模型输出里的Summary字段替换原始消息；或者只保留最近几轮原文，更早内容格式化为一句话摘要。这算是一个基础设计，而不是进阶优化。很多系统上线几个月后成本失控，回头一查就是这里没做。

5. 技巧四：把重复计算当负债，用缓存、增量和幂等设计降低“无用算力”

第三个技巧讲的是“喂给模型的上下文太多”，第四个技巧则要聊一种更隐蔽的浪费——同一个结果被反复计算。我见过不止一个系统的算力支出，大头不是用户触发的推理，而是内部定时任务一遍遍地把同样的事情重新做一遍。评审时如果没人追问任务触发机制，这类浪费可以平平稳稳地跑几个月，直到账单突破某个让人血压升高的数字。

5.1 先分清哪些计算是必要算力，哪些是重复无用算力

“算力”这个词听起来越底层越值钱，但站在系统设计角度，可以把算力分成三类：

• 必要算力：用户请求或业务目标直接触发的模型推理，如一个AI写作用户点了一次生成。
• 可复用算力：同样的输入在短时间窗口内会再次出现，结果可以直接复用，不需要重新推理。比如同为某个报告生成摘要，前一个用户刚生成过，另一个用户请求相同输入就能命中缓存。
• 无效重复算力：定时任务做全量重算、批次任务重复向量化、同一份文档被多个服务各自展开处理。这类成本几乎可以视为纯浪费。

在评审中我会系统性地扫描三个高危点：全量定时任务、重复向量化、缺少缓存层的同步调用链路。

5.2 缓存不是只有Redis，还要有“语义缓存”

普通缓存大家都会做，但AI系统里除了精确键值缓存，还有一个性价比极高的东西叫语义缓存。对于RAG问答、文档处理这类场景，很多时候用户问的问题字面不一样，但语义完全一样。比如“报销流程是什么”和“怎么走报销”表达完全不同，检索后送入模型的内容和答案却可以高度相似。如果向量化后能在向量库里按相似度阈值先命中缓存，直接返回上一次的结果，就能省下一次完整的RAG检索加模型生成。在重复咨询率很高的客服、内部问答、售前引导场景，语义缓存的命中率常常能做到三成以上，这是相当可观的一块算力节省。

我在评审时给方案方定的建议是：对结果稳定性要求不高的场景用语义缓存，如果业务敏感度要求每次答案新鲜，可以给缓存结果打上时间戳，超过有效期就必须重新生成。

5.3 定时任务优先做增量而不是全量

另一个常见问题是数据预处理链路里的全量计算。很多团队的方案逻辑很简单直接：“每5分钟把库里所有文档重新向量化一遍”，理由是代码好写、不怕漏数据。但一旦库里的文档量上来，这个任务会成为整个系统最大的算力吞金兽。

评审时我建议把每一个“每隔X分钟执行一次全量任务”都单独拎出来问：能不能改成增量？能不能用事件触发？能不能用版本号或更新时间的标记跳过没变化的数据？向量化一个短文档可能只要几十token，但全库几百万篇文档，每5分钟跑一次，成本是灾难性的。同样的需求，改成只处理变更文档的调度器，资源消耗能降到原来的1%，效果上没有区别。

另外，批处理任务还应该考虑幂等。所谓幂等，就是同一份数据无论被任务处理多少次，结果都一样，不会因为重跑而产生额外副作用。很多系统的失败重试机制写得粗糙，任务挂了就全量重来，期间模型调用翻倍。如果任务本身幂等，重试只需要从失败断点继续。

6. 技巧五：别按“峰值性能”买断算力，按真实流量曲线做弹性调度和混部

最后一个技巧其实已经超出了单次评审的范畴，但它必须在架构评审阶段就定下基调，否则后面很难改。核心是一句话：系统消耗的算力应该是真实流量的函数，而不是方案PPT里那个“峰值QPS乘资源系数”的常数。

6.1 你的系统是真的需要那么多卡，还是只有高峰期需要

我见过一个AI绘图类平台，业务流量一天之内大概是典型的“双驼峰”：上午10点到12点、晚上8点到11点是高峰，凌晨基本没什么人。但架构方案是按峰值需求预留常驻资源，低谷时段整夜开着几十张卡空转。这个浪费有多少？如果一天中只有6小时是真正的高峰，按24小时连续计费，至少有接近一半的算力费用是付给了闲置。

要解决这个问题，架构评审时我会重点看方案方有没有提供下面这些数据：

• 过去一段时间的实际请求分布，而不是只报一个平均值或峰值
• 是否已经按“在线推理集群”和“离线任务集群”做了资源池拆分
• 是否有根据负载扩缩容的配套设计，包括节点池的最小副本数
• 是否有能力把非实时任务调度到低谷时段执行

只要方案里没有扩容策略，或者扩容策略是“直接静态配置翻倍”，那就要在评审会上把这部分打回去补充。空转资源是购买算力之后最直接的资金漏损，完全可以通过调度策略减轻。

6.2 把离线任务挪到“算力菜市场”的折扣时段

如果把算力比作电力系统，实时推理是“必保生活用电”，那离线训练、批量数据分析、文档向量化、定时评测这类工作就是“可以错峰的工业用电”。评测、批量生成、数据清洗这类任务对时间不敏感，完全可以推迟到凌晨再执行。弹性资源池配合错峰调度，能利用低谷时段价格更低的算力份额，同样一笔预算能买到更多产出。

在架构设计上，关键是算力纳管层面把业务场景的调度策略做成一套统一服务，而不是每个业务团队自己手动控制服务器。这里我推荐用一个朴素但有效的方法：给任务打上优先级标签，调度器按优先级与资源水位自动排期。例如“用户实时请求”优先级最高，任何时候必须立刻执行；“异步批量生成”优先级中等，资源空闲时可以执行，高峰时挂起；“夜间评测任务”优先级最低，只允许在凌晨的窗口执行。这样一套简单的分级调度，在线推理的高峰期不会被离线任务抢资源，离线任务又能在低峰时段把闲置算力用起来。

6.3 容灾冗余也要量化，而不是翻倍堆资源

评审时经常卡在“稳定性”上：业务方担心集群崩溃，于是习惯性写“所有模块双副本，所有集群预留50%缓冲”。这种“每项都冗余”的累积效应非常夸张。A模块冗余50%，B模块冗余50%，C模块再冗余50%，叠加之后总体资源预留量已经数倍于实际负载。

我建议把容量冗余改成一套分级的策略：核心链路如对话生成、支付状态查询做高可用冗余；非核心链路如日志分析、批量计算结果校验，则降级到尽力而为即可。冗余不应该均匀地撒在每一个模块上，而应该像保险一样，优先保最不能出事的环节。这个原则需要评审委员会去挑战方案方：“你的系统真的全部模块都是核心吗？”大多数情况下，得到的答案都是“不全是”。

7. 把五个技巧收敛成一张评审现场能直接用的检查清单

说了这么多，很多读者可能最想要的是：“下次评审时我该拿着什么去问？”我的习惯，是把上面这些思路沉淀成一张成本评审清单，在评审会结束前一项项过。下面共享出来，你可以直接抄走改成自己团队的模板。

这份清单不追求一次把预算砍到最低，而是逼着方案方把每个和算力有关的设计决策都给出理由。真正有价值的评审，不是替业务方做决定，而是让大家在一个可以被量化和质疑的框架下做决定。

按我的经验，绝大多数AI项目的算力成本失控都不是某一个惊天大坑造成的，而是十个二十个看似合理的小设计叠在一起。上面五个技巧，本质上都是要求方案方回答同一个问题：“这笔算力花下去，对应的业务产出是什么？有没有更低成本的替代设计？”在评审阶段多问一句，比上线后优化省下的钱多得多。

我自己每次做评审复盘时最深的体会是：算力优化的核心不是让大家少用AI，而是让大家更精确地使用AI。算力账单本身不是敌人，真正的问题是架构里那些“不知道自己会花多少钱”的环节。把这些问题在方案阶段问清楚，比事后对账单有意义得多。