不生成文本的AI日吞一万亿Token：决策模型如何替代生成式大模型

1. 从“不生成文本”说起：一个反直觉的AI决策模型

第一次看到“不生成文本的AI日吞一万亿Token”这个说法，我的反应和大多数人一样：不生成文本，那它到底在干什么？毕竟我们早已习惯了大模型“输入提示词、输出一段话”的交互范式，从写代码到写文案，从翻译到问答，几乎所有主流AI产品都建立在“生成”这个动作之上。但偏偏有一类模型，它的核心任务不是“说”，而是“判断”——它不负责写出一段通顺的话，只负责在极短的时间内做出一个决策，比如“这条内容该不该推”“这笔交易有没有风险”“这个用户会不会流失”。

这类模型在业内通常被称为决策模型或判别式模型。和生成式大模型最大的区别在于：生成式模型输出的是一个概率分布下的文本序列，而决策模型输出的是一个标签、一个分数、一个动作。你可以把它理解成两种不同的工种：一个是作家，负责把想法写成文章；另一个是裁判，负责在毫秒之间吹哨。作家可以慢慢打磨，裁判必须快、准、稳。

标题里提到的“日吞一万亿Token”，其实是在强调这类模型的吞吐量级。一万亿Token是什么概念？如果按一个中文Token约等于0.7个汉字来粗略换算，一万亿Token大约对应七千亿汉字的信息量。这个量级远超普通生成式模型日常处理的请求量，因为决策模型往往部署在推荐系统、风控系统、广告竞价系统这类高频场景中，每一次用户滑动、每一次点击、每一次交易请求，背后都可能触发一次模型推理。它不需要生成华丽的文本，但它需要在海量请求中保持极低的延迟和极高的稳定性。

那为什么说它“撕开大模型的替代路线”？因为当前行业里有一种默认的思维定式：要做AI，就得做大模型；要做大模型，就得做生成。但决策模型的存在证明了一件事——在很多业务场景里，生成能力不仅不是必需的，反而是一种浪费。你不需要一个能写诗的模型来判断一条评论是不是垃圾广告，你只需要一个能快速分类的模型。把生成式大模型硬塞进这类场景，就像让一个文学教授去当停车场收费员，能力过剩、成本过高、速度还慢。

这篇文章适合谁看？如果你是对AI技术选型有困惑的产品经理、架构师，或者正在寻找大模型之外替代方案的技术负责人，再或者你只是好奇“不生成文本的AI到底怎么工作”，那接下来的内容会从设计思路、核心细节、实操过程到问题排查，一层层拆开讲清楚。我会尽量用从业者之间交流的方式，把这件事说明白。

2. 决策模型的核心设计思路与选型逻辑

2.1 为什么“不生成”反而是一种优势

要理解决策模型的价值，先得理解生成式模型在特定场景下的三个硬伤。

第一个硬伤是延迟。生成式模型每输出一个Token，都需要经过一次完整的前向计算，虽然现在有KV Cache、投机采样等优化手段，但自回归生成的本质决定了它的延迟下限。而决策模型通常只需要一次前向传播就能输出结果，不需要逐Token解码。在推荐、风控这类对延迟极度敏感的场景里，几十毫秒的差距就可能直接影响用户体验和业务指标。

第二个硬伤是成本。生成式模型的参数量动辄百亿千亿，推理时需要大量的显存和算力。而决策模型可以根据任务复杂度灵活选择参数量，从几百万到几亿参数都能跑出很好的效果。日吞一万亿Token的背后，如果用的是生成式模型，光是推理成本就足以让大多数公司望而却步；但换成决策模型，同样的吞吐量下成本可能只有前者的几十分之一。

第三个硬伤是不可控性。生成式模型的输出是开放式的，你很难保证它每一次都输出完全符合预期的结果。而决策模型的输出空间是封闭的，要么是类别标签，要么是数值分数，要么是有限的动作集合。这种封闭性带来了更高的可控性和可解释性，在金融、医疗、工业控制等领域尤为重要。

