多模态推理分段预取：图像 token 洪峰怎么削

多模态请求把 Prefill 的账算复杂了

文本推理的 Prefill 原本是可控的：输入长度可以从 prompt 估算，显存峰值随序列长度线性增长，调度器知道什么时候该批、什么时候该推。多模态请求进来之后，这个前提开始松。以视觉语言模型为例，一张高分辨率图切片编码后可能产生几百到几千个视觉 token，ModServe 的论文里也提到 Decoder-Only 架构处理高分辨率图像时生成的图像标记数会让计算开销跳一档。文本短、图像重，一批里混进两张海报，KVCache 的增量可能比同批的文本请求高出量级。

阿里巴巴在 RTP-LLM 上的 P-D 分离实践给出了一个具体数字：单个请求在 Prefill 阶段大约产生 5G 的 KVCache。这个数是文本场景，图像 token 堆进去只会更大。文章明确提到，如果把 KVCache 在 Prefill 全部结束后一次性同步到 Decode，瞬时洪峰会压垮 Decode 侧。他们采用的做法是按层发送——单层算完就把该层 KVCache 推过去，利用 Prefill 几百毫秒到数秒的执行窗口把带宽摊平。这个思路放到多模态请求上，问题不在于“要不要分段”，而是“哪一段该预取、预取多少、和图像编码怎么对账”。

Prefill 本身上是计算密集，多模态还要多算一次编码

多模态请求的负载可以粗分成两段。第一段是视觉编码器：图像预处理、切片、编码成视觉 token，通常也是 compute-bound，形状和语言模型的前几层不同，吃的是卷积或视觉 attention 的算力；第二段是语言模型 prefill：把拼接后的图文 token 喂进 Transformer，生成 KVCache 和第一个输出 token。第二段的耗时随总 token 数增长，第一段的耗时取决于图像分辨率和编码器规模。

直接把整个请求塞进同一个调度队列的后果是：编码阶段不产出 KVCache，但长时间占着调度槽。文本 Decode 请求在同一个池子里等待，TBT 开始抖。掘金那篇 Prefill 综述里列举的 Chunked Prefill 和优先级调度解决的是文本长短请求之间的公平性，解决不了“视觉编码不产生 KV、语言 prefill 才产生 KV”这种分工差异。这里能做分段预取的原因正好在于两段之间有明确的交接物：视觉 token。它很小，可以提前物化并传输，不需要像 KVCache 那样按层流式推送。

把图像 token 当作预取单元

一个可行的设计是把多模态请求拆成三个阶段：

1. 视觉编码阶段：在图像实例池里完成切片编码，输出视觉 token 张量，写到一个可以被下游读取的缓冲区。ModServe 的模块化设计就是把这个阶段从文本推理实例里剥出去，独立扩容、独立选型。
2. 拼装与 prefill 入队：语言模型实例拿到视觉 token 后，与文本 prompt 拼装，进入等待队列。视觉 token 的传输量通常远小于 KVCache——几千个 token 的隐藏状态在 MB 级，不需要层间流式扩散。
3. 语言 prefill 产出 KVCache：按层计算并按层发送给 Decode，和现有 P-D 分离的流向一致。

这里的“分段”有两层含义：一是计算解耦，视觉编码不阻塞语言 prefill 的批内公平性；二是数据预取，图像 token 在请求真正需要之前已经从编码池推到了语言实例的宿主内存或显存，降低了交接时的等待。RTP-LLM 用 GRPC Stream 跑 Prefill 和 Decode 之间的控制信息，多出来的这一跳同样可以用流式 PRC 来协调，代价是 CPU 侧的会话开销又要多一份——他们的经验是 P-D 分离后 CPU 消耗本来就会上去。

预取很容易做过头的三个地方

第一，图像 token 的显存预占放大批内抖动

预取意味着提前占资源。假设语言实例看到队列里有 8 个多模态请求，每个带 1500 视觉 token，保守地留给预取缓冲区的显存合计不小。这会推高单卡的常驻白耗，反而压低能放进批里的文本 Decode 请求数量。DenServe 的调度优化针对多阶段负载的重调度，核心问题同样是把“每个阶段的资源需求不一样”算清楚。工程上的做法是给预取区设一个可回收上限：进入 prefill 的请求才锁定 token 张量，排队靠后的请求允许被挤出并回退到重算或重新拉取。

