100个模型怎么选：5分钟决策树
朋友上个月看了我的灿海星图账单——42块。他打开自己的Anthropic账单，510块。我看了他的调用记录：翻译、润色、写邮件标题，全用的Claude 3.5 Opus。等于用手术刀削苹果。
本文是一篇实操指南。
核心操作
三层分级策略
第一层：轻量模型——日常80%的任务。 判断标准：不需要深度推理、不需要写代码、不需要读长文。典型任务：问答、润色、翻译、标题、邮件。推荐：MiniMax-abab6.5s。成本：~0.5元/百万token[¹]。
第二层：主力模型——日常15%的任务。 判断标准：需要写代码、写长文、数据分析。推荐：Claude Sonnet 4（编程首选）/ DeepSeek-V4-Flash（中文）。成本：~5-10元/百万token[¹]。
第三层：深度模型——日常5%的任务。 判断标准：需要架构设计、安全审查、深度研究。推荐：Claude 3.5 Opus / o1-mini / DeepSeek-R1。成本：~20-40元/百万token[¹]。
快速判断法
拿不准时问三个问题：
- 这个任务需要"创造力"吗？→ 需要 → 至少第二层
- 这个任务错了会有什么后果？→ 严重 → 至少第二层
- 这个任务以前人类做需要多少时间？→ >30分钟 → 至少第二层
三个都是"否"→第一层。一个"是"→第二层。两个以上"是"→第三层。
速度对比
| 模型 | 首token延迟 | 输出速度 | 上下文窗口 | 适合场景 |
|---|---|---|---|---|
| MiniMax-abab6.5s | 0.3-0.8s | 80-120 tok/s | 128K | 实时对话、快速迭代 |
| Claude Sonnet 4 | 0.8-1.5s | 50-80 tok/s | 200K | 日常编程、代码生成 |
| DeepSeek-V4-Flash | 1.5-3.0s | 30-50 tok/s | 1M | 中文长文、全仓库分析 |
| GLM-5.2 | 2.0-4.0s | 20-40 tok/s | 1M | 论文阅读、长文档分析 |
| Moonshot-v1 | 1.0-2.0s | 40-60 tok/s | 256K | 创意写作、脚本 |
| Claude 3.5 Opus | 3.0-8.0s | 20-40 tok/s | 200K | 架构设计、深度推理 |
| o1-mini | 5.0-15.0s | 15-30 tok/s | 200K | 数学推理、复杂分析 |
速度不等于效率。Opus和o1-mini的"慢"是内部多步推理。如果你频繁打断模型嫌慢，说明用的模型太强了；如果回答缺乏深度，说明用的模型太弱了[¹]。
按供应商逐个分析
Claude系列：Sonnet写TypeScript时类型推断和错误处理明显优于其他模型。写复杂泛型函数，GPT可能给any，Sonnet给精确类型约束。劣势：中文用词偏正式。Opus在架构设计场景给你完整方案——服务边界、数据流、通信协议、容错策略，不是提纲。
DeepSeek系列：百万上下文是实质优势——把50个文件的NestJS项目全丢进去分析依赖关系。中文技术写作是强项。R1的思维链推理强但等待时间长（10-30秒才开始输出），不适合日常对话。
GPT系列：Codex在调试场景有"直觉"——描述bug现象经常直接猜到根因。o1-mini适合数学推理。GPT-5.6英文写作最自然。
Kimi系列：Moonshot-v1中文创意写作最好——公众号软文、短视频脚本、广告文案。技术文档不行。和DeepSeek是互补：DeepSeek长于技术文档（准确严谨），Kimi长于创意文案（生动有感染力）。
GLM系列：GLM-5.2在百万上下文模型里长文理解精度最高。读50页论文能准确找出方法论创新点、实验细节、结论局限性。
MiniMax系列：规则很简单——每次先问自己，MiniMax够不够？够了就省。 很多人低估MiniMax，在简单任务上和高端模型差距极小，速度极快（首token < 1s）。
完整决策树
写代码：日常功能→Sonnet 4 / 全仓库分析→DeepSeek V4 / 架构设计→Opus / 复杂Debug→GPT-5.6 / 中文项目→Qwen-Max / 写测试→MiniMax
写文章：中文技术→DeepSeek / 中文创意→Moonshot / 英文→GPT-5.6 / 翻译→qwen-mt-turbo / 润色→MiniMax
自媒体：选题分析→DeepSeek / 脚本→Moonshot / 标题→MiniMax / 英文出海→GPT-5.6
科研：文献调研→GLM-5.2 / 实验设计→Opus / 数据分析→GPT-5.6 / 论文润色→GPT-5.6 / 深度推理→o1-mini / 中文论文→DeepSeek
成本优化
原则一：80/20法则。 80%任务用MiniMax，月均约42元。全用Opus月均约510元——12倍差距[¹]。
原则二：设预算上限。 在灿海星图后台设每日调用上限。
原则三：用批处理。 不逐条发"翻译这句话"，合并成"翻译这10句话"——节省90%的overhead。
模型路由机制
指定模型→路由引擎检查是否存在/健康→转发厂商API→返回。
不指定模型（自动路由）：分析prompt特征→<500字符+中文→MiniMax / >10K字符→百万上下文模型 / 包含"写代码"→Sonnet 4 / 包含"架构"→Opus。
常见选模型错误
- "反正不贵，都用最强的"→80%任务用轻量模型，Opus比MiniMax慢5倍消耗10倍token
- "便宜模型质量差"→MiniMax在翻译润色上表现几乎无差异
- "上下文越大越好"→很多任务不需要百万上下文，越大越慢越贵
- "新模型一定比旧模型好"→新模型在某些场景可能退步
- 生产环境固定用命名版本，不要用"最新"这类通配符
常见疑问
Q1：为什么不能所有任务全用最强模型？
80%的日常任务（翻译、润色、简单问答）轻量模型效果几乎没差别，但Opus速度慢5倍、消耗token多10倍。全用Opus月成本约510元，三层分级策略约42元——12倍差距。
Q2：Claude Sonnet和DeepSeek都能写代码，实际怎么选？
Sonnet类型推断和泛型处理更精确。DeepSeek百万上下文是关键优势——需要把整个项目仓库丢进去分析依赖关系，或输出以中文为主，选DeepSeek。日常功能开发首选Sonnet。
Q3：自动路由和手动指定，什么时候必须手动？
自动路由适合日常使用。生产环境或关键任务必须手动——自动路由可能把"请帮我设计微服务拆分方案"判断为普通问答，用轻量模型出浅薄方案。另外厂商原地升级导致模型行为变化时，手动固定命名版本避免突然翻车。
我为什么不用"一个模型打天下"的方案
OpenRouter这类聚合平台也支持多模型，但灿海星图的核心差异在于：(1) 中文模型覆盖——通义、Kimi、GLM、DeepSeek国产模型齐全；(2) 价格优势——内置议价能力，不是简单加价转卖；(3) 统一计费——一个账单看清所有模型消费，不用在厂商后台之间切换。