一个 API 路由 GLM-5.2、DeepSeek V4、MiniMax M3 和 Kimi K2.6（2026）

TL;DR — 把 GLM-5.2、DeepSeek V4（Pro 与 Flash）、MiniMax M3 和 Kimi K2.6 挂在同一把 ofox API key 后面，按任务路由，而不是给每个任务都付一个模型的价。按 2:1 的 input/output 比例 blended，单 token 成本从 $0.19/M（V4 Flash） 到 $2.40/M（GLM-5.2）——差 12.86x。下面一张每天 1000 任务的实算路由表，把 每月 $4,205 的全 GLM 账单砍到 $1,453（-65.5%）。路由规则很短：预算/批量 → V4 Flash，长 context（最高 1M token）→ V4 Pro 或 GLM-5.2，推理/代码 → GLM-5.2 或 Kimi K2.6，图片 → MiniMax M3 或 Kimi K2.6。四个模型都在同一个 OpenAI-compatible endpoint 上，所以路由就是改一个字符串的事——Python 和 Node 循环都附上。

团队常犯的错是挑一个模型、把所有任务都塞进去跑。一个批量摘要任务和一个硬推理任务，不该用同样的单 token 价。用一把 key 覆盖全部四个模型，最便宜的档位比最强档便宜 12.86x——所以整局棋就是：给每类任务匹配到能过它质量门槛的最便宜模型。

这是一篇带可复算成本数学的实操教程，不是”哪个路由器最好”的横评。下面每个数字都来自 ofox 的标价 per-token 费率（2026 年 6 月 23 日核实），每张表你都能用规格表自己重算。

TL;DR：什么任务用什么模型？

一句话结论：把批量流量默认到最便宜的档位，只把真正需要的任务升级上去。 下面是按任务形态划分的路由图。

给 2026 年大多数团队的诚实默认值：把大部分流量发给 deepseek/deepseek-v4-flash 或 deepseek/deepseek-v4-pro，把真正难的推理升级给 z-ai/glm-5.2，把任何带图片的任务发给 minimax/minimax-m3。这套在一把 key 后面就覆盖了混合负载里现实的 90%，不用做任何供应商迁移。

规格速览对比

2026 年 6 月 23 日对照 ofox /v1/models 目录核实。价格为每百万 token。

下面每个路由决策都由三个结构性事实驱动：

1. DeepSeek V4 Flash 是价格地板。 在 $0.14/$0.28 下，它 blended 比 GLM-5.2 便宜 12.86x。任何不需要顶级推理的任务从这里起步。
2. DeepSeek V4 的 cache 读取实际上免费。 两档 V4 的 cache 读取计费四舍五入到零，对比 GLM-5.2 的 $0.26/M。在重复 context 的负载上，这是一笔常被忽略的巨大节省。
3. 只有 MiniMax M3 和 Kimi K2.6 接受图片。 GLM-5.2 和两档 DeepSeek 都是纯文本。视觉任务恰好只有两条有效路由，而 MiniMax M3 是其中更便宜的那个。

Blended 成本：驱动路由的那个数

一个模型的头条 input 价只讲了一半故事。你实际付多少，取决于你的 input/output 比例。一个编码 agent 读得多（大 context）、写得少（一个 diff）——大约 2:1 的 input/output。对话更接近 1:1。从短 prompt 纯生成代码是 output 主导的，约 1:3。

下面是按编码典型的 2:1 比例（三分之二 input、三分之一 output）算的每百万 token blended 成本，以及相对作为推理档锚点的 GLM-5.2 的倍数：

Pull quote： 这份名单上最便宜的模型，比最强的那个便宜 12.86x。这个差距就是路由整个经济学论据的全部——重点不是哪个模型”赢了”，而是哪些任务能搭上便宜档位、还没人察觉。

排名会随负载形态略有变化。在 1:3 的 output 主导（代码生成）下，GLM-5.2 爬到 $3.65/M、Kimi K2.6 爬到 $3.24/M，而 V4 Flash 仍在 $0.245/M。output 主导的工作更猛地偏向 DeepSeek 档位，因为它们的 output token 是五个里最便宜的。如果你只记一条规则：任务写得越多，路由离开 GLM-5.2 和 Kimi K2.6 就越划算。

