1. 项目缘起：当LLM调用成本成为瓶颈

最近在折腾几个AI应用项目，无论是内部的知识库问答机器人，还是面向用户的创意生成工具，都绕不开一个核心组件：大语言模型（LLM）。项目初期，为了快速验证想法，我们通常会把所有请求都指向一个模型，比如GPT-4。效果确实惊艳，但账单也相当“惊艳”。随着用户量增长，一个月的API调用费用轻松突破五位数，这还没算上偶尔的流量高峰。

更头疼的是，我们发现用户的需求是分层的。80%的日常查询，比如简单的信息提取、格式转换、基础文案，用GPT-3.5甚至更轻量的开源模型（如Qwen-7B）就能处理得很好，响应速度还更快。但剩下20%的复杂逻辑推理、创意写作或代码生成，又确实需要GPT-4这类“重型武器”才能保证质量。如果全部用顶级模型，是巨大的资源浪费；如果全部用廉价模型，关键时刻又容易掉链子，影响用户体验。

于是，一个很自然的想法就冒出来了：能不能做一个智能的“调度员”？它能根据用户请求的“难度”或“类型”，自动把请求路由到最合适（通常是性价比最高）的模型上去，从而实现效果和成本的最优平衡。这就是“自适应路由”的核心诉求。市面上已经有一些方案，比如基于规则的路由（“如果问题包含‘代码’，就路由到Code Llama”），或者基于请求内容简单分类的路由。但这些方法要么不够灵活，需要人工维护大量规则；要么分类粗糙，无法精准评估问题本身的复杂度和对模型能力的需求。

直到我们开始仔细审视LLM服务本身产生的一样东西：日志。每一次API调用，无论成功失败，服务商（如OpenAI、Anthropic）或我们自建的模型服务，都会产生包含丰富信息的日志。这些日志里，藏着评估请求“成本”和“难度”的黄金指标。基于这个发现，我们启动了一个内部项目，并将其命名为TRACER。它的目标很明确：零成本地构建一个自适应路由系统。这里的“零成本”不是指服务器不要钱，而是指不依赖额外的标注数据、不进行复杂的模型微调、不引入新的昂贵外部服务，完全利用现有的、免费的LLM生产日志作为“燃料”，来训练这个智能调度员（路由模型）的判断能力。

2. TRACER系统核心设计：日志即监督信号

TRACER系统的设计哲学非常直接：向历史要答案。我们不再去猜测一个请求该用哪个模型，而是去翻看历史记录，看看“历史上”类似的请求，用哪个模型处理的效果最好、成本最低。这里的“效果”和“成本”，都直接来自于生产日志。

2.1 从生产日志中提取关键特征

LLM的生产日志通常包含结构化数据。对于一个完整的请求-响应周期，我们可以提取出以下多维特征，这些特征共同构成了路由决策的“依据”：

1. 请求内容特征：

   • 文本长度：用户输入的Token数量。通常，长文本可能意味着更复杂的任务。
   • 关键词与意图：通过简单的关键词匹配或轻量级文本分类（如fastText）提取的领域标签（如“编程”、“客服”、“创作”）。
   • 文本复杂度：可计算一些简单的语言学指标，如平均句长、罕见词比例、依存句法树的深度等。

2. 模型响应特征（来自日志）：

   • 响应时间：从发送请求到收到完整响应的延迟。这反映了模型的计算负载和当前服务状态。
   • 输出Token数：模型生成内容的长度。它与计费直接相关，是成本的核心组成部分。
   • Finish Reason：模型停止生成的原因，如stop（遇到停止词）、length（达到最大生成长度）、content_filter（内容过滤）。length可能意味着回答被截断，暗示问题可能需要更长的上下文或更深入的生成。

3. 隐式质量与成本信号（核心监督信号）：

   • 用户反馈信号：如果应用前端有“点赞/点踩”或“重新生成”按钮，这些交互日志是宝贵的质量标签。一次“点踩”后用户选择了“用GPT-4重新生成”，那么这次路由（如果用到了廉价模型）就是一次失败的负样本。
   • 链式调用模式：在Agent或工作流中，一个LLM的输出可能作为下一个LLM的输入。如果某个模型的输出频繁导致下游步骤失败或需要重试，这间接反映了其输出质量可能不稳定。
   • 成本：直接来自计费日志，即(输入Token数 + 输出Token数) * 模型单价。这是最直接的优化目标之一。

TRACER的核心任务，就是学习一个函数F(请求特征) -> 推荐模型。而这个函数的训练数据，不是人工标注的，正是从上述日志中自动构建的。

2.2 构建自监督训练数据

这是实现“零成本”的关键。我们不需要人工去为每一条历史请求打上“该用哪个模型”的标签。相反，我们利用日志中的“结果”来反推“最优选择”。