我个人的经验是：当一个任务可以被形式化为“分类”“排序”“匹配”“打分”时，优先考虑决策模型；只有当任务确实需要“生成一段自然语言”时，才动用生成式大模型。这个判断标准看起来简单，但在实际项目中，很多人会习惯性地把问题往生成式框架里套，结果绕了远路。

2.2 决策模型的典型架构选型

决策模型不是一个单一的技术，而是一类技术的统称。根据任务类型的不同，常见的架构选型包括以下几种。

选型的核心原则是：任务越简单，模型越轻；延迟要求越高，架构越偏向非自回归。比如内容审核场景，一个几百万参数的文本分类模型就能达到很好的效果，完全不需要上亿参数的模型。而广告竞价场景因为涉及序列决策和实时出价，可能需要更复杂的强化学习策略网络，但即便如此，它的参数量也远小于生成式大模型。

这里有一个容易被忽略的点：决策模型的性能瓶颈往往不在模型本身，而在特征工程和数据管道。生成式模型可以通过扩大参数量来提升效果，但决策模型的效果很大程度上取决于输入特征的质量。一个设计良好的特征管道，能让一个简单模型的效果超过一个复杂模型。所以在实际项目中，我通常会把更多精力放在特征设计和数据清洗上，而不是盲目追求模型结构的复杂度。

2.3 “日吞一万亿Token”背后的工程挑战

一万亿Token的日吞吐量，换算成QPS大约是每秒一百多万次请求。这个量级对工程架构提出了极高的要求，远不是“把模型部署上去”那么简单。

首先是批处理与并发。单次推理的延迟再低，如果串行处理也扛不住百万级QPS。实际系统中通常采用动态批处理技术，把多个请求合并成一个批次一起推理，充分利用GPU的并行计算能力。批处理的大小需要根据延迟要求和硬件资源动态调整，太大则延迟升高，太小则吞吐不足。

其次是模型量化与压缩。为了在有限的硬件资源下支撑如此高的吞吐量，决策模型通常会进行量化处理，把FP32的权重压缩到INT8甚至INT4，在精度损失可控的前提下大幅提升推理速度。知识蒸馏也是常用手段，用一个大模型教一个小模型，让小模型在特定任务上达到接近大模型的效果。

最后是多级缓存与降级策略。在极端流量峰值下，系统需要有选择地降级，比如对低优先级请求返回缓存结果，或者跳过某些非关键特征的计算。这些策略需要在系统设计阶段就考虑进去，而不是等到线上出问题再临时补救。

3. 核心细节解析与实操要点

3.1 特征管道的设计与优化

决策模型的效果，七分靠特征，三分靠模型。这句话在业内流传已久，虽然有些夸张，但确实反映了特征工程在决策模型中的核心地位。

特征管道通常分为离线部分和在线部分。离线部分负责从历史数据中统计各种特征，比如用户的点击率、商品的转化率、内容的互动率等，这些特征通常以天或小时为周期更新。在线部分负责实时计算当前请求相关的特征，比如用户当前的会话行为、请求的时间上下文等，这些特征需要在毫秒级内完成计算。

实操中最大的坑是离线在线特征不一致。离线训练时用的特征和在线推理时计算的特征如果存在偏差，模型效果会大打折扣。我踩过的一个典型坑是：离线统计用户过去7天的点击率时，用的是自然日；在线计算时用的是滚动7天窗口。这两个口径在大多数时候差异不大，但在跨天时段会出现明显偏差，导致模型在凌晨时段的预测准确率下降。

解决这个问题的标准做法是特征平台化。把特征的定义、计算逻辑、存储方式统一管理，离线训练和在线推理都从同一个特征平台读取数据。这样虽然前期投入较大，但长期来看能避免大量因特征不一致导致的问题。

注意：特征平台的建设不要一开始就追求大而全，可以从最核心的几十个特征开始，逐步扩展。过早追求平台化反而会拖慢项目进度。

3.2 模型训练中的数据采样与标签处理

