LoRA Speedrun 排行榜将 Qwen2.5-1.5B 微调缩短至 6:05，GSM8K 准确率达 61.1%

LoRA Speedrun 发布了一项 Qwen2.5-1.5B 微调纪录：用时 6 分 5 秒，在 GSM8K 上达到 61.1% 的精确匹配准确率。与该项目 11 分 57 秒的基线相比，这一结果将耗时缩短了 49%，同时取得了更高的评估分数。

这项改进无需使用更大的 GPU、更换基础模型或增加可训练参数。两次运行均使用一块 Nvidia L40S 和相同的秩为 16 的 LoRA 配置。新纪录改变的是训练样本的排列方式，以及哪些 token 参与损失计算。

这一差异使 LoRA Speedrun 排行榜比一次性的优化声明更值得关注。其固定的任务、硬件、准确率门槛和验证协议，将微调性能变成了一场可复现的系统竞赛。核心竞争不再是一个模型对抗另一个模型，而是高效的数据处理对抗那些把算力浪费在可避免的填充 token 和提示词 token 上的传统训练流水线。

LoRA Speedrun 排行榜重新定义了胜利

这一亮眼结果在相同的公开赛道规则下，同时实现了更短的实际耗时和更高的分数。

开发者 Saivineeth 于 2026 年 7 月 18 日发布了基线成绩和当前纪录。该项目的首个赛道要求参赛者使用一块 L40S GPU，在 GSM8K 训练集划分上微调 Qwen2.5-1.5B。

提交结果必须达到至少 57% 的精确匹配准确率。精确匹配是指提取出的最终答案必须与参考答案完全相同，而不仅仅是与预期推理过程相似。

基线运行训练了三个 epoch，用时 11 分 57 秒，在项目的 GSM8K 评估中获得 59.4% 的分数。更快的提交运行训练了两个 epoch，用时 6 分 5 秒，得分为 61.1%。

这些数字意味着耗时减少了 5 分 52 秒，同时也表明在该项目的评估设置下，准确率提高了 1.7 个百分点。耗时改善约为 49%，印证了代码仓库中所称的接近两倍提速。

该项目在 speedrun repository 中公开了排行榜、任务规范、脚本和验证材料。这种开放性很重要，因为微调速度声明经常混用不同的模型、加速器、数据集和停止条件。

LoRA，即低秩适配，会冻结原始模型权重，并训练附加在指定层上的较小矩阵。最初的 LoRA paper 将这种方法描述为一种减少可训练参数和内存需求的方式。

LoRA Speedrun 将提交限制为仅适配器训练，可训练参数不得超过 3000 万。参赛者仍可改变适配器放置位置、秩、调度策略、样本顺序、内核、量化方式和停止行为。

这种自由度为有意义的工程竞争创造了空间。这些限制可防止提交者仅靠替换任务、增加 GPU 或微调模型的全部参数来获胜。

衡量指标是训练的实际耗时，而不是浮点运算次数或训练步数。实际耗时的测量涵盖数据加载、填充、内核行为、优化器工作以及真实运行过程中产生的其他成本。

计时器并不测量端到端模型项目的每个阶段。评估时间不计入训练耗时，代码仓库也允许预先获取模型和数据集文件。因此，这项纪录描述的是一场受控的训练竞赛，而不是生产部署的总耗时。

尽管如此，受控范围正是该项目的主要优势。定义狭窄的纪录能够揭示那些常被宽泛且文档不足的比较所掩盖的优化效果。

这一设计延续了 modded-nanoGPT 的理念。modded-nanoGPT 是一项公开竞赛，它固定训练目标，并邀请参与者提交速度更快的实现。LoRA Speedrun 将这一形式应用于参数高效适配，而不是模型预训练。

这项纪录为未来的提交提出了一个简单的问题：能否有另一种技术在连续三次达到相同准确率门槛的同时，击败 6:05？这比声称某个微调库总体上更快更容易验证。

为什么数据效率正在给微调框架带来压力

这一结果给默认训练流水线带来了压力，因为大部分收益来自改变 token 利用方式，而不是改变适配器的数学原理。

许多微调比较聚焦于适配器的秩、量化、优化器选择或 GPU 等级。这些变量固然重要，但它们可能会分散人们对普通批次内部无效计算的注意力。

长度不同的样本通常会被填充，使一个批次中的所有序列具有相同长度。填充 token 使张量更容易处理，但不会增加有用的训练内容。

如果一个样本远长于相邻样本，较短的样本就会获得更多填充。加速器随后会处理那些对学习贡献很少或毫无贡献的位置。

