Day 0 / Day 1 支持表与更新日志：怎么读才不会读成承诺
本文所有事实以
hiyouga/LlamaFactory官方仓库 2026-08-09 的内容为准。我们没有安装、训练或部署过任何模型，文中数字均为仓库文档与源码里写着的值。
README 里最容易被误读的两块内容，一块是 Day 0 / Day 1 支持表，一块是那条长长的更新日志。它们的共同点是：写的都是已经发生过的事，而读的人几乎都会把它当成对未来的承诺，或者当成对「我现在跑得动吗」的回答。
这个误读的代价很具体：你在日志里看到「支持微调 Llama 4」，于是把选型定了、卡也租了，真上手才发现自己要解决的问题一个都没被这行字回答。这篇不讲某个具体功能怎么用，只讲这两块内容该怎么读、读完该去哪儿确认。
Day 0 / Day 1 表记录的是过去
先把表本身抄一遍，它一共只有两行：
| 支持时间 | 模型 |
|---|---|
| Day 0 | Qwen3 / Qwen2.5-VL / Gemma 3 / GLM-4.1V / InternLM 3 / MiniCPM-o-2.6 |
| Day 1 | Llama 3 / GLM-4 / Mistral Small / PaliGemma2 / Llama 4 |
这张表引用起来要带一句「README 自称」，因为它是项目方对自己历史动作的自述，我们没有逐个去核对每个模型当年的时间线。
更要紧的是它的时态。这两行说的是「这些模型发布当天/次日，仓库跟上了」，它是对过去的记录。读成「以后每个新模型都会在 Day 0 跟上」，就是把一份履历读成了 SLA。履历可以作为参考，但它记的是已经发生的事，本身并不构成对后续版本的承诺。
顺带说一句常见的连带误读：Day 0 这一档里出现的模型名，是模型家族的名字。你手上那个具体权重是哪个尺寸、哪个变体、哪个量化版本，这张表一个字都没提。要落到具体权重，得去看模型表和 template 那条线，我们另有专门篇目讲这两件事。
更新日志的三条读法纪律
README 的 changelog 是一串带日期前缀的条目，形如 [25/10/26]，在我们读到的那一段里是从新到旧排列的。摘几条与后端和算法相关的：
- [25/10/26] 支持 Megatron-core 训练后端（通过
mcore_adapter），指向 PR #9237 - [25/08/06] 支持微调 GPT-OSS，指向 PR #8826
- [25/04/21] 支持 Muon 优化器
- [25/03/15] 支持 SGLang 作为推理后端，用
infer_backend: sglang加速推理 - [25/02/11] 导出模型检查点时支持保存 Ollama modelfile
- [24/12/21] 支持用 SwanLab 做实验跟踪与可视化
- [24/10/09] 支持从 Modelers Hub 下载预训练模型与数据集
- [24/08/27] 支持 Liger Kernel，用
enable_liger_kernel: true提效
这些都是 README 更新日志记载的条目。有三条纪律必须先立住：
第一，它记的是「什么时候加进来的」，不是「现在是什么状态」。 一条日期为 24 年 8 月的条目，只说明那个时间点有这么一次加入。这个功能今天是否仍然按同样方式工作、有没有出现过回归、在你那个依赖组合下是否可用，日志一律没说，我们也不据此推断。
第二，条目里带的 PR 号是线索，不是结论。 PR #9237、PR #8826 这类编号的用处是让你能去仓库里翻当时的改动范围。它回答的是「这次改了哪些文件」，不回答「我该怎么配」。
第三，「支持」是个覆盖面很窄的词。 下一节专门拆它。
把一条日志落到可核查的锚点上
日志条目真正的用法，是把它当成一个索引：拿着条目里的关键词，去仓库里找到对应的字段名、取值枚举或环境变量，那才是决定行为的地方。举四个能一路对上的例子。
SGLang 那条（25/03/15）落到一个枚举上。 examples/inference/qwen3_lora_sft.yaml 里的注释写明了 infer_backend 的可选值：
infer_backend: huggingface # choices: [huggingface, vllm, sglang, ktransformers]
对应到 src/llamafactory/hparams/model_args.py，infer_backend 的默认值是 EngineName.HF。这一组信息比日志那行有用得多：它同时告诉你这个字段叫什么、有几个合法值、以及不写它的时候走哪一个。日志说「支持 SGLang」，配置说「你得自己把它切过去」，两句话缺一不可。
Liger Kernel 那条（24/08/27）在日志里就自带了字段名——enable_liger_kernel: true。这是最省事的一类条目，条目本身已经给出了可搜索的锚点。
Megatron-core 那条（25/10/26）在启动器里留了痕迹。 src/llamafactory/launcher.py 的 launch() 里有一段判断：只要 USE_MCA 或 USE_MEGATRON_BRIDGE 任一被启用，就强制 FORCE_TORCHRUN=1，代码里的原文注释是 # force use torchrun。也就是说，这条日志描述的能力不只是「多了一个后端选项」，它还改变了启动路径。这类连带影响，日志那一行是不会写的，只有源码会说。
Modelers Hub 那条（24/10/09）落到一个环境变量上，而且这是本站读者最容易踩到平台差异的地方。README 给的写法在两个平台上不一样：
# Linux / macOS
export USE_OPENMIND_HUB=1
:: Windows
set USE_OPENMIND_HUB=1
model ID 示例是 TeleAI/TeleChat-7B-pt。同一套写法还适用于 ModelScope Hub，变量换成 USE_MODELSCOPE_HUB=1（README 同样给了 set USE_MODELSCOPE_HUB=1 的 Windows 写法）。两行不能互换：cmd 里没有 export 这个命令，Windows 侧必须用 set 那一行。
至于 SwanLab 那条（24/12/21）对应的 report_to 有哪五个取值、finetuning_args.py 里 SwanLab 相关字段有几个，我们另有一篇专门讲，这里不展开。
「支持」这个词覆盖不到的三件事
日志写了「支持微调某模型」，这句话不包含以下三件事，而它们恰恰是决定你能不能开工的因素。
第一件是硬件。 README 的 Hardware Requirement 表里，7B 这一列上，Full（bf16 或 fp16，32）标 120GB，QLoRA / QOFT（4）标 6GB。这两格摆在一起，说明同一个「支持」在不同方法下的资源量级完全不是一回事。
必须带上的限定是：这张表在表头上方被 README 自己标了 * estimated（估算），它不是实测占用，我们也没有跑过任何一次训练。所以这里只陈述表里写的数字，不推导「你那张卡够不够」——那个结论需要实测，而我们没有。
第二件是依赖。 Requirement 表里 python 那一行写的是 Minimum 3.11、Recommend >=3.11，下限就是 3.11。日志里任何一条「支持 X」都默认你已经站在这条基线上了。README 还用 > [!IMPORTANT] 强调了一句 Installation is mandatory.
第三件是文档。 官方文档页 https://llamafactory.readthedocs.io/en/latest/ 在 README 里被标了 (WIP)。这个标注是项目方自己写的，我们不据此推断文档完成到什么程度；能落到实处的做法只有一条：日志、文档、示例 YAML、--help 输出四处不一致时，以仓库里的示例 YAML 和 --help 的实际输出为准，因为后两者跟你本机装的那个版本是同一份代码。
仓库当前状态才是终审
有三处可核实的现象，能让你对「以日志为准」这个习惯保持警惕。
其一，仓库里同时存在旧实现与一套 v1/ 重写。src/llamafactory/cli.py 的全部逻辑就是一个分支：环境变量 USE_V1 被启用时加载 llamafactory.v1.launcher，否则加载 llamafactory.launcher。仓库里另有与之配套的 tests_v1/ 和 examples/v1/。我们只核实了这个开关和目录的存在，v1 的完成度、稳定性、是否推荐使用，我们一概没有依据，也不推断。你需要知道的只有一点：同一个仓库里可能有不止一条代码路径，日志描述的是哪一条，日志本身不一定会说。
其二，仓库内部新旧名并存。launcher.py 构造的欢迎横幅里，项目主页写的仍是带连字符的旧名 https://github.com/hiyouga/LLaMA-Factory，而仓库当前的真实路径是 hiyouga/LlamaFactory，README 正文里两种写法也都出现。这是仓库里能核实到的差异，说到这儿就够了，改名时间、原因、有没有重定向我们都没核实，不做推断。对你的实际影响是搜资料时两种拼法都试一遍。
其三，显存表内部也有一处对不上的格子：2-bit 那一行的 70B 标的是 24GB，而通用列给的系数是 x/4，按 70 算得 17.5GB，两者不一致。这同样只陈述差异，不推断哪个数是「对的」。
一套可执行的读法
把上面几节收成三步，下次再看到一条日志时照着走：
- 在 README 的日志里定位条目，记下关键词和 PR 号。 这一步只解决「这件事存在过」。
- 拿关键词去
examples/下的 YAML 与src/llamafactory/hparams/下的参数定义里找对应字段。 找到字段名、取值枚举和默认值，才算知道它怎么开。找不到字段的，说明这条日志描述的可能是内部改动或另有入口，别硬猜。 - 回到本机环境确认。
llamafactory-cli的 USAGE 里列了env（show environment info）和version（show version info）两个子命令，train -h一类的帮助输出是参数的最终口径。顺带一提，USAGE 的 Hint 行里写了lmf是llamafactory-cli的官方短别名；launcher.py的命令解析是command = sys.argv.pop(1) if len(sys.argv) > 1 else "help"，不带任何参数时默认走help。
什么情况说明问题不出在「你读错了日志」？如果你已经在 examples/ 里找到了对应字段、取值也照抄了官方枚举、env 输出的依赖版本也在 Requirement 表的下限之上，那这次的障碍就跟日志无关了，该去 FAQ 和 issue 区找同样的报错，而不是回头反复读那一行「支持 X」。README 的 TIP 也是这么说的：遇到问题先读 FAQ（https://github.com/hiyouga/LlamaFactory/issues/4614）。
日志和支持表都是好东西，它们让你知道这个项目在往哪个方向长。只是它们回答的是「发生过什么」，而你上手时要问的是「现在的代码怎么跑」——这两个问题之间，隔着 examples/、hparams/ 和一次 -h。
本文依据 LlamaFactory 官方仓库（github.com/hiyouga/LlamaFactory）的 README、data/README.md、examples/ 下的配置与 src/llamafactory/hparams/ 的参数定义整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有安装、训练或部署过任何模型，文中显存数字均为官方标注的估算值（README 原文标 * estimated）而非实测占用。参数与默认值随版本变动，请以 llamafactory-cli train -h 的实际输出为准。