假设我们历史上有三个可用的模型后端：Model-Cheap(低成本，能力较弱)，Model-Mid(中等成本/能力)，Model-Expensive(高成本，能力强)。

对于一条历史日志记录，我们提取了它的请求特征X。当时，它被路由到了Model-Mid，并产生了日志结果R（包含响应时间、输出长度、用户反馈等）。

如何判定这次路由是否“正确”或“优秀”？

我们设计了一个综合收益函数Score(R)来量化这次调用的“好坏”。一个简单的版本可以是：Score = α * (质量指标) - β * (成本指标) - γ * (延迟指标)其中，α, β, γ 是权重系数，可以根据业务优先级调整。

• 质量指标：如果有直接的用户正反馈（点赞），则为 +1；负反馈（点踩）则为 -1；无反馈则为 0。更复杂的，可以用后续链式调用的成功率来加权。
• 成本指标：可以归一化后的调用成本。
• 延迟指标：归一化后的响应时间。

现在，对于同一条请求特征X，我们虽然不知道如果当时用了Model-Cheap或Model-Expensive会怎样，但我们可以做一个反事实估计。一种实用的方法是：

1. 寻找相似请求：在日志中，寻找与X在请求特征上最相似的K条记录，但这些记录是路由到其他模型（如Model-Cheap）的。
2. 估计收益：计算这些相似请求在各自模型下的平均Score。假设我们估算出，对于类似X的请求，用Model-Cheap的平均得分是S_cheap，用Model-Expensive的平均得分是S_expensive。
3. 生成训练样本：比较S_mid(本次实际得分),S_cheap,S_expensive。得分最高的那个模型，就被认为是处理X这类请求的“潜在最优模型”。于是，我们就得到了一条训练数据：(特征 X, 标签 Y=潜在最优模型)。

通过这种方式，我们海量的、无标注的生产日志，就被自动转化成了带有“路由标签”的训练数据集。这个过程完全自动化，无需人工干预，实现了“零成本”数据标注。

2.3 路由模型的选择与训练

有了训练数据，下一个问题是：用什么模型来做路由决策？

我们的目标是极低延迟和低成本。因为路由决策本身也是一次计算，如果它太慢或太贵，就失去了节省成本的意义。因此，重型模型（如另一个LLM）首先被排除。

轻量级分类模型是首选，例如：

• 逻辑回归 / 线性模型：速度快，可解释性强。可以将文本特征通过轻量级编码（如TF-IDF）后输入。
• 梯度提升树：如XGBoost、LightGBM。这类模型对表格型数据（即我们提取的各类数值和类别特征）处理效率极高，效果通常比线性模型好，且能捕捉非线性关系。
• 小型神经网络：如简单的多层感知机（MLP）。如果特征维度较高，神经网络可能更有优势，但需要权衡其推理速度。

在TRACER中，我们最终选择了LightGBM。原因如下：

1. 效率：训练和预测速度极快，单次路由决策通常在毫秒级。
2. 性能：在处理由数值、类别特征混合构成的表格数据上，表现通常优于其他传统方法。
3. 特征重要性：训练完成后，我们可以直观地看到哪些特征（如“输入长度”、“包含代码关键词”）对路由决策影响最大，这有助于我们理解系统行为和进行调试。
4. 稀疏特征友好：对于关键词等形成的稀疏特征，LightGBM能很好地处理。

训练过程就是标准的监督学习：输入是请求特征向量，输出是模型类别的标签（如0,1,2分别代表三个候选模型）。我们使用交叉验证来防止过拟合，并持续监控在验证集上的准确率。

3. 系统架构与工作流

TRACER不是一个孤立的算法，而是一个需要嵌入到现有LLM服务架构中的系统。下图展示了其核心工作流：

用户请求 │ ▼ [ 网关/代理层 ] │ ├─────────────────────────────────────┐ │ │ ▼ │ [ TRACER 路由引擎 ] │ │ │ ▼ │ (根据特征实时预测) │ │ │ ▼ │ [ 路由至最优模型后端 ] │ │ │ ▼ │ [ LLM 服务 (如 OpenAI, 本地模型) ] │ │ │ ▼ │ [ 返回响应给用户 ] │ │ │ ▼ │ [ 日志收集系统 ] ◄─────────────────────────┘ │ ▼ [ 日志存储 (如 ES, Kafka) ] │ ▼ [ 离线特征工程与训练管道 ] (定期运行，如每天) │ ▼ [ 更新 TRACER 路由模型 ]

3.1 在线推理流程