序列打包通过将多个样本放入一个共享的固定长度序列来解决这一问题。更好的打包方式可提高每次前向和反向传播中所处理的有用 token 比例。

获胜的提交将打包与仅补全部分损失掩码结合使用。这种掩码只计算回答 token 的训练损失，同时将提示词部分排除在学习目标之外。

提示词仍然提供上下文。不过，优化器不会将目标用在教模型复现问题文本上。

这些改变共同针对两种不同形式的低效。打包减少了未使用的序列空间，而仅补全部分掩码则将学习信号集中到期望的输出上。

获胜的运行还使用了两个 epoch，而基线使用三个。一个 epoch 是对所选训练数据的一次完整遍历。只要模型仍能达到准确率门槛，减少一个 epoch 就能省去大量工作。

这正是 61.1% 的分数至关重要的原因。无论 token 处理效率有多高，如果更快的运行结果低于 57%，就不具备参赛资格。

更快的提交并非勉强越过门槛。根据其公开的 verification report，被接受的结果通过了项目规定的重复运行和审核。

这一发现迫使热门微调技术栈的维护者重新审视其默认设置。以便利性为导向的流水线可能倾向于采用简单的批处理和全序列损失，因为这些选择适用于许多数据集。

速度竞赛提出了一个不同的问题：当任务和输出格式变得可预测时，哪些通用便利功能会带来可衡量的成本？

这种压力也传导到了内部机器学习团队。团队可能会花时间比较更新的加速器，却没有先衡量填充比例、每秒有用 token 数或不必要的损失计算。

硬件升级可以缩短运行时间，但可能不会改善低效的数据准备。软件层面的收益有时可以跨受支持的加速器迁移，而无需改变模型质量目标。

LoRA Speedrun 的结果并不能证明普遍存在 49% 的耗时缩减。其收益取决于序列长度分布、提示词格式、批次构建方式以及实际所需的 epoch 数量。

如果数据集中的样本长度一致，打包带来的收益就会更少。需要对每个 token 建模的任务，可能无法以相同方式使用仅补全部分掩码。

即便如此，这项纪录仍改变了举证责任。忽略打包的微调流水线现在需要解释，为什么其工作负载无法从更密集的 token 利用中获益。

损失设计也是如此。团队应明确，他们希望模型学习完整的对话记录，还是仅学习助手的补全部分。

对于开发者而言，这些问题会影响实验速度。更短的运行时间意味着可以在相同的计算时间窗口内测试更多调度策略、适配器放置方式和数据选择方案。

对于组织而言，更大的影响在于迭代能力。运营价值来自运行更多受控实验，而不是庆祝一次仅耗时六分钟的任务。

团队还需要保存配置、数据集和评估决策的记录。可搜索的 engineering knowledge base 有助于保存用一种训练方案替代另一种方案的原因。

如果缺少这些记录，更快的迭代可能带来更多实验，却无法增进组织层面的理解。只有当团队能够重现是哪项改变导致了某个结果时，速度才有价值。

打包和损失掩码击败了普通 LoRA 基线

这场竞争的核心是经过优化的 token 处理方式，对阵将便利性视为中性选择的普通 LoRA 流水线。

基线在所有线性层上使用秩为 16 的 LoRA 适配器，训练三个 epoch，并采用余弦学习率调度。纪录运行保留了相同的核心适配器配置。

这使得这项比较的重点异常明确。获胜的方法既没有从 LoRA 切换到另一种参数高效方法，也没有减少适配器的参数预算。

序列打包改变了每个模型输入的组成方式。流水线不再单独填充每个样本，而是将多条训练记录放入更长、占用更充分的序列中。

正确的实现必须保留样本边界。它不能让一个问题的 token 意外成为另一个问题的上下文，也不能破坏打包记录之间的标签。

仅补全部分掩码改变了目标标签。提示词位置会获得一个忽略标签，而回答位置仍参与交叉熵损失计算。

交叉熵损失用于衡量模型为预期的下一个 token 分配了多少概率。被掩码的位置不会参与该计算及其相关的学习信号。

这种组合提高了单位时间内的有效工作量。打包使输入模型的空白位置更少，而掩码则将优化方向集中到答案生成上。

两个 epoch 的调度进一步直接缩短了耗时。然而，如果不考虑批次组成和目标聚焦，仅减少 epoch 数量无法解释为何报告的分数反而更高。

因此，这一结果与其说是一种新的 LoRA 算法，不如说是严谨的系统工程。它通过减少周边环节的浪费，从相同的适配器设计中挖掘出更多价值。

