SGLang vs vLLMvLLM 的高并发原理PagedAttention解决 KV Cache 碎片Continuous Batching解决 GPU 空闲推测解码加速 Decode 阶段 vLLM 解决的是 如何让模型跑得快 的问题。ThinkingSGLang的作用是什么如何让业务逻辑跑得快SGLang 深度优化Radix 缓存与复杂任务的极致吞吐SGLang vs vLLMvLLM 的高并发原理PagedAttention解决 KV Cache 碎片Continuous Batching解决 GPU 空闲推测解码加速 Decode 阶段 vLLM 解决的是 如何让模型跑得快 的问题。ThinkingSGLang的作用是什么如何让业务逻辑跑得快PD 分离架构 -- Prefill/Decode 解耦PD 分离Prefill/Decode 解耦 是当前大语言模型LLM推理服务的主流高性能架构核心是将推理中两个计算特性完全不同的阶段拆分到独立的硬件 / 进程中执行解决资源错配、相互干扰、延迟抖动等问题。为什么需要 PD 分离?Continuous Batching 将 Prefill预填充和 Decode解码混合在同一个 GPU 上执行。虽然提升了吞吐但两个阶段的计算特性完全不同混在一起会产生严重的资源争抢。PD 分离架构核心设计1. 三层标准架构Router / 调度层请求路由、负载均衡、SLO 保障、P/D 节点状态管理。Prefill 集群高算力 GPU批量处理 Prompt、生成 KV Cache。Decode 集群高带宽 GPU消费 KV Cache、流式生成 Token。适用场景长上下文服务4k Token如 Kimi/DeepSeek高并发实时对话客服、助手、直播流式生成Copilot、代码补全、写作超长文本生成报告、小说、多轮对话Thinking混合执行的问题是什么当 Prefill 和 Decode 在同一个 GPU 上交替执行时• 执行计算密集的 Prefill 时会阻塞延迟敏感的 Decode → TPOT 飙升用户感觉卡顿• 执行访存密集的 Decode 时GPU 计算单元大量空闲 → 浪费了 Prefill 需要的算力 让短跑运动员和马拉松运动员在同一条跑道上交替训练谁都练不好。sumarry除了 vLLM业界还有其他 PD 分离实现• MooncakeKimi 的推理架构以 KV Cache 为中心的分离式架构• NVIDIA Dynamo提供声明式的 PD 分离部署VllmPrefillWorker VllmDecodeWorker• SGLang、llm-dKubernetes 原生推理栈PD 分离 计算与访存异构解耦 硬件专业化 流水线并行是当前 LLM 服务高吞吐、低延迟、高性价比的必选架构。Thinking为什么 Prefill 适合小 BatchDecode 适合大 Batch?• Prefill 本身就是计算密集型处理整个 Prompt 的矩阵乘法GPU 算力已经打满了。增大 Batch 只会增加排队延迟不提升吞吐。• Decode 本身是内存带宽密集型每步只算 1 个 tokenGPU 算力大量空闲。增大 Batch 让 GPU 同时处理更多请求空闲的算力被利用起来从 Memory-Bound 转向 Compute-Bound吞吐大幅提升。ThinkingPagedAttention Continuous Batching推测解码PD分离分别解决什么问题• PagedAttention 解决显存浪费• Continuous Batching 解决 GPU 空闲• 推测解码解决生成太慢• PD 分离 解决资源争抢。• PagedAttention优化层面内存层解决的问题KV Cache 碎片和浪费 把 KV Cache 切成小块按需分配像虚拟内存一样管理• Continuous Batching优化层面调度层解决的问题GPU 空闲等待短请求完成后干等长请求 每生成一个 token 就调度一次完成即腾位新请求立即填入• 推测解码 (EAGLE/MEDUSA)优化层面算法层解决的问题Decode 阶段 GPU 算力空闲(Memory-Bound) 小模型猜多个 token大模型一次并行验证减少生成步数• PD 分离优化层面架构层解决的问题Prefill 和 Decode 互相干扰 两阶段物理隔离到不同 GPU各自用最适合的硬件和 Batch 策略ThinkingPagedAttention Continuous Batching推测解码PD分离 如何叠加使用使用逻辑• PagedAttention 是基础设施贯穿 Prefill 和 Decode 两端所有场景都需要• Continuous Batching 在 Prefill 和 Decode 集群内部各自运行提升各自的 GPU 利用率• 推测解码 只在 Decode 集群中使用Decode 阶段是 Memory-Bound最需要加速• PD 分离 是最外层的部署策略决定了上面三者在哪里运行SGLang深度优化SGLang 通过fork/join/select/gen等原语将分支 - 求解 - 合并的提示模式高效落地既简化了多任务并行生成的代码又通过 runtime 优化KV 复用、约束解码等大幅提升了 LLM 推理的效率与稳定性。LangChain VS SGLangLangChain 是应用层工作流编排框架SGLang 是推理层 runtime 与编程抽象两者是互补而非替代的关系。维度LangChainSGLang核心定位应用层工作流编排Agent、RAG、多步骤任务推理层 runtime 轻量级编程抽象解决问题如何把 LLM 与工具 / 知识库 / 多模态组件串联成复杂业务流程如何让 LLM 推理更快、更省资源、更可控抽象层级高抽象面向开发者业务逻辑如RetrievalQA、AgentExecutor低抽象面向生成原语与调度如fork/gen/select典型场景客服机器人、知识库问答、代码助手、多轮对话 Agent高并发推理、批量生成、结构化输出、多维度评估SGLang系统中的RadixAttention技术SummaryRadixAttention技术CASEJSON约束输出CASE流式输出CASE性能测试CASEvLLM 与 SGLang 性能对比 - 相同任务下的性能差异QAQ:PagedAttention和RadixAttention都是解决KV Cache问题的前者按需分配后者重复使用PagedAttention核心是分页式显存管理解决 KV Cache 内存碎片化、按需分配的问题 RadixAttention核心是前缀 KV Cache 共享复用解决重复计算、冗余存储的问题两者都是为了优化 LLM 推理中 KV Cache 的内存效率与推理性能但侧重点完全不同。特性PagedAttention (vLLM)RadixAttention (SGLang)核心目标解决 KV Cache 内存碎片化提升显存利用率解决重复前缀的 KV Cache 冗余提升吞吐与延迟实现方式将 KV Cache 划分为固定大小的 “页”按需分配 / 释放类似虚拟内存用基数树Radix Tree组织 KV Cache共享相同前缀的 KV 数据典型场景多并发、变长序列场景如聊天、流式生成多轮对话、多分支生成、并行评估如 SGLang 的fork原语优化点内存利用率↑避免碎片支持更大并发计算量↓共享前缀无需重算显存占用↓去重存储代表框架vLLMSGLangQ:用SGLang加载运行模型后 再给一个SGLang 按照加载的不同大模型注入各种不同的SGLang程序吗SGLang 模型运行时Runtime 可编程执行引擎1.先用 SGLang加载一个大模型LLaMA、Qwen、GLM 等2.再向这个已经加载好模型的 SGLang 实例动态注入、运行各种 SGLang 程序3.不同模型 → 不同 SGLang 实例 → 各自跑不同的 SGLang 程序完全互不干扰Q:RadixAttention 和 PagedAttention是可以同时启用的吗 或者是冲突的吗?PagedAttention底层显存管理器分页、防碎片、按需分配物理块RadixAttention上层缓存复用器前缀共享、去重、减少重复计算[用户请求] → RadixAttention查前缀树 → 拿到复用的 Block IDs→BlockTable填复用块 分配新块→PagedAttention物理显存块、计算 Attention两者是 LLM 推理中 KV Cache 优化的黄金组合前者提供高效、无碎片的物理显存分页管理后者实现跨请求前缀的逻辑缓存共享复用二者分层协同、默认同启可同时最大化显存利用率与推理吞吐量。Qautodl上一个4090的机器 开一个 SGLang就把显存快占满了 怎么同时开SGLang和vLLM 用 4-bit 量化模型 各自限制 40% 显存 短上下文就能让 SGLang 和 vLLM 同时跑起来只是要牺牲一点性能和上下文长度。QPD分离 P和D一定要跑同一个模型吗模型不一样KV Cache对不上。PD分离 同一个模型的推理过程拆成PD两个阶段分到不同机器 / 卡上跑。QvLLM 能通过调优达到 SGLang 的性能吗可以无限接近通过上面提到的内存、批处理、量化等参数调优vLLM 的性能可以得到巨大提升在简单的、单轮的、不需要复杂结构化输出的文本生成任务中其表现会非常接近 SGLang。很难完全持平在高并发、多轮对话、RAG、强依赖结构化输出等复杂场景下SGLang 凭借其RadixAttention等架构优势性能上限更高vLLM 难以仅靠调参来抹平这种“结构性”差距。Q如果生产产线本地部署PD分离需要配合K8S做部署吗对于生产环境的本地部署尤其是追求极致性能和稳定性的场景将 PD 分离与 Kubernetes (K8s) 结合是最佳实践。K8s 作用隔离与异构管理、独立弹性伸缩 (Auto-scaling)、服务发现与负载均衡、声明式运维与故障自愈KV Cache 传输这是 PD 分离的难点。你需要一个高性能的机制来将预填充阶段产出的巨大 KV Cache 数据传递给解码节点。常见方案RDMA (Remote Direct Memory Access)最高效直接 GPU 间通信需要 InfiniBand 或 RoCE 网络。NCCL (NVIDIA Collective Communications Library)NVIDIA 的集合通信库也支持多机传输。共享内存/存储 (Redis/内存盘)相对慢一些但实现简单适合小规模。K8s 配置要点使用PodDisruptionBudget防止自愿中断如节点升级时同时杀死太多 Pod。为每个 Pod 配置requests和limits尤其是nvidia.com/gpu资源。使用readinessProbe和livenessProbe确保只有真正就绪的 Pod 才接收流量。