1. 请求拦截：所有LLM请求首先到达一个统一的网关（例如用Python的FastAPI或Go实现）。
2. 特征提取：网关实时提取当前请求的静态特征（如Token数、关键词）。
3. 路由决策：将特征向量输入到已加载的TRACER LightGBM模型中，模型输出一个概率分布或直接的模型ID。
4. 请求转发：网关将用户请求转发给TRACER推荐的后端模型服务。
5. 日志记录：无论成功与否，本次请求的完整上下文（原始请求、路由决策、响应结果、延迟、Token用量等）都被异步发送到日志系统。

3.2 离线训练与更新流程

1. 日志消费：定期（如每小时/每天）从日志存储中拉取一个时间窗口内的新日志。
2. 数据清洗与特征工程：重复在线特征提取的过程，并为每条日志计算其“综合收益”分数。
3. 构建训练集：运行前面提到的“相似请求查找与反事实估计”算法，为每条日志生成一个“潜在最优模型”标签。
4. 模型训练：使用新的训练数据，重新训练LightGBM路由模型。可以采用全量训练，也可以采用增量学习更新现有模型。
5. 模型验证与部署：在独立的验证集上评估新模型性能。如果效果提升（或至少不下降），则将其热更新到在线网关中，替换旧模型。这个过程最好能做到自动化、可回滚。

注意：模型更新频率需要权衡。更新太频繁，系统行为不稳定；更新不及时，无法反映最新的用户行为模式和数据分布。建议从每天更新开始，根据监控指标进行调整。

4. 关键实现细节与避坑指南

在实际搭建TRACER的过程中，我们遇到了不少坑，也总结出一些让系统更稳健的经验。

4.1 特征工程中的“辛普森悖论”

最初，我们只用“输入Token数”和“是否包含编程关键词”两个特征。训练出的模型倾向于将所有长文本都路由到最贵的模型。上线后，总成本确实没降多少。后来分析发现，这是因为长文本中既包含复杂的分析任务（需要强模型），也包含简单的文档摘要（廉价模型即可）。这就是特征过于粗糙导致的“辛普森悖论”——在分组（复杂vs简单）内部关系与整体关系相反。

解决方案：引入更细粒度的文本特征。

• 句法复杂度：使用spacy等工具计算平均依存路径长度。
• 语义密度：通过轻量级句子嵌入（如Sentence-Transformers的all-MiniLM-L6-v2）计算输入文本与一些典型任务模板（如“写一首诗关于...”、“总结以下文章”、“调试以下代码错误”）的余弦相似度，作为多个特征。
• 领域分类器：训练一个简单的多标签分类器（如使用scikit-learn的OneVsRestClassifier+LogisticRegression），识别请求属于“创意写作”、“逻辑推理”、“信息提取”、“代码生成”等中的哪些类别，输出概率作为特征。

这些特征帮助模型区分了“长的简单文本”和“长的复杂文本”，路由精度大幅提升。

4.2 冷启动与探索-利用困境

系统刚上线时，历史日志很少，特别是对于新出现的请求类型，没有足够的历史数据来评估哪个模型好。如果模型过于“自信”，可能会一直将新类型请求路由到一个次优的模型，无法收集到其他模型的数据，陷入局部最优。

解决方案：实现一个简单的ε-greedy策略。

• 在路由决策时，以一个小概率ε（如5%）随机选择一个非推荐模型。
• 这部分“探索性”的流量，虽然短期内可能效果不佳或成本更高，但为系统收集了至关重要的对比数据，用于后续模型训练。
• ε的值可以随着系统运行时间增长而逐渐衰减。

4.3 模型偏差与反馈延迟

路由模型是从历史数据中学的，如果历史数据本身存在系统性偏差，模型就会继承并放大这种偏差。例如，早期因为担心质量，人工干预将很多中等难度请求都路由给了贵模型，那么日志中就会充斥“中等难度请求+贵模型+高收益”的数据。训练出的新模型会认为这是最优解，从而无法将这类请求降级到廉价模型。

解决方案：引入延迟反馈校正和公平性约束。

• 延迟反馈：用户的正负反馈可能不会立即产生。系统需要能够关联一段时间后的反馈与之前的请求。这要求日志系统有强大的request_id链路追踪能力。
• 公平性采样：在构建训练集时，可以有意识地对“被廉价模型处理且获得好评”的样本进行过采样，对“被贵模型处理但反馈平平”的样本进行欠采样，以平衡数据集，纠正历史偏差。
• 在线学习：对于实时收到的强负反馈（如点踩），可以立即生成一个负样本（特征X， 标签=当前使用模型）用于模型的在线微调或记录，加速模型修正。

4.4 成本与延迟的权衡

综合收益函数Score = α * Quality - β * Cost - γ * Latency中的权重α, β, γ是业务决策的体现。

• 如果追求极致用户体验（如面向C端的聊天产品），可以设置α很高，β较低。
• 如果是对成本敏感的内部工具，可以调高β。
• 如果是实时交互应用，γ的权重也需要加大。

