6GB显存微调32B模型的实测与评估陷阱

6 GB 显存的笔记本 GPU，也能微调 32B 模型。作者给出的结果是：通过从磁盘逐块搬运权重，在 1024 tokens/step 下跑到约 37 tokens/s，显存占用 4.6 GB。但这篇更值得读的，是他如何发现三组看起来合理、实际测错的结果。

对做本地模型实验的程序员来说，它提供了两份参考：一份是小显存训练的工程思路，另一份是检查 AI 性能报告的方法。模型能跑起来、吞吐算对了、质量确实提升了，是三件需要分别验证的事。

6 GB 显存怎么装下 19.2 GB 权重

作者使用 Windows 笔记本，配置是 RTX 3050 Laptop、6 GB VRAM、34 GB RAM 和 NVMe SSD。32B 模型采用 NF4 量化后，权重仍有 19.2 GB，无法整体放进显存。

他的办法是把权重通过内存映射（mmap）关联到磁盘文件，再按 Transformer block 逐块加载，常驻显存的 block 保持很少，反向传播配合重计算。

大白话理解：显存只放当前要算的部分，需要其他权重时再搬进来，代价是额外的数据传输和重复计算。

这种方式的 I/O 成本按 step 支付，而不是每个 token 都付一次。因此，一个 step 处理更多 token，有机会摊薄搬运成本。作者通过固定序列长度的 LM 路径测得：

• 128 tokens 时，吞吐为 12.0 tok/s。
• 512 tokens 时，吞吐为 28.5 tok/s。
• 1024 tokens 时，吞吐为 36.7 tok/s。

上下文扩大 8 倍，吞吐约提高 3.1 倍，再往上就碰到内存限制。14B 的权重能放进系统 RAM，成本更低，作者报告其 2k/4k 序列的单步耗时约为 4–5 秒。

Dolly-15k SFT 训练 50 步后，32B 的评估 loss 从 1.8755 降到 0.9661，14B 从 2.3747 降到 0.9407。这支持「训练产生了可测变化」，但还不足以证明模型在实际任务上更好用。

三个错误，为什么都能伪装成实验结果

第一处错误出在加载顺序。评估脚本先加载 checkpoint，之后才向模型安装路由器模块，导致训练好的路由器参数没有加载进去。作者连续数天测的，其实是随机初始化的路由器。

原先报告称，学习式路由器选择了 0.0% 的内容块，表现等同于静态窗口。修复后，实际选择比例为 1.7–7.0%，困惑度（PPL，越低越好）比窗口差 0.005–0.13。学习式路由没有收益的判断仍大致成立，但支撑判断的机制解释已经变了。作者把无效实验保留在 results/invalid/，并修订了报告。

第二处错误是吞吐的分子用错了。SFT 路径每步读取一条数据，--seq 只是截断上限。Dolly-15k 的样本长度为 43–1964 tokens，中位数只有 134。把上限设成 1k–8k，并不会自动填满序列。

作者却拿上限除以耗时，报告了 4k 时 382 tok/s、8k 时 616 tok/s，以及「快了 8.6 倍」。真实提升是前面的 3.1 倍。一个早已存在的异常信号是：seq 增长后，单步耗时和显存占用几乎不变。

吞吐统计必须使用实际处理的 token 数。

第三处错误是基线预算不一致。局部注意力只允许使用 2 个 block，学习式路由器却能用 4–16 个，于是后者看起来领先约 5 PPL。改成相同 block 预算后，学习式路由器没有额外收益。

跑得动之后，更长上下文有用吗

自动调优也会误判。引擎根据上一步的显存占用增加常驻 block，在 seq 2048 时增长到 11 个，下一步溢入 Windows 共享内存，单步一小时仍未完成。

作者报告，强制限制 --blocks-on-gpu 1..2 --vram-hard-gb 5.3 后，同一个点变成 3.9 GB、193 tok/s。但后文又明确说，32B 的 2k 上下文仍无法完成训练，还差约 0.6 GB；障碍是占用 1.56 GB 的 bf16 lm_head，而所用 bitsandbytes 版本的 4-bit 实现存在问题。

这两个结果对应的完整配置、执行阶段，原文没有说清，不能据此认定 32B 已经能做 2k 微调。

更长序列也没有在当前预算下换来更好的长上下文质量。在总计 122,880 tokens 的训练量下，seq 512 训练后的 2k 上下文交叉熵（CE）为 1.2833，seq 2048 则为 1.3033。作者据此认为，这个规模下更该增加数据量。

路由器的收益同样依赖任务。在 WikiText 普通语言建模中，稠密教师模型本身就很少关注远处 block，路由器最终学成「起始注意力汇聚位置加最近窗口」。

换成检索数据，在答案位置蒸馏教师最关注的内容块，无需检索标签，路由器能以 25% 的 block 预算达到稠密注意力的精确匹配成绩；8k 时预算降到 6.25%，静态窗口则得零分。结果在 0.5B、3B 上复现，但普通语言建模的 PPL 会恶化。每 7 个 LM step 混入 1 个检索 step，保留两类能力的代价仍是增加 0.6 PPL。

我的判断

这篇最有价值的部分，是作者愿意公开推翻自己的漂亮数字。检查参数是否真的加载、吞吐分母是否正确、基线预算是否相同，比盯着加速倍数更能判断实验是否可信。

小显存运行 32B 的结果有工程价值，但硬件条件包含 34 GB RAM 和 NVMe SSD，不能只看「6 GB 显存」。与作者报告中更便宜的 14B 相比，原文也没有给出足够的下游任务对照，证明承担 32B 的搬运成本更划算。

「增加数据量比拉长窗口有效」有本次实验支持，适用范围仍是这个训练预算。路由器的检索收益也不能直接推广到一般代码任务。原文没有给出的对照，需要继续打问号。

能拿来做什么

• 做本地微调前，先核算显存、系统 RAM 和磁盘条件，再用目标数据比较 14B 与 32B 的任务效果和训练耗时。
• 给训练脚本记录每步实际 token 数、耗时和显存占用，明确区分 --seq 截断上限与固定长度输入。
• 修改模型结构后，检查 checkpoint 的加载结果；比较注意力方案时，统一 block 预算，再判断学习式路由是否值得增加复杂度。
• 复现实验可从 byjameson/stream-finetune 的 tools/finetune.py 入手，并对照 LONGCTX_FINDINGS.md、GUIDE_6GB_32B.md 核对配置与已知限制。