决策模型的训练数据往往存在严重的类别不平衡问题。比如内容审核场景，违规内容可能只占总量的千分之一甚至更低。如果直接用原始数据训练，模型会倾向于把所有样本都预测为“正常”，因为这样就能达到99.9%的准确率，但这样的模型毫无实用价值。

处理类别不平衡的常见方法包括：对少数类进行过采样、对多数类进行欠采样、调整损失函数的权重、使用Focal Loss等。我个人的经验是，过采样和损失函数加权结合使用效果最好。单纯过采样容易导致过拟合，单纯加权则可能让模型对少数类的判别边界不够清晰。

标签处理方面，决策模型对标签噪声的容忍度远低于生成式模型。生成式模型即使训练数据中有一些噪声，也能通过大规模预训练学到通用的语言表示；但决策模型如果标签噪声过大，会直接导致决策边界偏移。所以在实际项目中，标签清洗的投入往往比模型调参的投入更大。常见的手段包括：多人标注交叉验证、基于规则的预清洗、基于模型的不一致样本检测等。

3.3 推理服务的部署与优化

决策模型的推理服务部署，核心目标是低延迟、高吞吐、高可用。这三个目标之间存在天然的矛盾，需要根据业务场景做权衡。

低延迟要求通常意味着小批量甚至单条推理，但这样会浪费GPU的并行能力。高吞吐则要求大批量推理，但这样会增加单次请求的等待时间。实际系统中通常采用动态批处理来平衡两者：系统维护一个请求队列，当队列长度达到阈值或等待时间超过上限时，就触发一次批量推理。阈值和上限的设置需要根据业务对延迟的容忍度来调整。

模型量化是另一个关键优化手段。以INT8量化为例，理论上可以把推理速度提升2到4倍，显存占用降低一半以上。但量化会带来精度损失，需要在量化后对模型进行评估，确保精度下降在可接受范围内。我通常的做法是：先在验证集上评估量化前后的效果差异，如果差异小于千分之一，就直接上量化；如果差异较大，就考虑混合量化，对敏感层保留FP16精度。

提示：量化后的模型一定要在真实流量上做A/B测试，离线评估和线上表现有时会有明显差异。

4. 实操过程与核心环节实现

4.1 从零搭建一个决策模型的完整流程

假设我们要搭建一个内容质量评分的决策模型，输入是一段文本，输出是一个0到1之间的质量分数。这个任务不需要生成任何文本，只需要给出一个判断。以下是完整的实操流程。

第一步：明确任务定义和评估指标。质量评分是一个回归任务，但实际业务中往往更关心排序效果，所以评估指标除了MSE、MAE之外，还需要看NDCG、Spearman相关系数等排序指标。这一步看起来简单，但很多项目失败的原因就是任务定义不清晰，导致后续所有工作都缺乏方向。

第二步：数据收集与标注。从业务系统中抽取历史内容数据，通过人工标注或业务反馈获取质量标签。标注标准需要尽可能明确，比如“高质量”的定义是什么，“低质量”的边界在哪里。标注不一致是常见问题，需要通过标注手册和交叉验证来控制。

第三步：特征工程。根据任务特点设计特征，常见的包括：文本长度、词汇丰富度、句子平均长度、特殊符号比例、与已知高质量内容的相似度等。如果数据量足够，也可以直接用预训练语言模型提取语义特征，但要注意推理延迟的约束。

第四步：模型选型与训练。对于这个任务，一个轻量级的Transformer编码器加上回归头就足够了。参数量控制在千万级别，推理延迟可以做到毫秒级。训练时使用MSE损失，配合早停策略防止过拟合。

第五步：离线评估与调优。在验证集上评估模型效果，如果排序指标不理想，优先检查特征质量，其次考虑调整模型结构或超参数。不要一上来就换更大的模型，很多时候问题出在数据而不是模型。

第六步：部署与线上验证。将模型导出为ONNX或TensorRT格式，部署到推理服务中。先进行小流量灰度测试，观察线上指标和延迟表现，确认无误后再逐步扩大流量。

4.2 关键参数的计算与选择过程

