GaLore 与 APOLLO 的参数表对照：同 rank 同间隔，scale 差 16 倍

2026-08-09

本文所有事实以 hiyouga/LlamaFactory 官方仓库 2026-08-09 的内容为准。文中默认值均从 src/llamafactory/hparams/finetuning_args.py 的 field(default=...) 实读抽取。我们没有安装、训练或部署过任何模型，也没有读过 GaLore 与 APOLLO 的算法实现。

这篇文章只做一件很窄的事：把 LlamaFactory 里 use_galore 和 use_apollo 这两组字段的默认值并排摆出来，看它们在参数表这一层长得像不像。结论先说：rank 都是 16、update_interval 都是 200、target 都是 "all"，唯独 scale 一个写 2.0、一个写 32.0，差 16 倍；此外 APOLLO 侧比 GaLore 侧多出三个字段。

先把边界立在前面，因为这个题目太容易滑向”所以哪个更好”。

这篇不做什么

不解释算法原理。 GaLore 和 APOLLO 在本文里只当”参数前缀的名字”用。我们没有读过它们在这个仓库里的实现，也没有读过对应的原始论文，所以关于它们各自在数学上做了什么、怎么收敛、省不省显存，本文一个字都不会写。

不做优劣判断。 两组默认值摆在一起是参数表层面的客观对照，不是算法优劣的排序依据。参数多不等于更强，参数少也不等于更简洁。

不给调参建议。 你会在下文看到一堆具体数字，但你不会看到”建议把 galore_rank 调到多少”这种句子。该调成多少取决于你的模型、数据和硬件，官方没有给通用值，我们也没有跑过任何一次训练。

不给显存和速度数字。 我们没有在本机跑过任何一次训练。仓库 README 里那张硬件需求表原文标了 * estimated（估算），那是另一篇的题目，这里不引用它来给这两个算法背书。

两组字段原样摆出

先看 GaLore 侧，一共 7 个字段：

参数	默认值
`use_galore`	`False`
`galore_target`	`"all"`
`galore_rank`	`16`
`galore_update_interval`	`200`
`galore_scale`	`2.0`
`galore_proj_type`	`"std"`
`galore_layerwise`	`False`

再看 APOLLO 侧，一共 10 个字段：

参数	默认值
`use_apollo`	`False`
`apollo_target`	`"all"`
`apollo_rank`	`16`
`apollo_update_interval`	`200`
`apollo_scale`	`32.0`
`apollo_proj`	`"random"`
`apollo_proj_type`	`"std"`
`apollo_scale_type`	`"channel"`
`apollo_layerwise`	`False`
`apollo_scale_front`	`False`

这两张表就是本文的全部原始数据，剩下的篇幅都用来说明怎么读它们。

五处完全对得上的地方

把前缀去掉之后，两边有五个后缀是同名的，而且默认值也一模一样；再加上一组名字不同但职责对应的启用开关：

启用开关（名字不同名，但一一对应）：use_galore 与 use_apollo 都默认 False；
作用范围：galore_target 与 apollo_target 都默认 "all"；
rank：galore_rank 与 apollo_rank 都默认 16；
更新间隔：galore_update_interval 与 apollo_update_interval 都默认 200；
投影类型：galore_proj_type 与 apollo_proj_type 都默认 "std"；
逐层开关：galore_layerwise 与 apollo_layerwise 都默认 False。

（所以列表是六行：五组同名后缀的配置项，加一组各带自己名字的启用开关。）

对写配置的人来说，这种命名和默认值上的对称有一个很实际的好处：你把一份配置从一个前缀换成另一个前缀时，大部分字段名只需要改前缀，默认值不用重新查。但这只是拼写层面的省事，不代表两边的同名字段在实现里是同一件事。 我们没有读过实现，所以只能说到”名字和默认值一样”这个程度。

唯一一处显眼的差异：`scale`

galore_scale 默认 2.0，apollo_scale 默认 32.0。32.0 ÷ 2.0 = 16，这就是标题里那个 16 倍的来处。

这个比值需要三条限定，缺一条就会读歪：

第一，这是两个默认值的算术比，不是效果的比。 它不说明 APOLLO 的什么东西”强 16 倍”，也不说明谁的缩放”更激进”。

第二，同一个后缀不代表同一个量纲。 galore_scale 和 apollo_scale 只是两个恰好都叫 scale 的浮点字段，我们没有读过实现，不知道它们各自在代码里怎么被使用。把它们放在同一个坐标轴上比大小，前提是知道它们量纲一致，而这个前提我们没有验证过。

第三，APOLLO 侧还有两个名字里带 scale 的字段，apollo_scale_type（默认 "channel"）和 apollo_scale_front（默认 False），GaLore 侧没有同类命名的字段。这三个字段之间在实现里是什么关系，我们没有读过代码，说不了；但至少在参数表这一层，APOLLO 一侧的 scale 是和另外两个同族命名的字段一起出现的，孤立地拿 32.0 和 2.0 比，摆在眼前的字段就没数全。

