这就是 2026 年选型最常见的错误:把"哪个模型最强"当成了"我该用哪个模型"。

这两个问题根本不是一回事。GPQA、SWE-bench、ARC-AGI-2 这些榜单告诉你的是天花板,而你大部分的线上请求,离天花板远着呢。一个分类、一段摘要、一次格式化抽取——这些活儿,旗舰模型是高射炮打蚊子。选型不是选最强,是给每一类任务配一个"刚好够用、且最便宜"的模型。

这篇不排名。给你一套按场景拆的决策框架。

先认清:2026 年的模型是分梯队的

2026 年 5 月,前沿模型大概是这么个格局——记住具体版本号意义不大,它们每两三个月就跳一次,记住梯队就行:

这张表里藏着一个关键事实:旗舰和"快而省"之间,输出价格差了几十倍。 DeepSeek V4-Flash 的输出大约 $0.28,GPT-5.5 是 $30——一百多倍。这个差距不是边角料,它会直接决定你的产品能不能规模化。

而梯队之间的能力差距,这两年反而在缩小。2024 年你能明显感觉到旗舰和主力不是一个物种;2026 年,在很多具体任务上,主力模型只比旗舰差几个百分点,有时候你压根测不出来。能力在收敛,价格还拉得很开——这就是"按梯队选型"能省钱的根本原因。

所以第一条原则:默认从主力梯队起步,只在它确实顶不住时才往上抬。 不要反过来,从旗舰往下砍——那样你永远不知道下面那一档是不是早就够了。

维度一:能力够不够,要按"任务类型"问

“够用"不是一个模糊的感觉,它可以拆。把你的任务大致归到三类:

确定性任务——分类、实体抽取、格式转换、敏感词过滤。这类任务有标准答案,对错可量化。结论很直接:用快而省梯队,甚至小开源模型。 旗舰在这里没有任何优势,它多出来的"智商"在一个三选一的分类题上无处发挥。我前面说的那个翻车案例,就是这一类。

生成与改写任务——写文案、做摘要、客服话术、翻译。这类没有唯一答案,但对"质量"敏感。主力梯队是甜区。值得一提:Claude 系列在中长文写作上的语感明显更自然,一次能稳定输出十几万 token 不塌;如果你的产品核心就是"写得像人”,这个差异值得你多花那点钱。

推理与 Agent 任务——多步代码、需要调工具、长链路规划、“自己想办法完成”。这是 2026 年唯一真的需要旗舰的地方。一个 Agent 要连续做二三十步,每一步的小错误会累积,中间某一步判断失误,后面全废。这种场景下,旗舰多出来的几个点,放大到整条链路就是"能跑通"和"跑不通"的区别。GPT-5.5、Claude Opus 4.7 这一档,贵有贵的道理——但前提是,你的任务真的是 Agent,而不是被包装成 Agent 的一次性问答。

一个实操建议:别用一个模型扛所有任务。 成熟的做法是按任务路由——一个便宜模型做分流和简单活儿,难的才转交旗舰。这比"全程旗舰"省一大笔,也比"全程便宜"靠谱。

维度二:成本不是单价,是「单价 × 调用量 × 输出长度」

很多人看 API 价格,只瞄一眼那个"每百万 token 多少钱"。这是不够的。真正的账是三个数相乘:

• 单价——尤其是输出单价,通常是输入的 3 到 5 倍,而且 Agent 类任务输出占比高。
• 调用量——一天一千次还是一千万次,差四个数量级。
• 平均输出长度——让模型"先想再答"(reasoning)能提质量,但思考链本身也是要付费的 token。

把这三个乘起来,你常会得到一个反直觉的结论。举个例子:一个日活几万的客服机器人,绝大多数对话是"查物流"“改地址"这种,真正复杂的咨询可能只占 5%。如果你全程用旗舰,等于为了那 5% 的复杂场景,给 95% 的简单场景也付了旗舰价。把 95% 切到主力或快省梯队,月成本可能直接砍掉七八成,用户一点感知都没有。

两个几乎免费、却经常被忘掉的省钱手段,务必用上:

• Prompt Caching(提示缓存)——固定不变的前缀(system prompt、长文档、few-shot 例子)缓存住,命中后这部分输入便宜约 90%。多轮对话、RAG、批量同模板任务,收益巨大。
• Batch(批处理)——不要求实时返回的任务,走批处理接口,普遍五折。离线打标、夜间报表、内容审核这类活儿,没理由不用。

记住:选型省下的钱,常常比换一个"更便宜的模型"省得还多。 因为它省的是结构性的浪费。

维度三:延迟、上下文——被场景一票否决的硬约束

