企业官网建设流程全解析

如果你手里同时握着多个大模型的 API，大概率会遇到一个特别头疼的问题：要么直接用最强的那个，成本高到肉疼；要么省成本用小模型，复杂任务又频繁翻车。这就是典型的"单模型暴力调用"困境。这次要聊的Not Diamond选择器，核心做的事情就是帮你在多个模型之间做智能路由，按请求的实际难度和业务需求，把任务分给最合适的模型，从而在成本、延迟和效果三者之间找到一个可持续的平衡点。我这次分析的样本是llm90这个案例记录，它是一个典型的多场景模型路由落地项目，非常适合正在做大模型应用、搞 AI 产品原型，或者纠结"到底要不要上模型网关"的团队参考。

1. 为什么需要模型选择器：从单模型暴力调用说起

1.1 单一模型调用的三大短板

很多人最初做 AI 应用的时候，思维都是"一个模型打天下"。需求来了，不管是写一句文案、做一段代码补全，还是分析一份 JSON 日志，都往同一个模型上丢。这种用法的好处是简单，但跑一段时间就会发现三个明显问题。

第一个问题是成本结构性浪费。最强模型的按 token 计费通常是小模型的几倍甚至十几倍，但日常请求里至少有一半以上是简单任务，比如中文分词、实体提取、格式化输出、意图识别。这类任务用小模型完全够用，用大模型就是花冤枉钱。第二个问题是响应延迟被某个单一系统的负载绑架。同一个模型扛住所有请求，一旦遇到流量高峰，要么被限流，要么排队，整个应用跟着变慢。第三个问题是任务适配度不足。不同模型在数学推理、代码生成、长文本总结、创意写作这些维度上的能力曲线差异很大，没有哪个模型在任何一个维度上都绝对领先。单一模型等于放弃了在不同能力之间切换的灵活性。

llm90 这个案例里有一个很典型的细节：团队一开始把所有请求都导给某个头部闭源大模型，到了月底一看成本账单，发现光文本分类这一类简单请求就占了 30% 以上的 token 消耗，而这些分类任务的真实难度并不高。这就是暴力调用模式最大的问题——你为了 20% 的困难任务，为剩下的 80% 简单请求支付了不必要的溢价。

1.2 模型选择器到底在解决什么问题

模型选择器（LLM Router）本质上是在模型和应用之间插入一个智能调度层。它不负责生成内容，只负责回答一个问题：当前这个请求，应该交给哪个模型处理更合适。这里的"更合适"不是单纯追求回答质量最高，而是要在质量、成本、延迟、可用性几个维度之间做权衡。

Not Diamond 这类选择器的设计思路很像现实生活里的分诊台。病人来了先不直接找主任医师，而是由分诊台判断病情轻重：感冒发烧挂普通门诊，疑难杂症再转专家。这么做既能保证重病有专家接诊，又能让普通门诊的医生资源被高效利用。放在大模型场景里，普通门诊就是小模型，专家就是大模型，分诊台就是路由选择器。

llm90 案例里，他们把路由层放在应用和多个大模型 API 之间，所有请求先进路由服务，由路由服务根据请求的内容、任务类型、用户指定偏好等因素，决定调用哪一家模型。这样一来，业务代码里不再写死"调用 X 模型"，而是写"我要完成一个什么任务"，模型选择变成了动态行为。这种设计带来的直接好处是，以后有更强的新模型发布，不需要改动业务逻辑，只需要在路由层的模型池里加一个新成员，调整对应策略即可。

2. 核心技术拆解：Not Diamond 的选型逻辑与流程

2.1 路由决策是如何发生的

Not Diamond 的选型过程并不是简单地按关键词打标签，它的核心是一个基于上下文特征的路由策略。当一个新的请求进入时，选择器会先做几件事。

