Ming-3.0-asr-tiny 与 Moonshine 250M：一个模型从不停止聆听，另一个直到你说完才开始

在开始任何其他内容之前，需要先澄清一个命名问题，因为它会改变这场比较的性质。Moonshine 发布了三个检查点——Tiny 为 34M，Small 为 123M，Medium 为 245M——而Moonshine 250M是社区用来指代该系列顶配版本的简称，这个检查点的仓库名是moonshine-streaming-medium，其 safetensors 索引实际总计 265,898,112 个参数。Moonshine 组织中没有任何文件名为 250M。该模型是一个英语流式识别器，带有滑动窗口编码器和自回归解码器，面向笔记本电脑或手机打造，于 2026 年 1 月以 MIT 许可证发布。Ming-3.0-asr-tiny是一个 88.7 亿参数的中英识别器，其权重于 2026 年 10 月 14 日出现在 Hugging Face 上，且没有任何公告，围绕 Whisper 形状的编码器和 128 专家混合专家解码器构建，设计为一次性读取整段音频。它们不是同一市场上的竞争对手。它们是关于识别器何时才被允许发声这一问题的两种不同答案。本文称为 Moonshine 250M 的检查点记录在Moonshine Streaming Medium 模型卡，其中 safetensors 索引报告 265,898,112 个参数，而模型卡标注为 245M。这类发布背后有记录的 AI 故障和智能体事件收集在OrcaRouter AI Incident Archive，其中每个条目都带有自己的来源、严重性、置信等级和争议标记。

这个问题才是有用的框架，而且相比准确率对照表，它能带来更清晰的决策。Moonshine 250M 在音频还在输入时就开始输出文字，算力大约只需 0.1 到 1 TOPS。Ming-3.0-asr-tiny 则要等你交给它一个完整文件后才会输出内容，而且输出的转写结果完全没有时间戳。

每一个实际上是为了做什么而构建的

Moonshine 的架构是对常见流式折衷方案的一种刻意反转。编码器是一个滑动窗口 Transformer，具有有界局部注意力，并且完全不含位置嵌入——模型卡片称其为遍历式——在前两层和最后两层中的窗口配置为 (16, 4)，在中间层中为 (16, 0)，由此带来约 80 毫秒的前瞻。位置信息由编码器之后的适配器注入，再送入带有 RoPE 的标准因果解码器。音频前端以 50 Hz 运行，使用简单的时域操作，而不是梅尔频谱图。

解码器是自回归的，而 Moonshine 也讲明了这要付出什么代价：即使首 token 延迟很低，完整输出的延迟仍会随转写文本长度而增长。这是该设计坦诚的局限，也是在比较各种流式宣称时值得牢记的那一句话。流式意味着最初的词很快出现，并不意味着最后一个词会按比例地同样快出现。

Ming 不支持流式传输，其卡片也写明了这一点：捆绑示例不接受流式输入。长音频可以通过一个参数，在 8,192 个位置的上下文限制下进行分块，但把文件分块并不等同于消费实时流，而且配置中的输出格式字段被设置为plain。Ming 转而做的是携带上下文。它接受热词或前一轮对话作为转录提示的一部分，并在十五个中文方言测试集上进行了评估——湖南、闽南、粤语、川渝、上海、安徽、东北、河南、湖北、江苏、客家、陕西、山东、天津、云南。Moonshine 仅支持英语，完全没有这些。

两个参数数量，以及它们为何不同

有一个值得细细琢磨的细节，因为这类事情会悄无声息地破坏对比表：Moonshine 自己的模型卡将 Medium 列为 245M 参数、14 层编码器和 14 层解码器、768 维编码器和 640 维解码器。同一仓库中的 safetensors 索引报告的是 265,898,112。差距约为 2100 万，大致百分之八点五，而且这不是舍入误差——这是只计算骨干与计算随其发布的所有内容之间的差别。

Ming 在更大规模上也有同样的问题。其索引报告有 8,865,800,992 个参数；其图表将模型标注为 8.6B-A2B，这是总参数 86 亿、每个 token 约 20 亿激活参数的简写。该标注比索引低约 2.7 亿。

• 总参数量 — Ming-3.0-asr-tiny 8.87B（索引）对比 Moonshine 250M 266M（索引）；厂商标注为 8.6B 和 245M。

• 每 token 激活参数 — Ming 约为 2B，因为每一步有 128 个专家中的 8 个参与路由。Moonshine 是稠密模型，全部 266M 均激活。

• 编码器——32 层、1,280 维、20 个注意力头、128 个梅尔频带，形似 Whisper；相较之下，另一个是 14 层、768 维、基于 50 Hz 前端的遍历式滑动窗口 Transformer。

• 解码器——24 层、128 个专家、自回归；相比之下为 14 层、稠密、自回归。

• 延迟模型 — 整段片段输入，转录结果输出，无流式处理；相比之下，约 80 毫秒前瞻，并在音频仍在传入时给出首个 token。

• 输出——纯转录文本，无时间戳，无说话人分离；对比来自自回归解码器的转录文本，而该解码器在卡片中同样没有时间戳路径。

• 语言 — 中文和英文，外加15个中文方言测试集；对比仅英语。

• 许可证 — 两者均采用 MIT 许可证，并在 Ming 的仓库中保留随附的 Apache-2.0 许可证头声明。

准确性，但有一个前提：它们从未在同一段音频上测试过。

