Skip to content

fix(responses): MiMo 专项配置维护 — summaryMode none + streamIdleTimeout + singleSegmentReasoning false - #8263

Open
clearnature wants to merge 3 commits into
esengine:main-v2from
clearnature:mimo-vendor-config
Open

fix(responses): MiMo 专项配置维护 — summaryMode none + streamIdleTimeout + singleSegmentReasoning false#8263
clearnature wants to merge 3 commits into
esengine:main-v2from
clearnature:mimo-vendor-config

Conversation

@clearnature

@clearnature clearnature commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

摘要

MiMo(api.xiaomimimo.com)Responses provider 专项配置维护,对齐 MiMo-Code SDK 与官方文档,
修复长 reasoning 轮次的输出截断与 reasoning 摘要预算浪费。

本 PR 只含 MiMo 专项改动——纯局部配置,其他 vendor(deepseek/dashscope/未知)与全局设置
完全不受影响(详见下方"影响范围")。

改动(MiMo 专项)

参数 原值 新值 必要性
singleSegmentReasoning true false MiMo 支持多段推理(tool-loop 中可起新 reasoning 段)
summaryMode "none" 截断根因:MiMo 服务端把 reasoning.summary 折回上下文,thinking 逐轮翻倍直至截断
streamIdleTimeout 120s 8min MiMo cold-path TTFT ~5 分钟,默认看门狗会误杀
compactionOutputTokens 16K 4096 压缩摘要独立小预算
defaultMaxOutputTokens 32K 32K(保持) 见下方"输出预算声明"

配套:reasoning 对象在 effort 或 summaryMode 任一非空时发送(保证 MiMo 默认 effort "auto" 时
summaryMode="none" 不丢失);SSE idle 超时接入 vendor 能力表(零值回落默认)。

输出预算声明(重要)

默认 max_output_tokens(32K)同时覆盖 reasoning + 可见输出。长 reasoning 轮次会在可见正文前
耗尽预算,导致工具调用 JSON 截断。32K 默认不够长 reasoning 场景使用——用户需在面板/配置中
手动调整到 128000
(MiMo-Code 的 MIMO_OUTPUT_TOKEN_MAX,允许范围 [1, 131072])。
本 PR 保持上游 32K 默认,仅作文档声明,不覆盖默认值。

实测依据(128K vs 32K 隔离基准):成本 -40.9%、输入 token -67.6%、成功率 4/4 vs 3/4。

影响范围(纯 MiMo 局部)

  • vendorTable 按 vendor 隔离:summaryMode/streamIdleTimeout 仅 mimo 段设值,其余 vendor 零值 = 默认行为
  • streamIdleTimeout 零值回落 defaultStreamIdleTimeout(120s)——非 mimo vendor 行为不变
  • reasoning 发送:非 mimo vendor summaryMode 为空 → 退化为上游逻辑(仅 effort 非空才发)
  • warning 路径:显式 mimo 特判与上游经 singleSegmentReasoning 的判断结果等价
  • 全局设置零触碰:默认 32K 保持上游值,128K 仅作手动调整建议

验证

  • go test ./internal/provider/... 全 PASS(含 TestMiMoEmitsSummaryModeEvenWhenEffortEmpty)
  • MiMo API 实测:reasoning.summary="none" 被接受(HTTP 200)
  • MiMo effort 值仅接受 none/low/medium/high(HTTP 400 拒绝 auto/disabled/off/HIGH)

Cache-impact: low - vendor capability table and reasoning request format only; no system-prompt or tool-registry changes.
Cache-guard: go test ./internal/provider/responses/ -count=1

Documentation-impact: none - code-only PR, no docs changes; maintenance baseline doc lives on the local mimo-baseline branch

System-prompt-review: none - changes are in responses provider wire format only, no system-prompt or boot surface changes.

Yan Li added 2 commits August 11, 2026 07:14
Pure MiMo-local vendor config; other vendors and global settings are
completely unaffected (zero-value fallbacks keep deepseek/dashscope/
unknown behavior byte-identical to upstream):

- singleSegmentReasoning: true -> false (MiMo supports multi-segment)
- summaryMode: "none" — truncation root cause fix (MiMo folds
  reasoning.summary back into context, doubling thinking each turn);
  reasoning object now sent when effort OR summaryMode is set
- streamIdleTimeout: 8min (cold-path TTFT ~5min; zero-value falls back
  to defaultStreamIdleTimeout)
- defaultMaxOutputTokens: kept at upstream 32K — documented that users
  must raise it manually to 128000 for long-reasoning workloads
- compactionOutputTokens: 4096 (dedicated summary budget)
- WarnOnMissingToolCallReasoning: explicit mimo check (behavior-equivalent)

Docs: docs/mimo-maintenance.md — baseline, parameter rationale, and
scope proof (why other vendors / global settings are unaffected).
@github-actions github-actions Bot added provider Model providers & selection (internal/provider) v2 Go rewrite (1.x) — main-v2 branch, active development labels Aug 10, 2026
@clearnature

Copy link
Copy Markdown
Contributor Author

@SivanCola 这个是mimo 的专项参数维护,本地发现mimo 使用默认的32k 参数会工具占领很多。一大堆的技能。这个只是专项局部,不会影响其他模型。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

provider Model providers & selection (internal/provider) v2 Go rewrite (1.x) — main-v2 branch, active development

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant