推理深度、延迟与成本：基于升级路由的设计指南

为什么单一模型策略注定失败

大多数团队在构建 LLM 应用时，都会经历同一个陷阱：先用最强的模型跑通流程，然后发现延迟和账单同时失控。一个用于查询汇率的请求，和一个需要多步政策推理的合规分析，消耗的是同样的计算资源。

这份设计指南提出了一条清晰的破局路径：用升级式路由（Escalation-Based Routing）替代一刀切的模型选择，让每个请求只获得它真正需要的推理深度。

推理深度、延迟与成本的设计权衡

先诊断，再开方：五种典型症状

在动手改造架构之前，需要先定位问题到底出在哪一层。指南提供了一张诊断表，将常见症状映射到可能的主因和检查项：

延迟极低但回答模糊：通常是模型本身的推理深度不够，需要检查请求所需的链式推理步骤或策略细节是否被满足。
延迟飙升但成本可控：小模型被迫反复重试或退化为启发式规则，应审查 token 用量和推理调用次数。
每千 token 成本高但延迟可接受：大概率是用大模型处理了简单任务，需要核实路由规则中的「简单」映射。
同类请求的策略合规性不一致：检索上下文缺失或过期，需要确认检索组件拉取的是最新权威来源。
频繁升级到最大模型：推理预算阈值定义过于宽松，或风险阈值设得太低。

这张表的核心价值在于：它把「模型表现不好」这个笼统感受，拆解成了可定位、可修复的具体环节。症状是线索，不是根因证明——在归咎于模型预训练能力之前，先排查标签质量、上下文缺失和预处理管线。

三层升级架构的决策逻辑

整个架构的核心是一个简单的决策流：

请求是否属于「简单任务」？—— 单次查询、无需多步推理、确定性规则校验
如果是，路由到小模型；如果不是，检查延迟预算是否充足
延迟预算充足，路由到中模型；不足，直接升级到大模型

这里的关键概念是推理预算（Reasoning Budget）：由 token 数 × 成本 × 最大延迟三个维度共同定义，并暴露一个「预算超限」标志。

模型池至少需要三个层级：小模型（快速、廉价、深度有限）、中模型（延迟与推理能力均衡）、大模型（最高推理深度、更高成本）。每个层级通过统一的推理 API 暴露，并报告各自的 token 速率和单价。

LLM 路由（LLM Routing） 是这一架构的上位概念：在多个候选模型之间，依据请求特征动态选择最合适的一个，而非固定使用单一模型。业界常见的路由策略包括：基于规则的静态路由（按关键词或请求类型硬编码）、基于分类器的学习型路由（训练一个小模型预测请求难度）、以及本文采用的升级式路由（从低成本层级起步，预算超限时逐级上升）。升级式路由的优势在于决策成本极低（只需一次轻量判断），且天然带有「失败安全」特性——最坏情况下请求最终仍会落到大模型，不会因分类错误而永远得不到高质量回答。其代价是复杂请求可能要付出两次推理的延迟开销，因此对延迟预算的估算需要留有余量。

六个核心组件的职责划分

架构的清晰度取决于职责边界的清晰度。这份设计将系统拆分为六个关键组件：

请求路由器 负责对传入载荷进行分类（简单 vs. 复杂），并基于决策流选择初始模型层级。它消费请求元数据，并咨询推理预算引擎。

推理预算引擎 计算当前层级的预算——token × 成本 × 最大延迟——并暴露「预算超限」标志。它读取定价表、延迟 SLA 和请求复杂度估算。

成本/延迟监控器 记录每次请求的实际 token 消耗、墙钟延迟和货币成本，并将数据反馈给路由器用于自适应节流。当 SLA 漂移时触发告警。

模型池 持有至少三个模型变体，对外暴露统一的推理 API。

检索层 仅为需要事实基座的上下文提供外部最新文档（RAG），但绝不允许替代确定性规则评估。

确定性规则引擎 在 LLM 之外运行，强制执行必须 100% 正确的业务关键策略（如合规阈值）。LLM 可以建议规则，但引擎负责验证。

此外，可选的 微调 / LoRA 服务 在提示工程和检索被证明不够用时才介入，训练低秩适配器。适配器在评估通过后冻结，仅在回归测试通过时才合并用于推理。

LoRA（Low-Rank Adaptation，低秩适配） 是一种参数高效微调技术。它不修改基础模型的原始权重，而是在 Transformer 的注意力层中注入一对小尺寸的低秩矩阵（A 和 B），训练时只更新这两个矩阵。由于参数量通常只占原模型的 0.1%–1%，LoRA 大幅降低了显存占用和训练成本，并允许为不同任务训练多个适配器、在推理时按需加载或切换。需要强调的是，LoRA 冻结的是基础权重，但适配器引入的行为改变仍可能影响模型在目标任务之外的表现，因此「训练—评估—冻结—回归测试—合并」这条流水线中的回归测试环节不可省略。

