一个开源仓库最近立了块擂台。规则很简单:把 Qwen2.5-1.5B 丢到 GSM8K 数学题上做 LoRA 微调,只用一张 NVIDIA L40S(48GB),谁先训到准确率 57% 以上,谁训练用时更短谁赢。项目叫 LoRA Speedrun,目前挂榜首的成绩是 6分05秒,准确率 61.1%。
这个数字本身不算新闻。真正值得记一笔的,是它想解决的老问题:DoRA、rsLoRA、PiSSA、LoRA+、NEFTune、Unsloth 定制内核,这几年冒出一堆 LoRA 优化方案,但谁快谁慢,业内没有共同答案——各测各的模型,各测各的显卡,数字根本没法摆在一起比。
固定赛道,才有可比性
LoRA Speedrun 的规则写得很硬。
| 项目 | 规定 |
|---|---|
| 模型 | Qwen2.5-1.5B |
| 数据集 | GSM8K,固定 7473 条训练样本 |
| 硬件 | 单张 NVIDIA L40S(48GB) |
| LoRA 可训练参数 | 不超过 3000 万 |
| 运行环境 | 网络隔离的 Modal 沙盒 |
| 达标线 | 准确率不低于 57% |
| 验证方式 | 3 个新随机种子各跑一次,取平均墙钟时间 |
想上榜,先按仓库脚本自己跑通,再由维护者用三个全新随机种子重跑三次,全部达标才算数。
当前纪录靠的是序列打包和仅答案部分计算损失这两个技巧,把训练轮数从 3 轮压到 2 轮。基线版本是 11分57秒、准确率 59.4%。两相对比,时间接近腰斩,准确率还涨了近两个百分点。
这个提速不能简单归成"LoRA 算法快了一倍"。序列打包省的是数据填充的浪费,损失遮罩省的是无效梯度计算,轮数减少省的是硬训练步数。三件事叠在一起,才出来这个数字。
有两处细节,仓库没说清楚。一是墙钟计时具体算到哪一步,是否包含最终评测推理,页面没写明。二是 57% 这个门槛怎么定出来的,项目只强调这是竞速用的锚点,没解释依据。想引用这两个数字的人,最好自己按脚本跑一遍再下结论。
对照 modded-nanoGPT,但擂主目前只有一人
这套流程明显参考了 modded-nanoGPT——那个项目把预训练任务钉死,逼着大家在同一起跑线上比速度,后来真跑出了 Muon 这样的优化器改进。LoRA Speedrun 想复制的就是这个机制,把赛道从预训练搬到了参数高效微调。
思路本身没问题。论文里的加速比大多没法直接对比,因为模型、数据、硬件全不一样。一个统一擂台,至少能让"谁的技巧真的有用"这件事有据可查。
但现在的局限也很明显。整张榜单只有两条记录,两条记录的作者是同一个人。仓库拿到的关注有限,只有十几个 Star、两个 Fork,提交记录不多。所谓"独立复跑",指的是维护者用固定脚本重跑三次验证,还不是第三方团队拿自己的实现来打擂。两条记录标注的日期都指向同一天,且早于本文写作时间,这个时间戳本身存疑。
任务选择也框住了榜单能说明的范围。Qwen2.5-1.5B 是个 15 亿参数的小模型,GSM8K 是纯数学应用题。项目自己也承认,这类基础模型大概率已经在预训练阶段见过数学语料,达标不代表推理能力有突破。换成代码生成、多轮对话,或者更大规模的模型,序列打包和损失遮罩还能不能带来同等幅度的提速,现在谁也没验证过。
谁该关心,谁该再等等
对负责微调基础设施的工程师,这个项目是个现成的"技巧验证场"。想试序列打包、数据剪枝、rsLoRA 或者 Unsloth 内核这类具体优化手段,能在统一环境下拿到一个相对干净的对比数字,比自己东拼西凑几篇论文里的加速比靠谱得多。可以直接按仓库脚本跑起来,把自己团队常用的技巧摆进同一把尺子里量一遍。
对评估微调算力投入的团队负责人,现在还不是据此调整预算或采购计划的时候。样本只有两条,作者只有一人,任务只覆盖一个数学数据集和一个 15 亿参数模型。这些"单一"意味着榜单结论目前很难迁移到别的微调场景——换一个业务数据集、换一个更大的模型,提速比例大概率不会照搬。
接下来值得盯的,是有没有第三方团队拿自己的实现来打擂,任务会不会扩展到 GSM8K 之外,以及三次随机种子之间的波动数据会不会公开。这三件事任何一件成真,榜单的参考价值都会往上跳一截。