Gemini 4 Argon 全面开放：旗舰拆档了

「全面开放」这四个字要看后半句

谷歌把 Gemini 4 Argon 推送到全体可用，同时把 Antigravity 这一档留在最高订阅里。同一代模型按能力拆档售卖，已经成了常态。

这条消息的正确读法不是「又能免费用旗舰了」，而是厂商终于把谁有资格用旗舰这件事摆到了台面上。

拆档不是抠门，是成本现实。旗舰模型每服务一次都在花真钱，全免费加无限用量，账算不平。所以从前那种一个模型打天下的窗口，正在收窄成一个基础版本加若干按档位售卖的增强版本。

对你来说，这意味着复杂度上升，收益也上升。因为你可以开始按任务付费，而不是永远按最贵最好那一档付费。

为什么厂商开始把旗舰拆层

三个原因同时起作用。

一是成本刚性。旗舰模型的推理成本很难在一个面向大众的价格点上打平。

二是竞争需要。把能力最强的版本当卖点，能把重度用户拉到高档位，订阅收入才立得住。

三是用量差异实在太大。普通用户偶尔问一句，专业用户一天几千次调用，让他们付一样的钱既不公平，也不划算。这里顺便纠正一个常见直觉：把旗舰基础档免费开放不是做慈善，真实目的是把生态锁进自己的接口和计费体系，收入在体系之上。

结局就是一条很实在的经验：以后看到「某某模型发布」，要默认后面跟着一句「更高或更快的版本只给某某档」。把这句缺省的前提补上，你判断才准。

你要判断的其实只有三件事

不看宣传，回到自己的场景，只有三个问题。

你的瓶颈是能力还是成本。 如果现在的模型在某些任务上干脆做不对，那是能力问题，换更强的版本有用。如果它做得都对只是贵，那是成本问题，应该在路由和缓存上下功夫，而不是追旗舰。

这批任务值不值得用旗舰。 前面提过的分层在这里直接套：机械性任务、面向最终用户的任务、需要多步推理的任务，答案各不相同。

切换过去会不会顺带带来别的收益。 有的版本会带来上下文窗口、工具调用、思考预算的变化。这些东西往往比「更聪明一点」更值钱，因为很多你过去绕不过去的场景是靠它们打通的。反过来也一样成立：如果新版本只是泛泛地变聪明，而你要的那项能力没有变化，就没有切换的理由。判断要落在具体的失败样本上，不要落在平均分上。

关于「成本下降四成」这类传闻

有评测提到新版本在任务级成本上比上一代降了不少，量级在四成左右。这个数字要谨慎使用。

原因有两个。第一，跑评测的任务分布和你线上的任务分布几乎不可能一致，你在自己流量上测出来的差异通常要小很多。第二，最终单价取决于你怎么用：上下文长度、有没有命中缓存、有没有走批处理，这几项的影响常常比模型本身的标价更大。

所以正确的姿势是把它当成「值得测一下的信号」，不是可以写进预算的依据。决策前请务必用自己的数据跑一遍。

一百条对比法

不需要大动干戈，一天左右就能拿到够用的结论。

第一步，从真实日志里抽一百条请求，要覆盖你的主要场景，别全挑简单的。

第二步，定三条明确的验收标准。比如输出结构必须能被你的解析器直接吃掉、关键信息不能漏、风格保持在某个大致范围。标准要具体到可以判定，不要写「输出更好」。

第三步，两组盲测。不要把哪个是新版本告诉标注的人，混着跑，人工判差异。标注表建议就三列：可接受、需要改、不能用。三列比五分制好操作，也更接近真实决策。

第四步，只保留你真正在意的差异。你会发现大部分输出其实是等价的，真正有差别的往往集中在某一类任务上。

第五步，把结论写成一句可复用的话。比如「只有涉及长表格判断的请求才需要走高档版本」。这句话比任何评测分数都有用。

什么时候该换，什么时候不该

该换的情况：现有模型遇到明确的能力天花板；新的标价在你自己的用量核算下确实更便宜；新版本带来了你现在绕不过去的特性，比如更长的上下文或更稳的工具调用。

不该换的情况：现有模型跑得好好的，只是怕落后；评测分数涨了但你没有对应的任务；切换成本包括重写提示词和重跑验收，加起来大于一年能省下的钱。

这里有个容易漏的判断项。迁移成本是一次性的，节省是持续的。用量大到某个程度，哪怕单价只降一点点，长期也值得动手。反过来，如果你的量很小，那就别折腾，把时间留给产品本身。还有一个折衷选项很多人忘了：不必全换，可以按任务比例先把一部分流量切过去。这样你拿到了真实对比数据，也不必承担一次性的风险。

三个常见误区

误区一，把开放当成免费无限。 开放档通常有速率、上下文或并发上的限制。真正的无限只属于付费那一档，看清楚限制条款再动手。有不少团队是在正式放量之后才发现速率上限的，那时候改方案的成本，比当初多花半天看文档高得多。

误区二，一次切完。 旗舰切换尤其要灰度。失败的姿势五花八门，而且往往集中出现在你没测过的边缘问题上。

误区三，用最贵那档的表现评判整代。 拆档之后，同一代不同档的实际行为差异不小。你要测的是自己准备用的那一档，不是评测里跑的那一档。

上下文和缓存，比标价更影响账单

同一款模型，不同人的账单差出好几倍，差别主要在用法上。

第一个变量是上下文长度。很多人默认把整段历史都带进去，一次调用几万 token。试着只保留有效窗口，或者定期把历史压缩成摘要，账单的变化通常比换模型更明显。

第二个变量是缓存命中。把稳定不变的内容放在前面，把每次都变的内容放在后面，命中率才有意义。顺序反了，缓存等于白开。

第三个变量是批处理。非实时的活走批量通道，价格通常更友好。把 pipeline 拆成实时和离线，是一次性的改动，长期收益。

拆档时代怎么给提示词做版本管理

模型分层之后，你的提示词不再只有一套。同一个任务要在不同档位的模型上跑，行为就会有差异，这时候版本管理就变成刚需。

建议的做法是给提示词按任务编号，而不是按模型编号。任务编号是你的业务概念，稳定；模型编号会一直变。每份提示词下面挂一段适配说明，写清楚在什么档位上需要怎么微调。

还有个务实的细节：把模型名、温度、上下文上限这些参数跟提示词放在同一份配置里，而不是散在三处。这样回滚的时候是一份文件的事，不用在三个地方找版本对应关系。

给个人和小团队的现实建议

• 先按用量分档，再按模型分档。 把高频机械任务压到便宜档，把少量关键任务留给旗舰，这是收益最明显的组合。
• 把模型名放进配置，别写死在代码里。 分层时代换模型的频率会高很多，写死的成本会反复出现。
• 每月复盘一次单任务成本。 分层意味着你有更多组合可选，也意味着更容易选错。

最后说一句可能不那么动听的话。旗舰全面开放听起来像福利，实际是在提醒你：默认用好最贵那一档的时代已经过去了。会按档位给任务分类的人，接下来这一年省下的钱，比追任何一种优惠政策都多。