第一件是提取请求特征，包括任务指令本身、用户输入的文本内容、附带的系统提示词，以及一些可以观测的元信息，比如请求来源、用户 ID 所在的分组。第二件是对请求难度做预估，这一步类似给任务"称重"，判断它是简单分类、中等改写还是复杂推理。第三件是根据预先设定的路由策略，在候选模型池里计算每个模型对当前请求的匹配得分。最后，从得分最高的模型开始尝试调用，如果返回结果不满足预设条件，就自动触发降级或重试。

这个流程里最关键的其实是"动态性"。llm90 案例里最初用的是一个固定规则路由，也就是人工写死"包含某些关键词走 A 模型，否则走 B 模型"。这种方案看似可控，实际上一旦用户的表达方式超出规则范围就歇菜，而且规则越多越难维护。Not Diamond 的可配策略更灵活，它允许你按任务类型、期望质量、预算上限、延迟上限等维度做混合决策，而不是简单的 if-else。这意味着你可以对某个请求说"如果预估质量得分低于阈值，就升级到更大模型"，这种思路在小流量下看不出优势，但在大流量下能明显减少无效调用和返工。

2.2 特征、偏好与反馈：三个影响选型的关键维度

要理解选型逻辑，不能只停留在"选择器会做判断"这个层面，得拆开看它到底在依据什么做判断。我整理下来，主要有三个维度。

第一个维度是任务特征。系统需要知道这个请求属于什么类型的任务，比如是结构化数据抽取、自由文本生成，还是多步推理。这个判断可以通过对输入内容的语义分析得到，也可以由调用方显式声明。在 llm90 案例里，他们的做法是两种方案混合使用：能明确声明任务类型的请求走声明，不能声明的走语义特征判断。第二个维度是用户偏好。同一个请求，业务方希望它更便宜还是更准确？是要 200 毫秒内响应还是能接受 2 秒的等待换取更高的质量？这些偏好会被编码成路由参数。比如客服场景里，简单咨询要求低成本快速响应，而复杂的投诉工单则优先保证处理质量，这个差异就是通过偏好参数体现的。第三个维度是历史反馈。路由层会根据过去一段时间内每个模型在不同任务上的实际表现，持续修正后续的选型权重。这个反馈信号很重要，因为模型是会变的，同一个模型在某个版本上的表现和若干个月之后的表现可能差异很大，靠历史打分才能让路由策略不过时。

在实操中，这三个维度的权重并不是平均分配的，需要根据业务跑出来的数据去调。比如你发现延迟超时是主要问题，就把延迟因子调高；如果发现质量投诉增多，就调高质量因子的权重。在 llm90 的配置里，他们对"格式合规性异常"这类问题的反馈信号做了特别加权，因为在数据抽取场景里，哪怕语义正确，只要输出格式不合规，就等于白调一次。这就属于非常典型的经验补全。

2.3 从路由到兜底：一次请求的完整生命周期

只看路由决策本身是不够的，一个生产环境里的模型选择器必须处理"选完之后的异常情况"。llm90 案例里的请求生命周期可以按下面这几步理解。

请求先到达网关层，网关层完成基础的身份验证和流量统计，然后把请求交给路由模块。路由模块根据任务特征和偏好参数，在模型池里生成一个排序列表，选中的模型如果能正常返回结果，就把结果原样回传，同时记录这一次调用的质量打分。如果选中的模型超时、返回格式异常、或者内容安全校验不通过，路由层会按策略直接切换到排序列表里的下一个模型，这个动作称为降级切换。整个切换过程对上层业务透明，用户基本感知不到。

这个生命周期设计里有几个容易被忽略的细节。一个是超时时间不能设置得太短，因为大模型在复杂任务上的推理耗时波动很大，超时阈值设 2 秒可能误杀很多正常的慢请求；另一个是降级不能无限循环，最多尝试两到三个候选模型就应该停止，否则最坏情况下一个请求要等三倍的时间才能返回失败。llm90 这边给每个请求设置了 30 秒的总耗时上限，超过之后直接返回给用户一个兜底文案，同时记录失败原因用于后续优化路由策略。这些边界情况处理好了，路由层才能真正稳定。

3. 接入与集成：把 Not Diamond 装进你的应用

