企业官网建设流程全解析

1. 从单模型硬扛到多模型调度：我为什么要折腾这套网关

去年下半年开始，我手里同时跑着好几个AI应用：一个面向内部知识库的问答助手、一个给运营团队用的文案生成工具、还有一个做结构化信息抽取的小服务。最开始图省事，所有请求都往同一个大模型上怼——反正接口统一、代码简单，一个API Key走天下。结果跑了不到两个月，问题全冒出来了。

最直接的感受就是成本失控。文案生成这种对创意要求高的任务，用大模型确实值；但信息抽取这种活儿，本质上就是"把这段话里的字段抠出来"，用同一个模型纯属杀鸡用牛刀。月底一看账单，抽取类请求占了将近四成调用量，但贡献的业务价值可能连一成都不到。这种感觉就像你打车去楼下便利店买瓶水，车费比水贵十倍。

然后是延迟问题。有些场景用户对响应速度极其敏感，比如内部问答助手，用户问一句"上季度的报销政策是什么"，等三秒和等八秒的体验完全是两回事。但有些任务，比如批量生成周报摘要，跑个十几秒用户根本无所谓。把所有请求塞进同一个模型，等于让所有任务都承受同一个延迟水平，快的不够快，慢的也没必要那么慢。

还有一个容易被忽略的点：质量波动。同一个模型在不同类型的任务上表现差异很大。有的模型写代码强，有的模型中文理解细腻，有的模型在结构化输出上特别稳。你用一个模型去打所有场景，总有一些场景的效果让你想摔键盘。

所以我决定动手搭一套多模型调度网关。核心目标就三个词：成本透明、延迟透明、质量透明。让每个请求走它该走的模型，该省的地方省，该花的地方花，该快的地方快。这套东西我用蓝耘元生代平台做底座，下面把整个设计思路、实操过程和踩过的坑完整拆一遍。

2. 整体架构设计：调度网关到底该怎么分层

2.1 为什么不做简单的if-else路由

一开始我想得很简单：写个函数，判断一下请求类型，然后if-else分发到不同模型不就行了？真动手才发现，事情没那么简单。

第一，模型列表是动态的。今天这个模型便宜，明天可能涨价；今天这个模型响应快，明天可能因为负载高变慢。你硬编码在代码里的路由规则，过两周就过时了。

第二，判断维度不是单一的。你不能只看"任务类型"这一个维度。同样是文案生成，紧急的走快模型，不紧急的走便宜模型；同样是信息抽取，字段多的走强模型，字段少的走轻模型。这是一个多维度决策问题。

第三，你需要数据反馈。哪个模型在哪个任务上表现好，不能靠拍脑袋，得有实际调用数据支撑。没有数据反馈的调度系统，本质上还是拍脑袋。

所以我的架构分成了四层：接入层、决策层、执行层、观测层。接入层负责统一收口所有请求，决策层负责根据规则和数据选择模型，执行层负责实际调用和容错，观测层负责记录每次调用的成本、延迟和质量指标。

2.2 四层架构的职责划分

接入层的核心任务是"统一协议"。不管上层应用用什么格式传参，到了网关这里都归一化成统一的请求对象。这样做的好处是，后面换模型、加模型，上层应用完全无感知。我定义了一个标准的请求结构，包含任务类型、优先级、输入内容、期望输出格式、预算上限等字段。

决策层是整个网关的大脑。它维护一张模型能力表，记录每个模型在不同任务类型上的历史表现、平均延迟、单位成本。当一个请求进来时，决策层根据任务类型、优先级、预算约束等条件，从候选模型列表中选出一个最优解。这里我用的是"规则+评分"的混合策略，纯规则太死板，纯评分又不好控制边界。

执行层负责实际调用。它要处理的事情包括：超时控制、重试策略、降级方案、并发限流。比如你选了模型A，但模型A突然超时了，执行层要能自动降级到模型B，而不是直接把错误抛给用户。

观测层是我最看重的部分。每次调用都会记录：请求ID、任务类型、选中模型、实际延迟、token消耗、成本估算、输出质量评分（如果有反馈的话）。这些数据反过来喂给决策层，形成闭环。

2.3 蓝耘元生代在架构中的角色

蓝耘元生代在这套架构里承担的是模型供给和统一调用的角色。它提供了多模型的统一接口，我不需要自己去维护每个模型的SDK和鉴权逻辑。同时它的计费数据比较清晰，方便我在观测层做成本核算。

