最近火热的扩散语言模型真实落地场景介绍
扩散语言模型（dLLM）现在确实不是纯论文玩具了，但"落地"的程度要分档看——真正跑在付费 API 和生产系统里的，主要是 Inception 的 Mercury 系列；国内 DiffuSpace（Dream 7B）在做端侧 Agent 适配；Google 的 DiffusionGemma、蚂蚁 LLaDA 2.x、NVIDIA Nemotron 扩散系则更多在开源/实验/混合加速层。下面按落地深度给你拆开。
🟢 已经跑在商用 API / 生产里的场景
这条线基本等于 Inception Labs 的 Mercury 家族（Mercury 2 → 2.5 → 2026 年 10 月刚发的 Mercury 3），OpenAI 兼容接口，走 Inception API、Baseten、OpenRouter，也在推 AWS Bedrock / Azure Foundry 企业部署。
具体被点名的落地场景和客户：
- 实时语音 Agent：Mercury Voice 主打 TTFT < 170ms，已接 Audivi AI、Altur、OpenCall 的电话客服/语音代理；OpenCall 自述切到 Mercury 后 P99 从几分钟压到 1 秒、P50 不到 200ms。
- 搜索 / RAG 管道：一个查询背后几十次模型调用（规划、query rewrite、rerank、抽取、摘要），用 Mercury 做这些"高频小调用"，把总时延压回单次交互内。
- 代码助手的后台活儿：Augment Code 把 context compaction（长会话压缩）迁到 Mercury，时延从 150s → 27s、降成本 90%；还用来做 MCP 工具搜索、模型路由。
- 浏览器操作 Agent / 实时搜索 Agent / 客服：Mercury 3 早期客户里点到 TinyFish（浏览器 use agent）、RevisionDojo（互动教育，答题反馈 ~1s 返回）、Octen AI（智能眼镜场景，中位生成 0.9s）、Lorikeet（受监管行业的语音/聊天/邮件 concierge）。
- Microsoft NLWeb：Mercury 是 NLWeb 项目的创始 LLM 合作方，做交互式网页内容场景。
⚠️ 这些数字基本是厂商自报 + 客户证言，不是第三方审计。架构上 dLLM 确实在"多 token 并行 + 双向注意力 + 可自我修正"这条路上站得住，但别把 5–7x 吞吐、1000+ tok/s 直接当成你业务里一定能复现的数。
🟡 半落地 / 端侧与垂直行业适配中
- 国内 DiffuSpace（扩散智能）Dream 7B：2026 年 9 月和智能体平台 Acrab 合作，往 AI PC、智能汽车、机器人、智能家居这些端侧 Agent 场景推，官方给的测试数据是端侧运行最高 5x 提速；公司自己明说现阶段重心是 Coding Agent + 端侧部署，机器人那边还停在"全局规划能力有望安排动作顺序"的潜力叙述。
- 华为盘古体系：在 Agent 应用里探索扩散语言生成机制，参与 Dream 系列相关研究，但没看到对外独立产品。
- 临床护理语音：宁夏英炜智慧的 dLLM-ASR 方案，用"先验引导 + 自适应降噪"做语音识别解码，配合 PDA 医嘱 → 多方言宣教播报，已经在临床上线；这是把扩散解码用在 ASR 环节，不是通用对话 LLM。
- Gemini Diffusion（Google DeepMind）：目前仍是 experimental demo，没进商用 API 档。
🔵 开源 / 实验性，别当生产主力
- Google DiffusionGemma 26B-A4B（Apache 2.0）：并行去噪、H100 上 1000+ tok/s，但官方定位就是本地低并发、交互式编辑、代码 infilling、OCR/文档解析、约束生成；高 QPS 云端服务反而没优势，质量也比同档 Gemma 4 低一截。
- 蚂蚁 LLaDA 2.x（LLaDA2.2-flash 100B / mini 16B，128K 上下文 + tool use）、NVIDIA Nemotron-Labs-Diffusion / TwoTower、ByteDance Seed Diffusion：开源权重或技术报告层面，TwoTower 自己都承认比同门自回归骨干 aggregate 质量让 1.3% 换 2.42x 吞吐，LLaDA2.2-flash 在 SWE-bench 上落后同档 Ling-2.6-flash 约 12 分。
- DFlash / DSpark 这类 block diffusion drafter：实际角色是给自回归模型当草稿模型跑在 vLLM / SGLang / llama.cpp 里，不是独立对话模型——这属于"混合架构落地"，不是纯 dLLM 替代。
一张表看清"真落地"分布在哪
| 场景 | 落地状态 | 代表玩家 |
|---|---|---|
| 语音 Agent / 低延迟对话 | 商用 API 可用 | Inception Mercury Voice、OpenCall、Audivi |
| 搜索/RAG 内部多跳调用 | 生产调用中 | Mercury 系客户 |
| 代码助手（压缩/路由/工具搜索） | 生产调用中 | Augment Code |
| 浏览器 Agent / 客服 / 教育反馈 | 早期伙伴生产 | TinyFish、Lorikeet、RevisionDojo |
| 端侧 AI PC / 车机 / 机器人 | 适配测试阶段 | DiffuSpace + Acrab、华为 |
| ASR 解码加速 | 行业上线案例 | 英炜智慧 dLLM-ASR |
| 通用聊天主力 / 长文写作 / 重推理 | 仍靠自回归 frontier | GPT/Claude/Gemini 等 |
| 本地开发机低并发编辑 | 开源可用 | DiffusionGemma、LLaDA、Nemotron 扩散系 |
一个容易被忽略的判断
dLLM 现在的真实角色不是"取代 GPT/Claude"，而是做自回归模型体系里那些"被时延卡住、又被调用上万次"的辅助环节——路由、压缩、抽取、rewrite、语音首包、代码补全、Agent 子调用。这也是为什么它先落在语音、RAG、Coding subagent、端侧这几个场景，而不是先去卷长文创作和深度推理。
Top comments (0)