所以这一节最诚实的写法是：参数表上有一处 16 倍的数值差异，值得你在填配置时注意别照抄错，但它不足以支撑任何关于算法行为的结论。

APOLLO 多出来的三个字段

GaLore 有 7 个字段，APOLLO 有 10 个，多出来的正好三个：

参数	默认值
`apollo_proj`	`"random"`
`apollo_scale_type`	`"channel"`
`apollo_scale_front`	`False`

注意 apollo_proj 和 apollo_proj_type 是两个不同的字段，前者默认 "random"，后者默认 "std"，而 GaLore 侧只有 galore_proj_type（默认 "std"）这一个。写配置的时候这两个名字长得很像，容易看串行。

对使用者来说，这三个字段的直接含义是：APOLLO 这条路上你可以调的旋钮比 GaLore 多三个，因此配置文件里能出错的地方也多三个。它不意味着 APOLLO”更可控”或者”更复杂难用”，这两种说法都超出了参数表能支撑的范围。

这两组字段坐在哪一层

LlamaFactory 把超参按职责拆进了 src/llamafactory/hparams/ 下的 8 个文件：

src/llamafactory/hparams/
  __init__.py
  data_args.py
  evaluation_args.py
  finetuning_args.py
  generating_args.py
  megatron_bridge_args.py
  model_args.py
  parser.py
  training_args.py

GaLore 和 APOLLO 的这 17 个字段全部在 finetuning_args.py 里，和 lora_rank（默认 8）、lora_target（默认 "all"）、stage（默认 "sft"）、finetuning_type（默认 "lora"）是同一个文件里的邻居。这一点在排查”我这个字段写在配置里怎么没生效”时有用：它至少告诉你该去哪个文件搜字段名。

顺带说明，megatron_bridge_args.py、parser.py、training_args.py 这三个文件我们没有抽取过字段，所以本文不会描述它们的任何参数内容。

还有一处结构信息值得记：finetuning_args.py 里这类”算法开关”不止这两组。同文件里 BAdam 一整套字段的开关 use_badam 同样默认 False，另有 use_llama_pro、use_adam_mini、use_muon、pure_bf16 等一批布尔开关，默认值也都是 False。换句话说，默认路径上这些高级算法一个都没打开。 这是从默认值直接读出来的事实，不是我们的推荐。

你该怎么自己核这张表

这类文章最没用的读法是把数字背下来。参数和默认值会随版本变动，正确的做法是知道去哪儿核：

llamafactory-cli train -h

以及直接翻源码里 field(default=...) 那一行，文件就是上面列的 src/llamafactory/hparams/finetuning_args.py。本文所有数字都来自 2026-08-09 这一天的仓库状态，如果你手上的版本和这一天对不上，以你本地 --help 的实际输出为准，不要以本文为准。

另外提一句范围问题：我们没有抽取过 examples/ 下与这两个算法对应的示例 YAML，所以”源码默认值与示例配置是否一致”这个维度，本文不比。仓库里确实存在源码默认值与示例 YAML 写法不同的情况——最清楚的一例是 trust_remote_code，源码默认 False，而 examples/train_lora/qwen3_lora_sft.yaml 这类示例里显式写了 trust_remote_code: true。那是另外的题目，也不能因为那里不一致，就外推 GaLore/APOLLO 这两组字段也不一致。

这张对照表能支撑什么，到哪里就得停

能支撑的：

你在写配置时知道字段名怎么拼（尤其是 apollo_proj 与 apollo_proj_type 这对容易混的）；
你知道不显式写这些字段时，它们各自取什么值；
你知道 APOLLO 侧比 GaLore 侧多三个旋钮，迁移配置时不能只做前缀替换就完事；
你知道两边的 scale 默认值差了 16 倍，照抄另一边的数字是有风险的。

支撑不了的：

哪个更省显存、哪个更快、哪个收敛得更好；
你的模型和数据上该选哪一个；
rank 该不该从 16 改掉、update_interval 该不该从 200 改掉、scale 该不该动。

最后一类问题的答案是同一句话：取决于你的数据和硬件，官方没有给通用值，我们也没有跑过训练。看到别处给出”推荐值”的时候，值得先问一句它的出处在哪——是官方文档写的，还是某次具体实验的结果，还是没有说明来源。出处交代不清楚的数字，抄进自己的配置之前最好先存疑。

关于 LoRA 系那一组参数的默认值、偏好对齐那一组为什么没有独立的训练阶段目录、推理侧 vLLM 与 SGLang 的对称参数，我们各有专门篇目讲，这篇只负责把 GaLore 与 APOLLO 这两列数字对齐。

本文依据 LlamaFactory 官方仓库（github.com/hiyouga/LlamaFactory）的 README、data/README.md、examples/ 下的配置与 src/llamafactory/hparams/ 的参数定义整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有安装、训练或部署过任何模型，文中显存数字均为官方标注的估算值（README 原文标 * estimated）而非实测占用。参数与默认值随版本变动，请以 llamafactory-cli train -h 的实际输出为准。