vLLM 与 SGLang 的参数是对称设计的，差异只有四个字段
本文的参数名与默认值全部来自
hiyouga/LlamaFactory仓库src/llamafactory/hparams/下的源码，核对日 2026-08-09。我们没有安装、训练或部署过任何模型，也没有跑过任何一个推理后端。
把 src/llamafactory/hparams/model_args.py 里 vLLM 那一组和 SGLang 那一组字段并排放一起，会看到一件挺省心的事：它们是照着同一个模子长出来的。最大长度都是 4096，显存占用比例都是 0.7，都留了一个默认 None 的 *_config 口子。真正不成对的字段，两边各两个，一共四个。
这篇不讲两个引擎谁快谁慢——那种数据官方没给，我们也没跑过任何一次推理，不比。这篇只做一件事：把这十个字段的确切名字和源码默认值摆清楚，顺便挑出三处最容易在换后端时踩到的「看起来一样其实不是一回事」。
先确认这些字段住在哪一层
LlamaFactory 把超参按文件切开了。src/llamafactory/hparams/ 目录下有 data_args.py、model_args.py、finetuning_args.py、generating_args.py、evaluation_args.py、training_args.py、megatron_bridge_args.py，加上 parser.py 和 __init__.py——数据、模型、微调、生成、评测、训练、Megatron 桥接各占一个文件。
本文谈的这十个字段全部在 model_args.py 里，跟微调那一层（finetuning_args.py）和生成那一层（generating_args.py）不在同一个文件。这个位置信息比看起来重要：后面会看到，跨层有两组词根相同但含义不同的字段，混起来找会浪费时间。
同一个文件里还有一个前置字段：infer_backend，源码默认值是 EngineName.HF。也就是说，默认既不指向 vLLM 也不指向 SGLang。至于这两组带前缀的字段在什么条件下被哪段代码读取、不匹配的前缀会不会被忽略，我们没有读装配逻辑，不做推断，以 llamafactory-cli train -h 的实际输出为准。四个可选后端各自是什么，我们另有一篇专门讲。
对称的三组：名字不同，默认值一模一样
先看成对的部分：
| 维度 | vLLM 侧 | 默认值 | SGLang 侧 | 默认值 |
|---|---|---|---|---|
| 最大长度 | vllm_maxlen | 4096 | sglang_maxlen | 4096 |
| 显存占用比例 | vllm_gpu_util | 0.7 | sglang_mem_fraction | 0.7 |
| 透传配置 | vllm_config | None | sglang_config | None |
三组里最值得单独记一笔的是中间那行。同样是 0.7，字段名却不同：vLLM 侧叫 vllm_gpu_util，SGLang 侧叫 sglang_mem_fraction。一个用 gpu_util（显存利用率）的说法，一个用 mem_fraction（内存占比）的说法。写 YAML 的时候如果凭着「另一边那个叫什么来着」去补全，很容易把词根记串。真要换后端，最稳的做法就是回 model_args.py 或 -h 输出里对一遍名字，别靠肌肉记忆。
vllm_config 和 sglang_config 默认都是 None，两边各留了这么一个口子。能往里写什么、格式怎么写、它最终被交给引擎的哪一段代码，我们没有读过这部分实现，也没有在事实卡之外核实过，一律以官方文档与 llamafactory-cli train -h 的输出为准。这里只钉住一件事：这两个字段确实存在，默认都是 None。
最后补一句限定：这里对称的是参数表的形状，不是两个引擎的行为。vllm_maxlen 和 sglang_maxlen 默认值都是 4096，只说明这两个字段的 field(default=...) 写的是同一个数，不说明两个引擎对「最大长度」的处理方式相同。我们没有读过任何一侧的实现。
不对称的四个字段
两边各有两个字段在对面找不到位置：
| 只在 vLLM 侧 | 默认值 | 只在 SGLang 侧 | 默认值 |
|---|---|---|---|
vllm_enforce_eager | False | sglang_tp_size | -1 |
vllm_max_lora_rank | 32 | sglang_lora_backend | "triton" |
逐个说，但只说名字和默认值，不解释引擎内部在做什么——那部分我们没读过实现，展开就是编。
vllm_enforce_eager，默认 False。 这是个布尔开关，默认关着。
vllm_max_lora_rank，默认 32。 这是这四个不成对字段里唯一一个正整数默认值，下一节还会再提到它。
sglang_tp_size，默认 -1。 这是本文范围内唯一一个负数默认值。其它字段的默认值要么是布尔、要么是正数、要么是 None 或字符串，只有它是 -1。负数在很多项目里被用作哨兵值，但 LlamaFactory 这里的具体语义我们没有核实，不猜。
sglang_lora_backend，默认 "triton"。 字符串类型，默认是这个值。
有一处结构上的巧合值得记下来：两侧各自那两个独有字段里，各有一个跟 LoRA 有关——vLLM 侧是 vllm_max_lora_rank（一个数字上限），SGLang 侧是 sglang_lora_backend（一个字符串名字）。它们同样带 lora 词根，但一个描述的是数量维度，一个描述的是实现选择，形状完全不同。这是从参数表读出来的客观对照，不是说哪一侧的设计更好。
32 和 8 不是同一回事
这是本篇最容易翻车的一处跨层混淆。
vllm_max_lora_rank 默认 32，住在 model_args.py。而训练侧的 lora_rank 默认是 8，住在 finetuning_args.py——那是另一个文件、另一层参数，examples/train_lora/qwen3_lora_sft.yaml 里写的也是这个默认口径。
两个字段词根相同（都带 lora 和 rank），默认值不同（32 与 8），所属文件不同。它们之间该保持什么关系、你的场景里两个值该怎么填，官方没有给通用值，我们也不推断——这属于要回官方文档和 -h 输出确认的事。这里只把「它们是两个层的两个字段、默认值不一样」这个事实钉住，避免你在 YAML 里改了一个以为另一个跟着变了。
4096 和 1024 也不是同一回事
第二处跨层混淆在生成参数那一层。
vllm_maxlen / sglang_maxlen 默认都是 4096，在 model_args.py。而 generating_args.py 里的 max_length 默认是 1024、max_new_tokens 默认也是 1024。同一个「长度」概念，在两个文件里有三个字段、两个不同的默认量级。
生成那一层还有几个常被凭印象记错的值：do_sample 默认 True、temperature 默认 0.95、top_p 默认 0.7、top_k 默认 50。这几个默认值我们另有一篇专门讲，这里只提一句，是为了说明一件事：带引擎前缀的那组字段定义在 model_args.py，生成参数定义在 generating_args.py，是两份文件、两组独立的默认值。至于运行时两层之间怎么互相取值，我们没有读装配逻辑，不做推断。
同一文件里还有第三组前缀
model_args.py 里跟推理沾边的前缀其实不止两个。KTransformers 那组有六个字段：use_kt（默认 False）、kt_weight_path、kt_expert_checkpoint_path、kt_use_lora_experts、kt_lora_expert_num、kt_lora_expert_intermediate_size（后五个默认都是 None）。
把它跟前两组并排看，形状明显不一样：kt_ 这组没有「maxlen + 显存比例 + config 逃生口」这套三件套，而是以一个 use_* 布尔开关加一串路径与数量字段为主。这是三组参数在表层的结构差异，说到这里为止，不推断为什么这么设计。
另外，推理路径上还有两个不带引擎前缀、但同在 model_args.py 的通用字段：infer_dtype 默认 "auto"，use_kv_cache 默认 True。
换后端时，实际要核对的几件事
如果你已经决定要在这两个后端之间切换，按下面这个顺序核对，比对着参数表逐行猜省事：
- 先确认
infer_backend有没有显式写。 源码默认是EngineName.HF，不是这两个中的任何一个。 - 再确认前缀和词根都写对了。 两组是分开的两套字段名，
vllm_gpu_util在 SGLang 侧对应的字段叫sglang_mem_fraction，不是同一个名字换个前缀。这一条是本文最实用的一句。 - 两个
maxlen都默认 4096，但它跟generating_args.py里的max_length（默认 1024）是两个文件里的两个字段，别把其中一个当成另一个的写法变体。 - 要设的选项如果不在这几个字段里，两边各有一个默认
None的*_config字段，具体写法回各引擎自己的文档确认。 trust_remote_code这类跨训练与推理都会用到的字段另有口径差异（源码默认False，examples/下的示例 YAML 里显式写true），我们另有一篇专门讲这处差异，这里只提醒你在切后端时顺手看一眼自己那份 YAML 写的是哪个。
至于每个值该设成多少：取决于你的模型、数据和硬件，官方没有给通用值，本文也不给。我们能负责的只有「字段叫什么、源码里的默认值是什么」这一层。
这篇没回答的问题
说清楚边界，比多写两段更有用：
- 谁更快、谁更省显存：官方没给这两个后端的对比数据，我们也没有跑过推理，这一维不比。
- 两个 0.7 是不是等价：
vllm_gpu_util和sglang_mem_fraction默认值相同、名字不同，语义是否一一对应要看两个引擎各自的定义，我们没读实现，不下结论。 -1到底代表什么：sglang_tp_size的默认值是-1，含义以官方文档与-h输出为准。- 该选哪个后端：这取决于你的部署环境和已有技术栈，参数表这一层给不出这个答案。
参数与默认值会随版本变动，尤其是这种直接跟着上游引擎走的字段。真要动手前，回 llamafactory-cli train -h 的实际输出对一遍，比抄任何一篇文章（包括这篇）都可靠。
本文依据 LlamaFactory 官方仓库（github.com/hiyouga/LlamaFactory）的 README、data/README.md、examples/ 下的配置与 src/llamafactory/hparams/ 的参数定义整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有安装、训练或部署过任何模型，文中显存数字均为官方标注的估算值（README 原文标 * estimated）而非实测占用。参数与默认值随版本变动，请以 llamafactory-cli train -h 的实际输出为准。安全相关做法请结合自身环境评估，本文不构成安全方案建议。