fcitx5-voice-input

Appearance

调研：小米 MiMo ASR 模型与接入评估 ​

面向 fcitx5-voice-input（C++ Fcitx5 语音输入插件，采集 16kHz mono int16，VAD 分段后提交 ASR）。 调研日期：2026-09-25。调研 agent：@researcher。 本文件仅含事实与来源标注，方案为决策参考；事实与推断严格区分，推断处标注「推断」。 所有 URL 均来自本次 web 搜索/抓取的原文，未凭记忆编造。

0. 调研结论摘要（带置信度标注） ​

#结论置信度依据
C1确有其专门的 ASR 模型：官方名为 MiMo-V2.5-ASR（XiaomiMiMo/MiMo-V2.5-ASR），由小米 MiMo 团队端到端训练。不存在 MiMo-ASR-1.0 之类的命名高官方博客、GitHub、HF
C2MiMo-Audio 与 MiMo-V2.5-ASR 是两条不同产品线：MiMo-Audio-Tokenizer（1.2B, 25Hz RVQ）与 MiMo-Audio-7B-Base/Instruct 是「音频理解 LLM（few-shot）」，被 MiMo-V2.5-ASR 复用作 tokenizer；三者名字都真实存在高MiMo-Audio GitHub、arXiv 2512.23808、Tokenizer HF
C3开源权重可用：HF + ModelScope，8B decoder + 1.2B tokenizer，safetensors/bfloat16；HF 模型卡标 MIT，GitHub 仓库页标 Apache-2.0（两者均宽松、均允许商用，但标注不一致）高（存在）/ 中（license 一致性）HF 文件树、HF model card、config.json、GitHub
C4官方云 API 存在且 OpenAI 兼容：POST https://api.xiaomimimo.com/v1/chat/completions，model=mimo-v2.5-asr，音频走 messages[].content[].input_audio 的 base64 Data URL；认证头两种任选：api-key 或 Authorization: Bearer；无独立 /v1/audio/transcriptions高API 文档（中文）、API 文档（英文）、官方 FAQ
C5是「整段音频上传 + SSE 输出流」而非实时音频流：不支持 WebSocket/realtime 音频推流；stream=true 只对输出 token 做 SSE，音频必须先完整 base64 提交高（无 WS 端点）/ 中（增量粒度未实测）使用指南、API 文档、第三方 issue 佐证
C6音频格式硬约束：仅支持 wav/mp3，base64 编码后 ≤ 10 MB；不接受原始 PCM（需自行封装 WAV）。派生上限：16kHz mono wav 约 ≤ 3.9 分钟高（限制原文）/ 中（时长换算为推断）使用指南
C7计费按音频时长：¥0.5/小时、$0.074/小时；模型规格 8K 上下文 / 2K 最大输出 / 100 RPM / 10K TPM高官方定价页、模型页
C8本地推理栈：需 Python 3.12 + CUDA ≥12 + flash-attn==2.7.4.post1 + PyTorch（transformers，model_type: qwen2）。无官方 ONNX / llama.cpp / GGUF 路径；社区有 Apple MLX 4-bit 移植与第三方 OpenASR q4_k .oasr 包（峰值内存 7.6 GB、约 0.5× 实时）中GitHub Getting Started、config.json、MLX、OpenASR
C9接入本项目成本很低：现有 OpenAI chat 模式已经构造 data:audio/wav;base64,... 且解析 choices[0].message.content，与 MiMo 云 API 请求/响应高度一致；理论上改 BaseUrl/Model 即可接通。存在 2 个细节风险：asr_options.enable_itn 额外字段（按官方文档处置：MiMo 不发送，见 §9）、language 因现有代码覆盖 bug 实际未发送（已修复）；鉴权已实测 Bearer 可用（402 而非 401）高本地源码 src/addon/asr/openai_asr.cpp、API 文档、官方 FAQ、响应 API 兼容页
C10不具备「边说边出」能力：云 API 为一次性分段提交，无实时增量音频流；对语音输入法场景，延迟/交互不如现有 OpenAI Realtime、火山、Mistral 三个 WS 流式后端，但中文/方言准确率与成本有优势高C5、C7、官方博客
C11截至 2026-09-25，ASR 仍是 mimo-v2.5-asr：2026-09-22 发布的 MiMo-V2.6 系列为语言模型（Pro/Flash/UltraSpeed），不含新 ASR；ASR 定价页仍只有 v2.5-asr中-高官方定价页（更新 2026-09-21）、模型发布日志、V2.6 发布
C12官方中文基准领先：AiShell-2 2.52% CER、Fleurs-Zh 2.41%、Wenet Meeting 5.92%、Wenet Net 5.26%；英文 Open ASR 平均 5.73% WER（LibriSpeech-clean 1.45%）；粤语 WeNet-Yue 7.21%、Fleurs-Yue 3.28%；均为小米自评，缺独立复现高（官方数字）/ 中（可信度）官方博客评测表
C13无实时因子官方数据；第三方 OpenASR 包标 0.5× 实时（即 RTF≈2，比实时慢一倍），YouTube 实测约 18 GB 显存（bf16）。本地实时输入不现实中-低OpenASR、YouTube 实测
C14隐私：云 API 会把整段语音上传至小米服务器；想要离线需本地跑 8B+1.2B 模型（≥16 GB 显存）或第三方量化运行时高API 文档、HF 文件树