如果你想停止估算、直接拿自己的流量量真实数字，把全部五个模型路由到一把 ofox key——按量付费、没有月费、跟 OpenAI SDK 同形态，本文末尾的 A/B 循环只用改一行字符串就能换模型。

单任务成本：每个模型上跑一次 agent 要花多少

路由决策用每次运行的美元数比用每百万 token 费率更直观。取一个有代表性的 agent 运行：50,000 input token、15,000 output token（读一段 codebase、产出一处改动）。

同样的工作，每月 10,000 次这样的运行，就是 V4 Flash 花 $112，对比 GLM-5.2 花 $1,360。哪怕只有一半运行足够常规、能走预算档，路由决策也会自己回本好几倍。重点不是 V4 Flash 永远正确——而是给一个 V4 Flash 就能搞定的任务付 GLM-5.2 的价，纯属浪费。

路由决策矩阵（实算例子）

这是大多数”用路由器”文章跳过的部分：真正的每日数学。假设 每天 1000 个混合任务，分布如下（贴近现实）：

全部跑 GLM-5.2（一个模型的陷阱）对比把每类路由到成本匹配的模型：

路由后总额的拆分：

那 600 个批量任务——占 60% 的量——在 V4 Flash 上每天花 $1.18。同样 600 个任务跑 GLM-5.2 大约每天 $13.68——大约贵 11.6 倍。这一条路由规则（便宜批量 → V4 Flash）就完成了大部分活。美元真正集中的地方是长 context 类别，这也是下一节为什么重要。

flowchart TD
    A[进来的请求] --> B{需要图片输入吗？}
    B -->|是| C[minimax/minimax-m3]
    B -->|否| D{硬推理<br/>或 agentic 编码？}
    D -->|是| E[z-ai/glm-5.2]
    D -->|否| F{context > 200K<br/>token？}
    F -->|是| G[deepseek/deepseek-v4-pro<br/>cache 读取免费, 1M ctx]
    F -->|否| H[deepseek/deepseek-v4-flash<br/>最便宜档位]

Cache 读取：DeepSeek V4 安静的成本优势

上面的长 context 类别，正是 cache 改变数学的地方。DeepSeek V4 Pro 和 Flash 的 cache 读取计费实际上是 $0/M。GLM-5.2 按 $0.26/M 计费，MiniMax M3 是 $0.12/M，Kimi K2.6 是 $0.16/M。

取路由表里那个 300K-input 的长 context 任务（每次运行成本含 8K output），80% 的 input 走 cache（对反复跨请求复用同一 codebase context 的代码评审循环来说很现实）：

V4 Pro 起步就更便宜，省下的比例也更大，因为它的 cache 读取四舍五入到零，而 GLM-5.2 在被缓存的那部分上仍要付 $0.26/M。任何会重发同一段长 context 的负载——固定语料上的 RAG、迭代式代码评审、文档问答——都路由到 DeepSeek V4 Pro，免费的 cache 读取会复利。 这是一个路由输入项，GLM-5.2 更强的推理并不总能盖过它。

拆分推理档：GLM-5.2 vs Kimi K2.6

路由矩阵把”硬推理 / agentic 编码”发给 GLM-5.2 或 Kimi K2.6，而这个”或”该有一条规则，而不是抛硬币。两个都是这份阵容里最贵的一端——GLM-5.2 $1.40/$4.40，Kimi K2.6 $0.95/$4.00——而在 2:1 混合下，Kimi K2.6 其实 blended 略便宜（$1.97/M vs $2.40/M），因为它的 input 费率更低。三个具体因素决定路由：

实操规则：如果推理任务带大 context（>256K token），两者里只有 GLM-5.2 装得下——Kimi K2.6 会拒绝这个 input。 如果 context 稳稳低于 256K，且任务涉及图片或想要更便宜的单 token 费率，Kimi K2.6 是更好的路由。对大多数短 context 的 agentic 编码回合，Kimi K2.6 更低的 input 价让它成为推理档里的性价比之选；把 GLM-5.2 留给只有它 1M 窗口装得下的长 context 推理。Kimi K2.6 发布指南对它的 agentic 行为有更深入的介绍。

