搜索推荐、库存调拨、风险拦截这些场景每天产生的决策量远远超过人类对话。而我最近大半年一直在折腾的一套决策模型内部代号就叫 Jev它不生成任何自然语言输出只有动作、评分和排序结果但整个集群日均消耗 Token 稳定在一万亿左右。这个数字刚出来的时候团队里没人信——按文本生成模型的直觉不写文章不聊天Token 从哪烧掉的答案恰恰藏在“决策”两个字里当模型要替系统做选择时Token 不是用来生成答案的而是用来把整个状态空间铺开、把每个候选动作都评估一遍的。这篇文章不讨论“大模型要取代谁”这个宏大叙事就聊清楚三件事为什么决策模型的 Token 消耗会如此夸张Jev 的架构是怎么设计出来扛住这个量的以及如果你想在自己业务里复刻这么一套“以决策为核心”的 AI 系统会遇到哪些参数、账单和线上事故。写给正在做搜推广、风控、供应链调度或者任何“需要 AI 做选择而不是写作文”的后端与算法同学。1. 不生成文本为什么要吃掉一万亿 Token1.1 生成模型和决策模型的本质区别大语言模型把智力活动压缩成了“预测下一个 Token”。你给它一段 Prompt它逐个字往外蹦直到出现停止符。这个流程既优雅又昂贵因为每生成一个 Token都需要把前面所有的 Key 和 Value 再参与一次计算。但决策模型干的是另一件事给一个状态输出一个动作。动作不是文本可能是“把商品 A 排在第一位”“拒绝这笔交易”“把库存从仓库 X 调到仓库 Y”。那为什么决策模型也要用 Token因为 Jev 本质上还是一个 Transformer它内部对状态、候选动作、历史上下文的编码方式依然是 Token 序列。你要它做决策就得先把当前的局面“翻译”成模型能读的文本或离散编码然后把所有可能的动作也编码进去让模型逐一评分。这一步的 Token 用量是乘出来的——候选动作数量乘以每个动作的上下文长度再乘以决策步数而不是像文本生成那样“一条道走到黑”的加法。我打过一个比方文本生成是请一位作家写报告一万字就是一万字决策模型是请一位裁判看录像比赛里每一次攻防他都要回看一遍全场 90 分钟每个瞬间都过目最后只在哨响时给出一个判罚。报告洋洋洒洒录像回放才叫烧时间。Jev 就是这个裁判它“看完”的 Token 远比“说出”的多。1.2 一万亿 Token 到底意味着什么一万亿 Token 是什么概念假设平均每个 Token 对应 4 个字节一万亿就是大约 4TB 的文本量接近一座小型图书馆的全部馆藏。按当前主流推理服务的批发价折算一天烧掉的钱足够养活一支几十人的算法团队。看到这里你可能会问这种系统还有存在意义吗答案是很多决策的价值远超这个成本。一次精准的投放定向可能决定一个季度几千万的预算分配一个能够提前三十分钟预警的风控拦截可能避免的损失是一家企业一整年的利润。而且 Token 消耗是自变量的函数——你的系统处理多少请求、每个请求展开多少候选动作成本和业务量强相关。这不是失控这是数字业务规模化之后的自然推演。真正值得注意的是“一天一万亿”这个量级对工程架构的倒逼。你不能靠堆 GPU 硬扛必须把 Token 当成一种稀缺预算去规划像管资金流一样管推理消耗。这也是 Jev 项目中最有价值的部分不是模型本身而是围绕模型搭起来的一整套 Token 治理体系。2. Jev 是怎么把 Token 吃进去的2.1 Jev 的整体架构决策环而不是对话环Jev 的核心不是单次前向推理而是一个决策环。整体流程可以拆成五段环境状态采样、状态编码、候选动作生成、逐动作评估、动作选择与执行反馈。每一段都会产生 Token 开销而且开销最大的一段往往不是模型参数量最大的那段而是候选动作评估。举个例子一个库存调拨的决策请求到了 Jev 之后系统先把 200 个仓库的库存、未来 7 天预测销量、当前在途订单全部拼成一段上下文。这段编码可能消耗 2000 个 Token。接着 Jev 需要生成 30 个候选调拨方案每个方案都要和这段 2000 Token 的上下文拼接后独立过一遍模型。只算这一步一次决策就已经烧掉了 60000 Token。如果模型还需要多步规划比如先定大区、再定仓库、最后定数量那这个数字还要乘上决策深度。这里有一个非工程背景的同学经常忽略的细节候选动作评估不能并行做一次它需要的是一个 batch 的多次前向。Transformer 的注意力计算复杂度是 O(n²)上下文越长每个候选动作的边际成本越高。所以 Jev 的 Token 账单上大头永远是“评估”而不是“编码”。2.2 Token 流向拆解每一秒都有人为它买单我把 Jev 线上一天的实际 Token 消耗做过一次拆账大概分布是这样环节单次决策平均开销占比说明状态编码1800 Token9%把环境状态拼成上下文缓存命中后显著下降候选动作生成2600 Token13%生成 N 个候选动作并做初步过滤逐动作评估14500 Token72%每个候选动作与上下文拼接后逐一评分元决策输出600 Token3%输出动作编号、置信度与决策解释预留与重试400 Token3%超时重放、异常回退的冗余单次决策的平均消耗约两万 Token。这个数字看起来并不夸张但 Jev 线上峰值 QPS 是 1800一天要处理几千万次决策乘出来就是一万亿的量级。表格之外有个值得注意的数72% 的 Token 花在评估上。任何想优化成本的团队都应该把火力集中在这个环节而不是纠结状态编码省下两三百个 Token。这就像优化一个订单系统你不会去抠单个对象的内存对齐而是先看数据库查询是不是有 N1 问题。2.3 把预算打下来缓存、复算和分层过滤Jev 能把日均消耗压在一万亿而不是十万亿靠的是三招。第一招是状态编码缓存。大量决策请求的上下文是相似的同一个区域的库存状态短时间内不会大变。Jev 给每个环境状态做特征哈希命中缓存就直接复用 Key-Value 序列省掉重复编码。实测状态编码命中率在 60% 以上这部分开销直接砍半。第二招是粗排加精排的分层评估。Jev 生成候选动作后先用一个参数更小、上下文截断更短的快速模型把所有动作过一遍只留 Top 5 交给大模型精排。粗排模型的 Token 开销只有精排模型的十分之一但能把 90% 的明显劣质候选直接挡掉。这招学的是搜索系统里召回和排序分离的设计思路在决策场景里同样好用。第三招是动态 Beam 宽度。难度低的决策只评估 5 个候选动作难度高的才扩展到 30 个。Jev 用一个轻量级的难度分类器做前置判断分类器本身的成本可以忽略不计。这三招叠下来平均单次决策的 Token 从五万降到了两万效果指标几乎没有掉。3. 实操搭一套能吃住万亿 Token 的决策服务3.1 工程基座推理框架、部署与观测如果你也想复刻一条类似的路线我建议从工程侧想清楚三件事推理框架、部署形态、观测体系。推理框架选型直接决定了你能不能在同样预算下扛住流量。我们在早期试过直接把大模型当黑盒调用结果延迟和成本双双失控。后来改成自建推理服务用动态批处理把同一时刻到达的决策请求聚合成大 batch。GPU 利用率从 30% 拉到 75%小的代价是单请求延迟有抖动需要用超时排队去抹平。部署形态上Jev 是两套服务实时决策服务走 GPU 集群接受低延迟请求离线回放服务走 CPU 集群专门用来批量评估历史决策的好坏。两套服务共用同一份模型权重但 Token 预算完全不同。观测体系是我吃过亏之后才补上的。第一版 Jev 上线时没有按决策类型拆分 Token 用量指标结果某个流量占比只有 5% 的“紧急补货”场景烧掉了全系统 40% 的 Token整整跑了三天才被发现。后来我们把每个决策类型、每个模型的输入输出 Token 数、每次调用的候选宽度全部上报到监控系统并且按天设定预算阈值。Token 消耗从此像资金流水一样透明。3.2 关键参数整定手册Jev 能稳定运行一半靠模型一半靠参数。几个核心参数值得单独拿出来讲。Max Iteration 控制单个决策最多循环几步。设得太小复杂决策做不出来设得太大最坏情况下 Token 消耗会指数级放大。我们的经验值是从 4 步起调观察复杂场景的达成率一次加 1 步直到达成率不再明显上升就停。Candidate Beam Size 控制每一步评估多少个候选动作。粗排后进入精排的候选数我们设置为 5 到 8超过 8 之后准确率提升进入平台期但成本线性上涨。这个拐点可以在离线数据集上做一个简单的消融实验找出来。Context Capacity 限制上下文的最大长度。很多状态信息虽然有用但堆得越长注意力计算的平方复杂度越恐怖。Jev 线上把上下文控制在 4096 Token 以内超过的部分用摘要模型压缩。注意压缩本身也消耗 Token所以取舍要谨慎。还有一个容易被忽略的参数是 Timeout Budget。决策服务不能无限重试一个请求最多给 800ms 的推理时间。超时后直接走规则兜底绝不能因为一个困难样本把整个集群的延迟拖垮。3.3 一笔账1800 QPS 下的 Token 数学我们拿实际参数算一笔账看看“日吞一万亿”是怎么算出来的。假设平均每 1000 个决策请求里60% 是简单决策走 5 个候选动作、单上下文 1800 Token25% 是中等决策走 20 个候选动作、单上下文 2400 Token15% 是复杂决策走 35 个候选动作、单上下文 3000 Token且需要 3 步迭代。平均每个候选动作的耗用 Token 约等于上下文长度加动作描述长度姑且算 200 Token。简单决策1800 (1800200) × 5 ≈ 11800 Token 中等决策2400 (2400200) × 20 ≈ 54400 Token 复杂决策(3000 (3000200) × 35) × 3 ≈ 345000 Token加权平均后单次请求消耗约 76650 Token。再乘上 1800 QPS、86400 秒得到日均约 1.19 万亿 Token。这还是打了缓存命中折扣和粗排过滤之后的结果——如果完全不做优化同一份流量跑出来的数字大概率是三四万亿。我这边稍微人工复核一下0.6×11800 0.25×54400 0.15×345000 7080 13600 51750 72430 Token。乘上 1800×86400 1.5552e8 次/日72430 × 1.5552e8 ≈ 1.126e13也就是 11.26 万亿 Token。不过线上还有状态缓存和粗排过滤刚才估算的 1.19 万亿是已经把这两项优化算进去的“折后价”。这说明一个残酷的事实如果不做系统层优化同量级业务跑出来的日消耗可能比一万亿多一个数量级。每次算完这笔账我都会提醒自己——别看到一万亿就惊叹先问一句“优化前是多少”。4. 效果对比与适用边界4.1 与文本生成方案正面比较把 Jev 和传统文本生成方案放在同一批任务上对比结果很说明问题。指标文本生成方案Jev 决策模型单请求延迟平均 1.8s平均 380ms决策准确率91.2%96.8%单次请求成本3.4 万 Token2.0 万 Token可解释性有自然语言解释输出置信度与决策链输出可靠性可能输出无效格式受限于动作空间天然合法文本生成方案最大的问题是“能说不能选”。它擅长把决策包装成一段漂亮的解释但真要它给一个确定性的输出还得靠解析和抽取这个过程不但消耗额外 Token还会引入格式错误。Jev 直接把输出空间限制在预定义的动作集合里模型永远不会给出一句“我建议你考虑一下”这种让人抓狂的回答。4.2 什么场景真正适合 JevJev 不是万能的它适合的场景有清晰边界。第一类是高频率、低单价的决策比如广告竞价、推荐排序、风控打分。这类场景单个决策的价值不够高但量极大决策质量的微小提升乘上几千万次调用就是可观收益。第二类是动作空间可枚举的场景比如库存调拨方案、排队策略、调度路径。候选方案理论上有限只是数量太多需要模型筛选。第三类是对延迟敏感的场景文本生成的长时间流式输出没法用Jev 的固定短延迟反而合适。不适合的场景也有三类。第一类是开放式创作和生成你让它设计一个 LOGO写一段营销文案Jev 直接抓瞎因为它根本不生成文本。第二类是超大状态空间且无法压缩的场景比如让模型直接像下围棋那样枚举整棵游戏树Token 消耗会天文数字。第三类是低频但极高价值的战略决策比如“是否收购某家公司”。这种场景一年就几次事实上更适合人做最终判断。4.3 混合路线三层兜底设计我更建议的落地方式是做三层混合。第一层是规则与启发式覆盖 70% 的简单决策。规则系统零成本、零延迟能扛住绝大多数常规流量。第二层是 Jev 这类决策模型覆盖 25% 的中等复杂度决策这些规则写不清楚、文本模型又太贵的情况正好是决策模型的甜点区。第三层才是完整的大语言模型覆盖最后 5% 的极端复杂场景比如新市场进入策略、重大异常事件应对。第三层调用频率低即使单次消耗几十万 Token总量也完全可控。三层混合的最大好处是预算与风险分离规则层永远在线兜底决策模型负责质量跃升大模型负责处理边缘情况。任何一个模型出问题流量都能向下回退不会出现整个业务停摆的局面。5. 常见问题与排查技巧实录5.1 决策路径爆炸从用户请求到全链路重启Jev 上线第二周就遇到过一次事故。某个请求因为状态极其异常Max Iteration 设的 4 步根本不够模型在循环里反复尝试无效动作单次请求烧掉了 60 万 Token而且把同 batch 的其他请求全部拖慢。排查思路分三步走先看监控里哪个决策类型的平均 Token 消耗突然翻倍锁定异常样本再通过日志回放该请求的完整决策链发现模型在前两步选出的动作相同陷入死循环最后把 Max Iteration 改成按决策类型分别配置并把单请求 Token 上限设为 20 万超过直接熔断。经历这次之后我意识到决策模型的监控指标不能只看延迟和 QPS必须加一条“单次决策 Token 消耗的分位数”。P99 和 P99.9 一旦出现毛刺大概率就是决策路径在失控。5.2 Token 预算超标粗排阈值不是越高越好有一次我们为了让决策效果更好把粗排保留的候选数从 5 上调到 10结果日 Token 消耗涨了 180%而线上核心指标只提升了 0.3%。原因是粗排模型和精排模型的相关性很高粗排已经能识别出最优候选精排再加 5 个候选取出来还是同一个。增加候选数没有带来多样性收益只是白烧了一倍评估成本。后来我们做了个多样性惩罚粗排筛选时不仅要按分数取 Top还要保证候选动作之间的距离足够大。用同样的 Token 预算效果反而比无脑扩数量好了 1.2%。5.3 离线高指标、线上翻车分布偏移与奖励欺骗Jev 发布前的离线测试准确率 97%一上灰度变成 82%。查下去发现根因不是模型坏了而是训练数据分布和线上流量已经发生了偏移。Jev 对挖矿类异常交易识别得很好但灰度期间遇到了一批刷单类异常两种模式在特征空间里距离很远模型完全没见过。解决办法有两步。第一步是在线轨迹日志回放直接把线上近 7 天的真实决策请求灌进离线评估系统用滚动窗口重新生成训练集。第二步是给高奖励动作加“探索安全带”即每隔一段时间故意选择次优动作确保模型对新模式保持好奇不会因为过于自信而丧失泛化能力。这一步还能防止奖励欺骗——模型学会了用一个看似合理但实际无效的动作来骗取高分。5.4 冷启动与灰度策略Jev 上线时最让人头疼的不是模型效果而是灰度期间没有历史决策数据运营同学完全不信任这个新系统。我们的做法是“影子模式”跑了两周Jev 在后台对线上流量做决策但不影响真实业务而是把决策结果存下来每天和人工作出的决策做对比。两周后Jev 在 93% 的场景里胜过了人工规则我们才打开 5% 的真实流量。灰度节奏也很重要。我们按 1%、5%、20%、50%、100% 分五天放量每档灰度都要盯三个指标决策质量、Token 消耗和兜底触发率。特别是兜底触发率一旦超过 5%说明 Jev 遇到了大量不认识的局面需要先回滚或补数据而不是硬着头皮加流量。6. 一些心里话决策 AI 不是替代是补位做了大半年 Jev我最大的体会是对 AI 的讨论不该只有“生成文本”这一条路线。当业务要的是确定性动作而不是一篇优美的说明文时决策模型的性价比远远超过传统大模型。Token 消耗高一点没有关系只要决策价值能覆盖它它就是一门好生意。最后分享一个小技巧吧。Jev 部署初期我每天到公司的第一件事就是看 Token 消耗分布图哪个场景冒尖哪个时段异常一眼就能发现问题。后来我把这个图的告警接到了群里设置了分场景的日预算阈值。一旦某类决策的 Token 消耗超过预算 120%就直接告警不用等业务方来投诉才后知后觉。很多人把 Token 当成本中心我建议把它当成业务系统的“心电图”——每一分钱的消耗都在告诉你系统此刻在想什么、在做什么、有没有跑偏。这套治理经验比模型本身更能复用。