第二，预取顺序与完成顺序错位

视觉编码池的完成顺序取决于图像分辨率和当前队列，不会天然和语言侧的调度顺序对齐。如果按请求到达序预取，调度器按最短优先（SJF）挑任务时，预取好的长请求反而占着缓冲区。更稳的做法是让语言侧调度器把下一批候选请求的 token 张量位置告诉预取器，按候选顺序拉取。这样预取和调度策略绑在一起，而不是各跑各的。

第三，效果被视觉模型的 batch 延迟吃掉

视觉编码器很少单独为吞吐优化成大 batch——它天然要等整批图做完再返回。一张大图就可能能把小 batch 撑到几十毫秒。如果预取缓冲只有一两个请求的深度，编码侧的排队时间会直接翻译成语言侧的 TTFT 增加。有收益的场景通常是多图或图集批量处理，编码池能把批次拉大；单张高分辨率图的交互场景，预期收益要保守一些。

网络和隔离这两笔成本躲不开

多模态请求的跨实例传输恰好踩在 RTP-LLM 那篇提到的 S 大包传输问题上：视觉 token 张量是 batch 形状不固定、可落到 MB 级的数据块，而 KVCache 是 GB 级。两者在同一张 RDMA 网卡上抢带宽时，如果都走单边 RDMA，哪条流先申请到发送窗口是不确定的。文章里对 TCP 的评测是时延长且极易受 CPU 负载影响，所以多模态交接也倾向绕过内核协议栈，但 ACCL 这类点对点 RDMA 库对动态增删节点的支持是优势，在 P-D 池频繁替换实例的架构下有价值。

安全边界也需要落到配置上：RDMA 用 Prototype Domain 和 MR 隔离权限，注册列表决定了哪些缓冲可被哪个 peer 写。多模态预热区属于“可能被任何视觉编码实例写”的区域，范围设得过大，出错时污染面的排查成本比性能收益高。

上线前该看哪些指标

这部分容易被 ROIm 实验糊过去。建议至少分三层看：

• 视觉编码池侧：单请求编码耗时、图像池批大小利用率、编码池排队深度。如果池子空转也报高吞吐，指标没意义。
• 交接链路：视觉 token 预取到语言池的快照延迟、预取缓冲区使用率与打回率。打回率高意味着预取白做，先把调度器绑定和深度缩回。
• 语言推理侧：多模态请求的 TTFT 分位数、与同批文本请求的 TBT 干扰程度、每实例显存常驻占比拆出“输出状态和显存”。

IBM 的多模态 RAG 教程里提到图像处理耗时取决于视觉模型服务，这句话在工程上等价于：视觉编码是个不稳定的前置步骤，把它并入推理池就让一个慢图像拖累整批。先在没有容量压力的测试集群里把上面五类指标打全，再决定预取缓冲深度和编码池自动扩容阈值，顺序别反过来。

取舍在哪里

分段预取并不是一个开关。值的开销需要看你的图占 token 的组合：图文配比、分辨率分布、图像占比超过某个水平时，编码段和语言段的硬件利用率曲线的分离度才足以的架构差异明确列出来。把编码剥出去收益会正；降低时也意味着多付一份节点固定成本和两块池子之间的调度代理开销。Mooncake、Prefill/Decode 分离和 DistServe 这些方案都以服务端 P-D 分离为背景在设计负载均衡，而多模态的图档另加在 DistServe 的架构交接处——作为接入策略，在理论边界上收益不低于现有调度器做在 DistServe 中间节点处的串联部分，不是接入分流。因此，和“为省而为”的做法不同，先做序列采样和每阶段的利用率对比，了解空闲线程为多吗？那只好换而言之才是没有争议的地方——没有可避的问题。

多模态预取的关键不是编码快，而是避开编码与语言推理决策处谁快谁慢的时钟互相锁定；摸清这点，才能讲清每一层分段的独立性是否成立——也才把架构解耦所隐含的前提摊开来看。

至少到 RTP-LLM 上线落地那个数字程度，工程侧的收益仍受真实场景具体分段方式的影响：图表离线上游链路的质量测试应优先用平均分和 P99 分在仿真里是否被拉开同一步开始。当多模态比率高、单图像高分辨率、节点归属能分区扩容这类情况同时成立时，候选的层级分段才会合理。