这正是为什么客户端路由胜过锁死一个模型：“最好的推理模型”取决于推理任务的形态，而一个 model 字符串是它们之间最便宜的切换方式。

延迟和吞吐也是路由输入项

成本是最响的路由信号，但不是唯一的。两条会改变真实路由决策的运维注记：

• 交互式 vs 批量。 对一个用户能感知首 token 延迟的面向用户助手，最便宜的模型不自动是对的——一个稍贵但返回更快的模型，在交互式界面上可能值这个钱，而隔夜批量任务无论速度如何都该搭最便宜的档位。按界面路由，而不只是按价格：交互式流量容忍更高的单 token 成本，批量流量不容忍。
• 输出上限是硬约束。 如果单次响应必须超过 128,000 token——整文件重写、大型结构化导出——GLM-5.2 和 MiniMax M3 会触顶、调用被截断。只有 DeepSeek V4 档位（384K）和 Kimi K2.6（262K）能在单次调用里越过这道门槛。这是一个二元路由闸门，不是成本权衡：把超大输出的任务发给一个物理上能吐出那么多 token 的模型。

这两点都能被你的 pick_model 函数编码成普通条件判断——界面类型和预期输出大小通常在请求时就已知。

什么时候不要路由（以及改用什么）

路由不是免费的工程。三类多模型拆分是错误选择的情况：

• 单个开发者、每天 < 1000 次调用、全是同一类任务。 路由逻辑和逐模型的质量测试，花的时间比你省的还多。挑 deepseek/deepseek-v4-pro 作为一个强而便宜的默认值，然后继续干活。$0.59/M 的 blended 成本已经够低了，再做微优化不值那些分支代码。
• 你确实需要服务端自动融合。 ofox 按你的 model 字段路由——它不会自动挑模型或融合输出。如果你特别想要基于质量的自动选择或响应融合（OpenRouter Auto / Sakana 式的思路），那是另一类产品。用那类工具，或者在断定自动路由器值得那份不可预测性之前，先读我们的OpenRouter 是否可靠的诚实评测。
• 每个任务都真的需要顶级推理。 如果你的流量 100% 是没有预算档工作的硬 agentic 编码，那就没什么可路由的——跑 GLM-5.2（或 Kimi K2.6），跳过矩阵。路由只在你的负载是混合时才回本。对纯粹的双模型推理拆分，我们的 Claude Code 混合路由模式覆盖了那个更窄的场景。

路由的回报，与你流量的异质程度成正比。同质流量 → 一个模型。混合流量 → 上面那张矩阵。

用 ofox 试试：一个循环路由全部五个

五个模型都共享 https://api.ofox.ai/v1 和一把 ofox key。路由是客户端决策：你按每次请求设 model 字段。下面是路由函数，以及 Python 和 Node 两版 A/B 循环。

Python——按任务路由，再 A/B 候选模型

from openai import OpenAI

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="<OFOXAI_API_KEY>")

def pick_model(task):
    if task["has_image"]:         return "minimax/minimax-m3"        # only M3/Kimi take images
    if task["hard_reasoning"]:                                       # split the reasoning tier
        return "z-ai/glm-5.2" if task["context"] > 256_000 else "moonshotai/kimi-k2.6"
    if task["context"] > 200_000: return "deepseek/deepseek-v4-pro"  # free cache reads, 1M ctx
    return "deepseek/deepseek-v4-flash"                              # cheapest tier

def run(task, messages):
    model = pick_model(task)
    return client.chat.completions.create(model=model, messages=messages)

要在自己的流量上对比候选模型，固定 prompt、在 model ID 上循环——换字符串，其余全部不变：

CANDIDATES = ["deepseek/deepseek-v4-flash", "deepseek/deepseek-v4-pro", "z-ai/glm-5.2"]
for model in CANDIDATES:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": "Refactor this function for readability: ..."}],
    )
    u = r.usage
    print(model, u.prompt_tokens, u.completion_tokens)  # log tokens to price each route

Node——同样的形态

import OpenAI from "openai";

const client = new OpenAI({ baseURL: "https://api.ofox.ai/v1", apiKey: process.env.OFOXAI_API_KEY });