实操建议：不要凭感觉设置。可以先用历史数据，以不同的权重组合模拟运行一段时间，观察在“质量满意度”、“平均成本”、“P95延迟”等核心指标上的变化曲线，找到符合业务目标的平衡点。这是一个需要持续调优的过程。

5. 效果评估与监控体系

一个系统上线不是终点，必须有一套监控体系来确保其持续有效运行。

5.1 核心评估指标

1. 成本节约率：(基准总成本 - TRACER总成本) / 基准总成本 * 100%。基准可以是全量使用最贵模型的成本，也可以是上线前一段时间的平均成本。
2. 质量保持度：用户正面反馈率（点赞率）或任务完成成功率（在有多轮交互的场景中）不应有显著下降。可以设置一个阈值，例如下降不超过5%。
3. 路由准确率：在离线评估中，我们可以定义“准确率”。如果一条请求，TRACER推荐了模型A，而根据事后综合收益计算，模型A确实是所有可用模型中收益最高的，则计为一次正确路由。这个指标用于衡量模型本身的学习能力。
4. 模型覆盖率：观察各个后端模型接收到的流量比例。理想情况下，能力强的贵模型只处理少量复杂请求，大部分流量应被导向性价比高的模型。如果某个模型流量为0，可能意味着路由策略过于激进或该模型配置有问题。

5.2 监控大盘与告警

建立一个实时监控仪表盘，至少包含以下视图：

• 流量与成本趋势：展示总请求量、各模型调用量、实时估算成本。
• 路由分布：饼图或堆叠柱状图，展示当前时间段内请求被路由到各个模型的比例。
• 性能与质量：展示各模型的平均响应时间、错误率、以及用户反馈的正负比例。
• 异常检测：设置告警规则。例如：
  • 当最贵模型的调用比例连续1小时超过阈值（如30%）。
  • 当总体用户负反馈率突然飙升。
  • 当某个模型的平均响应时间异常延长。

5.3 A/B测试验证

在全面推广前，一定要进行A/B测试。将一小部分流量（如10%）随机分配，不经过TRACER路由，而是采用旧策略（如全量固定模型或简单规则路由）。对比实验组（TRACER）和对照组在核心指标上的差异，用统计方法确认TRACER带来的提升是显著的，而非随机波动。

6. 进阶思考与扩展方向

TRACER的基本框架搭建起来后，还可以向更多有趣的方向扩展。

6.1 从分类到回归：预测收益值

当前系统做的是多分类（选择哪个模型）。一个更精细的做法是训练一个回归模型，直接预测一个请求如果被路由到某个特定模型，其预期的综合收益Score会是多少。在线推理时，分别用同一个请求的特征，对每个候选模型都预测一个收益值，然后选择收益最高的那个。这样做的好处是，收益预测值本身可以作为置信度，如果所有模型预测的收益都很低，可能意味着这是一个全新或异常请求，需要特殊处理（如降级到默认模型并打上标签供后续分析）。

6.2 融入实时系统状态

目前的特征主要基于请求本身。但后端模型的服务状态也是动态的。如果某个模型实例当前负载很高、响应变慢，即使它适合处理某类请求，此时路由过去也会导致体验下降。

扩展：可以从模型服务的监控系统（如Prometheus）中拉取实时指标，作为特征加入路由模型，例如：

• 各模型后端当前的平均响应时间（滑动窗口）。
• 各模型后端的错误率。
• 各模型后端的可用性状态。

这样，TRACER就能实现动态的、感知系统负载的“弹性路由”。

6.3 处理超大规模模型池

当可选的模型非常多（例如十几个不同的开源和商用模型）时，为每个模型都预测收益可能计算量较大。可以考虑分层路由策略：

1. 第一层：一个快速的二分类器，判断请求属于“简单/常规”还是“复杂/特殊”。
2. 第二层：如果是“简单/常规”，从一个由多个廉价、快速模型组成的池子里，用更精细的特征选择最优的一个。如果是“复杂/特殊”，则从一个由少数几个强大模型组成的池子里选择。

这种分而治之的策略可以降低单个模型的复杂度，提高整体路由效率。

TRACER项目的实践告诉我们，在LLM应用走向大规模生产的过程中，“精细化运营”的价值丝毫不亚于模型本身的性能提升。通过巧妙利用系统自身产生的数据，我们能够以极低的边际成本，构建出智能的调度系统，在效果、成本和速度之间找到最佳平衡点。这不仅仅是节省开支，更是让整个AI服务架构变得更智能、更自适应、更具弹性。整个实现过程没有依赖任何神秘的黑科技，核心在于对业务数据的深刻理解、对机器学习原理的扎实应用，以及一个持续迭代的工程闭环。如果你也在为LLM的调用成本发愁，不妨从梳理你的日志开始，或许下一个优化点就藏在其中。