在决策模型的实操中，有几个关键参数需要仔细计算和选择。

批处理大小（Batch Size）的选择需要平衡吞吐和延迟。假设单次推理的延迟为T，批处理大小为B，则单批次的处理时间为T_batch，吞吐量为B/T_batch。理论上B越大吞吐越高，但T_batch也会随B增大而增大。实际选择时，可以先测量不同B下的T_batch，找到吞吐量曲线的拐点。比如B从1增加到32时，吞吐量提升了20倍；但从32增加到64时，吞吐量只提升了1.2倍，那32就是比较合适的值。

学习率（Learning Rate）的选择对决策模型的收敛速度和最终效果影响很大。经验法则是：对于Adam优化器，初始学习率可以设为1e-4到1e-3之间；对于SGD，可以设为1e-2到1e-1之间。如果训练过程中损失震荡明显，说明学习率偏大；如果损失下降过慢，说明学习率偏小。学习率预热和余弦退火是常用的调度策略。

量化精度（Quantization Precision）的选择需要根据硬件支持和精度要求来定。INT8量化在大多数GPU上都有良好的支持，精度损失通常在可接受范围内。INT4量化虽然能进一步压缩模型，但精度损失较大，适合对精度要求不高的场景。实际选择时，建议先在INT8上验证效果，如果满足要求就不必追求更低的精度。

4.3 线上服务的监控与告警

决策模型上线后，监控是保证服务稳定性的关键。需要监控的指标包括：请求量、延迟分布（P50、P95、P99）、错误率、模型输出分布、特征缺失率等。

其中模型输出分布是一个容易被忽略但非常重要的指标。如果模型输出的分布突然发生偏移，比如质量分数的均值从0.6突然降到0.3，可能意味着输入数据的分布发生了变化，或者模型出现了异常。这种偏移不一定触发传统的错误告警，但会直接影响业务效果。

特征缺失率同样关键。如果某个重要特征的缺失率突然升高，模型的预测效果会明显下降。监控系统需要在特征缺失率超过阈值时及时告警，并触发降级策略，比如用默认值填充或切换到备用模型。

注意：监控指标的阈值不要设得太死，要留出一定的波动空间。过于敏感的告警会导致告警疲劳，反而让真正的问题被忽略。

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

5.1 模型效果不达预期的排查思路

模型上线后效果不达预期，是最常见也最让人头疼的问题。我的排查思路通常按照以下顺序进行。

先查数据，再查特征，最后查模型。数据问题包括：训练数据和线上数据的分布是否一致、标签是否存在噪声、样本是否存在时间泄漏。特征问题包括：离线在线特征是否一致、特征是否存在缺失或异常值、特征的重要性是否符合预期。模型问题包括：模型是否过拟合或欠拟合、超参数是否合理、推理时是否使用了正确的模型版本。

这个顺序的原因是：数据问题的影响最大，但最容易被忽略；模型问题的影响最小，但最容易被过度关注。我见过太多团队在模型结构上反复折腾，最后发现是训练数据里混入了未来信息。

5.2 延迟突增的常见原因与解决方法

延迟突增是决策模型线上服务的典型问题。常见原因和解决方法如下表所示。

我遇到过一次典型的延迟突增：P99延迟从50毫秒突然升到500毫秒，但QPS并没有明显变化。排查后发现是某个特征服务的缓存过期策略配置错误，导致大量请求穿透到数据库，拖慢了整个特征管道。解决方法是修复缓存过期策略，并增加特征服务的降级逻辑。

5.3 模型更新与版本管理的经验

决策模型需要频繁更新，因为业务数据和用户行为在不断变化。模型更新涉及版本管理、灰度发布、回滚机制等一系列工程问题。

我的经验是：每次模型更新都要保留完整的版本记录，包括训练数据的时间范围、特征版本、超参数配置、评估指标。这样当线上效果出现问题时，可以快速定位是哪个环节发生了变化。灰度发布时，先放1%的流量，观察至少一个完整业务周期（比如一天），确认核心指标没有下降后再逐步扩大。回滚机制要确保在发现问题后能在分钟级内切回旧版本。