const pickModel = (t) =>
  t.hasImage        ? "minimax/minimax-m3"
  : t.hardReasoning ? (t.context > 256000 ? "z-ai/glm-5.2" : "moonshotai/kimi-k2.6")
  : t.context > 200000 ? "deepseek/deepseek-v4-pro"
  : "deepseek/deepseek-v4-flash";

const r = await client.chat.completions.create({
  model: pickModel(task),
  messages: [{ role: "user", content: "Summarize this changelog: ..." }],
});

只走多模态：给 MiniMax M3 或 Kimi K2.6 附一张截图

GLM-5.2 和两档 DeepSeek 都是纯文本——下面这个调用在它们上面物理性地会失败。把图片输入路由到 minimax/minimax-m3 或 moonshotai/kimi-k2.6：

import base64

img = base64.b64encode(open("screenshot.png", "rb").read()).decode()
r = client.chat.completions.create(
    model="minimax/minimax-m3",   # or moonshotai/kimi-k2.6
    messages=[{"role": "user", "content": [
        {"type": "text", "text": "What error is shown in this screenshot?"},
        {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{img}"}},
    ]}],
)

这就是整个路由器：一个 pick_model 函数加一个 OpenAI 客户端。没有新 SDK、没有逐模型 API key、一条计费线。每个模型的详情页在上面的表里都有链接——z-ai/glm-5.2、deepseek/deepseek-v4-pro、deepseek/deepseek-v4-flash、minimax/minimax-m3，以及 moonshotai/kimi-k2.6。

其他方案

如果一把 key、客户端路由适合你的负载，ofox 是最简单的路径：一个 OpenAI-compatible endpoint、一条余额、全部五个 model ID。对其他形态：

• ofox —— 一把 key、100+ 模型、OpenAI-compatible。你通过 model 字段掌控路由；计费和 endpoint 统一。当你想要自己写、成本可预测、确定性的路由时最合适。看 OpenRouter 替代方案拆解了解它在加价和可靠性上的对比。
• OpenRouter —— 大型目录，带一个可选的 Auto 服务端路由器替你挑模型。如果你特别想要自动选择、且能容忍不那么可预测的路由和平台加价，它有用。
• 直连各家 provider API —— 分别直接调 DeepSeek、Zhipu（GLM）、MiniMax 和 Moonshot，给你最原始的价格，但要对四把 key、四个 SDK、四条计费线做对账。只有在某一家供应商的单家用量非常高时才值得。
• 自托管 —— GLM 和 DeepSeek 都公开了开放权重，所以物理隔离或必须 fork 的部署是可能的。经济账只在规模化时才算得过来；看我们的 GLM-5.2 自托管硬件成本分析了解相对托管 per-token 价格的盈亏平衡数学。

要更深入的逐模型背景，GLM-5.2 接入指南、GLM-5.2 vs GPT-5.5 成本拆解、DeepSeek V4 Pro vs Flash 对比、DeepSeek V4 发布指南，以及 MiniMax M3 vs GPT-5.5 编码 benchmark 都比这篇路由概览更深一层。

FAQ

上面 frontmatter 里的 FAQ 块回答了最常见的路由问题（一把 key 路由、最便宜的模型、最长 context、哪些模型做视觉、真实节省、免费 cache 读取、没有服务端自动路由器、最大输出、以及如何 A/B）。那些答案与本文里的表一致——成本数字、model ID 和路由规则全文统一。

本次更新核实的数据来源

• ofox /v1/models 实时 API 目录 —— 全部五个 model ID、context window、最大输出，以及 per-token 价格（input / output / cache 读取）于 2026-06-23 核实
• ofox llms-full.txt —— OpenAI-compatible base_url https://api.ofox.ai/v1 及一把 key 跨模型已确认（2026-06-23）
• ofox z-ai/glm-5.2、deepseek/deepseek-v4-pro、deepseek/deepseek-v4-flash、minimax/minimax-m3、moonshotai/kimi-k2.6 的模型详情页 —— 全部返回 HTTP 200（2026-06-23）
• OpenAI Python SDK（PyPI 上 openai 2.43.0）和 OpenAI Node SDK —— 代码示例所用的 SDK 形态（2026-06-23）
• 所有成本表都可从规格速览表里的 per-token 费率重算