2026年9月24日,Liquid AI 发布针对其3B参数视觉语言模型 LFM2.5-VL-3B 的实验性推测解码草稿模型 LFM2.5-VL-DSpark。官方数据呈现出极具吸引力的账面回报:仅增加约 2.8 亿参数(279.5M,相当于为主模型增加 8.9% 的体积),就能在搭载苹果 M5 Max 芯片的设备上录得最高 3.13 倍的纯解码加速,并在发布首日就合入了 llama.cpp、MLX-VLM 与 SGLang 的调用支持。在小尺寸多模态模型加速向边缘端与个人终端渗透的当下,这种即插即用的无损提速方案看似是一剂良药。

但这套源自纯文本推测解码的工程思路,一旦移至多模态流水线,就必须面对物理特性的严苛审视。深入拆解实测数据可以发现,所谓倍率提升仅存在于单批次的解码切片中,多模态推理真正的工程瓶颈并未被这套轻量草稿模型解决。

纸面倍率的物理宿命:阿姆达尔定律与视觉编码墙

根据官方公布的架构数据,DSpark 并没有为视觉信号重构专门的感知通道,而是采用了一个 4 层纯注意力简化架构。其 279.5M 的总参数由 193.0M 的 4 层解码栈、21.0M 的隐状态投影层、65.5M 的马尔可夫头以及 6.4k 的归一化与置信度头构成。它的工作原理是从目标主模型的特定层中抽取隐状态,将映射到相同维度的图像补丁与文本 Token 一视同仁,预测出由 9 个候选 Token 构成的块。

官方在包含 GQA、TextVQA、COCO captioning、CharXiv、MMMU-Pro 以及多轮对话的 MMSpec 基准上展开测试。由于视觉预填充阶段的开销完全没有被压缩,实际收益呈现出显著的断层。在苹果 M5 Max 上,解码速度虽有 2.30 至 3.13 倍提升,但端到端延迟的改善仅为 1.56倍至2.62倍;在搭载 M3 Ultra 的设备上通过 llama.cpp 运行时,端到端加速进一步收缩至 1.30 至 1.77 倍;而在云端旗舰 H100 上,官方博客一度将解码加速区间误写为夸张的 20.4x to 2.66x,其实际有效数据为 2.04倍至2.66倍,端到端加速落在 1.64 至 2.27 倍之间。

DSpark 独立基准实测核心指标 8.9% 额外显存开销 主模型增配 279.5M 仅需 4 层解码栈 36% 候选块接受率 9 个候选 Block 中 单步均采纳 3.22 个 2.08x 单并发端到端提速 吞吐 258 提至 537 单位:tokens/s 53.7% 贪婪一致性留存 723 轮实测仅 388 轮 与单模型输出完全重合

这一落差的本质是阿姆达尔定律的必然约束。多模态任务与纯文本推理最大的差异,在于视觉编码器需要先行将整幅图像拆解为数百个视觉标记,并与用户提示词共同完成耗时巨大的预填充阶段。推测解码的算力节省仅仅发生在后续逐字蹦出的解码阶段,当视觉输入占据大量首字延迟时,纯解码阶段哪怕拉出三倍的极值,端到端体验也只能被未加速的前序环节死死拖住。

独立实测撕开裂缝:并发坍缩与精度分歧

若把视线从厂商精心构造的基准测试移向生产环境,落差会变得更加直接。社区针对 H100 搭配 SGLang 运行 600 个 MMSpec 样本(共计 723 轮对话)展开的独立实测显示,在单请求环境下,系统端到端吞吐量由基线的 258 tok/s 提升至 537 tok/s,整体加速为 2.08 倍。此时草稿模型在每个验证周期平均产出 4.22 个有效 Token,剔除奖励标记后实际平均接受 3.22 个 Token,对 9 个候选 Block 的实际命中率约为 36%

离线单跑的延迟拐点,往往会在并发涌入服务框架的瞬间土崩瓦解。

然而一旦提升并发深度,推测解码的边际效益便迅速蒸发。在批处理大小设为 1 时还能维持 2.08 倍提速,并发升至 8 时加速比滑落至 1.55 倍;当并发推高至 32 时降为 1.32 倍;在达到典型的工业服务并发度 64 时,整体加速仅剩 1.18倍。此时系统的主要瓶颈已从生成速度转向大模型的多重验证计算与树状注意力调度开销。

SGLang 框架下并发度对加速比的稀释效应 Batch = 1 (单请求) 2.08x Batch = 8 1.55x Batch = 32 1.32x Batch = 64 (生产服务) 1.18x

比吞吐衰减更棘手的是数学等价性在工程落地中的松动。官方博客强调推测解码具有绝对无损特性,即通过主模型严格验证每个候选词,贪婪采样下的输出与单模型独立推理完全一致。但在上述 723 轮多模态独立对话评测中,仅有 388轮 与无草稿的基线贪婪生成结果完全匹配,重合率仅为 53.7%。在 llama.cpp 社区关于合并此功能的 PR#29339 讨论中,开发者同样指出了底层 C API 尚未完全放开的问题,并记录了目标模型在量化状态下由于浮点误差累积导致贪婪解码路径发散的现象。


路线之争:通用隐层抽头与专用视觉压缩的权衡

DSpark 展现出的是一种典型的工程优先路线。它不尝试重构视觉特征,而是直接截取隐层状态向量,把视觉与文本特征压入同一个表征空间。这种架构最大的优势是通用与交付速度,使模型在发布第一天就能接入主流推理后端。

推理加速方案核心技术机制LLaVA-1.6 解码加速部署工程代价
Medusa纯文本多头树状预测1.42倍需适配树状验证分支
EAGLE-2文本特征上下文递归注入1.62倍增加前向步长依赖
ViSpec视觉Token压缩+全局特征注入2.58倍需侵入式重写视觉流水线
DSpark简化隐层抽头共享注意力2.04-2.66倍额外增加 8.9% 显存占用

但在学术界与前沿工程团队眼中,这种对多模态特性的模糊化处理牺牲了上限。对比基准显示,在 LLaVA-1.6 这类多模态模型上直接套用纯文本解码方案,Medusa 仅能换取 1.42 倍的解码加速,EAGLE-2 达到 1.62 倍;而专门针对图像冗余做动态 Token 压缩、并在验证阶段注入全局视觉先验的 ViSpec,能够跑出平均 2.58 倍的真实解码加速。DSpark 靠着 2.8 亿参数的纯注意力堆叠换来了不错的单机响应,却并未在多模态理解的特征利用率上给出深入解法。

  • 建议.对于在苹果 M 系列设备上搭建单用户多模态助手的终端开发者,DSpark 是一个值得尝试的现成组件,付出 8.9% 的显存增量换取操作响应速度通常较为划算。
  • 风险.若计划将其投入面向公众或内部密集请求的云端推理集群,切忌以 2 到 3 倍的官方宣传值预估服务器吞吐,高并发下验证瓶颈会使收益大幅缩水,且需注意量化部署时的输出精度发散。