★ 显存表怎么读：`* estimated` 这四个字与那个对不上的格子
本文所有事实以
hiyouga/LlamaFactory官方仓库 2026-08-09 的内容为准。我们没有安装、训练或部署过任何模型，文中显存数字全部是仓库 README 里写着的值，且是官方自标的估算值。
几乎每个人翻开 LlamaFactory 的 README，最先找的都是那张 Hardware Requirement 表——它看上去直接回答了「我这张卡到底能不能干」。但在表格开始之前，README 先用一行独立的小字给自己上了保险：\* *estimated*。这四个字决定了这张表能被用来做什么、不能被用来做什么。
这篇只做一件事：把这张表拆开，讲清每一列在说什么、哪些结论能从表里直接读出来、哪些结论表根本没打算给你。
先把表原样摆上来
在 README 的 Hardware Requirement 一节里，\* *estimated* 单独占一行，紧接着才是表格。本篇就是专门拆这张表的，所以逐格照抄如下：
| 方法 | Bits | 7B | 14B | 30B | 70B | xB |
|---|---|---|---|---|---|---|
Full (bf16 or fp16) | 32 | 120GB | 240GB | 600GB | 1200GB | 18xGB |
Full (pure_bf16) | 16 | 60GB | 120GB | 300GB | 600GB | 8xGB |
| Freeze/LoRA/GaLore/APOLLO/BAdam/OFT | 16 | 16GB | 32GB | 64GB | 160GB | 2xGB |
| QLoRA / QOFT | 8 | 10GB | 20GB | 40GB | 80GB | xGB |
| QLoRA / QOFT | 4 | 6GB | 12GB | 24GB | 48GB | x/2GB |
| QLoRA / QOFT | 2 | 4GB | 8GB | 16GB | 24GB | x/4GB |
这张表其实有四个坐标轴
第一个是「方法」列。 注意它的行粒度并不是「一种方法一行」：Full 被拆成了两行，一行写 bf16 or fp16，另一行写 pure_bf16；而 Freeze、LoRA、GaLore、APOLLO、BAdam、OFT 六个名字挤在同一行里；QLoRA / QOFT 则占了三行。
第二个是 Bits 列。 把它和第一列连起来看，就明白行粒度的真实含义了：这张表的每一行是「方法 + 精度」的组合，不是方法本身。Full 的两行分别标 32 和 16，那六个挤在一起的方法统一标 16，QLoRA / QOFT 的三行分别标 8、4、2。所以想在表里找「4-bit 的 LoRA 该看哪行」，答案是看 QLoRA / QOFT 的 4 那一行——量化那几档在表里是挂在 QLoRA / QOFT 这个名下的。
第三个是模型规模列，横着给了 7B、14B、30B、70B 四档具体数字。以 7B 这一列为例，从上到下依次是 120GB、60GB、16GB、10GB、6GB、4GB。
第四个是最右边的 xB 通用列，它给的不是数字而是系数：18x、8x、2x、x、x/2、x/4。它的作用是让你在四个规模档位之外也能有个换算的形状。
* estimated 在阅读层面到底意味着什么
这四个字是 README 自己标的，意思很直白：这些是估算值，不是实测占用。
我们没有 pip install 过这个项目，没有训练过任何一个模型，所以这篇文章不会出现任何一句「实际跑起来大概占多少」。表里的数字是仓库文档给的，仅此而已。
更值得注意的是这张表没有写出来的东西：它没有说明这些数字是在什么序列长度、什么 batch size、什么并行方式、什么优化器状态下估出来的。表里没写，我们也不替它补。这直接决定了这张表的正确用法——它是一把量级尺，不是一份配置单。
所以你不会在这篇文章里看到「你那张 24GB 的卡够不够跑 XX」这种结论。表本身没给出这个结论，我们也不替它给。同理，也不会有「那你就把 XX 参数设成 YY」这类建议——该设成多少取决于你的数据、你的模型和你的硬件，官方并没有给通用值。
能从表里直接读出来的两条
第一条是同一列内部的量级落差。 7B 这一列上，Full（bf16 或 fp16，32）标的是 120GB，Freeze/LoRA/GaLore/APOLLO/BAdam/OFT（16）标的是 16GB，两者相差 7.5 倍。这是把表里两个格子相除得到的，不掺任何推断。同一组对比换到 70B 那一列上，是 1200GB 对 160GB，两个数也都是表里现成写着的。表只给了这些格子，至于这个落差由哪些部分构成，表里一个字都没写，我们也不替它补。
第二条是通用列的系数结构。 18x / 8x / 2x / x / x/2 / x/4 这六个值本身就是表给的，从上往下逐级收窄。它给的是相对关系，读它的时候把它当成”这几条路线之间大致差几个数量级”就好。
那个对不上的格子
现在说这篇文章标题里的另一半。
拿最后一行（QLoRA / QOFT，2 bits）来看：这一行的通用列写的是 x/4。如果把 70B 代进去，x/4 得到的是 17.5GB；但表里 70B 这一格写的是 24GB。两者对不上。
这是表里能直接核实到的一处不一致，说到这儿就够了。我们不推断哪个数字是「对的」、不猜是笔误还是另有考量、更不拿它去评价这个项目的质量——这些我们都没有依据。你要做的也只是：在引用这张表的时候，知道有这么一格与通用列的公式不咬合，别把通用列当成逐格都能反推的换算公式来用。 其它格子怎么对，你可以自己拿表核一遍，我们不替这张表作解释。
顺带一提，仓库里这类「两处口径不一样」的地方不止显存表这一处。比较有名的还有两个：一是项目名，src/llamafactory/launcher.py 的欢迎语里写的项目主页仍是带连字符的旧名 https://github.com/hiyouga/LLaMA-Factory，README 正文里也混用 LLaMA-Factory 和 LlamaFactory 两种写法；二是 trust_remote_code，源码里的默认值是 False，而示例 YAML 里普遍写成 true。这两处我们另有篇目专门讲，这里只是提醒你：遇到数值型的东西，交叉核对两处比信任任意一处更划算。
Bits 这一列和 Features 那一条不是同一个集合
还有一处值得对照着看。README 的 Features 里，Scalable resources 那一条写的是通过 AQLM / AWQ / GPTQ / LLM.int8 / HQQ / EETQ 实现的 2/3/4/5/6/8-bit QLoRA，一共六档量化精度。
但显存表的 Bits 列里，QLoRA / QOFT 只出现了 8、4、2 三行。也就是说，3-bit、5-bit、6-bit 这三档在特性列表里被点了名，在显存表里没有对应的格子。
这不是矛盾，只是两处的覆盖范围不同：特性列表回答的是「支持哪些」，显存表回答的是「这几档大概是什么量级」。你要是打算走 3/5/6 bit 那几档，显存表里没有现成的行可以查——这一点表里就是这么写的，我们不替它外推。
选完行之后，表管不到的两件事
一件是 NPU 上的一个具体提示。 如果你按表选中了 QLoRA 那几行，而硬件是 Ascend NPU，README 的折叠块里另有一条提示：在配置里设 double_quantization: false，并给出了参考示例 examples/train_qlora/qwen3_lora_sft_bnb_npu.yaml。这是官方文档里的原话，不是我们的调参建议。
另一件是模型得先下得下来。 显存表帮你圈定了规模档位，但 7B 也好 70B 也好，权重先要能拉到本地。README 为 Hugging Face 下载不畅的情况给了切换下载源的写法，两个平台的写法不一样，照抄如下：
# Linux / macOS
export USE_MODELSCOPE_HUB=1
:: Windows
set USE_MODELSCOPE_HUB=1
切到 Modelers Hub 是同一套写法，变量换成 USE_OPENMIND_HUB=1。这两个环境变量各自的 model ID 填法我们另有一篇专门讲，这里只是补上「表看完之后紧接着会撞上的那一步」。
以上命令均照抄 README 原文，我们没有在本机执行过，以官方文档的实际内容为准。
这张表最适合用来做减法
回到最开始的问题：这张表该怎么用？
它擅长的是圈量级，不是给承诺。 表里 Full（32）那一行 7B 标 120GB、70B 标 1200GB，而 QLoRA / QOFT（4）那一行同样两档标的是 6GB 和 48GB——跨行之间差着的量级，光看表面的数字就能读出来。至于「这条路在你的机器上成不成立」，表没有回答，我们也不替它回答。反过来，当表里某一格的数字和你手上的显存接近时，估算值更是不够用：表标的是估算，没有承诺这个数，你只能在自己的环境里验证。
顺便记住 README 在这张表附近的整体口径：它的官方文档页在 README 里被明标 (WIP)，显存表自己标 * estimated。项目方在这些地方都留了余地，读的人也应该照样留着。
本文依据 LlamaFactory 官方仓库（github.com/hiyouga/LlamaFactory）的 README、data/README.md、examples/ 下的配置与 src/llamafactory/hparams/ 的参数定义整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有安装、训练或部署过任何模型，文中显存数字均为官方标注的估算值（README 原文标 * estimated）而非实测占用。参数与默认值随版本变动，请以 llamafactory-cli train -h 的实际输出为准。