Llama-Factory 训练时如何平衡计算与 IO 开销
在大模型微调的实际工程实践中，一个看似简单却极为关键的问题时常浮现：为什么我的 GPU 利用率只有 30%？明明配置了高端显卡，训练速度却不尽人意。答案往往不在模型结构本身，而藏于计算与 IO 之间的资源失衡之中。
尤其当使用如 Llama-Factory 这类一站式微调框架时，虽然上手门槛大幅降低，但若忽视底层系统行为的协调性，仍可能陷入'数据等磁盘、GPU 等数据'的恶性循环。真正的高效训练，不只是选对算法，更在于让每一块硬件都持续运转、各司其职。
要理解这个问题的本质，不妨从一次典型的训练流程说起。当你点击'开始训练'后，系统并不会立刻进入高负载计算状态——它首先要加载数据集、分词编码、组批填充，再传入模型进行前向传播。这个过程中，任何一个环节滞后，都会导致后续阶段停滞。
以一个 8B 参数级别的 LLM 为例，在启用 LoRA 的情况下，单卡 A100 或许能承载整个训练过程。但如果数据是从普通 SSD 逐条读取、未做缓存处理，那么 GPU 很可能每运行 200 毫秒就要等待 500 毫秒的数据供给。这种现象被称为'GPU 饥饿'，是 IO 瓶颈最直观的表现。
Llama-Factory 的价值恰恰体现在它不仅仅封装了模型和训练逻辑，更在架构层面预埋了多种机制来打破这一僵局。它的设计哲学不是'跑得起来就行'，而是'尽可能榨干每一瓦电力'。
异步流水线：让数据提前就位
解决 IO 延迟的核心思路是隐藏延迟（hide latency），即在 GPU 忙于当前批次计算的同时，后台提前准备好下一个批次的数据。这正是 PyTorch 中 DataLoader 的多进程异步加载能力所擅长的。
Llama-Factory 默认采用 torch.utils.data.DataLoader 配合 Hugging Face 的 datasets 库实现这一机制。通过设置 num_workers > 0，启动独立子进程负责磁盘读取与预处理；配合 pin_memory=True 将张量锁定在页锁定内存中，可使 Host-to-Device 传输速度提升数倍。
dataloader = DataLoader(
dataset,
batch_size=16,
num_workers=4,
pin_memory=True,
prefetch_factor=2,
persistent_workers=True
)
这里的关键参数值得细究：
num_workers=4并非越多越好。过多的工作进程会引发内存竞争甚至文件句柄耗尽，一般建议设为 GPU 数量的 2~4 倍；prefetch_factor=2表示每个 worker 预加载两个 batch，形成缓冲池，避免突发 IO 抖动造成断流；persistent_workers=True可复用进程，避免每个 epoch 重新创建带来的开销。
此外，框架默认将原始文本预处理为 Arrow 格式缓存（.arrow 文件），利用内存映射（memory-mapped loading）技术实现按需读取。这意味着即使数据集高达上百 GB，也不会一次性加载进 RAM，极大缓解了主机内存压力。
实践提示：如果你发现
CPU usage < 20%而 GPU 利用率波动剧烈，大概率是num_workers设置过低或数据解析逻辑存在同步阻塞。
参数效率革命：LoRA 与 QLoRA 的双重减负
如果说异步加载解决了'数据喂不快'的问题，那 LoRA 和 QLoRA 解决的则是'算不动'和'放不下'的难题。
传统全参数微调需要更新所有权重，对于 Llama-3-8B 这样的模型，意味着超过 70 亿个参数参与梯度计算，显存消耗轻松突破 80GB。即便有足够显卡，训练速度也会因庞大的计算图而受限。
LoRA 的思想非常巧妙：冻结主干模型，仅训练低秩增量矩阵。具体来说，原始权重 $ W \in \mathbb{R}^{d \times k} $ 不变，新增一个分解形式的扰动：