3.1 API 接入与基础配置

接入 Not Diamond 的第一步是申请访问凭证，然后把模型的 API 密钥统一托管到模型池配置里。这里要注意一个设计选择：模型密钥是配置在选择器服务端还是客户端。llm90 的实现里，密钥放在服务端，客户端只持有选择器自己的密钥。好处是模型密钥不会被暴露到终端用户，将来更换模型供应商时也不需要重新发版本给所有客户端。

基础配置里，模型池是核心。你得把要用到的模型全部注册进去，每个模型至少配置四个信息：模型名称、支持的上下文长度、单次调用成本估算值、平均延迟参考值。这些字段会参与路由计算，尤其是成本和延迟字段，如果填的是估算值，路由结果可能和实际账单对不上。所以 llm90 的做法是接一个计量模块，每过一段时间自动从供应商账单接口拉取真实数据，回填到配置表里，保证成本预估不会长期失真。

配置完成之后，最小可用流程是这样的：客户端发起一次请求，带上任务内容和路由参数，选择器根据模型池信息返回一个决策结果，然后把请求转发给选中的模型。这一层如果不做，直接让客户端去调用，未来每次调整模型池，都得在所有客户端里同步修改，那就失去了路由层的意义。所以哪怕最初只接两个模型，我也建议你一开始就走服务端路由，不要图省事。

3.2 与主流框架的集成方式

现在的应用很少是裸调 API，大部分都基于某个 Agent 框架或流程编排工具在跑。Not Diamond 的定位决定了它可以作为这些框架底层的"模型出口"来接入。

集成方式并不复杂。你只需要在框架的模型调用入口处替换成路由客户端的调用方法，原来的"直接给某模型发请求"变成"向选择器发请求，由它分配"。llm90 里，他们的项目同时跑了两类工作流：一类是自主 Agent 流程，Agent 内部多次调用模型；另一类是离线批处理任务。两类流程接入路由层之后，行为表现有明显差异。Agent 流程里，频繁的短请求受益于低延迟模型，整个循环跑下来耗时缩短了接近一半；离线批处理则主要受益于成本优化，因为很多批量文本清洗任务被路由到了低成本模型上。

集成过程中有一个常见坑：框架本身的自动重试机制和路由层的降级机制叠在一起，导致同一个请求被重复调用了好几次。llm90 一开始就在 Agent 框架里保留了默认重试两次的设置，结果路由层超时降级后，框架又对同样的输入重试了一次，单次请求的模型调用量直接翻倍。后面它们的解决办法是统一关闭了框架层的自动重试，把重试和降级逻辑完全收敛到路由层来管理。

3.3 路由策略的配置与调优实践

路由策略的配置是接入过程中最需要耐心的部分。如果你只是想跑通流程，用默认配置就够了；但要让路由效果真正贴合业务，必须经历一轮又一轮的调优。

调优的第一步是定义一个评估集。从历史请求里抽一批有代表性的样本，标注好"这个请求应该用哪个模型""满足什么条件算成功"。llm90 里，它们从三个月的日志里抽了两千条样本，覆盖了代码生成、客服问答、文本摘要、信息抽取四类高频任务，每一类里又区分简单和困难两个难度档。这样做的目的是让策略调整有可量化的依据，而不是靠感觉。

第二步是跑基线对比。把所有样本强制分配给某个单一模型，记录成本、延迟、成功率；然后把样本切到路由模式，用同样的指标口径再跑一遍。这个对比能直观地告诉你，路由到底带来了多少收益，是省了 40% 的成本，还是质量下降了 5 个百分点。llm90 的评估结果里有一个很有意思的发现：路由模式下，整体成功率并没有下降，某些简单任务的成功率反而上升了，因为小模型在简单任务上的专注度更高，输出更稳定，不容易出现大模型"想太多"导致的格式漂移。

