大模型推理框架笔记：vLLM、sglang 等

最近在折腾大模型应用时，发现推理框架几乎决定了服务的性能体验，比如吞吐、延迟、并发能力、显存利用率等。下面是一些个人整理的入门笔记，涵盖 vLLM 和 sglang 等常见方案。

为什么需要推理框架？

直接用 transformers 或原生模型推理通常有几个问题：

  • 吞吐低：一次只处理少量请求，GPU 利用率很差
  • 延迟不稳定：并发一多就开始排队、阻塞
  • 显存浪费：KV Cache 管理粗糙，同一批请求间不能很好复用
  • 部署困难：缺少完整的 HTTP / OpenAI API 兼容接口

推理/服务框架就是在「模型」之上加一层，让你更高效、更方便地把模型变成在线服务。

vLLM：高吞吐推理引擎

vLLM 是一个专注于高吞吐推理的引擎，核心卖点是：

  • PagedAttention：像操作虚拟内存一样管理 KV Cache，大幅提高显存利用效率
  • 高吞吐批处理：自动对来自不同请求的 token 做动态批处理
  • 兼容 OpenAI API：可以直接用 openai/openai-python 等 SDK 调用
  • 支持多模型 & 多 GPU：更适合做统一的大模型推理集群

典型用法一般是：

  1. 用 vllm serve 或 Python API 启动一个模型服务
  2. 通过 HTTP / WebSocket / OpenAI 风格接口发送请求
  3. 在上面挂一层网关、鉴权、限流等，就能变成生产环境可用的模型服务

适用场景：

  • 对吞吐要求高：例如问答机器人、多用户同时使用的应用
  • 需要兼容 OpenAI API，方便复用已有 SDK / 客户端
  • 想充分利用 GPU 资源，减少显存浪费

sglang：面向多模态与复杂工作流

sglang 一开始就把自己定位成「大模型程序语言 + 推理引擎」，除了性能，还强调：

  • 声明式的 Prompt/Workflow 描述：可以像写脚本一样定义多轮调用、分支逻辑
  • 多模态支持：文本、图像等多模态模型的统一调用
  • 与 vLLM 等后端集成：底层可以复用已有推理引擎

更直观地理解，可以把 sglang 看成：

  • 一部分是「框架」：负责任务调度、并发、缓存等
  • 一部分是「DSL（领域特定语言）」：让你用更结构化的方式描述复杂的 LLM 应用

适用场景：

  • 一个请求里需要多步调用模型，例如：分析 → 调用工具 → 再总结
  • 需要在服务端控制 Prompt 编排，而不是在客户端硬编码
  • 想在一个系统里统一管理多个模型、多个任务流

如何选择？

如果只是做一个简单的聊天机器人或补全接口，可以粗略这样选：

  • 只需要单模型、高吞吐、OpenAI 风格接口 → 优先考虑 vLLM
  • 需要复杂工作流、多模态、多阶段推理 → 可以研究 sglang 或类似框架
  • 已有自己的调度/工作流系统 → 用 vLLM 提供基础推理能力，在上层自己编排

当然，很多团队会组合使用：底层用 vLLM 提供推理服务，外面再套一层自定义的编排框架或 sglang。

本地玩一玩可以做什么？

如果只是想在一块或几块 GPU 上本地体验：

  • vLLM：
    • 跑起一个开源大模型（如 Qwen、LLaMA 等）的高吞吐聊天接口
    • 用 OpenAI SDK 写一个本地 chat CLI 或 Web 聊天界面
  • sglang：
    • 搭一个小型「智能助手」，请求链路里包含检索、工具调用等多步
    • 试着把「Prompt + 调用逻辑」都写成可读性更强的脚本，方便复用和迭代

总结

  • 推理框架的核心价值：把大模型变成真正可用、可扩展、可维护的在线服务
  • vLLM 更偏向底层推理性能优化，适合做统一推理后端
  • sglang 更偏向应用层编排和多模态/复杂工作流