一句话结论：MiMo-V2.5-ASR 是真实、已开源、且官方云 API 已开放的中文/方言强项 ASR 模型；对本项目而言，接云 API 的工程量极小（现有 chat 模式几乎可直接复用），但它是一次性上传的分段转录，不具备实时 WS 流式音频输入，因此定位应类似现有 whisper-1 HTTP 后端，而非 Realtime/火山/Mistral 三个流式后端。

1. 模型本体：MiMo 系列里到底哪个是 ASR ​

1.1 产品线澄清（对应问题 1） ​

MiMo 家族中与「语音」相关的有三个不同层次，必须区分：

名称性质规格与 ASR 的关系来源
MiMo-V2.5-ASR专用端到端 ASR 模型（本次调研主角）8B decoder + 1.2B audio tokenizer直接语音转文字GitHub、HF
MiMo-Audio-7B-Base / Instruct音频理解 LLM（few-shot，多任务）7B LLM，基于 MiMo-7B能做 ASR，但定位是通用音频理解，非专用识别MiMo-Audio GitHub、arXiv
MiMo-Audio-Tokenizer音频离散 tokenizer1.2B，25 Hz，8 层 RVQ，200 token/s被 MiMo-V2.5-ASR 复用为前端Tokenizer HF、arXiv
MiMo-V2.5 / V2.6（Omni）原生全模态语言大模型，可「听懂」音频310B/1T MoE不是专用 ASR，输出推理/对话MiMo-V2.5 页、V2.6
  • 没有 MiMo-ASR-1.0、MiMo-ASR-V2 之类命名；专用 ASR 的唯一官方名是 mimo-v2.5-asr（模型 ID）/ MiMo-V2.5-ASR（展示名）。置信度：高（官方 API 文档 model 字段仅列 mimo-v2.5-asr）。
  • MiMo-Audio-7B-Instruct 确实是真实名字，属于 2025 年 9 月发布的 MiMo-Audio（arXiv 2512.23808）系列；MiMo-Audio-Tokenizer 也是真实名字。它们不是 MiMo-V2.5-ASR 的别名，而是其架构前端来源。置信度：高。

1.2 架构与规格（一手） ​

来自 config.json（HF 官方权重）：

  • architectures: ["MiMoV2ASRForCausalLM"]，model_type: "qwen2"，transformers_version: 4.57.1，dtype: bfloat16。
  • Decoder：num_hidden_layers: 36、hidden_size: 4096、num_attention_heads: 32、num_key_value_heads: 8、max_position_embeddings: 8192。
  • 音频前端：audio_config（8 通道 RVQ、group_size: 4 patch、speech_vocab_size 为 8 层码本、audio_segment_size: 6000）。
  • 权重：7 个 model-0000x-of-00007.safetensors，HF 显示总大小约 32 GB（F32 标注，config 为 bfloat16）；model size 8B params。实测 bf16 加载约 18 GB 显存（第三方）。HF 文件树、YouTube