将这项纪录与 QLoRA、DoRA、PiSSA、rsLoRA 和 LoRA+ 等技术比较时，这一区别非常重要。这些方法会改变精度、参数化、初始化、缩放方式或学习率。

LoRA Speedrun 将其中几种方法列为开放探索方向，而不是已经取得的胜利。未来的提交可能会将它们与打包结合使用，也可能发现，在如此短的运行中，它们的额外开销大于收益。

例如，量化可以减少内存占用，但量化和反量化也会增加工作量。对于一个本就能轻松装入内存的 15 亿参数模型，节省内存并不会自动转化为更短的实际耗时。

自定义内核也存在类似的权衡。融合操作可以减少内存移动和启动开销，但编译时间或形状限制可能会增加短时训练任务的复杂性。

这场公开竞赛用一种通用指标揭示了这些权衡。只有完整训练流程用时更短且仍满足评估要求的方法才能胜出。

这种关注点将研究新意与实际运用价值区分开来。一种方法可能在科学层面颇具意义，却无法改善该赛道的成绩；而一个简单直接的批处理改动却可能称霸排行榜。

Qwen 基础模型也影响着这场竞赛。官方 Qwen 模型卡将其描述为一个拥有 15.4 亿参数、上下文长度为 32,768 个 token 的因果语言模型。

这场竞速并不测试完整的上下文长度。其配置、任务格式和批次限制决定了实际的序列工作负载。

GSM8K 包含需要多步推理的小学数学应用题。原始 GSM8K 数据集包含 7,473 道训练题和 1,319 道测试题。

该基准仍然有用，因为答案可以自动评估。然而，单一的精确匹配分数无法衡量广泛的数学推理能力、可靠性或模型在陌生领域中的表现。

该项目也承认另一个问题：现代基础模型可能在预训练期间接触过相似的数学内容。排行榜将 57% 视为优化目标，而非发现新推理能力的证据。

这种定位很重要。该纪录不应直接与所有已发布的 Qwen2.5-1.5B 基准分数进行比较。

提示词模板、解码规则、答案提取方式、模型变体和评估工具都可能改变 GSM8K 的结果。Qwen2.5-1.5B 和 Qwen2.5-1.5B-Instruct 也是两个不同的检查点。

有效的比较应限于项目内部。在该项目固定的赛道条件下，采用打包技术、训练两个 epoch 的提交比其公布的基线完成得更快，得分也更高。

若要提出更广泛的主张，则需要在其他模型系列和任务上复现。这一要求直接引出了该项目的第二条赛道。

61.1% 这一结果具有刻意限定的狭义含义

与一张截图相比，排行榜提供了更有力的验证，但其现有证据尚不足以确立一种通用的微调方案。

每个候选纪录最初都以拉取请求的形式提交，其中包含代码、配置详情、说明和自行报告的结果。随后，持续集成系统会执行静态验证。

该代码仓库称，自动化安全审查会检查网络访问、接触测试集、篡改评估工具以及数据外泄企图。提交必须经维护者批准后才能正式运行。

验证工具会使用全新的随机种子运行获批代码三次。三次运行都必须超过目标门槛，正式用时取三次运行的平均值。

这些运行在指定的 L40S 上、禁用网络的 Modal 沙箱内进行。该工具还会审计可训练的适配器参数，并检查模型和数据集的哈希值。

评审协议比一篇孤立的基准测试帖子包含更多信息。它定义了验收规则，并留下了可供其他开发者检查的产物。

Modal 的文档将 L40S 列为受支持且配备 48 GB GPU 显存的加速器。其 GPU 文档还指出，固定的加速器名称有助于用户申请特定的硬件类别。

然而，三次重新运行并不能消除所有变异来源。主机行为、软件版本、温度条件和云端调度仍可能影响较短的实际运行时间测量结果。

一次 6 分钟的运行会放大小额开销的重要性。启动行为、缓存产物、数据加载器耗时和编译决策会占据更大比例的总时间。

该项目通过固定环境并使用相同硬件解决了其中一些问题。公开的验证报告也会揭示某项性能提升能否经受全新随机种子的检验。

尽管如此，该纪录只属于一个模型与任务的组合。GSM8K 的提示词和答案结构相对规整，这可能有利于仅聚焦补全部分的训练。

其他任务可能要求模型在整个序列中复现格式。对话训练可能包含多轮助手回复、工具调用、系统指令或偏好标签。

当样本采用复杂的注意力掩码时，打包也会变得更加困难。简单粗暴的实现可能导致样本边界之间的信息泄漏，或扭曲位置行为。

第二条赛道是该项目对这一限制给出的首个回应。它将 SmolLM2-1.7B 与 SQuAD v1.1 配对，后者是一个具有不同输入和输出特征的问答数据集。