有些维度不参与"性价比"的权衡,它们是门槛:不过线,这个模型直接出局,多强多便宜都没用。

延迟。 如果你做的是实时语音对话,用户说完到 AI 出声的预算只有几百毫秒(这个我在上一篇里专门拆过)。这种场景,你要盯的是首 token 延迟(TTFT),不是模型聪不聪明。一个慢半拍的旗舰,体验上输给一个快的主力模型。反过来,如果是离线批处理,延迟根本不在你的考虑范围里——这时候为"快"付的溢价就是纯浪费。

上下文长度。 2026 年长上下文已经不稀缺:Gemini 3.1 Pro 和 DeepSeek V4 都是 1M token 窗口,Llama 4 甚至把 10M 带进了开源世界。但有窗口不等于会用。把 50 万 token 一股脑塞进去,模型对中间段落的注意力会明显下降——业内说的 “lost in the middle” 没有消失。所以长上下文是个二元的资格题:你的单次任务真需要塞进一整本书、一个大代码库,那 1M 窗口是硬指标;如果你的输入本来就几千 token,纠结谁的窗口更大毫无意义,该花力气的是 RAG 的检索质量,而不是模型的窗口数字。

判断方法很简单:先问"这个场景能不能容忍 X”,不能就直接划掉一批模型,再在活下来的里面比性价比。 别把硬约束和软偏好混在一起算。

维度四:闭源还是开源,2026 年这道题变简单了

两年前这是个艰难抉择,因为开源模型确实差一截。2026 年不一样了。

DeepSeek V4-Pro 在 SWE-bench Verified 上能摸到 80% 出头,和顶级闭源模型只差零点几个点,而且是 MIT 许可证。Qwen 3.5 / 3.6、Llama 4 也都在各自的领域逼近前沿。开源和闭源的能力差距,现在是用单个 benchmark 上的几个点来衡量,不再是"差一代"。 同时,主流开源模型现在发布即附带官方量化版本(Q4/Q5/Q8),部署门槛大幅下降。

所以这道题的判据,从"谁更强"变成了别的:

• 选闭源 API:你要的是省心。不碰 GPU、不管扩缩容、要最新最强、出了事有人兜底。绝大多数从 0 到 1 的产品,该走这条路——你的精力应该花在产品上,不是运维推理集群。
• 选开源:你有三个理由之一——量足够大(自己跑的边际成本能把闭源 API 打下去)、需要深度微调(让模型长出领域知识)、或者数据不能出门(下一节细说)。

还有个容易被忽视的点:开源是一份保险。 用闭源 API,你绑定了对方的定价、限流和模型下线节奏——它说某个版本退役,你就得连夜迁移。把一部分负载放在能自己掌控的开源模型上,是对供应商风险的对冲。

维度五:要不要私有化部署——这题先于选模型

如果你的数据是病历、银行流水、未公开的财报、核心代码——这一条会推翻上面所有结论。 它不是一个性价比维度,它是法律和信任的红线。

判断私有化部署需求,问三个问题:

1. 数据能不能离开你的网络? 受监管的医疗、金融、政务,答案常常是"不能"。
2. 合规要求审计闭环吗? 欧盟 AI 法案 2026 年 8 月全面生效,高风险系统要求可追溯、可解释、有人类监督。这些在一个黑盒 API 后面很难自证。
3. 数据主权有没有硬约束? 某些行业、某些地区,要求推理全程在境内、在自有设施内完成。

只要有一个答案指向"必须自己掌控",那就只能选能私有化的开源模型——Qwen、Llama、DeepSeek 这一类,把权重下载下来,跑在自己的 VPC 或机房里。这时候"GPT-5.5 更强"是一句正确的废话,因为它根本不在你的候选集里。

要提醒的是,私有化不是"省钱"的同义词。算上 GPU 采购或租赁、运维、扩缩容、安全加固,很多时候它比 API 更贵。 选它的理由是控制权和合规,不是成本。如果你既没有合规硬约束、量也撑不起一个推理集群,却因为"感觉更安全"去自建,那大概率是给自己挖坑。

把这套框架连起来

选型不是从一张排行榜里挑第一名,而是带着你的场景,依次过几道闸门:

flowchart TD
  A[一个具体任务] --> B{数据能否出本网络?}
  B -- 不能/强合规 --> P[私有化部署
开源模型: Qwen / Llama / DeepSeek]
  B -- 可以 --> C{任务类型?}
  C -- 确定性
分类·抽取·路由 --> D[快而省梯队
Haiku / Flash-Lite / 小开源模型]
  C -- 生成改写
文案·摘要·翻译 --> E[主力梯队
Sonnet / Flash / DeepSeek V4-Pro]
  C -- 推理 Agent
