12 张卡的吞吐比 8 张卡还高：多模态服务把编码器拆出去的真实收益与边界

导语：多模态请求要先过视觉编码器，把图片、视频、音频变成 embedding，而这一步的负载曲线跟 prefill、decode 完全不同步。vLLM 最近补齐了 EPD 解耦的一整套配套机制，官方实测也给出了这条收益区间到底有多窄。

核心要点

1. 编码阶段的压力随媒体大小、模态和请求混合浮动，与 prefill/decode 的需求独立变化，按整机扩缩容必然有一侧被浪费。
2. 拆分只是第一步，真正省下时间的是不重复做预处理：只转发元数据的请求让下游不再二次拉取、解码、缩放、切 patch。
3. 音频链路上，元数据转发把吞吐从 62.21 提到 73.13 req/s，平均延迟从 980ms 降到 853ms，准确率只差 0.25 个点。
4. DeepSeek V4.1 Flash 实测：并发 64–128 时，十二张卡（含四张编码卡）的每 GPU 吞吐仍高 6.6–9.5%，P90 首 token 延迟低 44–47%；但并发 16 时反而更低。

正文要点

问题出在三段耦合在一起。 一个多模态请求分三步：编码器产出 embedding、prefill 处理提示词和 embedding、decode 逐 token 生成。图片多的负载需要更多编码算力却不怎么需要解码，输出长的负载正好相反。绑在同一组 GPU 上，扩缩容只能按最忙那段算，另一段闲着；而且编码任务直接占掉了语言模型的显存和时间片。解耦之后可以按段独立配实例，还能把编码挪到专门的卡上。

只搬 embedding 是不够的。 下游实例拿到远程 embedding 后，还得重建输入布局——占位符长度、图像网格、特征长度、哪段位置对应哪个 embedding。做法通常是让它再取一遍原图、再解码缩放一次，等于把预处理白做两遍。这里的改法是把原始媒体换成一个只含结构信息的引用，embedding 仍走独立的数据通路，下游只拼占位符。上面那组音频数字就是这个改动的直接结果。

编码器实例的执行路径得单独做。 它不跑语言模型、不维护 KV cache、不产 token 采样，还照搬常规 runner 会出现编码没算完缓冲区就被复用的错误。配套改动还包括：只读需要的 checkpoint 分片，在剪枝版的 Kimi-K3 上，96 个分片只读了 2 个，权重加载从 683 秒掉到 0.31 秒；以及支持 ViT 的 CUDA Graph 捕获。

收益的上限来自缓存复用。 在六张 H20、两编码加四 P/D 的拓扑里做受控实验，把 512 张图重新分配到不同编码器制造本地未命中，共享复用让重复编码从 512 次降到 0 次，首 token 的 p50 从 1.209 秒降到 0.819 秒，p90 从 1.656 秒降到 0.891 秒，出 token 间隔基本没变。这是最理想情形，生产环境能省多少，取决于命中率和缓存本身的内存与 IO 开销。

瓶颈会搬家。 上 GPU 预处理加硬件解码后，30 帧视频的端到端吞吐提升了约 94–115%，但报告里同时写了：编码变快之后，瓶颈已经移到 P/D 层。拆解从来不消灭瓶颈，只是把它挪到下一段，各段配额要重新平衡。

落地建议与坑点

1. 先量三段各自的占时再决定拆不拆。媒体重、回答短的负载才吃得到收益；长输出负载真正想拆的是 decode，不是编码。
2. 拆分必须和去重预处理一起上线，否则省下的编码时间会被下游的拉取、解码、缩放吃回去。
3. 吞吐按全部 GPU 算，编码卡也要计入。低于并发 32 时解耦会因为跨节点传输和协调开销净亏，64 以上再上更稳。
4. 编码器实例别照抄语言模型实例的配置：跳过无关分片加载、关掉采样路径、开图捕获，启动时间能从分钟级掉到亚秒级；同时把缓存命中率当核心指标盯，它是第二轮收益的主要来源。