决策模型Jev：不生成文本，如何日吞一万亿Token？

开头

最近圈里讨论最凶的一个方向，不是哪个大模型又刷了榜单，而是一个听起来有点反直觉的思路：AI不生成文本，只做决策，照样能一天吃掉一万亿Token。决策模型Jev就是这条路线上一个比较有代表性的实验方向——它不做对话、不写文章、不吟诗作对，输入是一大堆上下文，输出是一个离散的动作或判断，比如“通过/拒绝”“调价0.3%”“派单给A节点”。说实话，我第一次看到这个设计的时候也愣了几秒：不做生成，那还算大模型吗？但仔细顺着它的推理路径捋下来，发现这条路恰恰精准地打在了生成式大模型最痛的那根神经上——自回归解码的串行瓶颈。

这篇文章会围绕决策模型Jev的定位展开，讲清楚它为什么敢喊“日吞一万亿Token”，核心架构里哪些设计支撑了这个吞吐量，以及如果你想在自己的业务里搭一套类似的决策模型链路，具体该怎么做、会踩哪些坑。适合正在做大模型推理优化、决策系统落地、或者想给高并发业务找一个更低延迟方案的工程师、架构师和数据团队参考。

1. 重新理解“日吞一万亿Token”：生成式LLM的吞吐瓶颈在哪

1.1 预填充与解码：不对称的算力账单

要知道决策模型Jev想解决什么问题，得先回到生成式大模型的推理过程上。现在主流的大模型推理大体分两个阶段：预填充和解码。

预填充阶段，就是你扔给它一大段Prompt，模型并行地把这段输入做前向计算，生成中间状态的KV Cache。这个阶段因为可以并行处理，吞吐其实相当可观，一台像样的推理机器跑预填充，每秒处理几万甚至十几万Token都是正常的。

真正的瓶颈在解码阶段。解码是自回归的，模型一次只能生成一个Token，把这个Token拼回输入序列，再预测下一个。每一步都依赖上一步的结果，没法并行。你让模型写一篇800字的文章，算上标点差不多就是800次串行的前向推理，每一次还都得带着越来越长的KV Cache算。这就是为什么长文本生成那么慢、那么贵——不是算力不够，是串行步骤的物理限制锁死了吞吐。

这就好比让一个作家写长篇小说，不管他文笔多好，逐字逐句写出来总是要时间的。你就算给他配再快的打字机，他也得一个字一个字敲。

1.2 “不生成文本”为什么能改写吞吐曲线

决策模型Jev的思路特别直接：既然解码是瓶颈，那我干脆不解码。它的输出不是一串文本，而是一个决策——本质上是把输出空间从“词表上的所有可能序列”压缩到“预定义的一组离散动作或数值”。模型读完上下文，直接跳到最后一步，在决策头上做一个前向计算，出结果。

这意味着整个推理过程只有一个阶段：读输入、出决策。没有自回归循环，没有KV Cache的持续膨胀，没有逐Token的串行等待。对推理引擎来说，吞吐的上限一下子从“生成速度”变成了“输入处理速度”。

一万亿Token这个数字听着吓人，但把账算清楚就很直白。假设你的推理集群预填充阶段能稳定跑到10万Token/秒/节点，单节点一天的吞吐就是10万乘86400秒，约86.4亿Token。想要达到一万亿Token，需要一百多个节点跑满全天。对一个正规的推理集群来说，这个规模不算离谱，但对于生成式模型，同样规模的集群恐怕连十分之一的Token都啃不下来，因为每个请求后面还拖着漫长的解码尾巴。

注意：这里说的是理论吞吐口径，实际还要算上请求排队、路由开销、动态批处理填充率这些损耗。但核心逻辑成立——决策模型把算力几乎全部投在“读”上，不浪费在“写”上，所以它的吞吐曲线本质上是可横向扩展的，这是它敢标出万亿级别的底气。

2. 决策模型Jev的核心设计：把“读完题直接给答案”变成架构

2.1 输入侧：Token处理管线与稀疏路由

决策模型的输入处理逻辑和大语言模型很像，甚至可以说它的底座就是一个预训练好的编码器。但在架构层面，决策模型Jev做了几个比较关键的变化。