第三步是基于对比结果做策略微调。如果某个难度档的任务频繁被路由到大模型，但实际跑出来的质量和用小模型差不多，就说明决策特征里"难度评估"的权重偏保守了。这时候需要调整难度阈值，让更多请求流向低成本模型。这个调整过程一定要小步快跑，每次只改动一个参数，然后重跑评估集，避免多个变量同时变化导致不知道哪个调整起效了。

4. llm90 案例分析：三个典型的落地场景

4.1 场景一：客服工单自动分类

第一个落地场景是客服工单自动分类。这类任务的特点是量大、单次请求语义复杂度低、对响应速度要求高。在直接调用单一模型的模式下，每个工单都走大模型分类，成本和延迟都高，而且大模型在这种重复性高的任务上并没有比小模型好多少。

llm90 给这个场景配置了双模型路由：默认走低成本模型，只有当工单内容里出现产品型号对比、异常行为描述、或多个问题点混合的情况时，路由层才判定为复杂案例，升级到强推理模型。判定依据有两个，一个是关键词特征，另一个是语义困惑度预估。这个"困惑度"概念很有意思，可以类比成"模型对这个请求有多拿不准"。拿不准的请求就升级，拿得准的就留在低成本通道，这套机制跑了一个月之后，简单工单的分类准确率没有下降，但整体调用成本降到了原来的 35% 左右。

实际操作中，我给这个场景调参的时候发现，升级阈值不能设得太灵敏，否则一个工单里只要出现一个稍微不常见的词，就会触发升级，几乎等于没有路由。后来改成"需要同时满足语义困惑度偏高中任务类型为咨询对比类"才升级，误判率才降下来。这个教训是：路由规则的组合条件比单一阈值可靠得多。

4.2 场景二：代码生成与审查

第二个场景偏开发者工具方向，是代码片段生成和代码审查建议。这个场景比客服分类要复杂，因为代码任务里"简单"和"困难"的差距非常大：写一个正则表达式和设计一个完整的模块划分，完全不是一个量级。

llm90 在这里用了分层路由的策略。第一层先判断请求是自然语言描述的需求，还是已有的代码片段。如果是已有代码片段，再判断是"解释逻辑""找错误"还是"补全功能"。不同的子任务类型对应不同的最优模型。比如解释已有代码这种任务，通常不需要特别强的推理能力，但需要模型有较好的忠实度，不要胡编 API；而生成完整函数则对推理能力要求更高，必须分配给强模型。

这个场景里的成本优化效果不如客服分类那么显著，但质量稳定性提升很明显。以前所有代码请求都走同一个模型，偶尔会出现在简单问题上输出过重设计、把代码改复杂了的情况。路由之后，简单任务的小模型输出反而更干净。另外，llm90 针对代码审查场景设置了一个独立的"绝不降级"规则：只要请求类型是"审查"，就不允许路由到比当前更弱的模型上，否则给出的建议质量不可控，这个红线值得借鉴。

4.3 场景三：内容摘要与数据分析

第三个场景是内容摘要和数据分析类的请求。这类请求输入的文本通常很长，token 消耗大，调用成本对模型选择非常敏感。

llm90 在这个场景上做了一个很务实的判断：如果输入内容长度超过一定阈值，优先选择上下文窗口大且单位 token 成本低的模型，而不是一味追求最强推理能力。因为摘要任务的核心瓶颈往往在上下文容纳量和忠实度，而不是数学推理，所以用一个中档模型，配合一个"先提取后总结"的两段式提示词模板，就能达到接近高档模型的效果。

这里我特别想提一个实操细节：摘要类任务一定要把"输入 token 长度"作为一个路由特征纳入决策。llm90 记录过一个典型问题，路由层一开始把长文本摘要请求分配给一个上下文窗口刚够用的模型，结果一旦文本超过窗口上限，框架自动做截断，摘要结果直接缺失了后半部分的关键信息。后面加了长度特征判定，超过窗口安全阈值的请求自动路由到更大窗口模型，这个问题就再没出现过。做内容类应用的朋友，这条经验可以直接抄。

5. 实测中的常见问题与踩坑指南

5.1 路由命中率不稳定的排查思路