具体来说，我在元生代上配置了多个模型端点，每个端点对应不同的模型。网关的执行层通过统一接口调用这些端点，决策层根据端点返回的历史数据做选择。这样整个系统对上层是透明的，对下层是灵活的。

3. 核心细节拆解：路由策略、成本核算与质量评估

3.1 路由策略怎么定才不拍脑袋

路由策略是整套系统的核心。我试过几种方案，最后落到了一个三层决策模型上。

第一层是硬规则。有些请求有明确的约束条件，比如"必须支持JSON输出"、"必须支持中文"、"单次调用成本不能超过X"。这些条件直接过滤掉不满足的模型，不需要参与后续评分。硬规则的好处是边界清晰，不会出现"评分算出来选了个不支持的模型"这种尴尬。

第二层是加权评分。对通过硬规则筛选的模型，按照多个维度打分：历史质量分、平均延迟、单位成本、当前负载。每个维度的权重可以根据业务需求调整。比如面向C端的问答场景，延迟权重调高；面向内部的批量处理场景，成本权重调高。

第三层是兜底策略。如果所有模型都不可用（比如全部超时），走一个预设的兜底模型，保证服务不中断。兜底模型不追求最优，只追求可用。

这里有个经验：权重不要设太多维度。我一开始搞了七八个维度，结果调参调到怀疑人生。后来精简到四个核心维度，效果反而更稳定。维度太多，每个维度的数据噪声会叠加，最终评分反而不可靠。

3.2 成本核算：每一分钱都要算清楚

成本核算是这套系统的价值锚点。如果算不清楚成本，调度就失去了意义。

我的做法是：按请求粒度记录成本。每次调用返回后，从响应中提取token消耗量，乘以该模型的单位价格，得到这次调用的估算成本。这个成本会写入观测层的数据库，同时累加到当天的总成本里。

这里有个细节：不同模型的计费方式不一样。有的按输入输出分别计价，有的统一计价，有的还有阶梯价格。我在配置里为每个模型维护了一个计费函数，输入是token量，输出是成本。这样不管计费方式怎么变，只要改配置就行，不用动代码。

另外，我设置了一个日预算告警线。当天累计成本超过预算的80%时，触发告警；超过100%时，自动把非紧急请求路由到更便宜的模型。这个机制救过我一次——有天晚上跑批量任务，忘了设上限，结果告警及时触发，避免了一次"账单惊吓"。

3.3 质量评估：没有反馈就没有优化

质量评估是最难的部分，因为"质量"本身很难量化。我的方案是分层评估。

对于结构化输出任务（比如信息抽取、分类），质量很容易判断：输出是否符合预期格式、字段是否完整、值是否正确。这类任务可以做到自动化评估，每次调用后直接打分。

对于生成类任务（比如文案、摘要），质量评估就复杂了。我的做法是：抽样人工评估+自动指标辅助。自动指标包括输出长度、重复率、关键词覆盖率等，这些指标不能完全代表质量，但能筛出明显有问题的输出。人工评估则是每周抽一批样本，由业务方打分，分数回写到模型能力表里。

这里踩过一个坑：不要用单一指标做决策。我曾经只看"输出长度"来判断文案质量，结果发现模型学会了"凑字数"，输出越来越长但质量越来越差。后来改成多指标综合，才把这个偏差纠正过来。

4. 实操过程：从零搭建调度网关的完整步骤

4.1 环境准备与模型端点配置

第一步是在蓝耘元生代上把需要的模型端点配好。我选了四个模型作为初始候选池：一个强推理模型（代号M1）、一个均衡模型（M2）、一个轻量快速模型（M3）、一个超低成本模型（M4）。这四个模型覆盖了从"高质量高成本"到"低质量低成本"的完整光谱。

配置的时候要注意：每个端点都要单独测试连通性和基础能力。我写了一个简单的测试脚本，对每个端点发三类请求：纯文本生成、JSON结构化输出、长文本摘要。记录每个端点的响应时间、输出格式正确率、基础质量分。这些初始数据作为模型能力表的冷启动数据。

# 模型端点配置示例（伪代码，实际配置在平台侧完成） model_endpoints = { "M1": {"endpoint": "xxx", "cost_per_1k_tokens": 0.12, "max_tokens": 8192}, "M2": {"endpoint": "xxx", "cost_per_1k_tokens": 0.06, "max_tokens": 4096}, "M3": {"endpoint": "xxx", "cost_per_1k_tokens": 0.02, "max_tokens": 2048}, "M4": {"endpoint": "xxx", "cost_per_1k_tokens": 0.005, "max_tokens": 1024}, }