第一个是稀疏路由。输入的一大串Token并不是每一个都需要经过全部参数。Jev在Transformer层里接入了稀疏门控路由，每个Token经过门控打分后，只会被分发到一小部分专家子网络里做计算。简单说，和样本相关度低的Token可以走轻量计算路径，只有真正承载关键信息的Token才走重型计算链路。这个思路在混合专家模型里已经很成熟，但Jev把它进一步强化：因为输出是离散决策而非生成文本，它对“细粒度语义精度”的要求没那么极端，反而更看重“关键信息捕捉”和“信号完整性”，所以路由可以做得更激进。

第二个是动态早退。不是所有请求都需要跑完整模型。Jev在中间层设置了多个决策头，对于置信度高的简单样本，前几层就能出结果，直接返回；只有置信度低的样本才继续往后传到更深层。这个机制在实际流量里很管用——大量请求其实是非常明确的，比如规则范围内的高度重复查询，早期出结果完全不损失准确率，但延迟和算力成本就降下来了。

第三个是长上下文重排。决策系统经常要处理很长很杂的上下文，比如几十万字的日志、多路数据流、历史行为序列。Jev在输入侧多做了两步：先做相关度预筛，再按时间衰减和信号强度重排Token顺序。这等于在正式推理前先做了一次轻量级的“注意力预排序”，让后续Transformer层的注意力计算更聚焦。实测下来，在处理超长日志型输入时，这项优化能把有效信息密度提升一个量级，减少注意力分散导致的误判。

2.2 决策头：从隐空间到可执行动作

模型读完上下文，最终要落到一个具体决策上，这就是决策头的活了。决策模型Jev的决策头有好几种形态，按场景选：

• 单标签分类头：适合“选一个”的场景，比如风险评级、是否拦截。
• 多标签打分头：适合“排个序”或“打批一行动作”的场景，比如内容标签命中、券包策略组合。
• 连续值回归头：适合输出数值的场景，比如定价系数、限流阈值、资源分配比例。
• 带约束的决策头：输出前先过一层规则函数，确保结果在业务边界内，比如价格不能低于成本、配额不能超上限。

决策头本身不算复杂，复杂的是置信度校准。你输出一个决策，不光要告诉业务方“选A”，还要告诉它“我有多确定”。Jev里做了温度缩放校准，就是让模型输出的概率分布更贴实际正确率。这一步有时候比模型本身还关键——下游系统要根据置信度决定是否转人工，如果置信度虚高，线上就会出大问题。

2.3 训练与对齐：决策模型的“语料”是反馈信号

生成式大模型的训练语料是文本，决策模型Jev的训练语料是反馈信号。它不学“下一句话是什么”，而是学“在给定状态下，采取什么动作能带来更好的结果”。

训练数据主要有三个来源。一是历史决策日志，比如过去一段时间的实际决策记录和最终结果；二是规则系统和专家经验的蒸馏，把老系统的决策逻辑变成软标签；三是在线反馈流，实时记录决策后的业务结果，比如转化率变化、延迟变化、错误率变化，拿回来做增量训练。

对齐目标上，Jev用的是一种类似“结果导向的偏好优化”的思路——两批决策方案，直接拿业务结果做排序，让模型去拟合“哪个选择更优”。这个训练范式比生成式模型的RLHF更干净，因为反馈是结构化的业务指标，不用靠人类偏好打分那么贵，也不会有文本生成的奖励稀疏问题。

3. 实操过程与核心环节实现：手把手搭一个决策模型链路

3.1 模拟项目X：一个毫秒级风控决策引擎

为了让你有体感，我们虚构一个具体场景：某跨平台交易系统需要一个风控决策引擎，每次交易请求进来，要在30毫秒内给出“放行/人工审核/拒绝”的决策。输入包括用户历史行为序列、设备指纹、交易上下文、当前策略参数，写下来差不多有几千到几万Token不等。

这种场景天然适合决策模型。老路子是用规则引擎配一些机器学习模型，但规则维护成本高、长序列语义捕捉弱；用生成式大模型更不行，响应速度完全扛不住。决策模型Jev就是为这种场景设计的。

项目的目标拆成三条：延迟P99低于30毫秒；拦截召回率比老系统提升10个百分点；误杀率不能涨。这三条目标直接把模型方案的技术选型锁死了。

3.2 关键步骤与参数选择

