模型原理 | 路由省钱

title: " 模型原理 | 路由省钱" category: 人工智能 tags:

• 大模型API中转站
• Token
• Scaling Law
• MoE
• 推理模型
• 多模态
• 4SAPI description: "用开发者视角解释Token、参数、Scaling Law、MoE、推理模型和多模态，并给出基于4SAPI的模型分层、路由、省钱和验收策略。"

上一篇我们讲了 AI 为什么会幻觉，以及怎么用提示词、检索、校验和日志把幻觉压下去。

这一篇继续往底层走一点。

但不讲公式。

我们只回答开发者最关心的 5 个问题：

Token 为什么决定成本？
参数越多是不是越聪明？
MoE 为什么看起来又强又便宜？
推理模型为什么适合写代码和排Bug？
多模态为什么能看截图、听语音、读表格？

理解这些概念，不是为了显得懂理论。

真正的价值是做模型路由：

简单任务用便宜模型。
复杂任务用强模型。
需要最新信息先搜索。
需要看图就切多模态。
需要可靠性就加校验和日志。

这也是大模型API中转站最适合发挥价值的地方。

1. Token：成本从这里开始

大模型不是按“问题个数”干活，而是按 Token 处理文本。

一次请求大致会消耗：

输入Token + 输出Token = 本次调用的主要计费基础

输入 Token 包括：

输出 Token 包括模型生成的答案、代码、JSON、报告等。

所以要省钱，第一反应不是换模型，而是先看：

是不是每次都塞了太多无关上下文？
是不是历史对话没有裁剪？
是不是RAG召回太宽？
是不是输出格式过度冗长？

很多系统降本 30% 到 50%，靠的不是换供应商，而是把 prompt 和上下文清理干净。

2. 参数：模型学到的“知识数字”

训练大模型时，会有大量参数。

可以粗略理解为：

参数 = 模型在训练中学到的可调数字

模型读海量文本，预测下一个 Token。

预测错了，就调整参数。

反复训练之后，语言规律、代码模式、事实片段、推理套路，会被压缩进这些参数里。

参数越多，模型通常越有容量，能装下更复杂的规律。

但参数不是越多越划算。

因为模型能力还取决于：

训练数据质量
训练数据数量
算力
模型结构
后训练和对齐
工具调用能力
上下文长度
推理时算力

这也是为什么同样号称“大参数”的模型，实际写代码、长文理解、函数调用、中文表达能力可能差很多。

3. Scaling Law：为什么大模型越做越大

2020 年 OpenAI 团队提出过一组缩放规律，核心意思是：

模型规模、数据量、计算量增加时，语言模型性能会呈现可预测提升。

后来 DeepMind 的 Chinchilla 工作又指出：

只堆参数不够，训练Token也要跟上。

他们给出的经验是，计算最优训练往往需要更多训练 Token，而不是单纯做一个参数巨大但训练不足的模型。

对开发者来说，不需要背论文细节。

记住一个工程结论就够了：

强模型贵，不只是因为参数多，而是因为训练、推理、上下文、工具和服务稳定性都贵。

所以模型选型不能只看排行榜。

还要看你的业务负载：

4. MoE：不是每次都叫醒所有专家

如果每次回答都动用全部参数，成本会很高。

MoE，也就是 Mixture of Experts，混合专家架构，思路很像分诊：

一个模型里有多个专家模块。
每个Token进来后，由路由器判断该交给哪些专家。
只有少数专家被激活。

这样做的好处是：

总参数可以很大，容量更足。
单次激活参数较少，推理成本更低。

你可以把它想成一个大型技术团队。

不是每个需求都拉全公司开会。

前端问题找前端，数据库问题找 DBA，架构问题再拉更强的人。

这就是为什么一些 MoE 模型看起来“总参数很大”，但调用价格和速度还能接受。

但 MoE 也不是万能。

它依赖路由质量。

如果路由错了，或者任务需要多个专家之间复杂协作，结果仍然可能不稳。

所以线上系统里，MoE 模型更适合通过真实任务测试，而不是只看参数宣传。

5. 推理模型：多想一会儿，少返工一点

普通聊天模型更像快速回答。