推理入口为 Python MimoAudio.asr_sft(path, audio_tag="<chinese>|<english>|Auto")，文件级、离线；官方 demo 仅提供 Gradio 上传/录音，未见 chunk 流式接口。GitHub

1.3 语言与场景 ​

官方宣称：中英双语 + 吴语/粤语/闽南语/四川话/河南/东北/陕西等方言、code-switch、歌词、强噪声、远场、多说话人、知识密集内容、原生标点、无需语言标签。GitHub、官方博客

2. 访问方式 ​

2.1 开源权重（自托管） ​

项值来源
GitHubgithub.com/XiaomiMiMo/MiMo-V2.5-ASR（Python，2026-04-23 创建，约 331 stars / 34 forks，10 open issues）GitHub
HuggingFaceXiaomiMiMo/MiMo-V2.5-ASR（~106 likes，月下载约 3,244）HF
ModelScopeXiaomiMiMo/MiMo-V2.5-ASR（HF README 提供）HF
TokenizerXiaomiMiMo/MiMo-Audio-Tokenizer（必须一起下载）Tokenizer HF
框架依赖transformers（qwen2 架构，trust_remote_code）+ flash-attn==2.7.4.post1GitHub、config.json
硬件前提Linux、Python 3.12、CUDA ≥12.0GitHub

License 存在标注不一致（重要，但两者都宽松）：

  • HF 模型卡元数据：License: mit。HF
  • GitHub 仓库页：Apache-2.0 license。GitHub
  • 小米对 MiMo-V2.5 系列开源公告统一表述为 MIT，允许商用推理与二次训练、无需额外授权。V2.5 开源公告

→ 结论：可用于商用/再分发的置信度 高；具体适用哪份 license 文本建议以权重仓库实际 LICENSE 文件为准（本次未抓取到该文件，标「未证实」）。

2.2 官方云 API（OpenAI 兼容 Chat Completions） ​

  • 端点：POST https://api.xiaomimimo.com/v1/chat/completions（中文文档与英文文档一致）。API 文档、API 文档
  • 认证：支持两种，任选其一：api-key: $MIMO_API_KEY 或 Authorization: Bearer $MIMO_API_KEY（官方 FAQ 明确列出）。官方 Python 示例用 OpenAI(base_url=..., api_key=...)（SDK 默认发 Authorization: Bearer），第三方集成 issue 亦记 Authorization: Bearer。官方 FAQ、API 文档、hermes issue → 对本项目含义：现有 Authorization: Bearer 发送方式可直接使用，无需新增鉴权头配置。
  • 请求体：model=mimo-v2.5-asr；messages[0].content[0].type="input_audio"、input_audio.data="data:{MIME};base64,..."；asr_options.language ∈ {auto,zh,en}；stream bool。
  • 响应：choices[0].message.content 为文本；usage.seconds（音频时长）、usage.prompt_tokens_details.audio_tokens（音频 token 数，示例 4 秒=25 token，即 6.25 token/s，与 patch 率一致）。
  • 计费/限额：¥0.5/小时、$0.074/小时；RPM 100、TPM 10K；8K 上下文、2K 最大输出。定价页、模型页
  • 平台定位：小米 MiMo 开放平台同时提供 OpenAI 兼容与 Anthropic 兼容 API；2026-06-23 起支持 OpenAI Responses API。API 平台更新日志

2.3 端侧 / 小米设备 ​

  • 官方渠道为「云 API + 开源权重」两条路；未发现面向第三方 App 的端侧 SDK，也未发现「仅限小米设备」的公开 ASR 接口。澎湃 OS 内置能力未在公开文档中说明（标「未证实」）。
  • 另有第三方「OpenASR」提供 .oasr 纯本地运行时（见 §4.3），非小米官方。

3. 协议与流式语义（对应问题 3） ​