底座选型：基础编码器选用一个中等规模的预训练Transformer编码器。规模不用太大。决策任务的难点主要在线索关联和异常捕捉，不是语言生成，所以编码器的参数规模控制在10亿级别以内比较合适，太大反而影响推理速度。我们实际用的是约7亿参数的编码器，加上决策头，整体模型大小在1GB左右，量化后能压到400MB以下。

输入Token化：把结构化的交易特征变成Token序列。比如把设备指纹分段做子词分词、把行为序列按时间戳排序后拼接。这一步要注意，决策模型的Token化不要直接照搬文本分词，需要专门调一个针对字段级结构的编码方式，让模型能看到字段边界。

决策头与损失函数：因为是三分类且类别不均衡，决策头用多输出头的结构，主头做三分类，辅助头做风险分数回归。损失函数用焦点损失加回归损失的加权和。焦点损失主要解决“拒绝”类样本占比过低导致的训练倾斜问题，回归损失则让风险分数有更平滑的梯度信号。

训练流程：先拿一年历史决策日志做冷启动，用规则引擎的输出做软标签，训一版能用的基座；然后切到在线反馈流，用结果导向的偏好优化做增量对齐。增量训练的节奏是每四个小时拉一次最新反馈数据，做小步长微调，避免模型震荡。

量化部署：模型量化到8bit，同时开启稀疏路由和动态早退。部署环境是4张国产推理卡组成的集群，背后接了一层流量网关做负载均衡。压测结果倒是很争气：

算上路由和早退，准确率有小幅回落，但换来了三倍的吞吐和一半的延迟。对风控场景来说，这个置换很划算。

实操提示：动态早退的置信度阈值一定要按线上流量分布来调，不要拍脑袋设。我们第一次上线把阈值设高了，结果大量复杂样本直接穿透到最后一层，P99延迟直接打回原形；后来按P99延迟反推阈值才调稳。

3.3 性能与成本测算

这个决策引擎的性价比在量化之后非常明显。单卡QPS超过一千，和传统的生成式大模型做同样输入理解任务相比，成本差距有近两个数量级。

成本测算的逻辑其实就一条：生成式大模型的费用大头在输出Token数量，决策模型的费用大头在输入Token数量。如果业务场景的输出本来就是结构化决策，那让模型去生成一大段解释文本反而是纯浪费。在我们这个模拟项目里，单次请求平均输入5000 Token，输出只有一个三元组决策。同样的输入量，如果走生成式模型让它“分析并给出建议”，它可能吐出来几百字的解释，推理时间至少多一个数量级，费用更是贵得离谱。

4. 常见问题与排查技巧实录

4.1 决策退化：模型永远选“A”怎么办

这是决策模型最容易踩的坑。某次我们在模拟项目上迭代了一个版本，上线后线上决策分布几乎变成了单一类别，放行率暴涨。排查下来发现是训练数据里负样本比例太低，加上焦点损失超参没调好，模型学了个捷径——大部分情况下选“放行”的损失就够低了，没必要冒险。

处理办法有两条。一是硬约束：在损失函数里加一个分布约束项，迫使模型输出的类别分布接近训练集的先验分布，偏离越多惩罚越大。二是做显式负采样：把训练数据里拒绝和人工审核的样本过采样到和放行样本相当的比例。这两种方法叠加之后，模型输出分布才回归正常。

4.2 路由热点：所有请求都挤到同一个专家上

因为输入数据本身是有偏的，比如大部分请求来自少数几个高频交易模式，入口的稀疏路由门控学偏了方向，大量Token被打到同一个专家子网络。结果就是那个专家成了热点，算力分配极不均衡，集群里有些卡闲得发慌，有些卡直接被打满，整体延迟反而劣化。

解决办法是给门控加一个负载均衡辅助损失，这个在混合专家模型里是标配做法，但决策模型场景下要更激进一点，因为决策任务的Token分布更集中。具体调法是把辅助损失的权重从常规的0.01调到0.05，并在训练时实时统计专家负载方差，方差超过阈值就加大惩罚系数。

4.3 评估偏差：只看准确率导致线上事故

决策模型最容易让团队产生错觉的指标是准确率。离线测试准确率98%，看着很美，一上线立马出问题。问题出在“先验概率陷阱”：如果线上99%的请求都是放行，那模型躺着放行也有99%的准确率，根本发现不了它对少数风险样本的识别能力有多差。

