快速结论:当你用 OpenAI 兼容提供商(如 Venice AI)发请求,对方返回 HTTP 400,但 Open WebUI 只显示通用的 Invalid request parameters,真正的字段级报错(如 Unrecognized key(s) in object: 'chat_template_kwargs')被丢弃。优先检查当前请求里是否带了该提供商不支持的额外参数。
适用环境:Open WebUI 0.0.20(0.0.20);macOS Tahoe 26.7;使用 OpenAI 兼容提供商(Venice AI,https://api.venice.ai/api/v1,模型 qwen-3-6-plus)。Issue 未提供 Python、CUDA、显卡、PyTorch、Ollama 版本信息。
最快修复方案:从 General Parameters 中移除 chat_template_kwargs,或把它只设置在支持该参数的模型上,然后重试请求。这是 Issue 评论中确认的当日修复方式。
注意事项:该做法只规避了提供商不接受的参数,并非让 Open WebUI 展示结构化 validation details 的通用修复。若其他 OpenAI 兼容提供商也出现同类通用错误,仍需按下方方法抓取原始响应才能定位真正原因。
问题场景
在 Open WebUI 中配置 OpenAI 兼容提供商(本例为 Venice AI),并通过 General Parameters 注入了一个上游不接受的参数 chat_template_kwargs。发送任意聊天消息时,上游返回 HTTP 400,Open WebUI 前端与后端日志都只保留通用的 Invalid request parameters,无法看到具体是哪个字段不合规,导致配置问题难以诊断。
报错原文
Upstream openai-compatible request failed: HTTP 400 (upstream_error)
url=https://api.venice.ai/api/v1
model=qwen-3-6-plus
code=-
message=Invalid request parameters
上游实际返回的结构化响应中包含:
{
"details": {
"_errors": [
"Unrecognized key(s) in object: 'chat_template_kwargs'"
]
},
"error": "Invalid request parameters",
"issues": [
{
"code": "unrecognized_keys",
"keys": ["chat_template_kwargs"],
"path": [],
"message": "Unrecognized key(s) in object: 'chat_template_kwargs'"
}
]
}
原因分析
Open WebUI 按 OpenAI 的错误格式来解析和展示上游错误,也就是读取顶层的 error 字段。Venice 在这个字段里放的是通用文案 Invalid request parameters,而把真正的原因放在它自己额外的 details / issues 字段中。
由于 Open WebUI 只取顶层通用错误,details 和 issues 里的字段级校验信息没有被保留或展示,所以用户只能看到笼统的 Invalid request parameters。可能原因还包括:不同 OpenAI 兼容提供商在错误体结构上并不完全统一,结构化校验细节的字段命名和嵌套位置各异,现有解析逻辑没有覆盖这些扩展字段。
Issue 提到这与 #27237 相关,但区别在于此处上游错误体已经被收到并部分解析,只是具体校验消息被丢弃。
环境排查
- 确认 Open WebUI 版本,本例为 0.0.20(0.0.20)。
- 确认操作系统,本例为 macOS Tahoe 26.7。
- 确认正在使用的 OpenAI 兼容提供商 base URL 与模型,本例为
https://api.venice.ai/api/v1和qwen-3-6-plus。 - 检查 General Parameters 或模型级参数中是否包含
chat_template_kwargs,尤其是{"chat_template_kwargs": {"reasoning_effort": "low"}}这类结构。 - 如条件允许,准备一个可拦截流量的代理,用于查看上游原始响应体。
解决步骤
- 进入 Open WebUI 的 General Parameters 配置,定位注入
chat_template_kwargs的参数项。 - 从 General Parameters 中移除
chat_template_kwargs;如果确实需要该参数,改为只设置在支持它的模型或提供商上,不要全局下发。 - 发送任意聊天消息重试,确认请求不再被上游以 400 拒绝。
- 若之后再次遇到语义不清的
Invalid request parameters,用拦截代理抓取上游原始响应,或查看提供商自身的请求日志,读取details/issues中的完整校验细节。 - 把抓到的具体字段名(如
chat_template_kwargs)与当前 Open WebUI 下发的参数逐项比对,移除不被提供商接受的那一项。
验证方法
移除 chat_template_kwargs 后重新发送同样的聊天请求,若不再出现 HTTP 400,且模型正常返回内容,说明问题已解决。按 Issue 复现步骤第 7 条,删除该参数后请求即成功,可作为验证依据。
参考来源
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。
![[Bug]: Rust frontend chat-template rendering fails with 500 "unknown function: raise_exception" for templates that legally use it (e.g. Qwen](https://www.chat-gpts.plus/wp-content/uploads/2026/09/59009-5c4e83a4-768x403.jpg)
![[Bug]: Host memory is not reducing after the model is loaded into Intel XPU](https://www.chat-gpts.plus/wp-content/uploads/2026/09/50269-2f2deaf5-768x403.jpg)
![[Bug]: GLM-5.3 reasoning leaks into content when clients pass enable_thinking/thinking=false — parser gates on kwargs the GLM-5.3 template n](https://www.chat-gpts.plus/wp-content/uploads/2026/09/54744-b3553957-768x403.jpg)