3.1 云 API 的真实流式程度（关键） ​

  • 没有 WebSocket / Realtime 音频端点。平台文档仅有 Chat Completions；第三方集成 issue 明确指出 ASR 走 /v1/chat/completions 而不是 /v1/audio/transcriptions。API 文档、hermes issue
  • stream=true 使用 SSE（server-sent events），但输入音频必须一次性完整提交（base64 Data URL），因此它是「输出 token 流」，不是「边说边发音频流」。置信度：高（输入侧）；输出是否逐 token 到达：中（未实测）。
  • 旁证：同平台 TTS 文档明确写「流式调用当前降级为兼容模式，仅在全部推理完成后以流式形式返回一次结果」——说明该平台的「stream」并不保证真增量。TTS 文档摘录
  • 对本项目含义：无法映射到 realtime 后端的增量语义；最接近的现有实现是 whisper-1 HTTP 一次性转录（AsrSession::End() 时整段提交、返回终稿）。

3.2 音频格式与限制 ​

项约束来源
容器仅 wav、mp3（不支持裸 PCM）使用指南
MIMEwav→audio/wav；mp3→audio/mpeg/audio/mp3使用指南
编码后大小base64 字符串 ≤ 10 MB使用指南
采样率/声道文档未规定（推断：随容器自适应，模型前端做重采样）—（未证实）
时长上限文档未给秒数；由 10MB 反推 wav@16k mono ≈ 3.9 分钟；由 8K 上下文与 6.25 token/s 反推 ≈ 21 分钟，故 10MB 是实际瓶颈推断（基于 使用指南、API 文档）
超时行为文档未说明；官方客户端未见显式超时字段未证实
语言asr_options.language 仅支持单语种 auto/zh/en；方言/code-switch 靠 auto 自动处理API 文档、模型页

对本项目：默认 maxSpeechMs=30000（30 秒）对应 wav 约 960 KB、base64 约 1.28 MB，远低于 10 MB 限制；即使把上限调到 60 秒（约 2.56 MB）也安全。

3.3 端侧运行不是流式 ​

开源仓库的 asr_sft() 为文件级调用；官方 issue 中有人询问时间戳输出，仍处 open 状态，说明功能面较基础。GitHub Issues

4. 本地推理栈（对应问题 4） ​

4.1 官方路径 ​

  • PyTorch + transformers（qwen2 架构，需 trust_remote_code）；CUDA ≥12，Python 3.12，flash-attn==2.7.4.post1（官方给出预编译 wheel 兜底）。GitHub
  • 需同时加载 MiMo-Audio-Tokenizer（1.2B）与 MiMo-V2.5-ASR（8B）两个权重。HF
  • 无官方 ONNX 导出、无官方 llama.cpp/GGUF、无 vLLM 接入文档（vLLM/vLLM-Omni 的 MiMo 案例针对的是 MiMo-Audio-7B 与 MiMo-V2.5 语言模型，不是本 ASR）。vLLM-Omni MiMo-Audio、llama.cpp issue

4.2 重采样 ​

  • 模型侧未要求 24kHz（与 OpenAI Realtime/whisper-1 场景不同）；但云 API 只收 wav/mp3，原始 16kHz PCM 需包一层 WAV 头（本项目 openai_asr.cpp 已有 FloatPcmToWav）。是否内部重采样到固定率：文档未说明，未证实。
  • 本地推理对 16kHz 输入的处理需看 asr_sft 实现（本次未抓到 src/mimo_audio 源码，标「未证实」）。

4.3 社区/第三方路径 ​

方案描述数据置信度
Apple MLX 4-bitmlx-community/MiMo-V2.5-ASR-MLX，Apple Silicon未给体积/速度中（有 HF 页，仅 macOS）
OpenASR .oasr第三方 q4_k 量化，纯本地、无 Python 推理；提供 openasr serve（OpenAI 兼容 audio.transcriptions）5.4 GB、峰值内存 7.6 GB、0.5× 实时（RTF≈2）、仅英/粤/普中-低（单一第三方站，未独立验证）
GGUF仅 MiMo-V2.5 文本 LLM 的 GGUF，明确「不含音频输入，需上游 llama.cpp 支持」；不适用于 ASR—高（明确说明）