很多人接入路由层之后，第一个遇到的困惑就是：怎么感觉选型结果忽好忽坏？今天这类请求走小模型，明天同样类型的请求却走大模型，看起来完全没规律。

这种情况九成以上是特征提取环节出了问题。路由的特征来源如果包含上下文文本，而文本本身内容变化很大，那么同一个任务类型也可能因为表述方式的差异，被判定成不同的难度档。排查方法是先把路由日志打开，逐条查看请求的特征向量和决策过程，重点看是哪个特征让系统选择了大模型。llm90 排查过一个类似的案例：一批客服请求，前面带了"紧急""投诉"等前缀的几乎全部升级到大模型，但实际内容都是很普通的咨询，因为这个前缀词在特征向量里被赋予了过高的权重。解决办法是对特征做归一化处理，或者给任务类型字段设置比文本内容更高的决策权重。

还有一个容易被忽略的点，是模型池里每个模型版本更新会导致行为变化。某个模型发布新版本后，在简单任务上的表现可能略有波动，路由层如果配置了基于历史反馈的权重修正，短期内会把大量请求调去走备选模型，看起来就像"路由突然疯了"。建议每次模型版本更新时，专门做一次针对性的回归评测，确认行为变化后再调整策略参数。

5.2 成本、延迟与质量的三角权衡

模型路由的调优本质是在成本、延迟、质量这三个目标之间找平衡，而且这三个目标不可能同时做到最优，必须有优先级。

llm90 的项目里，他们最开始设定的优先级是质量优先，成本第二，延迟第三，跑了两周之后发现支撑不起业务增长，因为每次请求都倾向于选更强的模型，成本优化形同虚设。后来调整为"在保证最低质量红线的基础上，延迟优先于成本"，整个系统的表现才有了明显改观。这个调整过程告诉我们一个道理：优先级不能靠拍脑袋定，要结合业务的实际压力来定。如果你的业务是用户实时对话，延迟超标的后果是用户流失，那延迟就必须排在成本前面；如果你的业务是离线分析，延迟多点无所谓，成本就是第一指标。

成本优化的具体方法，除了路由到小模型之外，还有两个技巧值得一试。一个是对简单任务开启"最短答案模式"，通过提示词限制输出长度，能显著降低生成 token 数；另一个是合理设置输出上限，很多模型支持的输出长度是可以调的，把输出上限从 4096 收紧到 1024，在摘要类任务上往往能省 60% 的输出成本，而质量几乎不受影响。

5.3 兜底策略与故障转移的设计

最后再专门讲讲兜底。不要以为有了路由层就万事大吉，路由层本身也可能出问题，所以生产部署一定要把故障转移想清楚。

llm90 的兜底设计分了三层。第一层是模型级兜底：首选模型调用失败，自动切换到次选模型。第二层是路由级兜底：如果路由服务本身出现超时或不可用，请求应该直接降级到默认模型，保证业务不中断。第三层是业务级兜底：如果所有模型都不可用，返回给用户一个固定的提示信息，同时把失败请求记入重试队列，等服务恢复后再处理。这个三层设计看起来很完整，但实现的时候有一个细节点容易出错：模型级兜底切换时，要清空第一次调用产生的中间状态和部分输出，否则可能出现"前半段是 A 模型生成，后半段是 B 模型生成"这种拼接错乱的结果。

另外一个建议是给兜底动作加上监控告警。llm90 里，每次降级切换都会打点记录，并设置了一个指标：单小时内降级次数超过 50 次就触发告警。这么做的好处是，当某个模型 API 出现问题，你能在用户察觉之前发现，而不是等投诉来了才去翻日志。生产环境里的路由层不是配置完就结束的，它是一个需要持续观察、持续调整的动态服务。我个人的体会是，路由层最花时间的不是初期接入，而是后面让策略慢慢逼近业务真实需求的过程。每跑一段时间就回头看看路由日志里的成本数据和失败数据，你会发现很多原来以为"不该变成路由"的判断，其实是当时对业务理解不够深。