现场是这样的。Ubuntu 22.04 上用 openai 1.55.3 调 deepseek-reasoner，为了做置信度过滤把 logprobs 设为 true 并加 top_logprobs=5，接口回 400，原文是 logprobs is not supported for this model，换 deepseek-chat 同样参数能通。
中间走过弯路，把「流式与非流式两条链路各写了一份参数」当成主因，改完现象没变。
这类报错背后常见的原因有几处，逐个排除就行。reasoner 系列不支持 logprobs 与 top_logprobs；配置文件里这两项是全局默认值 所有模型共用；SDK 把 logprobs 补进请求体 代码里看不到。
第一件事是用 curl 复现 只保留 model 与 messages
curl https://api.deepseek.com/chat/completions -H "Authorization: Bearer $DEEPSEEK_API_KEY" -H "Content-Type: application/json" -d '{"model":"deepseek-reasoner","messages":[{"role":"user","content":"你好"}],"logprobs":true}'然后按模型名做参数白名单 只给 chat 系列加 logprobs
python -c "m='deepseek-reasoner';kw={'logprobs':True} if m.endswith('chat') else {};print(kw)"随后把 top_logprobs 一起从请求构造里摘掉
python call_deepseek.py --model deepseek-reasoner --no-logprobs剩下的就是用同一批问题对比去掉前后的输出差异
python diff_out.py --a old.jsonl --b new.jsonl这类问题以前遇到过，但这次的触发条件和上次不一样。
怎么算真的好了，看的是同一批现象。返回 200，choices[0] 里有正常的 message.content，不再出现 400，chat 系列的置信度实验也不受影响。
提醒一点。reasoner 的输出里另有 reasoning_content，做置信度评估要换别的信号，光去掉 logprobs 补不回这部分信息。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。