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的生产日志通常包含结构化数据。对于一个完整的请求-响应周期我们可以提取出以下多维特征这些特征共同构成了路由决策的“依据”请求内容特征文本长度用户输入的Token数量。通常长文本可能意味着更复杂的任务。关键词与意图通过简单的关键词匹配或轻量级文本分类如fastText提取的领域标签如“编程”、“客服”、“创作”。文本复杂度可计算一些简单的语言学指标如平均句长、罕见词比例、依存句法树的深度等。模型响应特征来自日志响应时间从发送请求到收到完整响应的延迟。这反映了模型的计算负载和当前服务状态。输出Token数模型生成内容的长度。它与计费直接相关是成本的核心组成部分。Finish Reason模型停止生成的原因如stop遇到停止词、length达到最大生成长度、content_filter内容过滤。length可能意味着回答被截断暗示问题可能需要更长的上下文或更深入的生成。隐式质量与成本信号核心监督信号用户反馈信号如果应用前端有“点赞/点踩”或“重新生成”按钮这些交互日志是宝贵的质量标签。一次“点踩”后用户选择了“用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会怎样但我们可以做一个反事实估计。一种实用的方法是寻找相似请求在日志中寻找与X在请求特征上最相似的K条记录但这些记录是路由到其他模型如Model-Cheap的。估计收益计算这些相似请求在各自模型下的平均Score。假设我们估算出对于类似X的请求用Model-Cheap的平均得分是S_cheap用Model-Expensive的平均得分是S_expensive。生成训练样本比较S_mid(本次实际得分),S_cheap,S_expensive。得分最高的那个模型就被认为是处理X这类请求的“潜在最优模型”。于是我们就得到了一条训练数据(特征 X, 标签 Y潜在最优模型)。通过这种方式我们海量的、无标注的生产日志就被自动转化成了带有“路由标签”的训练数据集。这个过程完全自动化无需人工干预实现了“零成本”数据标注。2.3 路由模型的选择与训练有了训练数据下一个问题是用什么模型来做路由决策我们的目标是极低延迟和低成本。因为路由决策本身也是一次计算如果它太慢或太贵就失去了节省成本的意义。因此重型模型如另一个LLM首先被排除。轻量级分类模型是首选例如逻辑回归 / 线性模型速度快可解释性强。可以将文本特征通过轻量级编码如TF-IDF后输入。梯度提升树如XGBoost、LightGBM。这类模型对表格型数据即我们提取的各类数值和类别特征处理效率极高效果通常比线性模型好且能捕捉非线性关系。小型神经网络如简单的多层感知机MLP。如果特征维度较高神经网络可能更有优势但需要权衡其推理速度。在TRACER中我们最终选择了LightGBM。原因如下效率训练和预测速度极快单次路由决策通常在毫秒级。性能在处理由数值、类别特征混合构成的表格数据上表现通常优于其他传统方法。特征重要性训练完成后我们可以直观地看到哪些特征如“输入长度”、“包含代码关键词”对路由决策影响最大这有助于我们理解系统行为和进行调试。稀疏特征友好对于关键词等形成的稀疏特征LightGBM能很好地处理。训练过程就是标准的监督学习输入是请求特征向量输出是模型类别的标签如0,1,2分别代表三个候选模型。我们使用交叉验证来防止过拟合并持续监控在验证集上的准确率。3. 系统架构与工作流TRACER不是一个孤立的算法而是一个需要嵌入到现有LLM服务架构中的系统。下图展示了其核心工作流用户请求 │ ▼ [ 网关/代理层 ] │ ├─────────────────────────────────────┐ │ │ ▼ │ [ TRACER 路由引擎 ] │ │ │ ▼ │ (根据特征实时预测) │ │ │ ▼ │ [ 路由至最优模型后端 ] │ │ │ ▼ │ [ LLM 服务 (如 OpenAI, 本地模型) ] │ │ │ ▼ │ [ 返回响应给用户 ] │ │ │ ▼ │ [ 日志收集系统 ] ◄─────────────────────────┘ │ ▼ [ 日志存储 (如 ES, Kafka) ] │ ▼ [ 离线特征工程与训练管道 ] (定期运行如每天) │ ▼ [ 更新 TRACER 路由模型 ]3.1 在线推理流程请求拦截所有LLM请求首先到达一个统一的网关例如用Python的FastAPI或Go实现。特征提取网关实时提取当前请求的静态特征如Token数、关键词。路由决策将特征向量输入到已加载的TRACER LightGBM模型中模型输出一个概率分布或直接的模型ID。请求转发网关将用户请求转发给TRACER推荐的后端模型服务。日志记录无论成功与否本次请求的完整上下文原始请求、路由决策、响应结果、延迟、Token用量等都被异步发送到日志系统。3.2 离线训练与更新流程日志消费定期如每小时/每天从日志存储中拉取一个时间窗口内的新日志。数据清洗与特征工程重复在线特征提取的过程并为每条日志计算其“综合收益”分数。构建训练集运行前面提到的“相似请求查找与反事实估计”算法为每条日志生成一个“潜在最优模型”标签。模型训练使用新的训练数据重新训练LightGBM路由模型。可以采用全量训练也可以采用增量学习更新现有模型。模型验证与部署在独立的验证集上评估新模型性能。如果效果提升或至少不下降则将其热更新到在线网关中替换旧模型。这个过程最好能做到自动化、可回滚。注意模型更新频率需要权衡。更新太频繁系统行为不稳定更新不及时无法反映最新的用户行为模式和数据分布。建议从每天更新开始根据监控指标进行调整。4. 关键实现细节与避坑指南在实际搭建TRACER的过程中我们遇到了不少坑也总结出一些让系统更稳健的经验。4.1 特征工程中的“辛普森悖论”最初我们只用“输入Token数”和“是否包含编程关键词”两个特征。训练出的模型倾向于将所有长文本都路由到最贵的模型。上线后总成本确实没降多少。后来分析发现这是因为长文本中既包含复杂的分析任务需要强模型也包含简单的文档摘要廉价模型即可。这就是特征过于粗糙导致的“辛普森悖论”——在分组复杂vs简单内部关系与整体关系相反。解决方案引入更细粒度的文本特征。句法复杂度使用spacy等工具计算平均依存路径长度。语义密度通过轻量级句子嵌入如Sentence-Transformers的all-MiniLM-L6-v2计算输入文本与一些典型任务模板如“写一首诗关于...”、“总结以下文章”、“调试以下代码错误”的余弦相似度作为多个特征。领域分类器训练一个简单的多标签分类器如使用scikit-learn的OneVsRestClassifierLogisticRegression识别请求属于“创意写作”、“逻辑推理”、“信息提取”、“代码生成”等中的哪些类别输出概率作为特征。这些特征帮助模型区分了“长的简单文本”和“长的复杂文本”路由精度大幅提升。4.2 冷启动与探索-利用困境系统刚上线时历史日志很少特别是对于新出现的请求类型没有足够的历史数据来评估哪个模型好。如果模型过于“自信”可能会一直将新类型请求路由到一个次优的模型无法收集到其他模型的数据陷入局部最优。解决方案实现一个简单的ε-greedy策略。在路由决策时以一个小概率ε如5%随机选择一个非推荐模型。这部分“探索性”的流量虽然短期内可能效果不佳或成本更高但为系统收集了至关重要的对比数据用于后续模型训练。ε的值可以随着系统运行时间增长而逐渐衰减。4.3 模型偏差与反馈延迟路由模型是从历史数据中学的如果历史数据本身存在系统性偏差模型就会继承并放大这种偏差。例如早期因为担心质量人工干预将很多中等难度请求都路由给了贵模型那么日志中就会充斥“中等难度请求贵模型高收益”的数据。训练出的新模型会认为这是最优解从而无法将这类请求降级到廉价模型。解决方案引入延迟反馈校正和公平性约束。延迟反馈用户的正负反馈可能不会立即产生。系统需要能够关联一段时间后的反馈与之前的请求。这要求日志系统有强大的request_id链路追踪能力。公平性采样在构建训练集时可以有意识地对“被廉价模型处理且获得好评”的样本进行过采样对“被贵模型处理但反馈平平”的样本进行欠采样以平衡数据集纠正历史偏差。在线学习对于实时收到的强负反馈如点踩可以立即生成一个负样本特征X 标签当前使用模型用于模型的在线微调或记录加速模型修正。4.4 成本与延迟的权衡综合收益函数Score α * Quality - β * Cost - γ * Latency中的权重α, β, γ是业务决策的体现。如果追求极致用户体验如面向C端的聊天产品可以设置α很高β较低。如果是对成本敏感的内部工具可以调高β。如果是实时交互应用γ的权重也需要加大。实操建议不要凭感觉设置。可以先用历史数据以不同的权重组合模拟运行一段时间观察在“质量满意度”、“平均成本”、“P95延迟”等核心指标上的变化曲线找到符合业务目标的平衡点。这是一个需要持续调优的过程。5. 效果评估与监控体系一个系统上线不是终点必须有一套监控体系来确保其持续有效运行。5.1 核心评估指标成本节约率(基准总成本 - TRACER总成本) / 基准总成本 * 100%。基准可以是全量使用最贵模型的成本也可以是上线前一段时间的平均成本。质量保持度用户正面反馈率点赞率或任务完成成功率在有多轮交互的场景中不应有显著下降。可以设置一个阈值例如下降不超过5%。路由准确率在离线评估中我们可以定义“准确率”。如果一条请求TRACER推荐了模型A而根据事后综合收益计算模型A确实是所有可用模型中收益最高的则计为一次正确路由。这个指标用于衡量模型本身的学习能力。模型覆盖率观察各个后端模型接收到的流量比例。理想情况下能力强的贵模型只处理少量复杂请求大部分流量应被导向性价比高的模型。如果某个模型流量为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 处理超大规模模型池当可选的模型非常多例如十几个不同的开源和商用模型时为每个模型都预测收益可能计算量较大。可以考虑分层路由策略第一层一个快速的二分类器判断请求属于“简单/常规”还是“复杂/特殊”。第二层如果是“简单/常规”从一个由多个廉价、快速模型组成的池子里用更精细的特征选择最优的一个。如果是“复杂/特殊”则从一个由少数几个强大模型组成的池子里选择。这种分而治之的策略可以降低单个模型的复杂度提高整体路由效率。TRACER项目的实践告诉我们在LLM应用走向大规模生产的过程中“精细化运营”的价值丝毫不亚于模型本身的性能提升。通过巧妙利用系统自身产生的数据我们能够以极低的边际成本构建出智能的调度系统在效果、成本和速度之间找到最佳平衡点。这不仅仅是节省开支更是让整个AI服务架构变得更智能、更自适应、更具弹性。整个实现过程没有依赖任何神秘的黑科技核心在于对业务数据的深刻理解、对机器学习原理的扎实应用以及一个持续迭代的工程闭环。如果你也在为LLM的调用成本发愁不妨从梳理你的日志开始或许下一个优化点就藏在其中。
