关键参数对照
主线位置：启动参数，作用在「一个请求的一生」的调度、KV 块分配、前向几段。参数解析在两个引擎里都是 Python：vLLM 的字段在
vllm/config/，命令行由vllm/engine/arg_utils.py生成；SGLang 的字段在python/sglang/srt/arg_groups/fields/，解析钩子在同目录的*_hook.py。打开 Rust 前端后，前端自己的参数另算（见两种 Rust 前端），下表这些仍由 Python 引擎读。
版本：vLLM v0.32.0、SGLang v0.5.22
结论：
- 名字相近的参数不一定同义。最要紧的一对：vLLM
--gpu-memory-utilization管整个引擎，SGLang--mem-fraction-static只管权重加 KV（显存预算）。 - 两边很多参数的默认值是
None，意思是「启动时按显存、模型或其他参数推出来」。表里的「默认」写的是推出来的结果和推导它的位置，不是字段上的None。 - 默认值对 24 GB 卡、单卡、8B 生成模型、CUDA 而言。换卡型或模型，分档的那几行会变。
flowchart LR
cli["命令行参数"] --> field["配置字段<br/>默认常为 None"]
field --> hook{"启动时推导"}
hook -->|"按显存分档"| mem["预算、分块、并发"]
hook -->|"按模型能力"| cap["分块开关、前缀缓存"]
hook -->|"按 profile / 公式"| kv["KV 池大小"]
mem --> eff["生效值<br/>（启动日志里打印）"]
cap --> eff
kv --> eff
显存与长度
| 作用 | vLLM | 默认 | SGLang | 默认 |
|---|---|---|---|---|
| 显存比例 | --gpu-memory-utilization：引擎总预算 / 总显存 | 0.92（cache.py#L102） | --mem-fraction-static：(权重 + KV) / 总显存 | None → 按公式推，24 GiB 卡约 0.704（schedule.py#L27、memory_hook.py#L283） |
| 直接给 KV 大小 | --kv-cache-memory-bytes（字节）；--num-gpu-blocks-override（块数，测试用） | 都是 None（cache.py#L257、#L135） | --max-total-tokens（token 数） | None（schedule.py#L39） |
| 最大长度 | --max-model-len；-1 表示按 KV 自动缩 | None → 模型 config.json 推出的长度（model.py#L245、#L2624） | --context-length | None → config.json（model.py#L104）；单请求实际上限再和 KV 池取小（tp_worker.py#L549） |
| 权重精度 | --dtype | auto（model.py#L196） | --dtype | auto（model.py#L154） |
| KV 精度 | --kv-cache-dtype | auto，跟模型精度（cache.py#L122） | --kv-cache-dtype | auto（model.py#L191） |
两点补充：
- vLLM 的
--max-model-len大于模型配置推出的长度时直接报错，除非设VLLM_ALLOW_LONG_MAX_MODEL_LEN=1（model.py#L2662）。 - KV 精度的可选值、FP8 的 scale 存在哪，见 KV 量化。
并发与每步 token
| 作用 | vLLM | 默认 | SGLang | 默认 |
|---|---|---|---|---|
| 运行中请求上限 | --max-num-seqs | None → 按显存与入口分档，24 GB 卡起 OpenAI 服务 256（get_batch_defaults） | --max-running-requests | None → 按 KV 池推，2048 到 4096 之间且不超过 KV token 数的一半（schedule.py#L31、resolve_max_num_reqs） |
| 每步 token 上限 | --max-num-batched-tokens（解码和预填充共用） | None → 同上分档，24 GB 卡 OpenAI 服务 2048 | --max-prefill-tokens（一个预填充批的输入上限） | 16384（schedule.py#L67） |
| 吞吐模式 | --performance-mode throughput：没手设的上面两项翻倍 | balanced（vllm.py#L433，翻倍在 arg_utils.py#L3129） | 无对应 | — |
vLLM 启动时还会检查：关了分块预填充时 max_num_batched_tokens 不能小于 max_model_len；任何时候不能小于 max_num_seqs（scheduler.py#L314）。
调度
| 作用 | vLLM | 默认 | SGLang | 默认 |
|---|---|---|---|---|
| 分块预填充 | --enable-chunked-prefill / --no-enable-chunked-prefill | None → 模型支持就开，生成模型都支持（arg_utils.py#L2993） | --chunked-prefill-size；-1 关 | None → 按显存分档，24 GB 卡 4096（schedule.py#L52、memory_hook.py#L101） |
| 长 prompt 单步上限 / 混批 | --long-prefill-token-threshold | 0，不限（scheduler.py#L79） | --enable-mixed-chunk：解码搭进预填充批 | False（schedule.py#L202） |
| 队列顺序 | --scheduling-policy：fcfs、priority | fcfs（scheduler.py#L159） | --schedule-policy：fcfs、lpm 等九种 | fcfs（schedule.py#L82） |
| 优先级 | 同上取 priority | — | --enable-priority-scheduling | False（schedule.py#L99） |
| 收请求的保守程度 | 无对应 | — | --schedule-conservativeness：乘到 new_token_ratio 初值上 | 1.0（schedule.py#L135） |
两边「分块」的意思不同：vLLM 是一个 token 预算统一分给解码和预填充块；SGLang 是预填充批里预填充 token 的上限，默认不和解码混。见连续批处理和分块预填充。
前缀缓存
| 作用 | vLLM | 默认 | SGLang | 默认 |
|---|---|---|---|---|
| 开关 | --enable-prefix-caching / --no-enable-prefix-caching | None → 模型支持就开，decoder 生成模型支持（arg_utils.py#L3021、model.py#L2221） | --disable-radix-cache | False，即开；可被解析钩子改写（memory.py#L64） |
| 哈希算法 | --prefix-caching-hash-algo | sha256（cache.py#L143） | 无，树的键就是 token | — |
--no-enable-prefix-caching 这种写法来自 argparse.BooleanOptionalAction，vLLM 对布尔字段统一这样生成（arg_utils.py#L380）。SGLang 的前缀树有若干模型和后端会自动关掉，命中机制见前缀缓存。
并行、量化、投机解码
| 作用 | vLLM | 默认 | SGLang | 默认 |
|---|---|---|---|---|
| 张量并行 | --tensor-parallel-size / -tp | 1（parallel.py#L141） | --tp-size / --tensor-parallel-size | 1（parallel.py#L45） |
| 权重量化 | --quantization / -q | None → 读模型配置里的量化信息（model.py#L260） | --quantization | None，可解析（model.py#L171） |
| 投机解码入口 | --speculative-config / -sc：一个 JSON，method 选 ngram、eagle、eagle3、medusa 等 | None，不开（arg_utils.py#L714、method 字段 speculative.py#L399） | --speculative-algorithm：EAGLE、EAGLE3、NGRAM、STANDALONE 等，配套 --speculative-* 一组参数 | None，不开（spec.py#L31） |
两边的投机解码入口形状不同：vLLM 把草稿模型、步数等都放进一个 JSON；SGLang 是一组平铺的命令行参数。机制和接受率在 04 部分；效果待实测（C3-5）。张量并行的通信量在 05 部分；多卡数字待实测（C3-7）。
文本与请求
| 作用 | vLLM | 默认 | SGLang | 默认 |
|---|---|---|---|---|
| 聊天模板 | --chat-template（文件或字符串） | None → 依次找处理器、分词器自带的模板，再找内置兜底（cli_args.py#L86、hf.py#L272） | --chat-template | None → 用分词器自带的（serving.py#L170） |
| 自定义模型代码 | --trust-remote-code | False（model.py#L193） | --trust-remote-code | False（model.py#L100） |
| 超长输入截断 | 无服务端开关；请求里的 truncate_prompt_tokens | None，不截（protocol.py#L285） | --allow-auto-truncate | False，超长报错（serving.py#L248） |
怎么确认生效值
字段上的默认值和最终生效值常常不同，以启动日志为准：
- vLLM：
Chunked prefill is enabled with max_num_batched_tokens=…（scheduler.py#L306）；Available KV cache memory: … GiB；GPU KV cache size: … tokens, Maximum concurrency for … tokens per request: …。 - SGLang：
max_total_num_tokens=…, chunked_prefill_size=…, max_prefill_tokens=…, max_running_requests=…, context_len=…（scheduler.py#L1234）。
小结
- 显存：vLLM
--gpu-memory-utilization0.92 管整个引擎；SGLang--mem-fraction-static默认按公式推，只管权重加 KV。两边都能绕过比例直接给 KV 大小。 - 长度和并发：vLLM 的
--max-model-len、--max-num-seqs、--max-num-batched-tokens默认都按模型或显存推出，24 GB 卡起服务是模型长度、256、2048；SGLang 的--context-length跟模型，--max-running-requests按 KV 池推，--chunked-prefill-size24 GB 卡 4096。 - 开关类：两边的前缀缓存默认开、调度默认
fcfs、TP 默认 1、KV 精度默认跟模型、量化默认读模型配置、投机解码默认关。SGLang 的混批默认关。 - 默认是
None的参数，以启动日志打印的值为准。
💬 关联讨论
发起讨论加载中...