提示：模型版本命名建议包含日期和关键配置信息，比如“quality_model_20250101_int8_v2”，这样一眼就能看出模型的训练时间和量化精度。

5.4 决策模型与生成式模型的协同使用

虽然这篇文章的主题是决策模型替代生成式模型的路线，但在实际业务中，两者往往需要协同使用。比如在内容审核场景中，决策模型负责快速筛选出可疑内容，生成式模型负责对可疑内容进行详细分析和解释。这样既保证了效率，又提供了可解释性。

协同使用的关键是明确分工边界。决策模型处理高并发、低延迟、封闭输出的任务；生成式模型处理低并发、高延迟、开放输出的任务。两者通过消息队列或API网关连接，决策模型的输出作为生成式模型的输入或过滤条件。

这种架构的优势在于：大部分请求由决策模型处理，成本低、速度快；只有少量请求需要生成式模型介入，成本可控、效果更好。我实测下来，这种混合架构在内容审核场景中能把整体成本降低80%以上，同时保持甚至提升审核准确率。

6. 决策模型的适用边界与选型建议

6.1 什么场景适合决策模型

决策模型不是万能的，它有明确的适用边界。适合决策模型的场景通常具备以下特征：任务可以被形式化为分类、排序、匹配或打分；输出空间是封闭的或有限的；对延迟和吞吐有较高要求；对可解释性有一定要求。

典型场景包括：内容审核与过滤、推荐系统排序、广告竞价与投放、金融风控与反欺诈、工业质检与异常检测、搜索相关性排序等。这些场景的共同点是：不需要生成自然语言，只需要做出判断。

6.2 什么场景仍然需要生成式模型

生成式模型在以下场景中仍然不可替代：需要生成自然语言文本的任务，如对话、写作、翻译、摘要；需要开放式创作的任务，如代码生成、故事创作、图像生成；需要复杂推理和规划的任务，如多步推理、工具调用、任务规划。

这些场景的共同点是：输出空间是开放的，无法用有限的标签或分数来覆盖；任务本身需要“生成”这个动作，而不是“判断”。

6.3 选型决策的实用 checklist

在实际项目中做技术选型时，我通常会问以下几个问题：

• 这个任务的输出是封闭的还是开放的？封闭输出优先决策模型。
• 这个任务对延迟的要求是多少？毫秒级优先决策模型。
• 这个任务的日请求量是多少？百万级以上优先决策模型。
• 这个任务需要可解释性吗？需要优先决策模型。
• 这个任务需要生成自然语言吗？需要则选生成式模型。
• 这个任务的标注数据充足吗？不充足则考虑生成式模型做冷启动。

这个 checklist 不是绝对的，但能帮助快速缩小选型范围。我个人的体会是：大多数业务场景其实不需要生成式模型，只是大家习惯性地往那个方向想。把问题拆解清楚，往往会发现决策模型是更务实的选择。

6.4 从生成式到决策式的迁移经验

如果你正在考虑把一个生成式模型的任务迁移到决策模型，以下经验可能有用。

首先，重新定义任务。生成式模型的任务定义通常是“输入X，输出一段文本Y”；决策模型的任务定义需要变成“输入X，输出一个标签或分数Y”。这个转换过程需要和业务方充分沟通，确保新的任务定义能覆盖业务需求。

其次，复用生成式模型的中间表示。生成式模型的编码器部分通常已经学到了很好的语义表示，可以把这部分冻结，只训练后面的决策头。这样既能利用预训练的知识，又能大幅降低训练成本。

最后，逐步迁移而不是一次性替换。先让决策模型和生成式模型并行运行，对比两者的效果和成本。确认决策模型在核心指标上不落后后，再逐步把流量切换过去。这样风险可控，也能给团队足够的适应时间。

踩过几次坑之后，我越来越觉得：技术选型的关键不是追求最先进的技术，而是找到最适合当前业务场景的技术。决策模型和生成式模型各有各的适用场景，把它们放在正确的位置上，才能发挥最大的价值。