注意：单位成本一定要用实际测试数据校准，不要直接抄官方文档。我实测发现，某些模型的实际token消耗比预期高20%左右，因为系统提示词和格式指令也计入token。

4.2 请求归一化与任务分类

接入层的核心工作是把各种格式的请求归一化。我定义了一个标准请求对象：

class GatewayRequest: task_type: str # 任务类型：qa / copywriting / extraction / summary priority: str # 优先级：high / normal / low input_text: str # 输入内容 expected_format: str # 期望输出格式：text / json / markdown budget_limit: float # 单次调用预算上限（可选） timeout_ms: int # 超时时间（可选）

任务分类我用了两种方式结合：显式声明+隐式推断。上层应用如果能明确声明任务类型，直接使用；如果不能，网关根据输入内容和期望格式做推断。推断逻辑很简单：期望JSON输出且输入是长文本，大概率是抽取任务；输入是短问题，大概率是问答任务。

这里有个实操心得：任务类型不要设太多。我一开始设了十几种任务类型，结果每种类型的样本量都不够，统计数据没有意义。后来收敛到四类核心任务，每类的数据量足够支撑决策，效果反而更好。

4.3 决策引擎的实现细节

决策引擎的核心是一个评分函数。对每个候选模型，计算综合得分：

score = w_quality * quality_score + w_latency * (1 - normalized_latency) + w_cost * (1 - normalized_cost) + w_load * (1 - current_load)

其中权重根据任务类型和优先级动态调整。比如高优先级的问答任务，延迟权重设为0.5，成本权重降到0.1；低优先级的批量抽取任务，成本权重设为0.5，延迟权重降到0.1。

def calculate_score(model, task_type, priority): weights = get_weights(task_type, priority) quality = model.history_quality.get(task_type, 0.5) latency = normalize(model.avg_latency_ms, 500, 10000) cost = normalize(model.cost_per_1k, 0.005, 0.15) load = model.current_load return (weights['quality'] * quality + weights['latency'] * (1 - latency) + weights['cost'] * (1 - cost) + weights['load'] * (1 - load))

提示：normalize函数的作用是把不同量纲的指标映射到0-1区间。延迟用500ms到10000ms作为边界，成本用0.005到0.15作为边界。这些边界值要根据实际模型池的情况调整，不是固定值。

4.4 执行层的容错与降级

执行层要处理的核心问题是：选中的模型调用失败了怎么办。

我的策略是三级容错：第一级，同一模型重试一次（针对网络抖动等瞬时故障）；第二级，降级到评分次高的模型；第三级，降级到兜底模型。每一级都有超时控制，避免请求卡死。

def execute_with_fallback(request, ranked_models): for i, model in enumerate(ranked_models): try: result = call_model(model, request, timeout=request.timeout_ms) if validate_output(result, request.expected_format): return result, model except TimeoutError: continue except Exception as e: log_error(model, e) continue # 所有模型都失败，走兜底 return call_fallback_model(request), "fallback"

这里有个关键细节：降级时要记录原因。是超时、格式错误还是服务不可用？不同原因对应的优化方向不一样。超时多说明延迟评估不准，格式错误多说明模型能力评估有偏差。这些数据回写到观测层，驱动决策层优化。

4.5 观测层的数据采集与看板

观测层我用了最简单的方案：结构化日志+定时聚合。每次调用写一条JSON日志，包含所有关键字段。然后用定时任务每小时聚合一次，生成模型维度的统计报表。

{ "request_id": "req_20240115_001", "timestamp": "2024-01-15T10:30:00Z", "task_type": "extraction", "priority": "normal", "selected_model": "M3", "actual_latency_ms": 1200, "input_tokens": 850, "output_tokens": 120, "estimated_cost": 0.0194, "output_valid": true, "fallback_used": false }

看板我一开始想搞得很花哨，后来发现三个核心指标就够了：每个模型的日均调用量、平均延迟、单位成本。再加一个成本分布饼图，看钱主要花在哪些任务上。这三个指标能回答80%的问题。

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

5.1 模型评分震荡怎么办

问题现象：某个模型的评分忽高忽低，导致路由决策不稳定，同一个任务今天走M2明天走M3。

排查思路：先看数据量。如果某个模型在某个任务类型上的样本量少于50条，评分波动大是正常的，因为统计噪声太大。再看时间窗口。如果用的是"最近1小时"的数据，而模型调用量本身就不大，那评分基本就是随机数。

