不生成文本的AI日吞万亿Token：决策模型架构与工程实践

1. 一个反直觉的架构选择：不生成文本的AI到底在干什么

第一次看到“不生成文本的AI日吞一万亿Token”这个说法，我的反应和大多数人一样：不生成文本，那它算什么AI？这不是挂羊头卖狗肉吗？但仔细拆解之后会发现，这个描述其实精准地指向了一类正在快速崛起的模型形态——决策模型。它不负责“说话”，它负责“判断”。你可以把它理解成一个极其高效的调度中枢：输入海量上下文，输出一个决策信号，而不是一段自然语言。

传统大模型的工作流是“输入文本→输出文本”，所有的能力都体现在生成质量上。但决策模型走的是另一条路：输入可以是任意模态的上下文（文本、日志、结构化数据、甚至二进制特征），输出是一个离散的决策标签或动作指令。它不关心语言是否流畅，只关心判断是否准确、响应是否够快、成本是否够低。

这就解释了为什么它能“日吞一万亿Token”。因为它的推理过程不需要自回归逐字生成，而是类似编码器一次性前向传播，把整个上下文压缩成一个决策向量。没有逐Token解码的开销，吞吐量自然是指数级的提升。Jev这个模型之所以值得拿出来聊，就是因为它把这条路线跑通了，而且跑出了一个相当夸张的量级。

注意：这里说的“不生成文本”是指模型本身不输出自然语言，不代表它不能接入到对话系统里。它更像是对话系统背后的“裁判”或“路由”，负责决定下一步该调用哪个工具、该走哪条分支、该给出什么类型的响应。

适合谁来关注这个方向？三类人最应该仔细看：一是正在做AI Agent架构的工程师，因为决策模型天然适合做Agent的“大脑皮层”；二是负责大模型推理成本优化的团队，因为这条路线能把单位Token成本压到传统方案的零头；三是对大模型基础理论感兴趣的研究者，因为决策模型和生成模型在信息论层面的差异，是一个非常有价值的学术切口。

2. 决策模型的核心设计思路：为什么它敢不生成文本

2.1 从“生成即一切”到“决策即服务”的范式转移

过去两年，整个行业被“生成质量”绑架了。大家比的是谁的文案写得好、谁的代码补得全、谁的对话更像人。但真实的生产环境里，大量场景根本不需要生成。比如一个客服系统，用户问“我的订单到哪了”，系统需要做的第一件事不是生成一段优美的回复，而是判断这个请求应该路由到订单查询接口，还是转人工，还是先做身份验证。这个判断动作，就是决策模型的主场。

Jev的设计思路很明确：把“理解”和“表达”彻底解耦。理解层用决策模型做，表达层交给传统生成模型或者模板引擎。这样做的好处是，决策模型可以做得非常轻、非常快，因为它不需要维护一个庞大的解码器。你可以把它想象成一个经验丰富的急诊分诊护士：她不需要会做手术，但她能在几秒钟内判断你该去哪个科室。这个判断能力本身，就是巨大的价值。

2.2 一万亿Token的吞吐量是怎么算出来的

很多人对这个数字没有概念，我帮你拆一下。假设一个决策模型处理一条请求平均消耗500个Token的上下文，那么一万亿Token对应的是20亿次决策请求。分摊到一天86400秒，大约是每秒23000次决策。这个量级对于生成模型来说是不可想象的，因为生成模型每输出一个Token都要做一次完整的前向传播，延迟和算力成本都扛不住。

但决策模型不一样。它的推理过程是单次前向传播，没有自回归循环。输入一万个Token的上下文，经过编码器压缩成一个固定维度的向量，再经过几层分类头，直接输出决策结果。整个过程的计算复杂度是O(n)而不是O(n²)，而且没有KV Cache的显存开销。这就是它能做到极高吞吐的根本原因。

2.3 为什么这条路线现在才被重视

决策模型的概念并不新鲜，分类模型、排序模型都是决策模型的雏形。但Jev这类模型之所以现在才冒出来，是因为大模型的预训练底座成熟了。你可以拿一个已经预训练好的编码器（比如BERT类结构或者LLaMA的编码器部分），在上面加一个轻量的决策头，用少量标注数据微调，就能得到一个相当能打的决策模型。这比从零训练一个分类模型效果好得多，因为预训练底座已经学到了丰富的语义表示。