截至 2026 年 7 月 21 日，该赛道列出的基线用时为 11 分 8 秒，精确匹配率为 77.5%。它使用前 20,000 个 SQuAD 训练样本，并训练一个 epoch。

这项创纪录的打包技术尚未在两条赛道中都登顶。因此，代码仓库本身也区分了特定赛道纪录与普遍可迁移的方法。

这是最重要的审慎解读。6:05 的结果验证了固定条件下的一项优化，但其迁移能力仍是一个有待实证回答的问题。

排行榜设定的是阈值，而非追求准确率最大化。这种设计会奖励最快达到资格要求的运行，即使较慢的配置可能产生明显更好的模型。

这种权衡符合项目宗旨，但生产团队面对的是不同的目标。他们可能需要在单一基准之外进行安全评估、领域覆盖、校准和回归测试。

医疗、法律或金融适配器不应仅仅因为超过了某个公开准确率门槛就停止训练。其部署标准必须反映错误输出可能造成的后果。

同样，精确匹配评估可能掩盖推理缺陷。模型可能通过不稳定的逻辑得到正确的最终数字，而格式错误也可能导致合理的推理被判为错误。

因此，61.1% 的分数应被理解为该竞赛内部的达标结果。它既不是完整的模型评估，也无法证明 Qwen2.5-1.5B 获得了通用数学能力。

这种狭义解读并不会削弱其工程成果。它让该主张变得足够精确，从而可以接受检验。

下一批 LoRA Speedrun 纪录需要证明什么

接下来的三个信号将表明，6:05 究竟是一项持久的系统工程成果，还是一项早期的赛道特定优化。

第一个信号是由独立作者提交并在同一 Qwen2.5-1.5B 赛道上击败 6:05 的结果。目前排行榜上的基线和纪录出自同一位作者。

该代码仓库的验证流程降低了主张无法复现的风险。然而，外部参与者可以检验这些说明、环境和优化是否能够被项目创建者之外的人使用。

一个更快且获得认可的参赛结果将增强竞速赛制本身的可信度。它也会表明该基准拥有足够的优化空间，可以吸引相互竞争的方法。

值得关注的是，新参赛结果是否会使用数据筛选、单 epoch 训练计划、融合内核或其他 LoRA 放置方式。每种策略都针对不同的瓶颈，并有助于厘清剩余时间究竟花在了哪里。

第二个信号是，序列打包和仅补全部分的损失掩码能否改善 SQuAD 赛道的表现。若能迁移到 SmolLM2-1.7B 和另一项不同任务上，将支持更广泛的效率主张。

失败同样具有参考价值。它可能意味着该纪录高度依赖 GSM8K 的序列长度、输出格式或训练动态。

成功的跨赛道提交无需实现同样的 49% 降幅。它需要证明，该技术在满足 SQuAD 75.5% 门槛的同时，仍能保留具有实用价值的速度优势。

第三个信号是，随着更多提交和软件变更出现，官方验证用时将如何变化。稳定的重复运行结果将增强对实际运行时间排名的信心。

较大的波动则表明，排行榜需要围绕内核、驱动程序版本、缓存或主机层面的条件制定更严格的报告要求。较短的纪录需要格外严谨的计时规范。

这些信号比单纯的 GitHub 关注度更重要。Stars 可以反映兴趣，但无法验证一种训练方法的速度、准确率或可迁移性。

LoRA Speedrun 排行榜已经提供了一个可信的初步结果。它将公布的基线用时从 11:57 缩短至 6:05，同时将 GSM8K 精确匹配率从 59.4% 提高到 61.1%。

其更深层的贡献在于竞赛设计。固定硬件和任务，将算法选择、内核、数据管线和停止规则都纳入同一场可衡量的竞赛。

开发者应避免将这一结果视为通用方案。相反，他们可以复现该提交、检查 token 利用率，并在自己的工作负载上测试相同的改动。

最有价值的问题不是每个 LoRA 任务能否在六分钟内完成，而是当前管线是否将近一半的时间花在了原本根本不必进行的工作上。

未来几个月，获得认可的外部纪录、跨赛道迁移以及稳定的验证运行将给出答案。在此之前，6:05 是一项边界定义清晰且表现出色的基准测试结果。

如果你的团队微调较小的语言模型，请在更换硬件前测量填充量、有效损失 token，以及每秒处理的有效 token 数。然后记录每次受控运行，并在固定的质量阈值下比较结果。下一项有意义的 LoRA Speedrun 纪录将来自能够经受这些控制条件检验的证据，而不仅仅是一个更快的秒表读数。