后来我们把评估指标改成了按类别分层的召回率和混淆矩阵，牺牲一些“看起来很美的整体准确率”，换一个能真实反映模型能力的评估框架。同时对少数类样本单独盯F1分数，每次模型迭代必须先过这关才允许上灰度。这个习惯救了我们好几次。

4.4 上下文中毒与对抗样本：决策模型的安全短板

决策模型和生成式大模型一样有上下文注入风险。攻击者可以在交易备注字段里塞进恶意指令，试图影响模型判断。因为决策模型不输出文本，攻击面看起来更小，但它输出的动作直接驱动业务逻辑，一旦被误导，后果比生成一段错误文字严重得多。

我们的应对分三层：第一层，输入侧做字段隔离，把用户可编辑内容和控制信号严格分开编码；第二层，对输入做对抗扰动检测，用一个小模型判断输入序列里是否存在试图操纵决策的对抗片段；第三层，决策头输出前过一层业务规则过滤器，凡是规则内明确禁止的高风险组合，不管模型怎么输出都直接拦截。

4.5 安全与合规自查清单

最后还有一件事不能省——安全合规审查。决策模型直接作用于业务，一上线就带着真实影响，必须建立定期审计机制。我们内部保留了一套完整的线上决策日志，每次模型迭代都做一次全量回放，把新模型的决策和线上实际结果做对比，确认没有引入系统性偏差。规则过滤器不能依赖模型自己去学，必须把业务红线编码成硬规则，放在模型之外的防腐层。这部分工作不性感，但它是决策模型能不能长期安全运行的基本盘。

5. 影响范围与应用场景分析：决策模型走向哪

5.1 最适合的场景特征

判断一个业务是否适合换决策模型，看三件事：输出是不是离散动作、延迟要求高不高、输入Token量是不是远大于输出Token量。

三条同时满足的业务，就是决策模型的天然主场。我简单盘了一下：

5.2 决策模型不会替代LLM，而是重新划分边界

现在有一种声音说决策模型要取代生成式大模型，我不认同。决策模型Jev这类方向真正改变的是模型分工的边界：需要开放生成、解释、创造的任务还是得靠大模型；但凡是能被规范成决策问题、且对延迟和成本敏感的任务，决策模型会逐渐吃下来。

这种边界重划对工程架构的影响很具体。以前很多团队倾向于“一个通用大模型包打天下”，把风控、推荐、调度全都塞进一个模型里。但通用模型又贵又慢，产出还有大量冗余文本。未来更合理的架构可能是分层协同：决策模型负责高频、低延迟、结构化的判断，生成式大模型负责低频、高价值的解释与总结。成本曲线会因此被彻底改写。

5.3 给从业者的建议

如果你想在自己的业务里实践决策模型路线，我的建议是从“局部替代”开始。不要一上来就想替换整个系统，先挑一个边界清晰、反馈闭环完整的子任务试水，比如把某个耗时最高的规则判断模块换成决策模型。试水阶段重点盯三件事：延迟曲线、决策分布、少数类指标，不要看整体准确率。

成功之后再逐步扩大范围。另外，这个方向对团队的模型训练能力和工程能力都有要求，如果团队还没有自训练模型的经验，可以先从蒸馏和微调开源编码器起步，等积累了线上数据闭环，再考虑从零预训练自有底座。路要一步一步走，但方向值得押注。

我个人在实际操作中的体会是，决策模型最大的门槛不是技术，而是思维转换。团队里的算法工程师习惯了训练“会说话”的模型，突然让模型变成一个只会“点头或摇头”的判断器，很多人会本能地觉得“是不是浪费了模型能力”。但跑过几个场景之后，大家都会爱上这种干净利落的反馈循环。决策模型的设计哲学反而更贴近传统软件工程，输出可验证、行为可审计、性能可预测。

最后再分享一个小技巧：如果你不确定自己的业务适不适合走决策模型，先做一个星期的基础统计——把线上请求的输入Token量和输出信息量都记录下来，算一个输出/输入比。只要这个比值低得离谱，你就知道答案了。这个数据多数团队从来没量过，但它往往比任何技术预判都更能说明问题。