解决方法：我用了滑动窗口+指数平滑。评分不是用瞬时值，而是用最近N次调用的加权平均，越近的调用权重越高。同时设置最小样本量阈值，低于阈值的任务类型不参与评分决策，走默认路由。

5.2 成本估算和实际账单对不上

问题现象：观测层算出来的日成本是50块，实际账单是65块，差了30%。

排查思路：逐项核对。第一，检查是否有未记录的调用（比如测试请求、健康检查）；第二，检查token计算方式是否和平台一致（有的平台把系统提示词计入，有的不计）；第三，检查是否有阶梯计价或最低消费。

解决方法：我在观测层加了一个对账模块，每天拉取平台的实际账单数据，和估算数据做对比。差异超过10%就触发排查。后来发现主要差异来源是系统提示词的token没算进去，修正后差异降到了3%以内。

5.3 某个模型突然变慢导致大量超时

问题现象：某天下午开始，大量请求超时，用户投诉激增。

排查思路：先看是单个模型的问题还是全局问题。如果是单个模型，看它的延迟曲线是不是突然飙升。如果是全局问题，看是不是网关本身的瓶颈。

解决方法：短期方案是自动熔断。当某个模型的超时率超过阈值（比如20%）时，自动把它从候选池里摘除，15分钟后再放回来试探。长期方案是多端点冗余，同一个模型配两个端点，一个主用一个备用。

5.4 输出格式校验太严格导致误判

问题现象：模型明明输出了正确的JSON，但校验不通过，导致不必要的降级重试。

排查思路：检查校验逻辑。常见问题包括：模型在JSON外面包了markdown代码块标记、字段顺序和预期不一致、多了或少了一个可选字段。

解决方法：校验逻辑要宽松但有底线。我的做法是：先尝试直接解析，失败则尝试提取代码块内容再解析，再失败则尝试修复常见格式问题（比如补全缺失的引号）。只有所有尝试都失败，才判定为格式错误。这样误判率从15%降到了2%以下。

5.5 常见问题速查表

6. 运行三个月后的真实数据与个人体会

6.1 成本、延迟、质量的实际变化

跑了三个月，数据比预想的好。成本方面，整体下降了约45%。主要贡献来自两个方面：一是把大量简单任务从强模型迁移到了轻量模型，二是低优先级任务自动走了更便宜的通道。延迟方面，高优先级请求的平均响应时间从3.2秒降到了1.8秒，因为决策层会把它们优先路由到快模型。质量方面，结构化输出任务的格式正确率从82%提升到了96%，因为决策层会把格式要求高的任务路由到擅长结构化输出的模型上。

当然也有代价。系统的复杂度上去了，维护成本增加了。你需要定期校准模型能力表、调整权重参数、检查对账差异。如果调用量很小（比如每天几百次），这套系统的投入产出比可能不划算。但一旦调用量上到每天几千次以上，收益就非常明显了。

6.2 几个让我印象深刻的踩坑经历

第一个坑是过度优化。我一开始想把路由做到极致，每个请求都算一遍最优解。结果决策层本身成了瓶颈，增加了200ms的额外延迟。后来改成缓存决策结果，相同任务类型+优先级的请求复用同一个路由决策，5分钟内有效。延迟降下来了，效果几乎没损失。

第二个坑是忽视冷启动。新加一个模型时，没有历史数据，评分默认给0.5，结果它既不会被优先选中，也不会被完全排除，处于一个尴尬的中间态。后来我加了一个探索机制：新模型前100次调用强制分配5%的流量，快速积累初始数据。

第三个坑是日志太多。全量记录每次调用的完整输入输出，导致存储成本飙升。后来改成只记录元数据+抽样记录内容，存储成本降了80%，排查问题时也够用。

6.3 这套系统适合什么场景

如果你符合以下条件，这套多模型调度网关值得一试：调用量达到一定规模（每天至少几千次）、任务类型有差异（不是所有请求都干同一件事）、对成本或延迟有明确诉求（不是"能用就行"）。如果只是个人玩玩或者调用量很小，直接用单个模型更省心。

后续我打算在这几个方向继续优化：一是引入更细粒度的质量反馈，让业务方可以直接在界面上给输出打分，数据自动回写；二是做跨天的成本预测，根据历史数据预估明天的成本，提前调整策略；三是把决策逻辑配置化，让非技术人员也能调整路由规则，不用改代码。

这套东西说到底就是一个思路：别让一个模型干所有事，也别让调度逻辑拍脑袋。数据驱动、持续迭代，成本、延迟、质量这三个指标自然会往好的方向走。