Moonshine 的模型卡报告称，Medium 在八个英语数据集上的平均 WER 为 6.65：AMI 上为 10.68，Earnings-22 上为 11.90，GigaSpeech 上为 9.46，LibriSpeech test-clean 上为 2.08，test-other 上为 5.00，SPGISpeech 上为 2.58，TED-LIUM 上为 2.99，VoxPopuli 上为 8.54。其训练数据约为 300,000 小时语音。

Ming 在其英语公开测试集上报告的平​​均 WER 为 3.99——LibriSpeech clean 和 other、Multilingual LibriSpeech、FLEURS English、Common Voice 15 English 以及 VoxPopuli——在其中文测试集上的平均 CER 为 3.55。训练数据量未披露。

人们很容易把 3.99 和 6.65 放在一起，并宣称 Ming 在英语上更准确。不要这样做。五个英语数据集中有两个不同，聚合方式也不同，Moonshine 的模型卡没有发布能清晰对应 Ming 那五个数据集的逐数据集细分，而且两家厂商都没有运行对方的模型。在双方都报告的唯一数据集——VoxPopuli——上，Ming 在其正文中根本没有发布该数据集的英语数字，只发布了平均值，因此即便这一处唯一重叠也无法根据模型卡进行比较。这里的每个数字都是厂商报告的，且未被复现。

在没有共享测试集的情况下，能说的只是结构层面的东西。Moonshine 是一个 2.66 亿参数的稠密模型，在 30 万小时英语数据上训练。Ming 是一个 88.7 亿参数的混合专家模型，激活参数约 20 亿，训练数据它并未说明，并在带有大量方言成分的中文和英文上评估。一个激活参数是其十七倍、又具备语言模型先验的模型，理应在高难度英语音频上更准确；如果并非如此，反倒会令人意外。这是来自架构的预期，而不是测量结果。

部署现实出现分歧之处

Ming 需要一台带 CUDA GPU 的 Linux 机器，并安装 Python 3.12、PyTorch 2.11.0、torchaudio 2.11.0、Transformers 5.12.1、fla-core 0.5.2，同时设置 trust_remote_code=True 以加载其自身的建模代码。权重采用 BF16 格式，约 17.7 GB，分为两个分片。还有一条 SGLang 服务路径，固定到特定的适配器提交，这表明供应商期望它通过 API 运行，而不是在桌面上运行。

Moonshine 250M 的目标是低于 1 GB 的内存占用和大约 0.1 至 1 TOPS 的算力。它可通过面向边缘设备的 Moonshine Voice 框架运行，也可通过 Transformers 运行，而模型卡明确指出，Transformers 路径尚未实现完全高效的流式处理——它依赖 flash-attention 的滑动窗口支持。如果你想要该架构所承诺的流式行为，框架路径正是能够实现它的方式。

仓库才是检查点路线真正可见的地方：Tiny、Small 和 Medium 三个系列共二十四个标签，再加上卡片上告诉你若想实现真正的流式传输就该使用的框架。这正是 Ming 目前还不具备的维护叙事，也是这一选择的实用一半。

整个对比用两句话就能说清：一个模型的设计目的是被装进设备后让人忘掉它，另一个的设计目的是从 GPU 上提供服务，并附带一份热词列表。

一个以中文为先的团队实际上应该做什么

如果你的产品是英文的实时字幕或语音指令，那么 Moonshine 250M 正在完成 Ming 完全无法胜任的工作，而准确率上的差距——无论最终是多少——都不太可能比 Ming 无法处理实时流这一事实更重要。流式处理不是事后往一个读取完整片段的架构上添加的功能；它是编码器本身固有的属性。

如果你的产品涉及中文语音，或某地方言，或是事后生成转写、且人名等专有名词很重要的批量流水线，那么两者之中只有 Ming 能解决这个问题，而它才问世五天，下载量只有几十次。诚实的建议是在你自己的音频上做一次对比实测，评分依据要用命名实体召回率，而不是字符错误率，因为那正是 Ming 所针对的维度。

对于进行那场横向评测的团队来说，运维问题不在模型，而在管线：两套技术栈、两套依赖、两套凭据，而且如果不搭建测试框架，就无法在同一批流量上比较它们。OrcaRouter 并不托管这两个模型——Ming-3.0-asr-tiny 和 Moonshine 250M 是自托管的开放权重——但它确实让 200 多个托管模型共用一个 API 密钥，并支持自动故障转移，因此你用作评分对照的托管基线可以与自托管候选模型并排运行，而无需第二份合同。供应商标价按 0% 加价率透传，当你比较的是每小时音频成本而非每 token 成本时，这才是关键数字。

值得关注的悬而未决的问题

Ming 的模型卡指出，热词是提示，不是保证，并且输出是文本，不包含词级时间戳或说话人分离。Moonshine 的模型卡指出，其解码器在短片段或噪声片段上可能会幻觉出词语并重复短语。两者都坦诚说明了失效模式，这比大多数模型卡做到的更多；而且两者从相反的角度描述了同一个底层折衷：一个能生成流畅文本的自回归解码器，有时会生成并未被说出的流畅文本。

决定这场对比的并不是基准测试，而是用例。用你自己音频中同样的二十分钟分别运行两者——一半实时，一半批处理，一半英语，一半非英语——决定就完全不再关乎参数量。在此之前，对这场较量的正确描述是：一个模型是为持续聆听而构建的，另一个是为仔细阅读而构建的；而较小那个模型的名字，只是一种营销简称，对应一个实际上拥有 2.66 亿参数的检查点。