把线上代码切到 Ollama 做本地回归，请求里带了 logprobs=True 与 top_logprobs=5，返回 400，原文 unsupported parameter: logprobs，服务端是 Ollama 0.5.7。
一开始怀疑是「参数写在嵌套的 extra_body 里，位置不对同样被拒」，查了一圈，方向不对。
排查方向其实有限，先把可能性排一排。兼容层只实现了一部分 OpenAI 参数，未实现的直接拒绝。也可能是不同模型对 logprobs 支持不一致，换模型才报错。
不容易想到的是，SDK 会自动带上默认参数，版本越新带得越多。
第一件事是用最小请求确认兼容层可用
curl -sS http://localhost:11434/v1/chat/completions -H 'content-type: application/json' -d '{"model":"qwen2.5:7b","messages":[{"role":"user","content":"hi"}]}'接着逐个剥离可疑参数定位是哪一个
python probe_params.py --base http://localhost:11434/v1 --drop logprobs,top_logprobs需要概率时改走原生接口拿 token 概率
curl -sS http://localhost:11434/api/generate -d '{"model":"qwen2.5:7b","prompt":"hi","stream":false,"options":{"num_predict":16}}'中间停过一次，把已经改的东西回滚干净，再重新来一遍。
别只看报错消失，验证要多做一步。去掉不支持的参数后返回 200，chat/completions 正常给出 choices，探测脚本里被拒参数清单清空。
这里还有个坑。兼容层只能当灰度通道，参数支持面永远落后于官方，上线前把用到的参数逐个探一遍比看文档快。报错文案容易误导，真正的原因往往在相邻那一层的日志里。