[Bug]: reasoning_effort=’none’ capability gate ignores base_model, returning 400 for Azure custom deployment names (Azure GPT-5)

快速结论：这个报错通常出现在 LiteLLM 代理（Proxy）或 SDK 中调用 Azure GPT-5 系列模型、并传入 reasoning_effort='none' 时。核心问题是 supports_none_reasoning_effort 能力检查没有正确解析 Azure 自定义部署名（未通过 base_model 回退），导致请求被 LiteLLM 提前以 400 拒绝，而不是 Azure 拒绝。优先排查你的部署配置中 base_model 与 model_info 的写法，以及当前 LiteLLM 版本。

适用环境：Issue 中确认涉及 LiteLLM（v1.82.3 引入该 gate 后出现，报告者与评论者分别在 v1.86.2、v1.87.0+、v1.103.2 上测试）；使用 Azure OpenAI GPT-5 系列（gpt-5、gpt-5-mini、gpt-5-nano、gpt-5.1、gpt-5.2、gpt-5.4、gpt-5.4-mini、gpt-5.4-nano、gpt-5.5）作为后端模型；部署使用带日期/自定义的 Azure 部署名（如 azure/gpt-5.1_2025-11-13_global）。Issue 未提供操作系统、Python、CUDA、显卡等信息。

最快修复方案：暂无确认的一步修复方案。Issue 中可优先尝试的缓解手段是：在 Azure 部署的 model_info 中显式设置 supports_none_reasoning_effort: true（Issue 正文中作者实测该覆盖生效，none 能正常到达 Azure 并返回 200、reasoning_tokens = 0）；但后续评论指出，当同一 model_info 中同时设置了 base_model 时，该显式标志会被内部数据库继承的能力值覆盖，此时需要移除 base_model 才能让显式标志生效。

注意事项：移除 base_model 会失去其带来的规范模型元数据继承（如成本追踪、max-token 路径等），因此该 workaround 有副作用，不应视为最终方案。显式 supports_none_reasoning_effort: true 与 base_model 的优先级问题在 Issue 中未得到官方合并确认，相关 PR 状态存在反复，是否已在你的版本中修复需要自行验证。另外，即便 gate 开始遵循 base_model，Issue 指出 model_prices_and_context_window.json 中部分 Azure GPT-5 条目仍缺少或错误设置了 supports_none_reasoning_effort，可能依旧失败。

问题场景

用户在 LiteLLM 中调用 Azure OpenAI 的 GPT-5 系列模型，并通过 reasoning_effort='none' 请求关闭推理 token 消耗。典型配置是 Azure 自定义部署名配合 base_model 指定规范模型，例如 model: azure/gpt-5.1_2025-11-13_global 搭配 base_model: azure/gpt-5.1。请求不会到达 Azure，而是在 LiteLLM 的参数映射阶段就被拒绝，返回 400。

该问题在 LiteLLM 升级后出现（Issue 正文称 reasoning_effort='none' 的 gate 由 PR #22953 引入，首次出现在 v1.82.3）。

报错原文

litellm.UnsupportedParamsError: Azure OpenAI does not support reasoning_effort='none'
for this model. Supported values are: 'low', 'medium', and 'high'. To drop this
parameter, set `litellm.drop_params=True` or for proxy.

Proxy 场景下返回的完整响应体：

{
  "error": {
    "message": "litellm.UnsupportedParamsError: Azure OpenAI does not support reasoning_effort='none' for this model. Supported values are: 'low', 'medium', and 'high'. To drop this parameter, set `litellm.drop_params=True` or for proxy: `litellm_settings: drop_params: true` Issue: https://github.com/BerriAI/litellm/issues/16704. Received Model Group=gpt-5.5 Available Model Group Fallbacks=None",
    "type": "invalid_request_error",
    "param": null,
    "code": "400"
  }
}

原因分析

