为什么要横向对照
推理框架的差异集中在三处：调度方式（怎样把多个请求塞进同一批）、显存管理（KV 缓存怎么分配与复用）、生态位置（支持哪些权重格式与硬件）。vLLM、SGLang、TGI 面向服务端吞吐，Ollama 与 llama.cpp 面向单机与边缘。对照表的作用是快速缩小候选范围，最终选型仍要在目标硬件上实测。
框架对照（定性）
| 框架 | 定位 | 典型场景 |
|---|---|---|
| vLLM | GPU 服务端高吞吐引擎 | 在线 API、高并发对话、批量离线推理 |
| SGLang | 服务端引擎，前缀缓存优化突出 | 多轮对话、大量共享系统提示的场景 |
| TGI | Hugging Face 生态的服务端引擎 | 标准 Transformers 权重快速服务化 |
| Ollama | 单机模型运行与轻量接口 | 开发调试、个人工作站、内网小规模使用 |
| llama.cpp | CPU 与消费级显卡推理 | 边缘设备、桌面端、GGUF 量化部署 |
| LMDeploy | 国产模型与量化工具链较全 | AWQ 权重服务化、离线批处理 |
调度机制差异
| 机制 | 影响与取舍 |
|---|---|
| 连续批处理 | 请求随到随入批，吞吐高；批越大首 token 延迟越高 |
| 分页式 KV 管理 | 显存碎片小、可复用；实现复杂度高，是服务端引擎的标配 |
| 前缀缓存复用 | 共享前缀的请求省去重复预填充，多轮对话收益明显 |
| 单机按需加载 | 启动简单、显存占用可控；并发一上去就排队 |
两条验证路径
两条验证路径
# 服务端候选：先跑通 OpenAI 兼容接口再谈吞吐
vllm serve /models/Qwen --max-model-len 8192
curl http://127.0.0.1:8000/v1/models
# 单机候选：用命令行快速验证模型效果与量化档位
ollama run qwen2.5:7b
# 边缘候选：llama.cpp 用同一份 GGUF 对比不同量化档位
./build/bin/llama-bench -m model-q4_k_m.gguf对比时必须统一的变量
- 同一份权重与同一量化档位：不同量化档位之间的吞吐对比没有意义
- 同样的上下文长度与输出长度：长上下文下 KV 压力会改变排名
- 同样的并发梯度：从 1 到目标并发逐级测，找出开始排队的那一档
- 同样的硬件与驱动版本：换卡或换驱动后要重测，历史数据不能直接沿用
- 统一延迟口径：首 token 延迟与单 token 输出时间分开统计，混在一起无法归因
对照只做方向性筛选：宣传口径与实际差距最大的是「最大并发」这类数字，它依赖上下文长度与输出长度假设，必须换成自己的业务形状再测。
不要在一套基准上混跑多个引擎：同一台机器上先后安装多套框架容易互相污染依赖，压测机与生产机的依赖版本要对齐。
容易被忽略的对比维度是可观测性：是否暴露 KV 水位与排队请求数、日志能否按请求编号串起来，直接决定故障时能不能快速定位。
向厂商或社区提的问题
- 目标模型架构是否在支持列表内：注意力变体、MoE 与多模态往往支持进度不同
- 量化格式是否匹配手上的权重：AWQ、GPTQ、FP8、GGUF 各家支持程度不一样
- 多卡方案怎么做：张量并行、流水并行的支持情况与通信开销
- 有没有容量观测指标：KV 水位、排队请求数这类指标决定能否做容量规划
- 升级路径是否清晰：大版本之间的参数与接口变动幅度，决定运维成本