多步·调工具·规划 --> F[旗舰梯队
GPT-5.5 / Opus 4.7 / Gemini 3.1 Pro]
  D --> G{有延迟或上下文硬约束?}
  E --> G
  F --> G
  G -- 有 --> H[在满足约束的模型里
重新筛一遍]
  G -- 没有 --> I[按规模决定
闭源 API or 自建开源]

注意几个细节。第一道闸是数据合规,不是能力——合规一票否决,放在最前面,免得你比了半天性价比最后发现这个模型根本不能用。任务类型决定的是梯队,不是具体型号——型号每季度都变,梯队的逻辑稳定得多。延迟和上下文是筛选器,不是打分项——它们只负责把不合格的划掉。最后才轮到闭源还是开源,而这一步主要由调用量决定:量小走 API,量大到自建更划算时,再考虑迁。

最后

2026 年大模型这块,缺的从来不是好模型,缺的是"清楚自己要什么"。

榜单天天有人更新,排名天天有人吵,但你的客服机器人需要的可能只是一个稳定、便宜、够快的主力模型;你的代码 Agent 才真的吃旗舰那几个点的智商;你的合规系统压根不在公开榜单的讨论范围里。

把"哪个最强"这个问题放下。换成一串具体的问题:这个任务是什么类型?能容忍多少延迟?一天调用多少次?数据能不能出门?——这几个问题答完,该选哪个,基本也就清楚了。

选型的功夫,九成在想清楚需求,一成在看模型。顺序别搞反。

端到端听起来无可挑剔——语音直接进、语音直接出,中间不落文字,延迟低、情感保留好。OpenAI 的 gpt-realtime、Google 的 Gemini Live、豆包的端到端实时语音大模型,demo 都惊艳。但真把它塞进一个要上线的产品里,你会在第二周撞上几堵墙:它说错话你没法在中间拦一道、合规团队要审通话记录而你只有一段音频、客户要换个特定音色而 API 只给你 8 个预设。

所以选型这件事,不能只看 demo 的"哇"。这篇把实时语音 API 的关键维度摊开,再把 OpenAI、Gemini 和国内几家的真实定位讲清楚,最后按场景给建议。

先把"关键维度"对齐

挑实时语音 API,大家张口就是"延迟低不低"。延迟当然重要,但它只是八个维度里的一个。我把这八个维度列出来,你拿任何一个 API 去套都不会漏:

后面三项——是否端到端、可控性、合规——是连在一起的一条逻辑链,也是真正决定选型的地方。延迟和音色反而是"达标就行"的项。

OpenAI Realtime:能力最强,也最贵

OpenAI 的 Realtime API 用的是 gpt-realtime 这个 speech-to-speech 模型,语音直接进出,一个模型一个接口搞定。它的强项是指令遵循和工具调用——你给它一段复杂的 system prompt、挂十个函数,它能稳稳地按规矩走、该调哪个调哪个。这一点上,目前没有对手。

但价格要算清楚。gpt-realtime 按音频 token 计费,输入大约 $32 / 百万 token、输出 $64 / 百万 token。换算成每分钟:用户说话约 600 token/分钟,AI 说话约 1200 token/分钟。一个典型的客服对话(AI 说得比用户多),不开缓存的真实成本落在每分钟 $0.18 到 $0.46 之间——折合人民币一两块到三块多一分钟。

这个数字什么概念?一个日均 1000 通、每通 5 分钟的客服线,光语音 API 一个月就是几万到十几万人民币。所以 OpenAI 自己也反复强调 prompt caching:把固定的 system prompt 和工具定义缓存住,成本能压到每分钟 $0.05–$0.10。能不能用好缓存,直接决定这套方案在你这儿是不是"用得起"。

一句话定位:能力天花板最高,适合复杂任务、预算不敏感、面向海外用户的产品。中文场景它能用,但音色和语气的"中文味"不如国内方案地道,而且数据出境对国内合规是硬伤。

Gemini Live:语言覆盖广,生态绑得紧

Google 的 Gemini Live API 走的也是 native audio(端到端原生音频)路线,旗舰模型是 Gemini 3.1 Flash Live,主打低延迟双向语音、亚秒级音频流式输出。

它最突出的两点:语言覆盖和情感对话。Live API 支持 70 种语言的输入,原生音频模型提供 24 种语言、30 个 HD 音色,还带一个叫 affective dialog 的能力——会根据你说话的语气调整自己的回应风格。另外它有 proactive audio,能控制"什么时候该 AI 开口、什么时候该闭嘴",对付嘈杂环境下的误触发有用。

代价是生态绑定。Gemini Live 跑得最顺的姿势是接进 Google 自家的体系——Vertex AI、Firebase AI Logic、Android。你要是已经在 Google Cloud 上,它顺理成章;你要是个独立的中国团队,接入和合规的摩擦都不小。

