LLM服务器到底怎么扛住高并发？这个41分钟视频把vLLM和SGLang拆开讲

Jia-Bin Huang发布了一个41分钟的视频，标题很直给：How LLM Serving Actually Works。它回答一个具体问题：你在对话框里敲一句话，服务器到底做了什么；为什么同时服务很多人时，延迟和吞吐会互相拉扯。

完整视频在YouTube：https://youtu.be/T4SRu-trimA

视频没有停在概念层。它把vLLM和SGLang当工作例子，沿着请求进入服务器后的路径往下拆：调度器、KV cache、模型、sampler。章节从next-token prediction开始，讲到PagedAttention、prefix caching、结构化输出、投机解码、FlashAttention、CUDA graphs、量化、张量并行和MoE专家并行。

对普通用户，最值得先理解的是两个事实。第一，LLM生成每个token都要重复做大量计算，所以服务器会把算过的Key和Value缓存起来，这就是KV cache。第二，请求分两段：prefill处理输入，decode逐token输出。prefill更吃算力，decode更吃内存带宽。很多优化都绕不开这个差异。

调度器的任务是把不同请求塞进批次，提高吞吐。continuous batching（Orca）让新请求不必等整批结束，调度器还要处理优先级；chunked prefill（Sarathi-Serve）把长输入切块，goodput关心的是在延迟目标内完成多少请求。视频还提到把prefill和decode放到不同池子，这是在吞吐和延迟之间做取舍。对开发者来说，这里有个常见误区：批越大吞吐越高，但单请求延迟可能变差。调度策略决定你优化的是哪个指标。

KV cache吃显存，视频用操作系统虚拟内存做类比，讲到PagedAttention把cache分成块，显存池满了就preemption。视频还单独讲了KV cache需要多少内存。共享前缀是另一个重点：系统提示、聊天历史、agent上下文经常重复。vLLM用hashed blocks做前缀缓存，SGLang用RadixAttention维护缓存前缀的radix tree。缓存不够时还有eviction和HiCache。cache-aware scheduling会优先匹配最长前缀，但视频也点出代价：公平性会受影响。缓存命中率高不等于每个请求都变快，排队顺序会变。

结构化输出这一段对应用开发很实用。JSON、regex和状态机约束解码，XGrammar做压缩状态机。它说明约束生成发生在解码阶段，后处理补不回来。投机解码则是用小模型或Medusa、EAGLE、n-gram先起草，再验证。用便宜的草稿换更少的decode步数，前提是验证不能太贵。

底层优化部分更像在压固定开销：FlashAttention、kernel launch、CUDA graphs、torch.compile、overlap scheduling，以及FP8 KV cache和量化。大模型部署部分讲到DeepSeek-V3在8张GPU上的tensor parallelism、latent attention、data-parallel attention和MoE wide expert parallelism。最后落到replicas和cache-aware router。视频收在三个原则：never idle，never wasteful，never twice。翻译成大白话，别让GPU闲着，别浪费显存，别重复计算。

这三个词比很多架构图有用。LLM serving的优化没有单一银弹，调度、缓存、并行、量化各自解决一段约束。视频章节很长，如果只想抓主干，可以先看0:00到16:40，调度、KV cache、PagedAttention和前缀缓存都在这一段；后面再按兴趣跳结构化输出、投机解码和并行。对AI从业者，这份章节列表可以当排查性能问题的索引；对普通用户，它至少能解释清楚，为什么首token会慢，为什么长上下文贵，为什么系统提示缓存有意义。