Hacker News 上每隔一段时间就会出现一个帖子“Ask HN: Which model do you use for work?” 我每次看到都会点进去翻一翻因为回复里藏着大量真实的生产环境选型经验比任何榜单都有参考价值。这个问题看起来简单但真正用模型干过活的人都知道答案远不止“某个模型最强”那么简单。工作场景里的模型选择本质上是在能力、成本、延迟、稳定性和数据边界之间做权衡。这篇文章想把我在多个项目里选模型、切模型、排查模型报错的经历梳理一遍希望能给同样纠结选型的人一些参考。1. 为什么工作中选模型是个真问题而不是“喜欢哪个用哪个”1.1 从 Ask HN 热帖说起模型已经变成工作流基础设施HN 那个帖子的经典之处在于回答往往是“看场景”。有人会用最贵的模型做代码审查用便宜模型做格式化有人只用开源模型跑本地离线任务还有一部分人干脆说“我们公司内部统一用某个模型省得每个人踩一遍坑”。这说明模型选型已经变成工程决策而不是个人偏好。一个团队的模型选型会直接影响 CI 流水线费用、代码生成质量、Agent 任务成功率这些东西最后都会折算成时间和钱。我身边很多团队从上到下只维护一份模型配置原因就在这里减少混乱出问题也好排查。我自己也经历过从“随手换模型”到“固定生产配置”的转变。早期写脚本时经常今天用这个 API、明天换那个模型结果一到月底对账发现大部分钱都花在重复尝试上。后来学乖了把模型选型当作基础设施一样管理先定标准再谈体验。其实 HN 帖子里那些长篇回复翻来覆去都在说同一件事模型不是收藏品是工具工具就要讲适用性和成本。1.2 选错的代价三笔明明白白的账选错模型的代价不体现在某一次对话上而是长期累计的。先说时间上下文太小长文档分析做不了你就得手动把文档切成几段再拼接一天浪费一两个小时。再说钱同一任务贵模型和便宜模型的价格可能差一个数量级如果你把批量任务全跑在一个高配模型上月底账单会很吓人。最后说稳定性有些模型 API 高峰期会报容量错误Agent 跑了一半失败重试又烧钱又浪费时间。这三笔账在选型时就要算清楚不要等出问题再改。我见过不少项目上线时只看模型分数没算费率结果第一周就被成本劝退。更隐蔽的是延迟带来的隐性成本一个代码补全工具如果平均返回要八秒开发者的注意力早就切走了所谓的“提效”根本不存在。所以每次有人问我“哪个模型好”我都会先反问他你更缺时间、缺钱还是缺稳定答案不一样推荐完全不一样。1.3 回复里最常被忽略的三个前提预算、延迟、数据边界在参考别人“我用哪个模型”之前先确认三个前提。第一是预算个人开发者和公司能接受的单月 API 费用完全不是一个量级。第二是延迟交互式聊天能接受 5 秒内返回但批量处理可以接受慢一点同一个模型在不同场景下的可用性评价完全不同。第三是数据边界代码库、数据库结构、客户信息能不能发到云端决定了你是否只能走私有化部署。这三点一变任何人的答案都不可直接抄。这也是为什么我后面给的配置只算“参考”你必须按自己的场景重新评估一遍否则今天抄的配置明天就会变成生产事故。2. 工作场景下我按哪些维度挑模型2.1 上下文长度追求 1M 之前先问自己真的需要吗现在模型动辄支持 128k、200k甚至 1M token宣传看着很爽但我的经验是不要迷信最大上下文。原因有三个第一上下文越大单次请求的费用和延迟越高1M token 的请求按 token 计费是相当贵的第二模型在超长上下文里容易出现“lost in the middle”也就是中间段落的召回率下降你塞进去的信息未必都生效第三很多工具会把检索结果、系统提示、记忆库全部算进上下文你以为只发了 5 万 token实际已经接近上限。我用下面这张表当作参考基准任务类型建议上下文我的实测感受日常聊天、邮件草稿8k/16k足够省时省钱代码补全、单文件修改32k再长意义不大长文档摘要、深度分析128k必须实测末尾引用是否准确整仓库理解、大型 RAG200k/1M慎用先算账再上选模型时打开一份真实的长文档让模型引用文档最后几页的内容看看是否准确。这比看宣传数据靠谱得多。热词里那条 “this models maximum context length is 1048576 tokens” 很常见但真正干活的场景里大部分人连 100k 都用不满盲目追求大窗口只会让账单变大、响应变慢。2.2 代码能力与工具调用决定模型能不能进你的工作流工作里用模型最常见的是代码补全和 Agent 自动化两种。前者只要会续写代码后者要求模型真正理解“调用工具—拿到结果—决定下一步”的循环这个能力官方的说法叫 Function Calling / Tool Use。我实测的感受是很多模型在聊天场景表现惊艳一旦接进工具链输出格式不稳定、工具调用参数错位任务就频繁失败。所以选模型前我会用真实的代码仓库跑一遍“改 bug—跑测试—报结果”的流程而不是只看刷榜的 benchmark。值得提醒的是像 Codex、Claude Code 这类编码代理工具模型路由做得再好也顶不住模型本身工具调用能力弱。热词里有条报错是 “the gpt-5.6-sol model is not supported when using codex with a chatgpt account”其实就是模型不在当前工具允许列表里或者账号权限不足。还有一条是 “glm-5.3 isnt described by this versions model catalog”说明工具版本里的模型目录不认识你配置的名字。归根结底模型工具调用能力必须实打实测不做回归测试就切模型Agent 任务迟早翻车。2.3 成本、延迟与稳定性生产环境的隐形天花板这三个维度最容易被忽略也最影响生产。成本怎么算不要看单次价格要看任务完成率。便宜模型如果经常让 Agent 重试总成本反而更高。延迟怎么测要测峰值时段的 P95而不是中午空闲时的 P50。稳定性怎么看连续跑一周监控成功率记录失败重试率。我自己的做法是把这些指标写进一个表每个候选模型跑 20 个生产任务样本最后对比再决定。热词里那些 “selected model is at capacity”“unexpected status 404”报错本质上都是稳定性问题的体现第 4 节我会专门展开。另外生产环境一定要预留模型切换的开关别把模型名写死在几十个脚本里。3. 主流模型横向对比我实测下来的真实感受3.1 Claude 系与 GPT 系通用对话和工程生态的取舍我不站队只讲实际情况。在我负责的项目里Claude 系在长文本理解、结构化输出比如 JSON 和代码格式上表现比较稳特别适合“读长文档然后写总结”这类任务。GPT 系生态最成熟工具调用、插件、Agent 框架支持最广泛遇到问题查资料也最容易。如果团队里新人多我倾向于优先选生态成熟的那套因为踩坑成本低。技术选型从来不是只看模型智商还要看周边设施包括文档、社区、兼容性、监控面板。冷门模型再好出问题时连个对照案例都找不到那就不适合生产。这里特别提醒一句模型名别搞混。热词里有 “gpt-5.6-sol”“gpt-6-astra” 这类名字很多是小范围灰度或内部代号普通账号调用会直接报错 “does not exist”。真要用先去官方模型列表查一下别拿生产任务去试新名字。我见过有人在配置里填了个看起来很新的模型名结果整个 CI 全挂排查半天才发现是模型名写错。3.2 Codex / Claude Code 场景下的模型路由与常见坑这类工具不是直接调用 API而是通过自己的路由层间接调用模型所以模型名必须被工具识别。我之前遇到过的报错包括“the gpt-5.6-sol model is not supported when using codex with a chatgpt account”“codex selected model is at capacity”以及配置文件相关的 “codex provider 缺少 base_url 配置”。排查顺序我总结为三步第一步把工具升级到最新版很多新模型名是随版本更新的第二步用models list之类的命令列出当前账号可用模型确认名字完全一致包括大小写和后缀第三步检查账号权限和套餐免费账号调付费模型就会报 not supported。这个流程八成能解决问题。另外这类工具经常会读 config.toml比如指定 provider、base_url、api_key。报错 “cc switch local proxy failed while handling codex endpoint” 这类通常是本地网关或代理配置出了问题本质是 provider 的 base_url 没配上或配错了。我建议先把所有 provider 配置抽成一个独立文件再逐个验证不要靠猜。还有一句 “claude doesnt look like an anthropic model: expected a gateway model route” 也属于这一类表面上在说模型实际是网关把请求路由到了错误的模型上。3.3 DeepSeek、GLM 与本地 GGUF性价比与数据可控性开源和国内模型这两年进步很快。DeepSeek 的 API 价格非常有竞争力适合批量任务和成本敏感场景GLM 系列在中英文混合场景和函数调用上表现不错如果你想完全本地部署GGUF 格式是当前主流的模型序列化格式之一配合本地推理框架可以脱离云端 API适合对数据敏感的工作。但本地部署也有代价需要足够的显存模型规模越小效果越差版本升级和维护也要自己来。热词里有两条很典型的本地坑“no lm runtime found for model format gguf”和“error: pull model manifest: file does not exist”前者是推理框架不支持你下载的格式后者是模型仓库里的名字拉错了。我的建议是先评估数据隐私需求再决定要不要走本地路线。如果只是个人学习或原型验证本地 GGUF 很合适一次下载断网也能跑如果是团队生产优先考虑成熟的托管 API除非有硬性隐私合规要求。不要因为“免费”选本地算上服务器、电费和调试时间未必比 API 便宜。我踩过的坑是下载了一个新量化的 GGUF结果跑起来速度感人不如直接调 API。选本地部署前先用小模型试跑一轮确认吞吐量能满足业务再投入。4. 5分钟排查模型报错容量、上下文、配置三大类4.1 “selected model is at capacity”高峰期拒载怎么破这个报错完整文案通常是 “selected model is at capacity. please try a different model.”意思是模型需求太旺盛供应商在高峰期拒绝新请求。我的处理办法有三条第一准备一个备用模型遇到容量报错自动切换第二写重试逻辑比如指数退避重试三次每次间隔从几秒到几十秒第三如果是定时批量任务尽量避开高峰时段。另外如果连续半天都报这个错误就要检查是不是模型名写错了或者供应商已经把这个模型下线切换到模型目录里的其他实例试试。实操时我会在任务调度脚本里加一层容错例如for attempt in range(3): try: result call_model(primary_model, task) break except CapacityError: time.sleep(3 ** attempt) result call_model(fallback_model, task)这段逻辑看起来简单但能挡住大部分“半夜任务失败”的尴尬。遇到容量报错时千万别无限重试同一个模型那样只会一直失败。热词里 “error from provider (console): upstream request failed: model is unavailable” 也是类似场景换模型或换时段通常能立竿见影。4.2 “maximum context length”上下文超限的拆解流程报错长这样“api error: 400 this models maximum context length is 1048576 tokens. However...” 意思是你的请求里输入加输出超出了模型上限。处理流程分三步先看是哪个部分吃满了 token通常罪魁祸首是 RAG 检索结果太多或者历史消息没有清理然后对历史做摘要、压缩或者截断最旧的消息最后如果业务真的需要超长上下文再换更大的模型比如那种明确支持 1M 的版本。这里有个容易被忽略的点很多工具会把嵌入的文件内容全都算进 context比如你把整个代码仓库塞进提示词分分钟触发 “maximum context length”。热词里有一条 “error during compaction: api error: 400 this models maximum context length” 和 “codex ran out of room in the models context”都是同一个根源任务范围太大。解决后建议加一个 token 使用量监控每次请求前先估算超标就先做裁剪而不是直接发出去等报错再改。顺带一提粗略估算时 1 个 token 大约对应 0.75 个英文单词或者 0.5 个汉字中文场景尤其要注意别超。4.3 “model not supported / does not exist”名称、版本、权限三方校验这类报错主要有三种原因模型名拼写错误或不在当前工具白名单里工具版本太旧不认识新模型账号权限不够比如免费账号调付费模型。排查方法很简单先用官方 API 或工具列出所有可用模型确认名字再更新工具到最新版最后检查账号套餐。热词里那条 “unexpected status 404 not found: the modelgpt-6-soldoes not exist or you...” 就是典型模型名错了或者被下线了。遇到这种别硬猜直接查模型列表最快一般一个命令就能看到官方支持的所有模型名。我还见过一种情况同一套工具连不同供应商模型路由表不同。同一个名字在这个供应商能用在另一个供应商直接 404。所以配置里务必写明 base_url 和模型目录不要跨商乱套。另外Claude Code 这类工具经常会缓存模型目录升级工具后旧名字还在报错清一下缓存再试。这类问题通常不是模型本身的问题而是工具和账号之间的“沟通”出了问题。4.4 config.toml 与 provider 配置“缺少 base_url”这类报错的通用套路现在很多 CLI 工具用 config.toml 管理模型配置报错也特别多比如 “chatgpt 无法加载 config.toml:model”“codex provider 缺少 base_url 配置”“local proxy failed while handling codex endpoint”。这类问题 90% 是配置键拼错、路径不对、环境变量没生效。我建议按下面的顺序排查先确认配置文件路径用--config参数或默认目录打印当前生效配置再确认 provider、model、base_url、api_key 四项齐不齐然后跑一个最简单的列表命令验证连通性最后再跑完整任务。千万别一上来就重装工具多数时候是配置文件有问题不是工具坏了。一份最简配置大概长这样[provider] name example base_url https://api.example.com/v1 api_key env:EXAMPLE_API_KEY [model] primary deepseek-flash fallback glm-5.3写完后先config validate一把再跑一次最小调用确认通了我才会继续接业务。热词里 “adk kotlin 的 model 目前仅内置 gemini” 也是同类问题工具只支持内置模型你却配了外部模型自然不认。配置类错误最怕“凭感觉改”一定要让工具自己告诉你它读到了什么配置。5. 我现在的生产环境模型配置给你一份可以直接抄的作业5.1 按任务分四类别用同一把尺子量所有需求我现在的做法是把工作里的模型需求分成四类每类配一个默认模型。第一类日常问答、邮件草稿、格式整理用便宜快速的小模型够用就行不需要上旗舰。第二类代码生成、代码审查、小范围重构用中高档模型具体型号看团队对哪套生态熟悉比如 DeepSeek、GLM 或者主流的通用模型。第三类长文档分析、合同摘要、技术报告用长上下文模型并在外层套摘要和裁剪流程防止一次性塞爆。第四类Agent 自动化任务用工具调用能力强、API 稳定的模型同时配置重试和降级。这样分完预算、延迟、稳定性的边界都清晰了不会出现“一个模型打天下”的窘境。这四类任务的模型切换在代码里其实很轻量把模型名做成配置项每个任务声明自己需要的模型等级就行。我甚至会在 prompt 里标注当前任务的类型让路由逻辑自动选择对应模型。这样团队新人也知道该往哪个配置里填不会乱改。5.2 主力模型 降级模型兜底方案怎么写任何模型都有不可用的时候生产环境必须留后路。我的做法是主线模型 A备选模型 B如果 A 连续三次报容量或超时错误自动切到 B同时每个任务设最大重试次数避免无限重试烧钱。配置层面把所有模型名、base_url、api_key 抽成环境变量或独立配置文件切换模型时只改配置不动业务代码。这样就算供应商临时下架模型我改一行就能恢复。前面也提过我踩过硬编码模型名的坑——模型一换代几十个脚本全要改真的很痛苦别学我。降级不是简单换一个名字而是要考虑能力差异。主力模型擅长复杂推理备选模型可能只适合简单任务所以我会在调用逻辑里区分如果任务对输出质量要求极高宁可重试也不降级如果只是格式化或摘要降级完全没影响。这种分级策略能最大程度保住核心任务的体验同时控制成本。5.3 新模型跟踪每季度小范围验证一次别拿生产试新新模型层出不穷连“从零构建大模型”的教程都快成标配了但工作里不需要追新。我的节奏是每季度把候选新模型加入测试集跑一遍我自己整理的 20 个典型任务记录输出质量、成本、延迟再和当前基线对比。只有新一代模型在多数任务上有明显优势才正式切换。另外很多新模型名在灰度期只对部分账号开放直接切换会踩 404 和 not supported 的坑。想尝鲜就开个小账号单独测测完再决定要不要报到正式的配置里。我见过有人看到新模型发布当天就切生产结果发现 API 端点都还没稳定整个下午都在填坑。新模型发布后的头两周我基本只观察社区反馈不动自己的配置。等文档和 SDK 更新了再在测试环境跑一轮确认稳定后才会考虑升级。6. 最后分享几个踩坑后的真实心得写到这里我最想说的是别再纠结“哪个模型最强”了真正该问的是“这个任务用哪个模型最合适、最稳定、最省钱”。我因为上下文超限浪费过整个晚上因为容量报错让定时任务中断过因为模型名不是官方名被 404 折腾过一个下午。所以我的默认规则是任何重要任务都要有重试和回退任何模型名都以官方列表为准任何配置改动都先验证再批量应用。这三条说起来简单但能帮你省下大量时间。最后再分享一个小技巧在本地维护一张模型速查卡记下模型名、适合任务、上下文上限、单 token 价格、常见报错关键词。每次切模型前先翻一眼再用真实任务跑一轮回归基本就不会翻车。选型不是一锤子买卖它是跟着业务需求不断调整的日常工程决策。如果你现在正面临选型困扰不妨先把你手头最典型的五个任务拿过来跑一遍让结果替你说话而不是让排行榜替代你的判断。
Hacker News 上每隔一段时间就会出现一个帖子“Ask HN: Which model do you use for work?” 我每次看到都会点进去翻一翻因为回复里藏着大量真实的生产环境选型经验比任何榜单都有参考价值。这个问题看起来简单但真正用模型干过活的人都知道答案远不止“某个模型最强”那么简单。工作场景里的模型选择本质上是在能力、成本、延迟、稳定性和数据边界之间做权衡。这篇文章想把我在多个项目里选模型、切模型、排查模型报错的经历梳理一遍希望能给同样纠结选型的人一些参考。1. 为什么工作中选模型是个真问题而不是“喜欢哪个用哪个”1.1 从 Ask HN 热帖说起模型已经变成工作流基础设施HN 那个帖子的经典之处在于回答往往是“看场景”。有人会用最贵的模型做代码审查用便宜模型做格式化有人只用开源模型跑本地离线任务还有一部分人干脆说“我们公司内部统一用某个模型省得每个人踩一遍坑”。这说明模型选型已经变成工程决策而不是个人偏好。一个团队的模型选型会直接影响 CI 流水线费用、代码生成质量、Agent 任务成功率这些东西最后都会折算成时间和钱。我身边很多团队从上到下只维护一份模型配置原因就在这里减少混乱出问题也好排查。我自己也经历过从“随手换模型”到“固定生产配置”的转变。早期写脚本时经常今天用这个 API、明天换那个模型结果一到月底对账发现大部分钱都花在重复尝试上。后来学乖了把模型选型当作基础设施一样管理先定标准再谈体验。其实 HN 帖子里那些长篇回复翻来覆去都在说同一件事模型不是收藏品是工具工具就要讲适用性和成本。1.2 选错的代价三笔明明白白的账选错模型的代价不体现在某一次对话上而是长期累计的。先说时间上下文太小长文档分析做不了你就得手动把文档切成几段再拼接一天浪费一两个小时。再说钱同一任务贵模型和便宜模型的价格可能差一个数量级如果你把批量任务全跑在一个高配模型上月底账单会很吓人。最后说稳定性有些模型 API 高峰期会报容量错误Agent 跑了一半失败重试又烧钱又浪费时间。这三笔账在选型时就要算清楚不要等出问题再改。我见过不少项目上线时只看模型分数没算费率结果第一周就被成本劝退。更隐蔽的是延迟带来的隐性成本一个代码补全工具如果平均返回要八秒开发者的注意力早就切走了所谓的“提效”根本不存在。所以每次有人问我“哪个模型好”我都会先反问他你更缺时间、缺钱还是缺稳定答案不一样推荐完全不一样。1.3 回复里最常被忽略的三个前提预算、延迟、数据边界在参考别人“我用哪个模型”之前先确认三个前提。第一是预算个人开发者和公司能接受的单月 API 费用完全不是一个量级。第二是延迟交互式聊天能接受 5 秒内返回但批量处理可以接受慢一点同一个模型在不同场景下的可用性评价完全不同。第三是数据边界代码库、数据库结构、客户信息能不能发到云端决定了你是否只能走私有化部署。这三点一变任何人的答案都不可直接抄。这也是为什么我后面给的配置只算“参考”你必须按自己的场景重新评估一遍否则今天抄的配置明天就会变成生产事故。2. 工作场景下我按哪些维度挑模型2.1 上下文长度追求 1M 之前先问自己真的需要吗现在模型动辄支持 128k、200k甚至 1M token宣传看着很爽但我的经验是不要迷信最大上下文。原因有三个第一上下文越大单次请求的费用和延迟越高1M token 的请求按 token 计费是相当贵的第二模型在超长上下文里容易出现“lost in the middle”也就是中间段落的召回率下降你塞进去的信息未必都生效第三很多工具会把检索结果、系统提示、记忆库全部算进上下文你以为只发了 5 万 token实际已经接近上限。我用下面这张表当作参考基准任务类型建议上下文我的实测感受日常聊天、邮件草稿8k/16k足够省时省钱代码补全、单文件修改32k再长意义不大长文档摘要、深度分析128k必须实测末尾引用是否准确整仓库理解、大型 RAG200k/1M慎用先算账再上选模型时打开一份真实的长文档让模型引用文档最后几页的内容看看是否准确。这比看宣传数据靠谱得多。热词里那条 “this models maximum context length is 1048576 tokens” 很常见但真正干活的场景里大部分人连 100k 都用不满盲目追求大窗口只会让账单变大、响应变慢。2.2 代码能力与工具调用决定模型能不能进你的工作流工作里用模型最常见的是代码补全和 Agent 自动化两种。前者只要会续写代码后者要求模型真正理解“调用工具—拿到结果—决定下一步”的循环这个能力官方的说法叫 Function Calling / Tool Use。我实测的感受是很多模型在聊天场景表现惊艳一旦接进工具链输出格式不稳定、工具调用参数错位任务就频繁失败。所以选模型前我会用真实的代码仓库跑一遍“改 bug—跑测试—报结果”的流程而不是只看刷榜的 benchmark。值得提醒的是像 Codex、Claude Code 这类编码代理工具模型路由做得再好也顶不住模型本身工具调用能力弱。热词里有条报错是 “the gpt-5.6-sol model is not supported when using codex with a chatgpt account”其实就是模型不在当前工具允许列表里或者账号权限不足。还有一条是 “glm-5.3 isnt described by this versions model catalog”说明工具版本里的模型目录不认识你配置的名字。归根结底模型工具调用能力必须实打实测不做回归测试就切模型Agent 任务迟早翻车。2.3 成本、延迟与稳定性生产环境的隐形天花板这三个维度最容易被忽略也最影响生产。成本怎么算不要看单次价格要看任务完成率。便宜模型如果经常让 Agent 重试总成本反而更高。延迟怎么测要测峰值时段的 P95而不是中午空闲时的 P50。稳定性怎么看连续跑一周监控成功率记录失败重试率。我自己的做法是把这些指标写进一个表每个候选模型跑 20 个生产任务样本最后对比再决定。热词里那些 “selected model is at capacity”“unexpected status 404”报错本质上都是稳定性问题的体现第 4 节我会专门展开。另外生产环境一定要预留模型切换的开关别把模型名写死在几十个脚本里。3. 主流模型横向对比我实测下来的真实感受3.1 Claude 系与 GPT 系通用对话和工程生态的取舍我不站队只讲实际情况。在我负责的项目里Claude 系在长文本理解、结构化输出比如 JSON 和代码格式上表现比较稳特别适合“读长文档然后写总结”这类任务。GPT 系生态最成熟工具调用、插件、Agent 框架支持最广泛遇到问题查资料也最容易。如果团队里新人多我倾向于优先选生态成熟的那套因为踩坑成本低。技术选型从来不是只看模型智商还要看周边设施包括文档、社区、兼容性、监控面板。冷门模型再好出问题时连个对照案例都找不到那就不适合生产。这里特别提醒一句模型名别搞混。热词里有 “gpt-5.6-sol”“gpt-6-astra” 这类名字很多是小范围灰度或内部代号普通账号调用会直接报错 “does not exist”。真要用先去官方模型列表查一下别拿生产任务去试新名字。我见过有人在配置里填了个看起来很新的模型名结果整个 CI 全挂排查半天才发现是模型名写错。3.2 Codex / Claude Code 场景下的模型路由与常见坑这类工具不是直接调用 API而是通过自己的路由层间接调用模型所以模型名必须被工具识别。我之前遇到过的报错包括“the gpt-5.6-sol model is not supported when using codex with a chatgpt account”“codex selected model is at capacity”以及配置文件相关的 “codex provider 缺少 base_url 配置”。排查顺序我总结为三步第一步把工具升级到最新版很多新模型名是随版本更新的第二步用models list之类的命令列出当前账号可用模型确认名字完全一致包括大小写和后缀第三步检查账号权限和套餐免费账号调付费模型就会报 not supported。这个流程八成能解决问题。另外这类工具经常会读 config.toml比如指定 provider、base_url、api_key。报错 “cc switch local proxy failed while handling codex endpoint” 这类通常是本地网关或代理配置出了问题本质是 provider 的 base_url 没配上或配错了。我建议先把所有 provider 配置抽成一个独立文件再逐个验证不要靠猜。还有一句 “claude doesnt look like an anthropic model: expected a gateway model route” 也属于这一类表面上在说模型实际是网关把请求路由到了错误的模型上。3.3 DeepSeek、GLM 与本地 GGUF性价比与数据可控性开源和国内模型这两年进步很快。DeepSeek 的 API 价格非常有竞争力适合批量任务和成本敏感场景GLM 系列在中英文混合场景和函数调用上表现不错如果你想完全本地部署GGUF 格式是当前主流的模型序列化格式之一配合本地推理框架可以脱离云端 API适合对数据敏感的工作。但本地部署也有代价需要足够的显存模型规模越小效果越差版本升级和维护也要自己来。热词里有两条很典型的本地坑“no lm runtime found for model format gguf”和“error: pull model manifest: file does not exist”前者是推理框架不支持你下载的格式后者是模型仓库里的名字拉错了。我的建议是先评估数据隐私需求再决定要不要走本地路线。如果只是个人学习或原型验证本地 GGUF 很合适一次下载断网也能跑如果是团队生产优先考虑成熟的托管 API除非有硬性隐私合规要求。不要因为“免费”选本地算上服务器、电费和调试时间未必比 API 便宜。我踩过的坑是下载了一个新量化的 GGUF结果跑起来速度感人不如直接调 API。选本地部署前先用小模型试跑一轮确认吞吐量能满足业务再投入。4. 5分钟排查模型报错容量、上下文、配置三大类4.1 “selected model is at capacity”高峰期拒载怎么破这个报错完整文案通常是 “selected model is at capacity. please try a different model.”意思是模型需求太旺盛供应商在高峰期拒绝新请求。我的处理办法有三条第一准备一个备用模型遇到容量报错自动切换第二写重试逻辑比如指数退避重试三次每次间隔从几秒到几十秒第三如果是定时批量任务尽量避开高峰时段。另外如果连续半天都报这个错误就要检查是不是模型名写错了或者供应商已经把这个模型下线切换到模型目录里的其他实例试试。实操时我会在任务调度脚本里加一层容错例如for attempt in range(3): try: result call_model(primary_model, task) break except CapacityError: time.sleep(3 ** attempt) result call_model(fallback_model, task)这段逻辑看起来简单但能挡住大部分“半夜任务失败”的尴尬。遇到容量报错时千万别无限重试同一个模型那样只会一直失败。热词里 “error from provider (console): upstream request failed: model is unavailable” 也是类似场景换模型或换时段通常能立竿见影。4.2 “maximum context length”上下文超限的拆解流程报错长这样“api error: 400 this models maximum context length is 1048576 tokens. However...” 意思是你的请求里输入加输出超出了模型上限。处理流程分三步先看是哪个部分吃满了 token通常罪魁祸首是 RAG 检索结果太多或者历史消息没有清理然后对历史做摘要、压缩或者截断最旧的消息最后如果业务真的需要超长上下文再换更大的模型比如那种明确支持 1M 的版本。这里有个容易被忽略的点很多工具会把嵌入的文件内容全都算进 context比如你把整个代码仓库塞进提示词分分钟触发 “maximum context length”。热词里有一条 “error during compaction: api error: 400 this models maximum context length” 和 “codex ran out of room in the models context”都是同一个根源任务范围太大。解决后建议加一个 token 使用量监控每次请求前先估算超标就先做裁剪而不是直接发出去等报错再改。顺带一提粗略估算时 1 个 token 大约对应 0.75 个英文单词或者 0.5 个汉字中文场景尤其要注意别超。4.3 “model not supported / does not exist”名称、版本、权限三方校验这类报错主要有三种原因模型名拼写错误或不在当前工具白名单里工具版本太旧不认识新模型账号权限不够比如免费账号调付费模型。排查方法很简单先用官方 API 或工具列出所有可用模型确认名字再更新工具到最新版最后检查账号套餐。热词里那条 “unexpected status 404 not found: the modelgpt-6-soldoes not exist or you...” 就是典型模型名错了或者被下线了。遇到这种别硬猜直接查模型列表最快一般一个命令就能看到官方支持的所有模型名。我还见过一种情况同一套工具连不同供应商模型路由表不同。同一个名字在这个供应商能用在另一个供应商直接 404。所以配置里务必写明 base_url 和模型目录不要跨商乱套。另外Claude Code 这类工具经常会缓存模型目录升级工具后旧名字还在报错清一下缓存再试。这类问题通常不是模型本身的问题而是工具和账号之间的“沟通”出了问题。4.4 config.toml 与 provider 配置“缺少 base_url”这类报错的通用套路现在很多 CLI 工具用 config.toml 管理模型配置报错也特别多比如 “chatgpt 无法加载 config.toml:model”“codex provider 缺少 base_url 配置”“local proxy failed while handling codex endpoint”。这类问题 90% 是配置键拼错、路径不对、环境变量没生效。我建议按下面的顺序排查先确认配置文件路径用--config参数或默认目录打印当前生效配置再确认 provider、model、base_url、api_key 四项齐不齐然后跑一个最简单的列表命令验证连通性最后再跑完整任务。千万别一上来就重装工具多数时候是配置文件有问题不是工具坏了。一份最简配置大概长这样[provider] name example base_url https://api.example.com/v1 api_key env:EXAMPLE_API_KEY [model] primary deepseek-flash fallback glm-5.3写完后先config validate一把再跑一次最小调用确认通了我才会继续接业务。热词里 “adk kotlin 的 model 目前仅内置 gemini” 也是同类问题工具只支持内置模型你却配了外部模型自然不认。配置类错误最怕“凭感觉改”一定要让工具自己告诉你它读到了什么配置。5. 我现在的生产环境模型配置给你一份可以直接抄的作业5.1 按任务分四类别用同一把尺子量所有需求我现在的做法是把工作里的模型需求分成四类每类配一个默认模型。第一类日常问答、邮件草稿、格式整理用便宜快速的小模型够用就行不需要上旗舰。第二类代码生成、代码审查、小范围重构用中高档模型具体型号看团队对哪套生态熟悉比如 DeepSeek、GLM 或者主流的通用模型。第三类长文档分析、合同摘要、技术报告用长上下文模型并在外层套摘要和裁剪流程防止一次性塞爆。第四类Agent 自动化任务用工具调用能力强、API 稳定的模型同时配置重试和降级。这样分完预算、延迟、稳定性的边界都清晰了不会出现“一个模型打天下”的窘境。这四类任务的模型切换在代码里其实很轻量把模型名做成配置项每个任务声明自己需要的模型等级就行。我甚至会在 prompt 里标注当前任务的类型让路由逻辑自动选择对应模型。这样团队新人也知道该往哪个配置里填不会乱改。5.2 主力模型 降级模型兜底方案怎么写任何模型都有不可用的时候生产环境必须留后路。我的做法是主线模型 A备选模型 B如果 A 连续三次报容量或超时错误自动切到 B同时每个任务设最大重试次数避免无限重试烧钱。配置层面把所有模型名、base_url、api_key 抽成环境变量或独立配置文件切换模型时只改配置不动业务代码。这样就算供应商临时下架模型我改一行就能恢复。前面也提过我踩过硬编码模型名的坑——模型一换代几十个脚本全要改真的很痛苦别学我。降级不是简单换一个名字而是要考虑能力差异。主力模型擅长复杂推理备选模型可能只适合简单任务所以我会在调用逻辑里区分如果任务对输出质量要求极高宁可重试也不降级如果只是格式化或摘要降级完全没影响。这种分级策略能最大程度保住核心任务的体验同时控制成本。5.3 新模型跟踪每季度小范围验证一次别拿生产试新新模型层出不穷连“从零构建大模型”的教程都快成标配了但工作里不需要追新。我的节奏是每季度把候选新模型加入测试集跑一遍我自己整理的 20 个典型任务记录输出质量、成本、延迟再和当前基线对比。只有新一代模型在多数任务上有明显优势才正式切换。另外很多新模型名在灰度期只对部分账号开放直接切换会踩 404 和 not supported 的坑。想尝鲜就开个小账号单独测测完再决定要不要报到正式的配置里。我见过有人看到新模型发布当天就切生产结果发现 API 端点都还没稳定整个下午都在填坑。新模型发布后的头两周我基本只观察社区反馈不动自己的配置。等文档和 SDK 更新了再在测试环境跑一轮确认稳定后才会考虑升级。6. 最后分享几个踩坑后的真实心得写到这里我最想说的是别再纠结“哪个模型最强”了真正该问的是“这个任务用哪个模型最合适、最稳定、最省钱”。我因为上下文超限浪费过整个晚上因为容量报错让定时任务中断过因为模型名不是官方名被 404 折腾过一个下午。所以我的默认规则是任何重要任务都要有重试和回退任何模型名都以官方列表为准任何配置改动都先验证再批量应用。这三条说起来简单但能帮你省下大量时间。最后再分享一个小技巧在本地维护一张模型速查卡记下模型名、适合任务、上下文上限、单 token 价格、常见报错关键词。每次切模型前先翻一眼再用真实任务跑一轮回归基本就不会翻车。选型不是一锤子买卖它是跟着业务需求不断调整的日常工程决策。如果你现在正面临选型困扰不妨先把你手头最典型的五个任务拿过来跑一遍让结果替你说话而不是让排行榜替代你的判断。
