Agent Notes

推理优化 · 推理框架选型 ​

用真实负载比较 vLLM、SGLang、TensorRT-LLM 与 Ollama。场景表和口条看全量笔记。

0. 总图 ​

先问请求长什么样，不要先比某一张 tokens/s 表。

text
有没有公共前缀？要不要硬 JSON？
        │
        ├─ 单轮、散问、要对齐 OpenAI → vLLM
        ├─ 多轮 / 同模板 / 约束解码 → SGLang
        ├─ 固定模型、极致单卡延迟 → TensorRT-LLM（编译图，换模型成本高）
        └─ 本机试用、单用户 → Ollama（不是生产吞吐框架）

四层优化（分页、持续批、推测、PD）是能力，不是品牌。vLLM 前两层默认就有；SGLang 把前缀树和约束解码当一等公民；TRT-LLM 吃编译和固定形状；Ollama 吃易用。

先问这几个问题 ​

  1. 请求有没有公共前缀 — 多轮客服、同一 system prompt、批量同模板。没有前缀，Radix / prefix cache 赚不到。
  2. 输出是不是必须合法 — 工具参数、JSON schema。Prompt + 后校验会漏；约束解码是硬限制。
  3. 能不能接受换引擎的迁移 — 已经跑着 vLLM、流量又散又短，不必只因为对比表就迁。
  4. 上线后 cache_hit_rate — 接近 0，换 SGLang 也没用。

怎么选 ​

场景倾向理由
简单问答、单轮vLLM缓存价值小，生态和 OpenAI 兼容更熟；要 EAGLE 也先它
多轮、客服SGLang历史前缀反复出现，Radix 才有命中可赚
批量、同一模板刷数据SGLang共享前缀，少重复 Prefill；收益必须压测
严格 JSON、Agent 工具参数SGLang原生约束解码
固定模型、要抠单卡延迟TensorRT-LLM编译优化；模型一换要重编
笔记本 / 演示Ollama安装快，不是高并发方案

两者都能出 /v1。不要说成「SGLang 一定更快」：短、散、没有共享前缀的请求，PagedAttention + Continuous Batching 已经够。vLLM 后来也有 prefix caching，差距主要在树是不是一等公民、约束解码是不是原生。

口条：没前缀用 vLLM，有前缀或要硬 JSON 用 SGLang。

和另外几层怎么叠 ​

选型之后才谈叠层：

  • 无论谁，生产几乎都要分页 + 持续批。
  • 推测解码看 Decode 是否 Memory-Bound，见推测解码。
  • PD 分离是流量和长 prompt 上来之后的部署形态，见 PD 分离。
  • 指标和压测方法见性能指标与诊断。

深入 ​