结论：目前没有可被 C++ 直接 dlopen 的官方推理库；C++ 接入现实路径只有「调云 API」或「本地跑一个 OpenAI 兼容 sidecar 服务（如 OpenASR）再复用现有 HTTP 后端」。后者性能（RTF≈2）与可信度都不足，暂不建议作为默认。

5. 接入 fcitx5-voice-input 的具体路径（对应问题 5） ​

5.1 最接近的现有后端：OpenAI chat 模式（不是 realtime/volcengine） ​

本地源码 src/addon/asr/openai_asr.cpp 的 chat 分支与 MiMo 云 API 对照：

环节现有 chat 模式MiMo 云 API 要求匹配
端点{baseUrl}/chat/completions/v1/chat/completions✅
音频data:audio/wav;base64,<b64>同✅
消息type=input_audio + input_audio.data同✅
语言设 asr_options.language（但见 5.2 bug）asr_options.language⚠️
响应解析choices[0].message.content同✅
鉴权Authorization: Bearer文档 api-key（Bearer 待证实）⚠️
其它字段额外发 asr_options.enable_itn=true文档未列 enable_itn⚠️

因此，零/低代码接入的可行性很高：给用户一个「MiMo」后端（或直接指引在现有 OpenAI 子配置里设 BaseUrl=https://api.xiaomimimo.com/v1、Model=mimo-v2.5-asr、ApiMode=chat）即可发起转录。

5.2 需要修复/注意的细节与工作量 ​

  1. language 覆盖 bug（必看，已修复）：openai_asr.cpp 中先 body["asr_options"]["language"]=...，随后 body["asr_options"] = asrOpts;（仅含 enable_itn）整体覆盖，导致 language 从未真正发送。本实现已统一构造，language 与 enable_itn 均按配置正确发送（见 §9）。
  2. enable_itn 额外字段：MiMo 文档的 asr_options 只定义 language；MiMo 平台在响应 API 兼容页声明「未定义参数会被过滤并可能返回请求异常」mimo-responses。因此接入 MiMo 时不应发送该字段——本实现新增 EnableItn 开关（默认 true 保持 DashScope 行为，MiMo 配 false），无需实网验证容忍度。
  3. 鉴权头（已解决）：官方 FAQ 明确 api-key 与 Authorization: Bearer 两种均可，现有实现的 Bearer 头发送方式无需改动。官方 FAQ
  4. 超时：现有 CURLOPT_TIMEOUT=30L。30 秒语音在云上转录通常够用，但长段 + 排队可能超时，建议 MiMo 后端放宽（如 60–120s），并保留取消回调。
  5. 无需新增依赖、无需重采样：WAV 封装与 base64、libcurl HTTP 均已具备。这是相比 realtime 后端的一大优势。
  6. 架构落点：新增 AsrEngine/AsrSession 实现（可高度复用 OpenaiAsrSession 的一次性提交模型）+ voiceinput-config.h 新增 MimoAsrConfig 子块 + AsrBackendAnnotation 增 mimo 枚举项。工作量：小（1 个 .cpp/.h + 配置 + CMake 列表 + i18n）。

5.3 备选方案 ​

方案描述增量体验工作量成本/风险
A. 云 API - 复用现有 chat 模式仅改 BaseUrl/Model/ApiMode无（一次性）极小受 §5.2 细节影响；无语言强制
B. 云 API - 新增 mimo 后端复制 chat 路径，修正 language/鉴权/超时无（一次性）小推荐；隔离未来 API 变化
C. 本地 sidecar（OpenASR）本地 openasr serve，复用 whisper HTTP 后端指向 localhost无小（项目侧）隐私好，但 RTF≈2、第三方可信度低、仅英/粤/普
D. 官方自托管（8B+1.2B）自建 GPU 服务暴露 OpenAI 兼容接口无大（外部）需 ≥16GB 显存，无 CPU/C++ 路径

建议：若目标是「中文/方言高准确率、可接受一次性返回」，选 B（新增 mimo 后端），关键前置是修 language/鉴权/超时；若只做快速验证，先用 A 打通。不建议用 MiMo 替代现有三个 WS 流式后端来追求增量体验。

6. 横向对比（对应问题 6） ​

6.1 准确率（小米官方自评，官方博客；低 WER/CER 更好） ​

