LlamaFactory 生成参数默认值：`temperature` 是 0.95、`top_p` 是 0.7，不是你以为的那组
本文事实以
hiyouga/LlamaFactory官方仓库 2026-08-09 的内容为准。我们没有安装、训练或部署过任何模型，文中所有默认值都是从源码的field(default=...)里读出来的。
如果你现在闭着眼睛报一组”常见的生成默认值”，多半会报出温度 0.7、top_p 0.9 这一对。LlamaFactory 的源码里不是这么写的：temperature 默认 0.95，top_p 默认 0.7。这两个数字都在，但一个变大了、一个挪了位置。
这篇不讨论这组值好不好、该不该改——那是你的数据和硬件说了算，官方也没给通用推荐值。这篇只干一件事：把这一层默认值钉死在文件和字段上，让你下次写文档、复现别人的结果、或者被同事问”你那边温度是多少”的时候，有一个可以指过去的出处。
先把出处钉死
这一组参数写在 src/llamafactory/hparams/generating_args.py。
这个路径本身就是信息。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。也就是说，“生成时怎么解码”和”模型怎么加载""数据怎么切”是分开的三摊事，各有各的文件、各有各的默认值。
顺带说明一句边界：parser.py、training_args.py、megatron_bridge_args.py 这三个文件我们没有抽取其中的字段，本文不会描述它们里面有什么参数。这里只用得上”仓库按这几个维度分了文件”这一层结构事实。
十个字段的默认值
generating_args.py 这一层一共十个字段，全表如下（都是源码 field(default=...) 的实读值）：
| 参数 | 默认值 |
|---|---|
do_sample | True |
temperature | 0.95 |
top_p | 0.7 |
top_k | 50 |
num_beams | 1 |
max_length | 1024 |
max_new_tokens | 1024 |
repetition_penalty | 1.0 |
length_penalty | 1.0 |
skip_special_tokens | True |
需要说清楚的是这张表的性质：它是这个仓库里这一层的默认值，不是”业界通行值”，也不是”最佳值”。至于每个字段在解码过程中具体怎么起作用，那是生成接口的通用语义，请以相应的官方文档为准，本文不在这一层展开——我们能负责的只是”仓库里写的是多少”。
那两个被记错的数字
回到标题上的这一对。
temperature 的源码默认是 0.95，top_p 的源码默认是 0.7。凭印象记的那组”0.7 / 0.9”，在这里一个都对不上：0.7 确实出现了，但它挂在 top_p 上，不是 temperature。这就是这类误记最麻烦的地方——不是完全没见过这个数字，而是记得数字、记错了字段。
必须守住的两条边：
第一，不推断为什么这样设。 我们只读到了默认值，没有读到任何解释这组取值的设计说明。所以本文不会告诉你”作者是为了 XX 才把温度调到 0.95”。
第二，不给推荐值。 你的场景该用多少，取决于你的模型、你的数据分布和你的评估口径，官方没有给出通用建议，我们也没有跑过任何一次生成。这篇能给你的增量只有一句：别按记忆填，按你实际在用的那个版本的源码或 -h 输出填。
如果你在写实验记录或者论文附录，这条边界尤其重要。写”使用默认生成参数”而不写具体数值，读者半年后拿另一个版本复现，很可能对不上；写死了数值又不标版本，同样对不上。稳妥的写法是把版本和数值一起写。
这类误记难被发现的原因在于它出在”人这一侧”：字段名你没写错，写错的是你脑子里给这个字段配的那个数。程序拿到的是合法字段和合法取值，你自己以为的那组值和实际生效的那组值悄悄错开，而这个错开不体现在任何配置文本上。运行时会不会给出提示，我们没有核过 LlamaFactory 的参数解析行为，不做断言。所以对这一层的核对，能给出的办法只有”每次都回源码看一眼”这一种笨办法。
别把三个 0.7 混在一起
这是本篇最值得记的一个坑：LlamaFactory 里有不止一个 0.7，它们分属不同的文件、不同的层，含义互不相干。
top_p：0.7，在src/llamafactory/hparams/generating_args.py，属于生成/解码这一层vllm_gpu_util：0.7，在src/llamafactory/hparams/model_args.py，属于推理后端这一层sglang_mem_fraction：0.7，同样在model_args.py，是 SGLang 侧与上一条对应的那个字段
后两个属于”推理后端怎么占资源”的范畴，和采样没有关系；vLLM 与 SGLang 这两套后端参数之间的对称关系，我们另有一篇专门讲，这里只借用这三行来说明一件事：在这个仓库里，看到一个数字先看它写在哪个文件的哪个字段上，同一个 0.7 换个字段就是另一回事。
翻别人贴的 YAML 配置片段时这个习惯特别管用。配置文件是扁平的，top_p: 0.7 和 vllm_gpu_util: 0.7 挨在一起也毫无违和感，但它们回到源码里是两个 dataclass。同理，在 issue 或者群聊里看到一句”我这边是 0.7”，先问清是哪个字段再往下聊，否则两个人能对着两件事讨论半天。
表里还有几处”同值不同名”
除了 0.7，这张表内部也有几组值相同、名字不同的字段，读表时容易并成一个印象：
两个 1024。 max_length 默认 1024，max_new_tokens 默认 1024。这是两个独立的字段，只是默认值恰好相同。它们同时存在时最终以哪个为准，属于代码内部的处理逻辑，我们没有把这段逻辑写进事实核对范围，因此这里不做断言——请以官方文档和 llamafactory-cli train -h 的实际输出为准。
两个 1.0。 repetition_penalty 与 length_penalty 默认都是 1.0。同样是两个字段。
两个 True。 do_sample 默认 True，skip_special_tokens 默认 True。这两个布尔一个在解码策略侧、一个在输出处理侧。
一个 1。 num_beams 默认 1。
把这四组分开记，比记”这张表里有一堆 1024 和 1.0”要可靠得多。
顺手提一句另一层的默认值
同样是”默认值不一定是你以为的那组”，evaluation_args.py 那一层也有几个值得先看一眼的：评测默认是 5-shot（n_shot 默认 5）、随机种子默认 42、默认语言 lang 是 "en"。评测这几个参数我们另有一篇专门讲，此处不展开，只是提醒你：生成这一层的默认值管不到评测那一层，两个文件各写各的。
遇到默认值该怎么核
给一套可执行的动作，替代”凭印象”：
- 先定位层。 你要找的这个参数是解码相关（
generating_args.py）、模型加载与后端相关（model_args.py），还是训练方法相关（finetuning_args.py）？找错文件就会找到一个同名不同层的东西。 - 读
field(default=...)。 这是默认值唯一可靠的出处，比任何博客、任何记忆、任何截图都可靠。 - 跑一次
-h交叉验证。 官方给的口径是以llamafactory-cli train -h的实际输出为准；你手上装的是哪个版本，输出就是那个版本的答案。 - 写下来的时候带上版本。 参数与默认值随版本变动，只写数值不写版本，等于把坑留给下一个人。
- 区分”没显式写”和”等于默认”。 你的 YAML 里没写
temperature，不代表它一定等于0.95——中间还有配置合并、后端差异这些环节，本文没有核过这些环节的行为，不做保证。
最后再说一遍这篇的立场：我们能确认的是”仓库里写的是 temperature: 0.95、top_p: 0.7”，不能确认的是”你应该用多少”。后半句没有通用答案，官方也没给。
本文依据 LlamaFactory 官方仓库（github.com/hiyouga/LlamaFactory）的 README、data/README.md、examples/ 下的配置与 src/llamafactory/hparams/ 的参数定义整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有安装、训练或部署过任何模型，文中显存数字均为官方标注的估算值（README 原文标 * estimated）而非实测占用。参数与默认值随版本变动，请以 llamafactory-cli train -h 的实际输出为准。