Skip to main content

One post tagged with "vLLM"

vLLM inference engine integration and performance

View All Tags

Serving Multimodal at Scale in llm-d

ยท 21 min read
Xiyue Yu
Software Engineer, Google
Abdullah Gharaibeh
Senior Staff Software Engineer, Google
Alexey Roytman
Senior Technical Staff Member, IBM
Nili Guy
Nili Guy
R&D Manager, AI Infrastructure, IBM
Guy Girmonsky
AI Platforms Research Engineer , IBM
Kaushik Mitra
Software Engineer, Google
Rahul Gurnani
Software Engineer, Google

Text inference has a comfortable shape in llm-d. A request arrives as a few thousand tokens, prefill and decode run back to back on one replica, and a prefix-aware router keeps the KV cache warm. Every layer of the stack โ€” scheduler, load balancer, autoscaler โ€” is calibrated against that shape.

Then someone attaches an image, and it is tempting to think of the result as the same request with a picture bolted on. It is not. A multimodal request differs from a text-only one in almost every property a serving system actually reads: how big it is, how much it costs, how long it takes before the first output token, what identity its cache entries have, and how many stages it has to move through. The parts of the stack that were calibrated on text keep working, silently, on numbers that no longer mean what they used to.

This post walks those differences deliberately. First what makes media content different from text content. Then what that does to an inference request, difference by difference. Then, for each one, what llm-d actually does about it โ€” the token estimator, the content-hash routing path, the retuned affinity gate, and the encode tier. Model server like vllm is the engine throughout; its per-replica mechanisms are the floor, not the answer.