iomgaa/PolyGateway
1
0
Fork 0
Code Issues 3 Pull Requests Actions Packages Projects Releases 9 Wiki Activity

MiniMax-M3 的 enable_thinking 在真实网关上不再产出推理,4 条 e2e 全红(main 既有) #17

New Issue
Closed
opened 2026-08-25 01:22:32 +08:00 by iomgaa · 1 comment
iomgaa commented 2026-08-25 01:22:32 +08:00
Owner
Copy Link
Copy Source

现象

tests/e2e/test_thinking_live.py::TestMiniMaxM3 的 4 条在真实网关上全红,且与任何近期改动无关——在 issue #15 的分支与 main 上各跑一次,失败的是同样 4 条:

用例 分支 main
test_l2_enable_actually_enables FAILED FAILED
test_l3b_none_is_recognised_not_silently_dropped FAILED FAILED
test_l4_extra_body_overrides_the_profile FAILED FAILED
test_l5_non_stream_path_matches_stream FAILED FAILED

main 上单跑该类: 4 failed, 3 passed in 174.18s。同批 slow 的其余部分正常(全档 39 passed / 4 failed / 2 skipped)。

病灶

enable_thinking=True 时 10 轮全部没有推理产出,reasoning_tokens 恒为 None,content 直接就是答案:

assert (0 * 2) > 10
[{'round': 1, 'prompt_tokens': 216, 'completion_tokens': 58, 'reasoning_tokens': None, 'content': '23 12'},
 ... 10 轮全部 reasoning_tokens=None ...]

prompt_tokens 恒为 216、completion_tokens 在 45-58 之间波动,说明请求确实发出去了、模型也确实在答题,只是没有推理段。四条用例的共同前提都是"MiniMax-M3 在开启档下会产出推理",这个前提当前不成立,所以 L2/L3b/L4/L5 一起倒。

两种可能,尚未区分

  1. 网关侧模型行为变了 —— MiniMax-M3 不再返回推理内容,或改了返回字段/格式(那样 _reasoning_on 的识别口径要跟着改)。
  2. 库的 thinking 注入对该模型失效了 —— resolve_thinking 产出的请求体不再被该模型接受(静默忽略而非报错)。

区分方法: 抓一次真实请求体与原始响应,看 thinking/reasoning_content 相关字段到底发出去没有、回来没有。若请求体正确而响应无推理段,是 (1);若请求体里根本没带上开关,是 (2)。

影响

  • 挡住发布清单第 4 步(合并 main 后须跑 pytest -m slow)。1.3.0 是在确认这 4 条为既有问题、与该版本无关之后发的。
  • 若是 (2),则 enable_thinking 对该模型是静默失效——配置写了、库不报错、实际没生效,属 P5(严禁默认值/静默掩盖错误)要消灭的形态。

环境

  • 发现于 2026-08-24,库 1.3.0 与其前身 main(1.2.4)。
  • 网关 newapi.iomgaa.online,模型 MiniMax-M3。
  • 该文件默认不进提交门(标 slow),故日常开发不会暴露它。
## 现象 `tests/e2e/test_thinking_live.py::TestMiniMaxM3` 的 4 条在真实网关上全红,且**与任何近期改动无关**——在 issue #15 的分支与 `main` 上各跑一次,失败的是同样 4 条: | 用例 | 分支 | main | |---|---|---| | `test_l2_enable_actually_enables` | FAILED | FAILED | | `test_l3b_none_is_recognised_not_silently_dropped` | FAILED | FAILED | | `test_l4_extra_body_overrides_the_profile` | FAILED | FAILED | | `test_l5_non_stream_path_matches_stream` | FAILED | FAILED | main 上单跑该类: `4 failed, 3 passed in 174.18s`。同批 slow 的其余部分正常(全档 `39 passed / 4 failed / 2 skipped`)。 ## 病灶 `enable_thinking=True` 时 **10 轮全部没有推理产出**,`reasoning_tokens` 恒为 `None`,`content` 直接就是答案: ``` assert (0 * 2) > 10 [{'round': 1, 'prompt_tokens': 216, 'completion_tokens': 58, 'reasoning_tokens': None, 'content': '23 12'}, ... 10 轮全部 reasoning_tokens=None ...] ``` `prompt_tokens` 恒为 216、`completion_tokens` 在 45-58 之间波动,说明请求确实发出去了、模型也确实在答题,**只是没有推理段**。四条用例的共同前提都是"MiniMax-M3 在开启档下会产出推理",这个前提当前不成立,所以 L2/L3b/L4/L5 一起倒。 ## 两种可能,尚未区分 1. **网关侧模型行为变了** —— MiniMax-M3 不再返回推理内容,或改了返回字段/格式(那样 `_reasoning_on` 的识别口径要跟着改)。 2. **库的 thinking 注入对该模型失效了** —— `resolve_thinking` 产出的请求体不再被该模型接受(静默忽略而非报错)。 区分方法: 抓一次真实请求体与原始响应,看 `thinking`/`reasoning_content` 相关字段到底发出去没有、回来没有。若请求体正确而响应无推理段,是 (1);若请求体里根本没带上开关,是 (2)。 ## 影响 - **挡住发布清单第 4 步**(合并 main 后须跑 `pytest -m slow`)。1.3.0 是在确认这 4 条为既有问题、与该版本无关之后发的。 - 若是 (2),则 `enable_thinking` 对该模型是**静默失效**——配置写了、库不报错、实际没生效,属 P5(严禁默认值/静默掩盖错误)要消灭的形态。 ## 环境 - 发现于 2026-08-24,库 1.3.0 与其前身 `main`(1.2.4)。 - 网关 `newapi.iomgaa.online`,模型 `MiniMax-M3`。 - 该文件默认不进提交门(标 `slow`),故日常开发不会暴露它。
iomgaa commented 2026-08-26 16:42:27 +08:00
Author
Owner
Copy Link
Copy Source