推理模型更像先在内部拆题、规划、验证，再给最终答案。

它适合这些任务：

复杂代码修改
架构设计
疑难Bug排查
数学和逻辑题
多约束方案比较
长链路Agent任务

不适合什么？

改一个按钮文案
翻译一句话
生成一段普通营销文案
简单摘要
固定格式客服回复

因为推理模型通常更慢、更贵。

所以正确用法不是“所有请求都上推理模型”，而是分层：

普通模型：快、便宜，处理80%的简单请求
推理模型：慢、贵，处理20%的复杂请求
兜底模型：当普通模型失败或校验不通过时再调用

在 4SAPI 里，你可以把这些模型放到不同令牌、不同分组或不同路由策略里，方便统计成本和效果。

6. 多模态：让模型看见更多上下文

多模态模型能处理文字以外的信息，比如：

图片
截图
语音
视频片段
PDF页面
表格截图

它的基本思路仍然是把不同信息转换成模型能处理的数字表示，再放到统一空间里理解。

对开发者最实用的场景是截图调试。

比如前端样式问题，用文字描述很费劲：

右上角那个按钮好像偏了一点，表格下面空白太多，移动端标题挤在一起。

直接给截图，模型会更快定位问题。

多模态尤其适合：

但要注意：看图模型也会幻觉。

尤其是截图很糊、文字太小、图片被裁切时，它可能会猜。

所以关键业务仍然要做结构化校验。

7. 一套可落地的模型路由

把前面这些概念落到 4SAPI，可以设计一套很实用的路由。

用户请求
  -> 任务分类
  -> 选择模型
  -> 生成结果
  -> 校验
  -> 失败时升级模型或补充检索

7.1 任务分类

先把请求分成几类：

7.2 路由规则

可以写成很简单的规则：

if 包含图片:
  使用多模态模型
elif 包含“最新/今天/价格/政策/版本”:
  先联网搜索，再用通用模型总结
elif 任务包含“架构/疑难Bug/多约束/推理”:
  使用推理模型
elif 任务是批量分类或改写:
  使用低成本模型，低temperature
else:
  使用默认通用模型

再加一个失败升级：

if JSON校验失败:
  带错误信息重试一次
if 仍失败:
  升级到更强模型
if 回答缺少来源:
  重新检索或拒绝输出确定结论

7.3 4SAPI 调用示例

下面是一个最小化示例。

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.FOURSAPI_API_KEY,
  baseURL: "https://4sapi.com/v1",
});

type TaskType = "cheap" | "reasoning" | "vision" | "search";

const modelMap: Record<TaskType, string> = {
  cheap: "从4SAPI模型列表复制低成本模型名",
  reasoning: "从4SAPI模型列表复制推理模型名",
  vision: "从4SAPI模型列表复制多模态模型名",
  search: "从4SAPI模型列表复制联网或通用模型名",
};

async function ask(taskType: TaskType, prompt: string) {
  const completion = await client.chat.completions.create({
    model: modelMap[taskType],
    temperature: taskType === "cheap" ? 0.3 : 0.1,
    messages: [
      {
        role: "system",
        content: "你是严谨的技术助手。事实不足时直接说明，不编造。",
      },
      {
        role: "user",
        content: prompt,
      },
    ],
  });

  return completion.choices[0]?.message?.content;
}

生产里不要把 modelMap 写死在代码中。

更好的方式是放配置中心：

default_model
cheap_model
reasoning_model
vision_model
fallback_model

这样当价格、能力、稳定性变化时，不用发版就能调整。

8. 成本治理清单

最后给一份适合团队落地的清单。

一句话总结：

懂一点大模型原理，最终是为了少花冤枉钱，少让AI在生产环境里乱猜。

Token 决定成本，参数决定容量，MoE 影响性价比，推理模型解决复杂任务，多模态扩展输入边界。

把这些能力通过 4SAPI 统一接入、统一日志、统一分组，再配上任务路由，你就不会被某一个模型或某一个供应商绑死。

参考资料：

• Attention Is All You Need
• Scaling Laws for Neural Language Models
• Training Compute-Optimal Large Language Models
• Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity
• Chain-of-Thought Prompting Elicits Reasoning in Large Language Models