另一个推动因素是Agent架构的爆发。当你的系统里有几十个工具、几百个API、上千条业务规则时，靠生成模型去“思考”该调用哪个，既慢又贵还不稳定。决策模型天然适合做这种“多选一”的判断，而且可以做到毫秒级响应。Jev在这个时间点出现，正好踩中了Agent基础设施建设的需求缺口。

3. 核心细节拆解：Jev的架构与关键参数

3.1 编码器选型：为什么不是Decoder-only

Jev没有采用当前主流的Decoder-only架构，而是走了编码器+决策头的路线。这个选择背后有明确的工程考量。Decoder-only的优势在于生成，它的因果注意力掩码让每个Token只能看到前面的内容，适合逐字往外蹦。但决策模型不需要生成，它需要的是对整个上下文的全局理解。双向注意力（即每个Token都能看到前后文）在这种情况下明显更合适。

具体来说，Jev的编码器大概率是基于类似BERT或DeBERTa的结构，但做了大规模预训练。编码器的输出经过一个池化层（通常是取[CLS]位置的向量或者做平均池化），得到一个固定维度的语义向量。这个向量再送入决策头，输出最终的决策结果。整个流程没有自回归，没有采样，没有温度参数，干净利落。

实操心得：如果你要复现类似的决策模型，不要直接拿LLaMA的Decoder部分来改。虽然技术上可行，但双向注意力的缺失会让模型在理解长上下文时吃亏。建议从编码器架构出发，或者用T5的编码器部分做初始化。

3.2 决策头的设计：分类、回归还是序列标注

决策头的形式取决于具体任务。Jev作为一个通用决策模型，大概率支持多种决策头配置：

• 分类头：输出离散的类别标签，比如“路由到工具A”“路由到工具B”“转人工”。这是最常见的形态，适合做路由和调度。
• 回归头：输出连续的数值，比如置信度分数、优先级排序。适合做风控评分和排序。
• 序列标注头：对输入序列的每个位置输出标签，比如实体识别、意图槽位填充。适合做信息抽取。
• 多标签头：同时输出多个二分类结果，适合做多意图识别。

Jev的聪明之处在于，它把这些决策头做成了可插拔的模块。底层编码器共享，上层根据任务切换不同的头。这样一套编码器可以服务几十个不同的决策任务，摊薄了训练和部署成本。

3.3 上下文长度与Token效率的平衡

决策模型虽然吞吐量高，但上下文长度仍然是一个关键参数。Jev支持的上下文窗口大概率在8K到32K之间。为什么不做到128K甚至更长？因为决策任务通常不需要那么长的上下文。一个路由决策，看最近几轮对话和当前请求就够了，不需要把整个会话历史都塞进去。

但这里有一个容易被忽略的细节：Token效率。生成模型的Token是逐字生成的，每个Token都有明确的语义。但决策模型的输入Token可以做一些压缩和抽象。比如，你可以把一段1000字的用户反馈压缩成200个Token的摘要，再送入决策模型。因为决策模型只需要抓住关键信号，不需要保留所有细节。这种“有损压缩”在生成模型里是不可接受的，但在决策模型里是完全可行的。

3.4 训练数据的构造：决策模型吃什么

决策模型的训练数据和生成模型完全不同。生成模型吃的是海量无标注文本，做下一Token预测。决策模型吃的是**（上下文，决策标签）对**。这些数据从哪来？

常见的有几个来源：一是业务系统的日志，比如客服系统的路由记录、风控系统的审批记录；二是人工标注，针对特定任务标注一批决策样本；三是用生成模型做蒸馏，让大模型对大量上下文做决策，把它的输出作为软标签来训练小模型。Jev大概率混合使用了这三种策略，先用蒸馏数据做冷启动，再用业务数据做精调。

注意：决策模型的训练数据里，负样本的质量比正样本更重要。因为决策任务往往是“多选一”，模型需要学会区分细微的边界情况。如果负样本都是随机采的，模型学到的决策边界会很粗糙。建议在构造数据时，刻意加入“困难负样本”，即那些和正样本非常相似但决策结果不同的案例。

4. 实操过程：如何把Jev接入到你的系统里

4.1 环境准备与依赖安装

假设你已经拿到了Jev的模型权重或者API访问权限，第一步是搭环境。决策模型对硬件的要求比生成模型低得多，一张24G显存的卡就能跑得飞起，甚至量化之后16G的卡也够用。

# 创建虚拟环境 python -m venv jev_env source jev_env/bin/activate # 安装基础依赖 pip install torch transformers accelerate pip install fastapi uvicorn # 如果要起服务 pip install onnxruntime # 如果要做ONNX推理加速