模型AiShell-2Fleurs-ZhWenet MeetingWenet Net英文 Open ASR 平均LS-cleanWeNet-Wum4singer
MiMo-V2.5-ASR2.522.415.925.265.731.4519.553.95
Qwen3-ASR-1.7B2.673.215.904.945.761.6324.294.82
FunASR-1.52.572.755.955.285.881.5029.085.58
Seed-ASR 2.02.633.317.224.898.092.8132.599.46
Gemini-3.1-Pro4.523.3012.099.69——64.874.25
Whisper-large-v3————7.442.01——

注：表中未列 whisper 的中文 CER。全部为小米公布的评测结果，未见第三方独立复现（标「中」置信度）；OpenASR 页引用了同样的数字。OpenASR

6.2 与本项目现有后端对比 ​

维度MiMo 云 APIOpenAI whisper-1 HTTP（现状）OpenAI Realtime / 火山 / Mistral（WS）
传输HTTP Chat Completions（整段 base64）HTTP multipart（整段）WebSocket 推流
增量无（SSE 仅输出）无有
首字延迟一次性返回一次性数百 ms 级（各后端不同）
中文/方言强（官方 SOTA 宣称）一般（方言弱）取决于后端
成本$0.074/h ≈ $0.00123/minwhisper-1 ≈ $0.006/minrealtime ≈ $0.017/min
格式仅 wav/mp3，≤10MB多种音频格式常需 24kHz PCM 等
隐私上传小米上传所选云上传所选云
实现成本极低（可复用 chat 模式）已有已有

成本换算：$0.074/小时 ÷ 60 ≈ $0.00123/分钟，约为 OpenAI whisper-1 标价的 1/5、Realtime 的 1/14。定价页

7. 风险与不确定性（对应问题 7） ​

  1. 非实时：无 WS/realtime 音频输入；对本插件「边说边出」的价值有限。属结构性限制，非临时状态。置信度：高。
  2. 输出流式是否真增量未知：stream=true 的 SSE 在 TTS 侧已被官方明确降级为「推理完成后一次性返回」，ASR 侧无同类说明，需最小原型实测。置信度：中。
  3. 鉴权头不确定（已解决）：官方 FAQ 明确两种头均可，Bearer 可直接用。置信度：高。官方 FAQ
  4. enable_itn 兼容性未知（已按文档处置）：ASR 文档未定义该字段，平台声明未定义参数可能被过滤或触发异常；接入 MiMo 一律关闭 EnableItn，无需实测容忍度。置信度：高（文档）。
  5. License 标注不一致：HF=MIT、GitHub=Apache-2.0；均为宽松许可，商用风险低，但合规文本需以仓库 LICENSE 为准。置信度：中。
  6. 服务稳定性/生命周期：MiMo 平台迭代很快（V2 → V2.5 已下线旧版；V2.6 已发布），存在模型/端点调整风险；但 ASR 当前为唯一 ASR 型号且仍在售。置信度：中-高。
  7. 本地路径门槛高：8B+1.2B、CUDA、flash-attn 固定版本（编译易踩坑）、无 ONNX/llama.cpp。C++ 端无直接推理路径。置信度：高。
  8. 社区活跃度有限：GitHub ~331 stars、10 open issues、仅 1 个公开 issue 且无官方响应；官方迭代节奏偏向语言模型，ASR 维护力度未知。置信度：中。
  9. 关于「Muon 优化器 / tokenizer 依赖」：本次未找到 MiMo-V2.5-ASR 使用 Muon 优化器的官方说明，标「未证实」；tokenizer 依赖确认为必须额外下载 1.2B 的 MiMo-Audio-Tokenizer（双模型加载是主要工程负担）。GitHub、config.json
  10. 无公开的独立延迟/RTF 数据：仅有第三方 OpenASR「0.5× 实时」与 YouTube「18GB 显存」的二手数据。置信度：低-中。

