Liquid AI 发布了面向 3B 参数视觉语言模型 LFM2.5-VL-3B 的实验性推测解码草稿模型 LFM2.5-VL-DSpark。官方给出的数据颇具诱惑力：仅增加 2.795 亿参数（相当于为主模型增加 8.9% 的显存常驻），就能在苹果 M5 Max 芯片上跑出最高 3.13 倍的纯解码加速，并在发布首日合入了 llama.cpp、MLX-VLM 与 SGLang 的调用链。
在端侧大模型急于寻求流畅交互的当下，这套方案看似是一剂低成本的解药。然而所谓的三倍提速，仅仅存在于特定负载的单批次自回归切片中。一旦把测试环境推向真实的工业并发、极度依赖量化的移动终端，或是需要深度推理的复杂场景，隐藏在背后的工程代价与物理瓶颈便彻底暴露出来。
账面倍率的物理宿命：被视觉预填充拖住的端到端体验
DSpark 采用了一种极具工程巧思但也极其简化的设计：模态无关性。它没有为视觉信号重构专门的感知通道，而是直接抽取目标模型深层的隐藏状态。图像切片与文本提示词一旦进入网络深层，都已被投影为统一维度的数学张量。DSpark 复用纯语言模型的注意力解码架构，仅用 1.93 亿参数的 4 层解码器堆栈、2100 万参数的隐层投影层、6550 万参数的 Markov 预测头以及 6.4k 参数的归一化组件，每次向前推测 8 到 9 个候选词元。
官方在 MMSpec 基准测试中记录了显著的解码加速，但整体系统不可避免地撞上了阿姆达尔定律这堵高墙。多模态任务与纯文本交互最大的不同，在于视觉编码器必须先把高分辨率图像拆解为数百个切片，再连同提示词共同走完漫长的预填充流程。推测解码只能优化随后的自回归吐字，根本动不了前序的计算开销。
当任务偏向短文本输出时，这种断层尤为剧烈。在短问答 TextVQA 测试中，苹果 M5 Max 的纯解码速度虽然提升了 2.69 倍，但因为解码在整个响应周期内占比极低，最终端到端提速缩水到了 1.56 倍。只有在长逻辑链推理的 MMMU-Pro 上，生成耗时占据主导地位，端到端加速才勉强拉高到 2.62 倍。
在 M3 Ultra 的 llama.cpp 部署中，端到端加速进一步跌至 1.30 到 1.77 倍。在英伟达 H100 平台上，端到端提速同样被死死压制在 1.64 到 2.27 倍之间。
生产落地的两道暗礁：并发吞吐坍塌与量化评估缺席
把视角转向真实工业环境，账面光环碎得更快。
在 H100 搭配 SGLang 的实测中，单请求环境下端到端吞吐量确实能从基线的 258 tok/s 提升到 537 tok/s，实现 2.08 倍加速。草稿模型在 9 个候选词元中平均被采纳 3.22 个，命中率约为 36%。
但推测解码的边际收益在高并发下会呈断崖式下跌。并发升至 8 时，加速比回落到 1.55 倍；并发推至 32 时，降到 1.32 倍；当达到典型的工业级并发深度 64 时，整体加速仅剩 1.18 倍。此时 GPU 的计算瓶颈已经从逐字生成的内存带宽转移到主模型的并行验证计算与树状注意力调度开销上。
比并发衰减更刺眼的是官方在技术报告中保持沉默的评测盲区。
官方公布的所有加速指标均基于 16-bit 浮点权重跑出，并明确表示量化模型不在本次评估范围内。然而在个人电脑和边缘终端上，几乎没有人会以原始 FP16 精度去跑一个 3B 多模态模型。端侧开发者普遍依赖 INT4 或 GGUF 格式来缓解显存带宽瓶颈。当主模型原本就已经被量化算法榨干了访存收益，在此之上额外挂载一个草稿模型，能否换回正向收益依然成疑。
更严重的问题在于工程落地对数学等价性的侵蚀。推测解码在理论上宣称无损，即贪婪采样下的输出与单模型独立推理完全一致。但在 723 轮多模态独立对话评测中，仅有 388 轮与基准输出完全重合，一致性只有 53.7%。在 llama.cpp 社区的合并讨论中，开发者同样记录到目标模型在量化状态下由于微小浮点误差累积，导致贪婪解码路径发生发散。
路线权衡与能力错配：快枪手打不中靶心
DSpark 展现的是一种极致求快的工程实用主义。它绕开了复杂的视觉特征重构，直接用隐层张量作为输入，换取极快的多框架集成速度。
| 推理加速方案 | 核心技术机制 | LLaVA-1.6 解码加速 | 部署工程代价 |
|---|---|---|---|
| Medusa | 纯文本多头树状预测 | 1.42倍 | 需适配树状验证分支 |
| EAGLE-2 | 文本特征上下文递归注入 | 1.62倍 | 增加前向步长依赖 |
| ViSpec | 视觉Token压缩+全局特征注入 | 2.58倍 | 需侵入式重写视觉流水线 |
| DSpark | 简化隐层抽头共享注意力 | 2.04-2.66倍 | 额外增加 8.9% 显存占用 |
在多模态专用设计面前，通用抽头方案的上限受到制约。纯文本思路的 Medusa 和 EAGLE-2 在多模态模型上提速较为有限；而专门针对图像冗余做动态词元压缩的 ViSpec 能实现 2.58 倍真实加速。DSpark 靠着 2.8 亿参数堆叠拿到了可观的账面数值，但并没有在多模态特征利用上提供新的理论贡献。
更根本的制约在模型本体的能力分布。LFM2.5-VL-3B 本身偏科严重，其在纯视觉定位与屏幕感知上表现扎实，RefCOCO 达到 87.9，ScreenSpot-v2 达到 80.7；但在复杂逻辑推理与智能体工具调用上力不从心，MMMU-Pro 得分仅为 30.5，BFCLv4 工具调用基准更是低至 32.5。
草稿模型能让文字以三倍速倾泻在屏幕上，却救不了底模在复杂指令下的逻辑混乱。
商业准入门槛同样是一道界线。模型采用 LFM Open License v1.0 协议，仅对年营收低于 1000 万美元的企业免费开放商用，中大型团队依然面临高昂的采购成本。同时，MLX-VLM 目前仅支持温度为零的贪婪采样，SGLang 也依赖较新的特定组件版本。
历史上的机械增压技术常有类似境遇：为发动机前端泵入更多空气，能换来短距离冲刺的爆发力，但整车的巡航极速依然受限于底盘调校与散热极限。DSpark 就像是给自回归解码装上了一个精巧的机械增压阀，然而在重载的视觉编码与高并发调度面前，这股爆发力很快就会被整车重量抵消。
如果你的业务场景是个人单机运行屏幕自动化交互或长图分析，且团队在免费商用额度以内，DSpark 确实能用 8.9% 的显存增量换来更干脆的操作响应；但若计划将其推入高并发的云端推理集群，或寄希望于在低配设备的量化环境下跑出跑分奇迹，这本账大概率算不过来。