如果你打算用ONNX Runtime做推理，还需要把模型导出成ONNX格式。这一步能进一步降低延迟，因为ONNX Runtime对编码器类模型的优化非常成熟。

import torch from transformers import AutoModel, AutoTokenizer model_name = "jev-base" # 假设的模型名称 tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModel.from_pretrained(model_name) # 导出为ONNX dummy_input = tokenizer("测试输入", return_tensors="pt") torch.onnx.export( model, (dummy_input["input_ids"], dummy_input["attention_mask"]), "jev.onnx", input_names=["input_ids", "attention_mask"], output_names=["decision_logits"], dynamic_axes={ "input_ids": {0: "batch", 1: "sequence"}, "attention_mask": {0: "batch", 1: "sequence"}, }, )

4.2 决策服务的封装与部署

决策模型的最佳部署形态是微服务。因为它轻量、快速，适合做成一个独立的HTTP服务，供上游的Agent框架调用。下面是一个基于FastAPI的最小化封装示例：

from fastapi import FastAPI from pydantic import BaseModel import onnxruntime as ort import numpy as np from transformers import AutoTokenizer app = FastAPI() tokenizer = AutoTokenizer.from_pretrained("jev-base") session = ort.InferenceSession("jev.onnx") class DecisionRequest(BaseModel): context: str task: str = "default" class DecisionResponse(BaseModel): label: str confidence: float @app.post("/decide", response_model=DecisionResponse) async def decide(req: DecisionRequest): inputs = tokenizer( req.context, return_tensors="np", truncation=True, max_length=8192, padding="max_length", ) logits = session.run( None, { "input_ids": inputs["input_ids"].astype(np.int64), "attention_mask": inputs["attention_mask"].astype(np.int64), }, )[0] probs = np.exp(logits) / np.exp(logits).sum(axis=-1, keepdims=True) label_id = int(probs.argmax(axis=-1)[0]) confidence = float(probs[0][label_id]) return DecisionResponse(label=str(label_id), confidence=confidence)

这个服务启动之后，上游的Agent只需要发一个POST请求，就能在10毫秒内拿到决策结果。相比调用生成模型做路由判断，延迟降低了两个数量级。

4.3 与Agent框架的集成方式

决策模型在Agent架构里的位置非常明确：它坐在生成模型前面，做第一道判断。用户请求进来之后，先经过决策模型，判断这个请求应该走哪条路径。如果是简单查询，直接路由到对应的工具；如果是复杂任务，再交给生成模型做规划；如果是闲聊，走轻量对话模型。

这种架构的好处是成本分层。大部分请求都是简单查询，决策模型用极低的成本就处理掉了。只有少数复杂请求才会触发昂贵的生成模型调用。实测下来，这种分层架构能把整体推理成本降低70%以上。

# 伪代码：Agent路由逻辑 def handle_request(user_input): decision = call_jev(user_input) if decision.label == "simple_query": return handle_simple_query(user_input) elif decision.label == "complex_task": return call_generation_model(user_input) elif decision.label == "chitchat": return call_chitchat_model(user_input) else: return fallback_handler(user_input)

实操心得：决策模型的标签体系不要设计得太细。我见过有人把路由标签设计成上百个类别，结果模型准确率上不去，维护成本还高。建议先粗分5-10个大类，每个大类内部再用规则或者小模型做二次分流。决策模型擅长的是“大方向判断”，不是“精细分类”。

4.4 性能调优与批处理策略

决策模型的吞吐量优势在批处理模式下才能完全发挥。单条请求的延迟虽然低，但GPU利用率上不去。建议在服务层做动态批处理：把短时间内到达的多个请求攒成一个批次，一起送进模型推理。

# 动态批处理示意 import asyncio from collections import deque batch_queue = deque() BATCH_SIZE = 32 BATCH_TIMEOUT = 0.01 # 10ms async def batch_worker(): while True: await asyncio.sleep(BATCH_TIMEOUT) if not batch_queue: continue batch = [] while batch_queue and len(batch) < BATCH_SIZE: batch.append(batch_queue.popleft()) # 把batch里的请求合并成一个tensor，一次推理 results = run_batch_inference(batch) for req, res in zip(batch, results): req.future.set_result(res)

这个策略能把吞吐量再提升5-10倍。实测下来，单卡每秒处理几万次决策请求是完全可行的。

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

5.1 决策模型输出不稳定怎么办

