Databricks称在AI Runtime上把Qwen 27B微调时间缩短至六分之一
Databricks博客报告，在GPU利用率已达 98% 的情况下，通过融合内核与重排批数据，把Qwen 3.8 27B在ultrachat_200k上的微调从 7 小时 44 分钟降到 1 小时 17 分钟。
AI解读：Databricks在博客中称，在自家AI Runtime（AIR）上微调Qwen 3.8 27B，把完整数据集上的训练时间从 7 小时 44 分钟降到 1 小时 17 分钟，约为原来的六分之一，吞吐从 9,396 tok/s提升。
该结果来自两个主要改动：安装flash-linear-attention与causal-conv1d两个预编译内核，把大量小算子合并，端到端先降到 2 小时 5 分钟；再把 2D矩形批改为 1D打包张量并传入example position_ids以减少padding，降到 1 小时 17 分钟。
Databricks强调高GPU利用率会误导：基线训练时GPU平均利用率 98%，但torch trace显示CPU每步准备时间超过GPU执行时间、单步有数十万次小算子，真正瓶颈是CPU向GPU入队速度。
博客给出的数据仅针对HuggingFaceH4/ultrachat_200k数据集和固定的 8,192 tokens批次上限；其中 1D打包带来的约 36% 批次数减少会随数据集长度分布变化，并非通用比例。
Databricks在官方博客中称，其在AI Runtime（AIR）上把Qwen 3.8 27B在HuggingFaceH4/ultrachat_200k数据集上的完整微调从 7 小时 44 分钟缩短到 1 小时 17 分钟，约为原来耗时的六分之一，训练吞吐从 9,396 tok/s提升。
这一结果不是来自更换硬件或降低模型规模。Databricks称基线训练时GPU平均利用率已有 98%，公司认为该指标具有误导性，于是用torch trace进一步定位耗时，再做了内核融合与批数据重排两类改动。
基线设置与初步诊断
Databricks说，基线使用transformers库的标准训练循环，配合FSDP2做模型分片以容纳权重和优化器状态，并开启激活检查点以换取更大的每GPU批量；数据加载器采用 2D批次、每批最多 8,192 个token，并padding到该批次的最大长度。
完整数据集训练耗时 7 小时 44 分钟、平均GPU利用率 98%。Databricks称利用率只反映GPU有多少时间在做事，不反映做事时的效率；torch trace显示CPU每步准备时间超过GPU执行时间，并存在数十万次小算子（如aten::bmm单步超过 3 万次）。
Databricks据此判断CPU无法足够快地向GPU入队算子，导致GPU停顿。
安装融合内核：7 小时 44 分降到 2 小时 5 分
Databricks称，Qwen的attention默认走torch SDPA，但大量小算子来自非标准的gated delta network层；transformers的Qwen实现已声明支持flash-linear-attention和causal-conv1d两个内核。
公司建议自行安装内核（pip、源码编译或预编译包），并配合容器在构建时装好以缩短作业启动时间。博客提醒，Hugging Face Kernel Hub虽然方便，但内核常与torch、CUDA版本绑定，找不到匹配版本时transformers会静默回退到未优化内核。
安装这两个Python包后，Databricks称端到端提速 3.7 倍、降到 2 小时 5 分钟，算子总数减少约 15 倍。博客还提示训练需要前向与反向内核，部分内核只实现了推理加速。
1D打包去掉padding：2 小时 5 分降到 1 小时 17 分
Databricks说，默认 2D矩形张量会为padding浪费空间。由于flash-linear-attention只支持传统 1D packed tensor，他们把输入改成 1D打包，并传入正确的example position_ids，让模型把注意力限制在同一条样本内。
公司称这一改动把训练从 2 小时 5 分钟降到 1 小时 17 分钟（1.6 倍）。主要原因是每批序列数增加、总批次数减少约 36%，但博客注明该比例取决于数据集样本长度分布；次要原因是flash linear attention内核按输入形状做JIT编译，此前形状动态导致数分钟额外编译。
Databricks提示该改动会让输入管线更复杂、更易出错并可能影响模型质量；另一种按长度排序减少padding的做法可能让相邻样本产生意外相关性。