一句话定位:多语言、出海、且本来就在 Google 生态里的团队首选;否则生态税不便宜。

国内方案:端到端追上来了,合规是主场

如果你的产品主要面向国内用户,大概率绕不开国内 API,原因很简单:数据不出境这一条,海外方案直接出局。好在国内这两年追得很快。

• 豆包端到端实时语音大模型(火山引擎):真正的端到端 speech-to-speech,中文语境下的语气、情感、方言识别是它的主场——能听懂二十多种方言混着说,能保留口语里的吞音、口音。计费按音频 token 折算(用户输入约 6.25 token/秒,输出音频约 25 token/秒),开了 cache 之后中文场景的性价比明显比 OpenAI 好。要注意它有 QPM/TPM 限流,上量前得先谈配额。它还支持付费定制音色——这点对要做品牌化产品的团队很关键。
• MiniMax Speech 2.6:端到端延迟做到 250ms 以下,40 多种语言、支持 zero-shot 声音克隆,语音质量在国内第一梯队。
• 阶跃 Step Realtime API:基于百亿参数的端到端语音模型 Step-1o-Audio,主打超低延迟和双向打断。
• 阿里通义:走的更偏"组件"路线——比如 Qwen3-ASR-Flash-Realtime 是流式 ASR,适合你自己拼级联的时候拿来当其中一块。

国内方案的整体判断:端到端能力已经够用,中文表现甚至更地道,真正的护城河是合规和本地化支持(出问题能找到人、能签数据处理协议)。短板是出海语种和海外节点不如 OpenAI/Google。

自己拼级联 vs 用端到端 API

这是选型里最纠结的一道题。把两条路线摊开看:

flowchart TB
  subgraph E2E[端到端 API]
    direction LR
    A1[语音输入] --> A2[speech-to-speech 模型] --> A3[语音输出]
  end
  subgraph CAS[自拼级联]
    direction LR
    B1[语音输入] --> B2[流式 ASR] --> B3[LLM] --> B4[流式 TTS] --> B5[语音输出]
  end
  style A2 fill:#fde7c2,stroke:#e8b23c
  style B3 fill:#cfe8d5,stroke:#5fa777

端到端 API 的好处是省心:一个接口,延迟天然更低(少了模块间的转接),情感和韵律保留得好(信息没在"转文字再转回来"的过程里丢)。坏处是它是个黑盒——

• AI 说错话,你没有一个文字中间层可以拦截、改写、过滤敏感词;
• 出了 bug,你不知道是"听错了"还是"想错了",难定位;
• 想换模型?整个交互逻辑都绑在这家 API 上,迁移成本高;
• 合规要审计通话内容,你手上只有音频,得再补一道转写。

自拼级联(流式 ASR → LLM → 流式 TTS)正好相反:三个模块各自独立、可观测、可替换。LLM 那一环你能插审核、能换模型、能做 RAG;ASR 出来的文字天然就是审计记录。代价是延迟预算更紧(模块间多了转接),工程上要把每一环都做成流式、串好,任何一环"攒齐再传"整条链路就塌了——这部分我在上一篇延迟预算里拆得很细。

我的判断:别把它当非此即彼。

• 强管控、强合规的场景(电话客服、金融、政务)——用级联。你需要那个文字中间层,不是为了延迟,是为了"能拦、能审、能换"。
• Web 端的陪伴、教育、互动娱乐——上端到端。这些场景吃的是情感和自然度,黑盒一点可以接受,延迟低反而是卖点。
• 有规模的团队,最后大概率两套都跑,按场景路由:简单闲聊走端到端,涉及交易、要落库审计的环节切回级联。

按场景给一份选型建议

把上面的东西收敛成一张可以直接用的表:

几条收尾的提醒:

第一,先问合规,再聊技术。如果你的数据不能出境,海外两家在第一轮就该被划掉,不用再纠结它们 demo 多惊艳。

第二,价格一定要按"开缓存后"算。不开缓存的 headline price 没有参考意义,真实生产环境一定是带缓存跑的,两者能差三到五倍。

第三,别为了 demo 的惊艳付黑盒的代价。端到端那种"丝滑感"很诱人,但你的产品如果需要拦一句话、审一段记录、换一个模型,这些能力级联方案现成就有,端到端要你自己补,而且补不齐。

实时语音 API 这个赛道 2026 年还在快速变,价格、模型几个月一变。但选型的底层逻辑是稳的:先用合规和可控性把候选名单砍短,再在剩下的里面比延迟和价格。顺序反了,你会在一个最终用不了的方案上,白白调优三个月。