已随 1.3.1 修复并发布,与 issue #16 是同一件事(处置详见 #16 的说明)。

本 issue 提出的两种可能,实测给出了第三种答案:

  1. 网关侧模型行为变了 —— MiniMax-M3 不再返回推理内容
  2. 库的 thinking 注入对该模型失效了

都不是。注入生效、模型也确实在推理(prompt_tokens 194→216,completion_tokens 3→60),变的是 MiniMax 这一路不再上报 usage.completion_tokens_details。本 issue 里那句「prompt_tokens 恒为 216、completion_tokens 在 45-58 之间波动,说明请求确实发出去了、模型也确实在答题,只是没有推理段」——前半句对,后半句错:那多出来的 40 多个 token 就是推理段,它被计费了,只是没通过 reasoning_content 回传(非流式)或没被判据看见(流式)。

本 issue 专门点出的那条,是这一版最该修的东西

若是 (2),则 enable_thinking 对该模型是静默失效——配置写了、库不报错、实际没生效,属 P5(严禁默认值/静默掩盖错误)要消灭的形态。

实际形态比 (2) 更微妙:配置生效了、模型也照做了,静默的是库对结果的判断。但落点相同——本版起 LLMResponse.thinking_observation 如实作答,判不出来时是 unknown 而非伪装成「没推理」。

非流式那一档:钱花了,东西拿不到

实测 M3 非流式开启推理时 completion_tokens 从 3 涨到 53,而响应里既无 reasoning_content 也无 usage 明细——推理已计费却一个字都不回传。这是上游行为,库修不了,但从本版起不再默不作声:该档判为 unknown 并告警一次,说明「已注入开启参数,但本路径观测不到,推理内容可能已计费却不回传」。要拿正文,该模型请走流式。

挡住发布清单第 4 步这一条已解除

tests/e2e/test_thinking_live.py 的 L1–L9 现已全 PASS(判据换成三态裁定,并删掉了那个从一开始就不成立的 _ON_MIN_COMPLETION 魔数退路——两档的 completion 分布本就重叠)。L5 也重新定义了:它原本断言「非流式开启档应观测到推理」,而那件事在 M3 上永远不会发生,现在改为断言「参数确实到达」加「库如实标记观测不到,而非伪装成没推理」。

已随 **1.3.1** 修复并发布,与 issue #16 是同一件事(处置详见 #16 的说明)。 本 issue 提出的两种可能,实测给出了**第三种**答案: > 1. 网关侧模型行为变了 —— MiniMax-M3 不再返回推理内容 > 2. 库的 thinking 注入对该模型失效了 都不是。**注入生效、模型也确实在推理**(`prompt_tokens` 194→216,`completion_tokens` 3→60),变的是 MiniMax 这一路不再上报 `usage.completion_tokens_details`。本 issue 里那句「prompt_tokens 恒为 216、completion_tokens 在 45-58 之间波动,说明请求确实发出去了、模型也确实在答题,**只是没有推理段**」——前半句对,后半句错:那多出来的 40 多个 token 就是推理段,它被计费了,只是没通过 `reasoning_content` 回传(非流式)或没被判据看见(流式)。 ## 本 issue 专门点出的那条,是这一版最该修的东西 > 若是 (2),则 enable_thinking 对该模型是**静默失效**——配置写了、库不报错、实际没生效,属 P5(严禁默认值/静默掩盖错误)要消灭的形态。 实际形态比 (2) 更微妙:配置生效了、模型也照做了,**静默的是库对结果的判断**。但落点相同——本版起 `LLMResponse.thinking_observation` 如实作答,判不出来时是 `unknown` 而非伪装成「没推理」。 ## 非流式那一档:钱花了,东西拿不到 实测 M3 非流式开启推理时 `completion_tokens` 从 3 涨到 53,而响应里既无 `reasoning_content` 也无 usage 明细——**推理已计费却一个字都不回传**。这是上游行为,库修不了,但从本版起不再默不作声:该档判为 `unknown` 并告警一次,说明「已注入开启参数,但本路径观测不到,推理内容可能已计费却不回传」。要拿正文,该模型请走**流式**。 ## 挡住发布清单第 4 步这一条已解除 `tests/e2e/test_thinking_live.py` 的 L1–L9 现已全 PASS(判据换成三态裁定,并删掉了那个从一开始就不成立的 `_ON_MIN_COMPLETION` 魔数退路——两档的 completion 分布本就重叠)。L5 也重新定义了:它原本断言「非流式开启档应观测到推理」,而那件事在 M3 上永远不会发生,现在改为断言「参数确实到达」加「库如实标记观测不到,而非伪装成没推理」。
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
iomgaa
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: iomgaa/PolyGateway#17
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?