[Bug]: zai provider drops response_format, making structured output impossible for GLM models

快速结论：当客户端通过 LiteLLM 的 zai provider 请求 GLM 模型的结构化输出（response_format，尤其是 json_schema）时，该参数会被 provider 的固定白名单丢弃或直接报错，而代理仍可能返回 HTTP 200，导致下游解析 JSON 失败。优先排查是否使用了 zai/glm-* 模型并依赖 response_format 做 schema 约束。

适用环境：Issue 中复现的环境为 LiteLLM 1.103.0，涉及 zai/glm-5.3-flash、zai/glm-4.7、zai/glm-5-turbo、zai/glm-5.3 等 GLM 模型，并复现于 Graphiti MCP 服务（zepai/knowledge-graph-mcp:standalone）；操作系统、Python、CUDA、显卡信息 Issue 未给出。

最快修复方案：升级到包含 PR #48335 的 LiteLLM 版本。该修复合并后，zai 接受 response_format，在 glm-5.3 和 glm-5.3-flash 上原生发送 json_schema，其他模型则通过 JSON 模式并把 schema 写入提示词。

注意事项：Issue 中提到，Z.AI 端点对 json_schema 的原生支持并不完整（glm-4.7 返回散文、部分模型返回 markdown 表格），json_object 仅保证返回合法 JSON 但不保证符合 schema；因此即使升级，使用 glm-4.7 等模型的严格 schema 约束仍可能不可靠。此外，Issue 指出 litellm.supports_function_calling() / supports_response_schema() 对 zai/glm-5.3 返回 False 的元数据问题，是否随该 PR 一并修复，Issue 中未明确说明。

问题场景

用户通过 LiteLLM 代理，将带 response_format 的结构化输出请求转发给 zai provider 的 GLM 模型（如 glm-5-turbo、glm-4.7）。客户端例如 Graphiti MCP 服务，调用 client.responses.parse(text_format=<PydanticModel>) 发送严格的 json_schema。结果要么在 drop_params: true 下参数被静默丢弃，代理返回 200 但内容是自由文本；要么直接抛出 UnsupportedParamsError。若模型组配置了 fallback，该报错还会被吞掉，代理从备份模型返回 200。

报错原文

UnsupportedParamsError: zai does not support parameters: ['response_format'], for model=glm-5-turbo

1 validation error for ExtractedEntities
Invalid JSON: expected value at line 1 column 1

Completions.create() got an unexpected keyword argument 'json_mode'

原因分析

最可能的原因是 litellm/llms/zai/chat/transformation.py 中 ZAIChatConfig.get_supported_openai_params() 返回了硬编码的参数白名单，其中不包含 response_format：

base_params = ["max_tokens", "stream", "stream_options", "temperature",
               "top_p", "stop", "tools", "tool_choice"]

因此 response_format 无法进入 map_openai_params，在调用 provider 前就被丢弃或拒绝。Issue 还指出，上游 Z.AI API 本身对 response_format: json_schema 支持有限，但强制工具调用（forced tool call）可返回符合 schema 的参数，因此修复方向是复用 BaseConfig._add_response_format_to_tools() 做转换。Issue 正文还提到该路径存在 json_mode 未被 OpenAI SDK 处理器消费、以及结果位于 tool_calls 而非 message.content 的配套问题。

环境排查

确认 LiteLLM 版本：Issue 复现版本为 1.103.0，请确认是否已包含 PR #48335 的修复。
确认模型名是否为 zai/ 前缀的 GLM 模型，以及具体子型号（不同型号对 json_schema 的原生支持不一致）。
检查 LiteLLM 配置中是否设置了 drop_params: true，以及模型组是否配置了 fallback。
检查响应头 x-litellm-attempted-fallbacks 和返回体中的 model 字段，确认是否被路由到备份模型。
确认客户端实际发送的 response_format 类型是 json_schema 还是 json_object。

解决步骤

升级 LiteLLM 到包含 PR #48335 的版本，使 zai provider 接受 response_format。
若暂时无法升级，在 Issue 评论中提到可通过 allowed_openai_params: [response_format] 强制透传参数；但仅对 json_object 可行——需把 schema 写进提示词文本，并要求模型只输出一个符合该 schema 的 JSON 对象。对 json_schema 原样透传会返回散文，不可依赖。
对必须使用严格 schema 的场景，优先选用 Issue 验证可用的 glm-5.3、glm-5.3-flash、glm-5-turbo；Issue 指出 glm-4.7 无法完成强制工具调用。
关闭或谨慎使用 fallback 静默兜底，避免 UnsupportedParamsError 被备份模型的 200 响应掩盖，至少先做一次无 fallback 的验证请求。
若在上游直接调用 Z.AI 时 ReAct 失败，按评论做法将 json_object 与提示词内嵌 schema 组合使用；注意这不是严格校验。

验证方法

向 zai/glm-5.3 或 zai/glm-5.3-flash 发送一个带 response_format 的请求，确认不再出现 UnsupportedParamsError；检查响应体可以被目标 Pydantic 模型或 schema 解析器成功解析，而不是抛出 Invalid JSON: expected value at line 1 column 1。同时确认响应中的 model 是预期模型、x-litellm-attempted-fallbacks 未触发。若使用 Graphiti MCP，观察其摄入 episode 不再因 ExtractedEntities 校验失败而被丢弃。