可能原因是 supports_none_reasoning_effort 能力检查的解析路径问题。Issue 正文给出的调用链为：get_optional_params → AzureOpenAIGPT5Config.map_openai_params → _supports_reasoning_effort_level → _supports_factory → _get_model_info_helper，这些环节都不接收或查询 base_model。gate 直接用原始部署名字符串（如 azure/gpt-5.1_2025-11-13_global）去查能力，这个字符串既不是注册表键，也不会回退到 base_model，查找失败后走 except -> return False 路径，于是判定为不支持 none 并拒绝请求。

与之对比，base_model 在成本追踪和 max-token 路径上是被遵循的，说明这是该 capability gate 特有的遗漏。Issue 作者用 per-deployment 的 model_info: { supports_none_reasoning_effort: true } 覆盖后，none 成功到达 Azure 并返回 200、reasoning_tokens = 0，证明 Azure 端接受 none，拒绝来自 LiteLLM。

后续评论补充了另一层可能原因：当 proxy 配置中 model_info.base_model 被设置（例如 base_model: azure/gpt-5-nano）时，LiteLLM 会去 model_prices_and_context_window.json 查找该模型并继承其能力限制。若内部数据库中该条目没有 supports_none_reasoning_effort: true，就会静默覆盖用户在同一 model_info 块中显式设置的 supports_none_reasoning_effort: true，继续阻止 none。

环境排查

确认 LiteLLM 版本：Issue 中问题在 v1.82.3 之后出现，报告者在 v1.86.2 复现，评论者在 v1.87.0+ 与 v1.103.2 上仍复现。
确认使用的 Azure GPT-5 模型型号（gpt-5、gpt-5-mini、gpt-5-nano、gpt-5.1、gpt-5.2、gpt-5.4、gpt-5.4-mini、gpt-5.4-nano、gpt-5.5 均在 Issue 中被提及）。
确认 Azure 部署配置：model 是否为自定义/带日期部署名，是否设置了 base_model，以及 model_info 中的能力标志。
确认 model_info 中是否同时存在 base_model 与 supports_none_reasoning_effort，二者的优先级是问题焦点之一。
确认该模型在 model_prices_and_context_window.json 对应条目中的 supports_none_reasoning_effort 取值（Issue 指出部分条目缺失或错误）。
Issue 未提供操作系统、Python、CUDA、显卡等环境信息，无需据此排查。

解决步骤

确认在 LiteLLM 尚未修复的版本上，请求确实因 gate 被拒而非 Azure 拒绝。可在 Azure 部署的 model_info 中显式加入 supports_none_reasoning_effort: true，观察 reasoning_effort='none' 是否能成功返回 200 且 reasoning_tokens = 0。Issue 作者实测该覆盖有效，可作为定位手段（可优先尝试）。
如果同一 model_info 中同时设置了 base_model，且显式 supports_none_reasoning_effort: true 不生效，可尝试移除 base_model。评论者指出没有 base_model 时 LiteLLM 会跳过内部数据库查找，从而尊重显式标志（可优先尝试）。注意这会丧失规范模型元数据继承，如成本追踪与 max-token 相关路径。
关注上游修复进展。Issue 中提到 PR #28490 通过 base_model 解析 Azure capability gate、声称 v1.87.0 及以后（以 cherry-pick 进入发布分支）已修复，但随后评论指出相关 PR 未合并、在 v1.103.2 上仍复现，Issue 最终以 “Closing as fixed” 关闭。是否已真正修复需以你所用版本的实际表现验证。
若上述 workaround 与版本升级均无效，可在 Issue 中按维护者要求提供最小复现并重开：当前 LiteLLM 版本、完整 Azure 部署配置（含 base_model 与 model_info）、请求体与完整 400 响应。

验证方法

发起一次带 reasoning_effort='none' 的 Azure GPT-5 请求，确认不再返回 UnsupportedParamsError 或 400；成功时应返回 200，且响应中 reasoning_tokens = 0（Issue 作者用此指标确认 none 真正生效）。建议对你实际使用的所有 GPT-5 型号分别验证，因为 Issue 指出部分模型的注册表条目仍可能缺少该标志。