8. 元评审（剩余不确定与最弱证据） ​

  • 最弱证据：
    1. C13 的本地性能数据（0.5× 实时、18GB）来自单一第三方站与一个 YouTube 视频，未做基准复现；
    2. OpenASR .oasr 运行时的真实性与性能（§4.3）未能独立验证，仅凭其官网自称；
    3. 「Bearer 是否可用」已由官方 FAQ 确认（两种头均可）；「ASR SSE 是否逐 token」仍为文档未明确项，需实测。
  • 最强证据：模型存在性/命名/开源地址（GitHub+HF 官方双源）、云 API 端点与请求/响应结构（中英文官方文档一致）、格式与 10MB 限制、定价（官方定价页 2026-09-21 更新）。这些置信度高。
  • 未覆盖：官方仓库 src/mimo_audio 源码（抓取 CRAWL_NOT_FOUND）、权重仓库 LICENSE 文件正文、api.xiaomimimo.com/v1/audio/transcriptions 是否实际存在（未发探测请求）。因此「无独立 transcription 端点」基于文档与第三方 issue，置信度高但非直接探测。
  • 时效提醒：调研日 2026-09-25；MiMo 平台更新频繁，接入前应复核 API 文档 与 定价页。
  • 对项目决策的关键提醒：language 覆盖 bug 与 enable_itn 兼容性不可忽略——前者已修复，后者按官方文档处置（接入 MiMo 不发送该字段）；实网探针已证实 Bearer 鉴权与请求形态，真实转写待补测（见 §9）。

9. 决策与实施记录（2026-09-25） ​

最终决策：采用方案 A+——不新增 mimo 独立后端，改为修复现有 OpenAI chat 模式使其可直接对接 MiMo 云 API（用户确认范围；理由：chat 路径已覆盖绝大部分请求/响应形态，新增后端只增加配置面与维护点）。

已实施（本地离线验证，ctest 12/12 通过）：

  • 新增请求体构造纯函数 src/addon/asr/utils/chat_asr_request.{h,cpp}，单元测试 tests/chat_asr_request_test.cpp 覆盖 4 种 language/ITN 组合。
  • 修复 language 覆盖 bug：原实现 body["asr_options"] = asrOpts 会整体覆盖、丢弃 language；现在两者统一构造，auto/空值时省略 language。
  • enable_itn 改为可配置：OpenAIAsrConfig.EnableItn（默认 true，保持 DashScope 行为）；MiMo 用户设 false。
  • 用法（无需新后端）：ActiveBackend=openai、BaseUrl=https://api.xiaomimimo.com/v1、Model=mimo-v2.5-asr、ApiMode=chat、Language=zh、EnableItn=false。

实网验证（2026-10-01，按量付费 Key，探针复用 BuildChatAsrRequestBody + Bearer + choices[0].message.content 解析路径）：

#样例asr_options结果耗时
V18s 普通话{"language":"zh","enable_itn":true}HTTP 200，转写正确740ms
V28s 普通话{"language":"zh"}HTTP 200，转写正确842ms
V38s 普通话省略HTTP 200，转写正确721ms
V449.2s 普通话{"language":"zh"}HTTP 200，全文转写正确2390ms
  • 鉴权：Authorization: Bearer 验证通过（充值前 402、充值后 200，均非 401）。
  • enable_itn 未定义字段：V1 返回 200，说明当前服务端会过滤未定义字段；但官方 ASR 文档仅定义 language，平台声明未定义参数「可能返回请求异常」，因此默认建议仍为 EnableItn=false，不依赖未定义行为。
  • 30s 超时：49.2s 音频 2.39s 完成，远低于 CURLOPT_TIMEOUT=30；无需放宽超时。
  • 转写质量：与 Wikibooks《Chinese (Classical Mandarin)》原文逐句一致（繁体原文输出为简体，如「我自己來了」→「我自己来了」、「他常常誇自己」→「他常常夸自己」）。
  • SSE 增量（stream=true）未验证——当前实现只用 stream=false，不影响接入。

决策变更触发条件：若 MiMo 推出 WS 实时音频接口，或 chat 路径出现多家供应商参数分歧，再评估方案 B（独立 mimo 后端）。

参考链接 ​

小米官方（一手）

第三方 / 社区（二手，辅助）

Fcitx5 Voice Input Documentation

Copyright © 2026