RAG（Retrieval-Augmented Generation，检索增强生成） 指在生成回答之前，先从外部知识库中检索相关文档片段，并将其作为上下文拼入提示词。它让模型能够访问训练数据之外的、时效性更强的事实信息，因此在汇率、政策条款这类频繁变动的场景中被广泛采用。但必须区分「事实基座」与「事实正确性」：RAG 只是把候选证据递交给模型，模型是否忠实引用、检索结果本身是否权威、文档是否过期，都不在 RAG 的保证范围内。这也是文章强调实时值必须走独立 API 而非缓存进提示的根本原因——检索层无法替代对时效性有硬要求的确定性取值。

两条关键架构决策记录

ADR 001：采用升级式模型选择

背景：平台同时处理高吞吐查询和低吞吐策略分析。早期原型用单一大型模型，导致大部分流量的延迟不可接受，计算支出膨胀。

决策：采用三层升级策略（小 → 中 → 大），由推理预算引擎治理。路由器基于轻量静态分析（token 估算、链式推理线索的存在）将每个请求初步分类为「简单」或「复杂」。如果首次推理后预算超限，系统自动重新路由到下一层。

验收标准：95% 的请求在其分配层级的延迟 SLA 内完成；日均计算成本相比单模型基线降低 ≥ 30%；引入升级机制后策略违规事件不增加。

ADR 002：实时值检索保持在 LLM 推理之外

背景：部分欺诈检测请求需要最新汇率。早期设计将汇率缓存到提示中以避免额外调用，导致缓存过期时偶发合规错误。

决策：引入工具/API 组件，由 LLM 通过函数调用风格的提示来调用。该组件在请求时从权威服务获取值，实时值调用的结果永不缓存。

验收标准：每次实时值请求恰好触发一次外部 API 调用；可审计日志显示获取值的时间戳与请求时间戳匹配在 ±5 秒内；上线后无因数据过期导致的合规测试失败。

教学示例：Python 决策助手的设计思路

指南提供了一个教学性质的 Python 模块，演示预算计算和路由逻辑。核心函数 _budget_exceeded 同时检查三个条件：预估 token 数乘以单价得到的成本是否在阈值内、实际延迟是否满足层级 SLA、token 数是否超出模型上下文窗口。三个条件全部满足才不升级。

decide_model 函数则从「简单请求从小模型起步」开始，测量已消耗时间，若预算超限则升级到大模型。所有配置常量（成本、延迟上限、token 上限）都作为占位符，生产系统应从中心化策略存储中注入真实值。

这段代码的工程价值不在于逻辑复杂度，而在于它把「何时升级」这个模糊判断变成了三个可量化、可配置、可测试的条件。

推理预算（Reasoning Budget） 与传统的成本预算不同，它是一个多维约束而非单一金额上限。文章将其定义为 token 数、货币成本、最大延迟三者的共同约束，意味着一次请求只有在三个维度同时满足时才被视为「预算内」。这种设计的工程意义在于：延迟和成本往往呈反向权衡（大模型更贵但可能一次做对，小模型便宜但可能反复重试反而更慢），单看任一指标都会做出错误决策。将三者打包成布尔标志「预算超限」，则把复杂的多目标优化简化成了一个可测试的升级触发条件，这也是示例代码 _budget_exceeded 同时检查三个条件的原因。

评估与维护的多源共识

无论参考哪一方的实践指南，以下检查项都反复出现：

decide_model 的单元测试必须覆盖简单/复杂、预算超限和时间边界场景
用模拟延迟和成本曲线做端到端路由集成测试
确定性规则引擎输出的回归测试套件必须在任何 LoRA 更新后保持不变
验证成本/延迟监控器报告的每层平均值与 SLA 表匹配
抽样检索增强提示，验证事实基座是否与源文档一致
每季度检查推理预算引擎的阈值是否仍与业务风险容忍度对齐

指南特别强调了几条编辑准确性原则，它们在不同来源中形成了共识：RAG 改善事实基座但不保证正确性、完整性或合规性；LoRA 冻结基础模型权重并学习低秩更新，但不保证所有先前行为被保留，需要在目标任务之外做回归测试；实时值 API 必须在请求时调用，缓存或过期值在任何合规敏感操作中都是不可接受的。

这套设计真正解决了什么

升级式路由的本质，是把「模型能力」从一个全局配置项变成了一个按请求动态分配的资源。通过显式定义升级路径、量化推理预算、将确定性逻辑与概率推理分离，团队可以同时保持低延迟、成本与请求真实难度成比例、以及能力与任务复杂度的对齐。

这不是一个追求极致性能的方案，而是一个追求可控性的工程框架。它的价值在规模化时才会真正显现——当每天处理百万级请求时，30% 的成本降低和 95% 的 SLA 达标率，远比在个别困难任务上多几个百分点的准确率更有意义。