Gemini CLI 聊天正常，摘要却报 503：后台模型怎么配
Gemini CLI 主模型能用，后台会话摘要却提示 flash-lite 无可用渠道？对照 v0.67.0，区分聊天、会话摘要和上下文压缩，用任务级配置修改摘要模型，再核对实际请求。
Gemini CLI 已经能正常回答，终端却又出现 503，报错里还是一个自己没选过的 flash-lite 模型。遇到这种情况，先找出失败的是主聊天，还是另一条后台调用。只在 /model 里反复切换，可能一直没改到出问题的那条路径。
本文处理的是为历史会话生成一行说明的摘要任务。它与长对话接近上限时的上下文压缩分别配置。下面按 2026 年 11 月 8 日查阅的 Gemini CLI 正式版 v0.67.0 说明；初次接入先完成 Gemini CLI 的 Nbility 配置。
报错里的模型，可能来自会话摘要
Issue #29065 提供了一个具体例子：作者使用 Windows 上的 CLI 0.56.0，主模型是 gemini-3.1-pro-preview，聊天正常；后台会话摘要却请求 gemini-3.1-flash-lite。所用中转服务的当前分组没有这个模型的可用渠道，返回 model_not_found，HTTP 状态是 503，随后发生退避重试。
这是作者的故障记录。Issue 由作者于 9 月 23 日关闭，公开讨论里没有给出明确的正式修复版本，不能仅凭 Closed 推断当前版本已经解决了所有同类配置问题。
但当前正式版有一条可以核对的配置路径：v0.67.0 的 SessionSummaryService 使用 summarizer-default 请求摘要；默认模型配置把这个任务指向 flash-lite。这个短名称还要解析为具体模型 ID，不能直接当成最终发出的名称。
在该版本的默认解析规则中，flash-lite 通常对应 gemini-3.1-flash-lite；启用相应的 latest Flash-Lite 条件时，对应 gemini-3.5-flash-lite。自己的安装、功能条件、回退策略和服务端映射仍可能改变实际目标，以请求记录为准。
先分开这三种“模型设置”
| 调用在做什么 | v0.67.0 中相关的选择入口 | 需要确认什么 |
|---|---|---|
| 回答当前问题、推进主任务 | /model、启动参数及当前聊天模型 | 当前主聊天实际请求了哪个模型 |
| 给历史会话生成一行说明 | summarizer-default | 这个任务解析后的目标能否由当前凭据访问 |
| 缩短当前对话历史以继续工作 | chat-compression-* 系列配置 | 对应聊天模型选到了哪个压缩配置 |
官方 模型选择说明也明确提示，/model 和 --model 不覆盖子 Agent 的模型。会话摘要还有自己的配置键，因此“主模型已选好”不能作为整条 Agent 工作流都已验证的证据。
这里的 summarizer-default 也可能被其他总结工具结果的路径使用；修改它并不只影响会话列表的文字。另一方面，只修改这个键，不会同时改掉 summarizer-shell、classifier 和整组 chat-compression-*。遇到压缩报错时，应先核对压缩调用，不能直接套下面的摘要配置。
看完整错误，确认是不是模型可用范围不匹配
先运行 gemini --version，在交互会话里用 /about 核对当前版本、模型与认证方式。保留失败时间、任务阶段、请求中的模型 ID、HTTP 状态和脱敏后的错误正文。
重点看错误正文是否同时出现 model_not_found、具体模型名和“当前分组无可用渠道”一类说明。这个组合优先指向模型可用范围或路由配置；反复重放相同请求通常不会改变它。只有一个 503、没有进一步信息时，还需要排查临时容量、上游状态等其他原因。
主聊天正常，只说明那一次请求的模型和路径可用。继续核对：
- 摘要调用是否使用同一地址、认证方式和令牌；当前令牌及分组是否允许报错里的精确模型 ID。
- 服务是否支持 Gemini 原生
generateContent路径。OpenAI Chat Completions 能用，不足以证明这条路径可用；Nbility 的地址和字段见 Gemini 原生兼容 API。 - 项目是否覆盖了用户设置，系统管理配置是否又覆盖了项目设置。只检查一份
settings.json，可能看不到最终生效的值。
界面里的重试提示也需要日志佐证。近期 Issue #30080报告了后台或旧请求的重试状态可能混进前台显示；作者在 11 月 7 日的后续验证中还更正了最初的预算疑问，没有复现“重试预算错误”。这类显示线索不能单独证明请求被路由到了错误模型。
若请求一直因同一个模型不可用而失败，先处理配置，再恢复任务。多层重试的放大过程解释了为什么客户端和网关一起重试，会把一个明确错误拖成更长等待。
用任务级规则指定摘要模型
有两种处理方向：让当前凭据能够使用原本的摘要模型，或者给摘要任务指定一个自己已经验证过的模型。选择取决于模型服务是否提供它、当前权限和参数兼容性；把模型名改成某个别名，本身不会增加权限或补齐能力。
如果选第二种方式，可以使用官方支持的 modelConfigs.customOverrides。先保留原设置，再把下面的内容合并进用户级 ~/.gemini/settings.json，或所需项目的 .gemini/settings.json。已有 modelConfigs 或 customOverrides 时，在原对象和数组里加入这条规则，不要重复创建同名 JSON 键，也不要覆盖其他规则。
{
"modelConfigs": {
"customOverrides": [
{
"match": {
"model": "summarizer-default"
},
"modelConfig": {
"model": "YOUR_SUMMARY_MODEL_ID"
}
}
]
}
}
将 YOUR_SUMMARY_MODEL_ID 替换为当前令牌可用、支持这条 Gemini 调用及相关参数的真实模型 ID。它可以与主聊天相同，也可以是另一款合适的模型；使用更大的模型可能改变费用和响应时间，需要按实际调用判断。
这条规则匹配任务配置名 summarizer-default，只提供新的 model。根据 v0.67.0 的解析实现，它会保留该配置继承的生成参数，包括默认的 maxOutputTokens: 2000。因此它比修改整个 flash-lite 共用模型更容易控制影响范围。
保留参数不代表参数一定适合新模型。若目标模型不接受继承的温度、采样或输出设置，应按该模型文档另行调整，不能为了消除 model_not_found，再制造一个参数错误。官方 高级模型配置说明解释了别名继承与覆盖；配置参考列出了 customOverrides。
这也是初始选择规则，后续可用性回退、其他更具体的规则和服务端映射仍可能影响最终请求。保存后重新启动一个用于验证的 CLI 进程，检查实际调用；不要只看到 JSON 能解析，就认定线上问题已解决。
验证时，要确实触发一次摘要请求
先在临时目录做一段不含私有数据的演示对话，至少发送两条用户消息，再正常退出。随后从同一目录运行：
gemini --list-sessions
这条命令可能请求模型，并非纯离线列目录。 v0.67.0 的会话列表实现在列出会话前，会尝试补充最近一个符合条件的历史会话摘要信息。已有摘要或相关元数据、用户消息数量不足等情况，可能让一行摘要请求被跳过。因此，列表显示正常、错误没有再出现，都不能单独算作模型配置已经生效。
用脱敏后的请求记录确认这几件事：
- 确实产生了这条摘要调用，模型 ID 是预期值，或能解释其后续回退目标。
- 请求成功并生成了可用的会话说明；原来的模型不可用错误没有在同一路径重现。
- 再发送一条主聊天请求，它仍使用预期配置并正常完成。
使用 Nbility 时，可以将时间和模型与用量日志对照；日志能辅助确认调用，任务归属仍要结合 CLI 记录判断。若看不到摘要请求，先查触发条件和配置层级，不要通过删除原有会话来强行触发。
如果还是请求旧模型，检查是否启动了另一套 CLI、项目或系统覆盖，以及其他匹配规则。若模型已变、错误变成参数不支持或超时，按新错误继续排查。需要撤回时，只移除本次新增的覆盖项，保留已有配置。
本文用 v0.67.0 的实际配置解析器做了离线检查：任务级覆盖能替换目标、保留继承参数，并让主聊天、summarizer-shell、classifier 和所检查的压缩配置保持原值。没有运行完整 CLI 复现旧报告，也没有发送带认证的聊天或摘要请求；最终效果仍需在自己的服务上验证。
把主聊天和后台调用分别记下来，也有助于理解 Agent 为什么会产生多次模型调用。遇到无法解释的失败，按错误文档的记录清单提供脱敏时间、模型、请求 ID 和错误正文，才能继续缩小范围。
核验资料
- Gemini CLI v0.67.0 Release，2026-11-04
- 会话摘要服务、默认模型配置与配置解析器
- 会话列表入口与摘要触发条件
- 上下文压缩配置选择，用于区分本文范围
- Issue #29065及近期重试显示报告 #30080，状态与后续截至 2026-11-08 查阅时