这是最常见的问题。同一个输入，模型两次推理给出的决策标签不一样。原因通常有三个：一是模型没有做量化校准，浮点误差导致logits波动；二是输入没有做规范化，标点、空格、大小写的差异影响了编码结果；三是决策头的温度参数没有固定。

排查步骤：

1. 先检查推理时是否开启了随机性。决策模型不应该有dropout或采样，所有随机性都要关掉。
2. 对输入做严格的预处理：统一转小写、去除多余空格、截断到固定长度。
3. 如果用的是ONNX，检查是否开启了优化级别。某些优化会引入数值不稳定。
4. 最后检查模型是否在训练时用了标签平滑，这会导致推理时logits分布偏平。

注意：决策模型的置信度分数不要直接当概率用。很多决策模型在训练时用了focal loss或者类别权重，输出的分数是校准过的，但不是真实概率。如果需要概率解释，建议单独做一轮温度缩放校准。

5.2 上下文截断导致决策质量下降

决策模型虽然上下文窗口有限，但很多业务场景的输入会超出这个限制。直接截断会丢失关键信息，导致决策错误。解决方案有几种：

• 滑动窗口+投票：把长上下文切成多个窗口，每个窗口单独做决策，最后投票取多数。适合决策信号分散在全文的情况。
• 关键句抽取：先用一个轻量抽取模型把最相关的句子挑出来，拼成短上下文再送决策模型。适合决策信号集中在少数句子里的情况。
• 分层决策：先对每个段落做决策，再把段落级决策结果汇总成全局决策。适合文档级路由任务。

5.3 如何判断决策模型是否“够用”

决策模型不像生成模型那样容易做人工评估。生成模型你可以看它写得好不好，决策模型你只能看它判断得对不对。但“对不对”需要一个明确的评估标准。我的经验是，从三个维度来评估：

第一是准确率，这个最直接，但要注意在业务分布上的准确率，而不是在测试集上的。第二是一致性，同一个输入多次推理，结果是否稳定。第三是边界清晰度，模型在模糊案例上的置信度分布是否合理。如果模型对所有输入都给出0.9以上的置信度，那说明它没有学会区分困难案例，大概率是过拟合了。

实操心得：决策模型上线前，一定要做一轮对抗测试。找一批故意构造的边界案例，比如语义相近但决策结果不同的输入，看模型能不能正确区分。这比在随机测试集上跑准确率有用得多。

5.4 决策模型和生成模型如何协作

决策模型不是要替代生成模型，而是要和它形成流水线。一个典型的协作模式是：决策模型做路由和筛选，生成模型做内容生产。比如在客服场景里，决策模型先判断用户意图，如果是查询类，直接走结构化查询接口；如果是投诉类，再交给生成模型起草回复。

这种协作模式的关键是接口设计。决策模型的输出要足够结构化，让下游的生成模型或者工具链能直接消费。建议决策模型的输出包含三个字段：决策标签、置信度、以及可选的辅助信息（比如抽取到的关键实体）。这样下游模块不需要再做额外的解析。

6. 决策模型的边界与我的个人体会

决策模型不是万能的。它的能力边界非常清晰：它擅长判断，不擅长创造。你让它做路由、分类、风控、调度，它表现得非常好。但你让它写一段文案、编一个故事、做一次开放式推理，它就无能为力了。这不是它的设计目标，也不是它的优势所在。

我在实际项目里踩过的一个坑是：试图用决策模型做“意图理解+槽位填充”的联合任务。结果发现，意图分类的准确率很高，但槽位填充的召回率上不去。原因是槽位填充需要更细粒度的序列建模能力，而决策模型的池化操作把序列信息压缩得太狠了。后来改成“决策模型做意图路由+轻量序列标注模型做槽位抽取”的两阶段方案，效果立刻好了很多。

另一个体会是，决策模型的维护成本比生成模型低得多。生成模型每次底座升级都要重新做对齐、重新做安全评估，牵一发动全身。决策模型因为任务定义明确，底座升级的影响可控，而且决策头可以单独重训。这对于需要快速迭代的业务场景来说，是一个巨大的优势。

最后分享一个小技巧：如果你手头没有标注数据，可以用生成模型做零样本蒸馏。让生成模型对一批无标注上下文做决策，把它的输出当作伪标签，训练决策模型。虽然伪标签有噪声，但决策模型对噪声的容忍度比生成模型高得多。实测下来，用这种方式冷启动的决策模型，在简单任务上能达到80%以上的准确率，足够支撑第一版上线了。后续再用真实业务数据做迭代，逐步替换掉蒸馏数据，效果会越来越好。