如果你维护过一个多模态问答服务一定会遇到这样的场景单看推理引擎的吞吐指标一切正常可一旦有用户上传图片整体延迟就开始失控GPU显存忽高忽低甚至偶发OOM。这不是模型的问题也不是推理框架的问题而是整个服务架构在设计之初根本没有把多模态当作一等公民来对待。我近一年大部分精力都花在重构一套面向大规模多模态推理的高效服务架构上。这里说的多模态主要是视觉语言模型的推理服务化也就是图文理解、视觉问答、多图对比这类场景。这篇文章不打算堆概念也不会贴一堆架构图我想用最直接的方式把整个设计过程、关键取舍和踩过的坑讲清楚。适合正在做模型服务化、推理性能优化或者准备给团队多模态能力做平台化的工程师参考哪怕你只是刚接触推理服务也能从里面找到可以直接落地的思路。1. 多模态请求的三本账为什么原有LLM架构扛不住1.1 请求结构、显存占用与数据吞吐三个维度同时变化很多人以为多模态推理就是在纯文本大模型前面加一个视觉编码器把图片变成向量塞进去剩下的事情和文本生成没区别。这个理解本身没错但工程实现上差别非常大。最直观的变化体现在三笔账上。第一笔是请求结构。纯文本请求的输入长度相对稳定几百到几千token是常态。而图文请求的token组成是两段拼接文本token加上图像token。一张336x336分辨率的图经过视觉编码器后通常会产生576个图像token五张图就是2880个token再叠加几百个文本token单条请求的输入可能直接冲到3000 token以上。更麻烦的是多图请求、纯文本请求、单图长文请求会同时到达token长度分布极其不均匀从几百到几千都有方差比纯文本场景大一个数量级。第二笔是显存占用。视觉编码器本身就要吃一块显存图像token进入大模型后还要参与KV Cache的计算和存储。射线一算同样并发数下多模态请求的KV Cache消耗比纯文本请求高出好几倍。如果还是按纯文本场景的经验值去给显卡分显存K8s里没有OOM就属于运气好。第三笔是数据吞吐。图片进来先要下载、解码、缩放、归一化这些都是纯文本链路里根本不存在的CPU密集型操作。一张十几MB的图光解码就可能吃掉几十毫秒CPU时间如果这些操作堆在推理引擎的worker里做GPU会频繁空转等待CPU把张量喂进来。1.2 纯文本推理框架的调度假设在图文场景下失效我们最早直接复用了之前跑文本大模型的推理架构核心依赖的是那个比较成熟的连续批处理调度方案。这套东西在纯文本场景确实好用但它的调度假设是输入token数相对均匀、序列长度差异可控。而多模态请求进来之后同一个batch里可能同时存在一个几十token的文本短请求和一个几千token的图像长请求。调度器只能看到token总数按token数去分配显存和算力结果就是短请求被长请求拖着走长请求的显存峰值又瞬间把整个batch填满。更深层的问题在于这套架构里没有视觉编码器的位置。要么把视觉编码器塞进推理进程里让图像编码和文本解码抢同一块GPU的算力导致大模型解码吞吐被视觉编码拖累要么每个请求单独远程调用一个视觉服务QPS稍微起来一点视觉服务的网络IO先被打爆。两种方式我都试过结局都不体面。1.3 新版架构上线前必须定下的硬指标踩过这些之后重构一开始我们就先定了几个硬指标后面所有设计和验证都围绕这几条来TTFTTime To First Token首token延迟P95控制在3秒以内单卡解码吞吐在混合负载下达到纯文本架构的85%以上长尾请求不对整体SLO产生连锁影响服务在QPS突增2倍的情况下不雪崩。这些指标不一定适用你的场景但它逼着我们把多模态推理服务拆成了输入链路、调度策略、显存管理、解码执行四个独立问题来分别解决而不是笼统地调调batch size就完事。2. 四层架构的主干设计与三个关键取舍2.1 接入层、调度层、执行层、存储层各管什么重构后的架构从功能上拆成四层接入层、调度层、执行层、存储层。这四层不是物理上必须分开部署的四个服务而是逻辑上必须职责分离的四个模块。我们的做法是前两层合并为一个无状态网关服务执行层单独部署推理集群存储层走对象存储加缓存。接入层负责所有多模态输入的标准化。图片下载、格式转换、缩放、归一化、图像特征编码全部在这一层完成最终产出一个统一的内部请求包文本token序列加视觉特征张量再加上请求元数据。调度层拿到这个请求包后决定它什么时候进入推理引擎、和哪些请求组成一个batch、按什么优先级执行。执行层就是纯推理引擎它只需要处理规整的张量不再关心图片长什么样。存储层放原始图片、编码后的特征缓存还有推理结果。这里有一个很容易被忽略的点接入层和调度层都必须是无状态的。无状态意味着可以随便水平扩容前面挂SLB或者一致性哈希都行某台机器挂了流量自动分配到其他节点不会影响在途请求。2.2 把视觉预处理全部前移到接入层理由和代价这是整个架构里第一个关键取舍。视觉编码到底放在哪一层我们争论过很久。放在执行层的好处是省去特征传输GPU直出视觉token坏处是图片下载和解码这些不可控的耗时直接占用推理引擎的worker线程一个慢图片请求就能把一个batch卡住几秒钟。放在接入层的好处是推理引擎拿到的永远是规整的特征张量batch吞吐非常稳定坏处是接入层的CPU和带宽压力剧增。最终我们选了后者。核心判断依据是图片预处理的耗时方差极大而推理引擎的batch调度对一个慢成员拖住整个batch极其敏感。把不稳定的输入处理隔离在推理引擎之外相当于给GPU加了一层缓冲垫。代价也不是白付的。接入层的CPU占用明显上升尤其是JPEG解码这种操作特别吃单核性能。我们的应对办法是给接入层配一个独立的CPU worker pool解码操作全部丢进线程池做异步处理再用队列削峰。容量规划的时候按单图平均CPU耗时 × 峰值QPS × 平均图数来估算需要的CPU核数而不是拍脑袋开几个实例。2.3 连续批处理和优先级调度之间怎么平衡调度层用的还是连续批处理但加了一个重要的前置条件视觉编码已经在接入层完成执行层的引擎只处理特征序列。这样引擎看到的图像请求就是一个普通的长输入序列请求不需要在batch中间去等视觉编码结果。第二个改动是给每个请求打上预估长度标签。调度器根据文本token数加图像token数估算出请求的总长度再结合等待时长算一个综合优先级。这样做的目的是防止几千token的长请求把短请求无限饿死。具体参数是一个加权公式优先级 等待时间系数 × 预估token数系数。短请求等待超过一定阈值后优先级会快速上升强行插入下一个可用的batch空位。我们在压测中发现如果没有这个机制当多图长请求占满batch时纯文本短请求的TTFT会恶化到不可接受的程度。加了长度感知的优先级调度之后短请求P95 TTFT从4秒多降到2秒以内而长请求的吞吐只损失了不到10%这个代价完全值得。3. 预填充与解码分离多模态推理的显存峰值被谁吃掉3.1 输入token猛增后预填充阶段成为显存大头大模型推理分成两个阶段预填充Prefill和解码Decode。预填充阶段一次性处理整个输入序列并行计算所有token的KV向量是典型的计算密集型解码阶段逐个生成token每步只算一个token是典型的访存密集型。多模态请求的输入token数量远高于纯文本所以预填充阶段的显存峰值和耗时都会显著拉高。我们实际测过一个7B参数级的视觉语言模型单条输入3000 token在预填充阶段需要的显存峰值差不多是纯文本500 token请求的5倍。多条长输入并发预填充时KV Cache的消耗会以极快的速度把显存填满。这里算一笔账一个24层、隐藏维度2048的模型FP16精度下单条2048 token的请求KV Cache占用约384MB。如果batch size是16那就是6GB。而这个量级的多模态输入在实际业务里非常常见五张图加几百字文本的请求输入轻松超过2048 token。显存预算如果没提前算清楚OOM只是时间问题。3.2 同一块GPU里做预填充和解码会互相拖累传统架构里预填充和解码共用同一块GPU用连续批处理在两者之间切换。这在一开始是可行的因为预填充虽然吃显存但耗时短decode虽然慢但显存占用平滑。多模态请求出现后问题来了预填充阶段的大显存峰值会限制batch size而decode阶段希望batch尽量大以提高吞吐两个目标在那个共享显存的池子里直接冲突。更隐蔽的问题是慢请求占坑。一个3000 token的预填充请求可能在GPU上跑几十毫秒到上百毫秒才能真正完成期间新进来的短请求只能排队。短请求等得越久TTFT越差用户体验越崩。我们最终落地的是预填充与解码分离的方案也就是常说的PD分离。预填充单独放在一组GPU实例上这批实例专门吃大batch高并行度解码单独放在另一组实例上这批实例专攻低延迟逐token生成。两组实例之间需要把KV Cache张量传输过去解码实例收到KV Cache之后直接从生成阶段开始跑。3.3 分离之后TTFT和吞吐的实际变化PD分离不是银弹它最大的代价是KV Cache跨机传输带来的网络开销。我们最初用TCP传输实测单次传输的P95要100多毫秒如果传输超大KV块甚至会到几百毫秒这部分开销直接加到TTFT上差点抵消了分离带来的收益。后来换成RDMA之后传输时间压到30毫秒以内整个方案才真正成立。分离前后的对比数据同样混合负载压测、8卡推理集群指标未分离PD分离后变化TTFT P954.2s1.8s下降57%解码期batch size上限1224提升100%单卡解码吞吐1480 token/s1980 token/s提升34%恶劣长尾请求占比5.6%0.8%下降86%数据本身不关键关键是趋势把预填充和解码分开之后两个阶段各自都能用更合适的batch规模和显存策略整体吞吐反而上去了。4. KV Cache与显存预算的工程实战4.1 一条公式算清KV Cache能占多少显存显存预算这件事不能靠感觉不够了就调低并发必须算清楚每个组件各占多少。整体显存由四块构成模型权重、KV Cache、激活值、临时缓冲。其中KV Cache是最大变量。一个实用的公式KV Cache字节数 批大小 × 序列长度 × 层数 × 隐藏维度 × 2K和V各一份× 字节数以24层、隐藏维度2048、FP162字节的模型为例batch 16、序列长度2048的KV Cache总量是16 × 2048 × 24 × 2048 × 2 × 2 ≈ 6.0GB。这已经是一个很保守的多模态请求batch了如果序列长度拉到4096KV Cache直接翻倍到12GB。加上模型权重约6GB、激活值和视觉编码器占用单卡44GB的显存很快就捉襟见肘。我们在压测中发现一个关键现象多模态请求的KV Cache消耗峰值全在预填充阶段decode阶段的KV Cache总量反而因为缓存了预填充结果而保持稳定。所以显存预算不能按均值来配必须按峰值来留buffer否则偶发的长输入请求就会把整个batch拉爆。4.2 给每条请求的KV占用加上租约KV Cache是稀缺资源多模态请求的长度方差又大如果放任不控制一个极端长图请求可能一次性吃光整个KV池子把后面所有请求的TTFT全部拖爆。我们的做法是引入租约机制来管理KV Cache分配。具体来说推理引擎启动时就预分配一块大的KV池用块式管理。每条请求进入引擎前必须先申请一个KV租约租约里写明这条请求最多能占用的KV块数上限。申请不到就排队等前面的请求释放了块再进来。请求结束后租约立即回收。这套机制类似内存里的malloc/free但加了一条关键约束块数上限。租约上限怎么定我们根据SLO反推在测试环境跑了不同上限值的对比每请求KV上限占池子比例长请求成功率短请求P95 TTFT池子利用率30%99.2%3.7s61%15%99.0%2.1s78%8%85.0%1.9s83%最终选了15%这个档位。长请求偶尔等一等没问题短请求的体验必须保住。这个比例不同场景差异很大你们上线前一定要用自己业务的负载分布重新压一遍别直接抄我的参数。4.3 量化、稀疏化在视觉模型上的取舍显存不够第一反应是量化。但量化在视觉语言模型上不能一刀切。我们的实测结论是大模型的decoder层做INT8量化基本无感显存省了接近一半权重空间但视觉编码器对量化误差非常敏感一旦量化到INT8图文理解类任务的效果打分会出现肉眼可见的下降。我们最终的方案是混合精度视觉编码器保持FP16LLM decoder层的权重做INT8量化KV Cache用INT8存储。KV Cache量化稍微麻烦一点需要按块统计scale好在现在推理框架普遍都支持这个能力。效果上理解类任务的准确率掉了不到1个点显存占用却实打实降下来了。另外一个容易被忽视的点是稀疏化。视觉token之间存在大量冗余理论上可以裁剪一部分图像token来减少KV Cache占用。我们试过简单的启发式裁剪比如按空间位置均匀抽样效果不稳定裁多了影响理解裁少了省不了多少显存。这块想做好得引入真正学习的稀疏化方案工程成本不低短期不是优先级。5. 稳定性和长尾问题踩过的三个真实的坑5.1 视觉编码并发打满接入层CPUGPU却在空转第一次全链路压测我们的GPU利用率一直上不去QPS一升接入层的CPU先爆了。火焰图一看接近一半的CPU时间花在JPEG解码和图像缩放上。GPU这边因为等不到特征张量大量时间在空转。排查链路很清晰接入层CPU 100% - 定位到图像解码与归一化 - 确认热点在libjpeg和图像缩放 - 把解码操作移出请求处理主线程丢进独立worker pool - 加进程级图片解码缓存同一张图短时间不重复解码。这里我学到的最重要一课是推理服务的性能瓶颈不一定在GPU。做容量规划的时候一定要算清楚CPU和GPU的比例。一个坏的架构是GPU闲得没事干CPU忙到冒烟双方都在互相等待。5.2 大图请求导致队头阻塞和内存尖刺压测进行到一半TTFT突然出现周期性尖刺p50完全正常p99一下跳到5秒以上。日志里翻到几个超大分辨率图片请求单张原图16MB分辨率8000x6000。深挖下去发现两个问题。第一个是图像缩放逻辑写得太粗糙代码先把原图完整解码到内存再整体缩放到目标尺寸一张16MB的图在解码后会膨胀成几百MB的RGB数组并发一高内存直接撑爆。第二个问题是这些大图还会占住FIFO队列头后面的短请求全部被堵住这就是队头阻塞。修复方案分两步第一步限制输入图片的原始分辨率和文件大小上限超过阈值直接返回明确的错误码而不是让服务硬扛。第二步重写缩放逻辑用流式缩略图的方式按目标尺寸做分块解码避免原图整幅解码。上线后内存尖刺消失TTFT尖刺也基本看不到了。5.3 跨机传输超时演变成请求雪崩PD分离上线后出现过最惊险的一次事故某个时段KV传输偶尔超时超时后解码侧拿不到结果就开始重试重试又把预填充侧的负载推高预填充侧处理不过来更多请求超时形成雪崩。那次事故持续了将近二十分钟服务的SLO达成率掉到了80%以下。根因有三个。第一传输链路没有背压控制队列无限堆积网络一抖延迟就指数级上升。第二请求在整个链路里没有设总预算时间一个请求可以在预填充侧等很久然后在传输侧再等很久迟迟不超时。第三重试策略太激进解码侧一超时立刻重试而不是退避一段时间。修法是三层叠加传输队列加背压队列满了直接拒绝新请求而不是无限堆积请求从进入预填充到输出第一个token设置总预算TTFT上限超时直接返回降级响应重试策略改成带随机退避的有限次重试。改完之后即使底层网络抖动系统也能自动降级而不是雪崩。6. 指标、压测与扩容怎么证明架构真的高效6.1 TTFT、ITL、吞吐和SLO达成率一个都不能少一套架构说再多最后要看指标。我们日常盯四个核心指标TTFT从请求到达网关到收到第一个token的时间直接决定用户体感快不快。ITLInter-Token Latency相邻两个token之间的延迟决定输出流畅度。吞吐每秒生成token数这是容量规划的依据。SLO达成率TTFT和ITL在约定阈值以内的请求占比我们通常看P95和P99。这四个指标单看哪一个都没意义。TTFT短但吞吐上不去高峰期就是排队吞吐高但ITL抖动生成质量就忽快忽慢。我习惯把它们放在同一张监控面板上看任何一个指标偏离基线都能立刻发现问题。不同场景的SLO阈值差距也很大实时对话场景TTFT要求800ms以内图文生成任务可以放宽到3秒离线批量处理甚至不关心TTFT只关心整体吞吐。定SLO之前一定要和业务方对齐预期不然你自己以为服务很好业务方却觉得体验差到不行。6.2 混合负载压测与长时间稳定性验证压测方案是整个工程里最容易被低估的部分。我做压测时坚持两个原则。第一负载必须混合。不能只测纯文本或纯多模态要按业务真实比例构造单图短问、多图长文、纯文本、高分辨率大图这四类请求混在一起压。我们内部脚本会先统计线上请求的token长度分布和图片分辨率分布再按这个分布去生成压测数据。只压纯文本能跑出来的漂亮数据上线后分分钟打回原形。第二压测时长必须足够长至少30分钟以上。很多问题只有在KV Cache碎片化积累到一定程度后才会暴露。我们有一版调度器优化前20分钟指标非常好看到35分钟时显存碎片率达到30%吞吐直接掉了两成。短压测根本测不出这种长尾问题。压测流程我一般分三步走先按预估峰值负载的80%压10分钟找基线再突然把负载拉到200%测弹性然后回到80%继续压20分钟看恢复情况。这个流程能同时验证稳态、弹性和恢复能力。6.3 从光模块走向按模态拆分的资源池最后聊聊后续扩展。当前架构解决了视觉编码和文本解码的资源隔离问题但仍然是一个池子跑所有模态的逻辑。如果业务同时有图像输入和视频输入它们对编码侧的算力需求完全不同混在一个池子里又会互相干扰。方向是进一步按模态拆分资源池图像编码一组实例、视频编码一组实例、LLM decode共享但按比例配额。调度器根据请求类型把任务分发到不同的池子类似网格调度的思路这样可以让每种模态的负载波动都不影响其他模态。这次重构给我最大的感触是做推理服务架构别急着上复杂方案先把监控指标定义清楚让数据告诉你瓶颈在哪个环节。而多模态服务里最容易出问题的往往不是模型推理本身而是输入链路、资源调度、跨机通信这些周围的环节。把这几块理顺了GPU的利用率自然就上去了。