LoRAFusion: Efficient LoRA Fine Tuning for LLMs

Source #

• Title: LoRAFusion: Efficient LoRA Fine-Tuning for LLMs
• arXiv: https://arxiv.org/abs/2510.00206
• PDF: https://arxiv.org/pdf/2510.00206
• DOI / Venue: EuroSys 2026 DOI；arXiv comment 标注 Accepted by EuroSys 2026。
• Code/Project: CentML/lorafusion；Artifact branch eurosys-ae；Zenodo artifact。
• OpenReview / Review page: 未发现公开 OpenReview、ARR 或 EuroSys reviewer comments 页面。
• Authors: Zhanda Zhu, Qidong Su, Yaoyao Ding, Kevin Song, Shang Wang, Gennady Pekhimenko。
• Submitted: 2025-09-30.
• Current version read: arXiv v1, 2025-09-30；TeX source and arXiv API checked 2026-06-28.
• Subjects: Machine Learning, Artificial Intelligence, Distributed Computing.

作者与关系 #

• Zhanda Zhu: University of Toronto, Vector Institute, NVIDIA.
• Qidong Su: University of Toronto, Vector Institute, NVIDIA.
• Yaoyao Ding: University of Toronto, Vector Institute, NVIDIA.
• Kevin Song: University of Toronto, Vector Institute, NVIDIA.
• Shang Wang: University of Toronto, Vector Institute, NVIDIA.

阅读目标与判断边界 #

本笔记关注：

1. LoRA 微调为何会在参数和 FLOPs 很小的情况下产生显著 runtime overhead。
2. FusedLoRA / FusedMultiLoRA 如何通过图切分和横向融合减少 memory traffic。
3. 多 adapter 训练调度如何在 pipeline dependency 约束下平衡变长样本并减少分布式训练开销。

判断边界：

• 论文把 kernel 和 scheduler 设计为 lossless，实验重点是 throughput；本文不提供新的模型质量结果，可信度依赖数值等价、global batch 顺序保持和作者实现。
• 端到端实验集中在 summarization workloads、4 个 LoRA adapters、H100 / L40S 和 Megatron-LM / mLoRA 生态；更多任务、更大 adapter 数、QLoRA / DoRA / VeRA、Tensor Parallelism 和其他硬件仍需复验。
• mLoRA baseline 由作者在 LoRAFusion 系统内重实现高性能通信，并乐观假设其 kernel 与 naive single LoRA 性能相同；相对 mLoRA 的差距应按这个实现条件理解。

论文脉络 #

1. 研究问题、背景和价值 #

LoRA 让大模型微调从全参数更新转向 adapter 更新，显著降低参数、梯度和 optimizer states 的显存压力。以 LLaMA-3.1-70B 为例，论文估算 full-model fine-tuning 仅模型状态就需要约 1120GB GPU memory，LoRA rank 16 仅增加约 0.29% 参数，模型状态可降到约 142GB。这个差异解释了 LoRA 在云服务、私有数据适配、hyperparameter tuning 和多租户微调中的实际价值。

系统问题来自另一个维度：显存下降后，训练吞吐成为核心瓶颈。用户常同时训练多个 adapter，探索不同超参或数据版本。这些任务共享同一个 frozen base model，却通常被独立运行，导致 base model 重复占用、pipeline 气泡和 GPU load imbalance。

论文要回答的问题是：LoRA adapter 很小，为什么训练仍会慢很多；共享 base model 的多 adapter 训练能否作为系统优化对象，而不仅是节省显存的技巧。

2. 已有解决方案与不足 #

现有 LoRA fine-tuning 系统主要复用 full-model fine-tuning 里的 FSDP、TP、PP、kernel fusion 和 on-the-fly packing。PEFT、LLaMA-Factory、llama-cookbook 等路径可以让训练放进显存，但没有专门处理 LoRA 分支的 memory traffic。

服务侧已有 Punica、S-LoRA、dLoRA 等 multi-LoRA inference 系统，它们的主要场景是 autoregressive single-token decoding，瓶颈来自小 token count 下 frozen GEMM arithmetic intensity 不足。微调场景已经处理完整序列，frozen GEMM 计算强度通常足够，瓶颈转向 adapter 低秩分支的 memory-bound 操作，以及分布式训练中的 pipeline bubble / load imbalance。

mLoRA 是已有 multi-LoRA fine-tuning 系统，能把不同 adapter 的样本填入 pipeline bubble，但论文指出它仍使用通用 LoRA kernel，未处理大激活重复读写；调度也主要按容量和 uniform adapter filling，缺少对变长样本负载不均的约束优化。

3. 作者可能的思考路径 #

作者很可能先从 profiler 看到一个反直觉现象：LoRA 添加的参数少于 1%，理论 FLOPs 也小，但 LoRA linear layer 相比 frozen linear layer 仍出现约 40% forward slowdown 和 36% backward slowdown。进一步拆解后，瓶颈集中在低 rank GEMM 和 dropout、element-wise multiplication、branch addition 等 memory-bound 操作，它们反复读取和写回 full-sized activation。

接着，作者把 LoRA adapter 的低 rank 中间张量 $S = \hat{X}A$ 当成系统切点：full-sized $X$、$Y$ 很贵，rank-$r$ 的 $S$ 很小；如果在 $S$ 处切分计算图，就能保留高性能 GEMM tiling，同时融合围绕大激活的 memory-bound 操作。

最后，作者把单 adapter kernel 扩展到 multi adapter batch：多个 adapter 共享 frozen base model，adapter 权重按 tile-level routing 动态选择。这个 kernel 提供了混合 adapter microbatch 的执行基础，调度层就能围绕 pipeline dependency 和 token capacity 做更主动的数据重排。

4. 核心假设或切入点 #

LoRAFusion 的核心假设有三条：

1. LoRA runtime overhead 主要来自大激活张量的额外 memory traffic，而非低秩矩阵乘法的计算量。
2. LoRA 计算图中 rank-$r$ 中间张量足够小，显式 materialize / reload 它比 full graph fusion 的 recomputation 或 cross-block synchronization 更划算。
3. 多个共享 base model 的 adapter 训练可以在保持每个 adapter global batch 顺序的前提下混合调度，从而减少 pipeline bubble、提升 communication-computation overlap 并平衡变长样本。

5. 方法 / 系统 / 理论框架 #

FusedLoRA。 对 forward pass，LoRAFusion 先融合 dropout 和 down-projection，避免重复读取 full-sized input activation；再把 base GEMM $Y_1=XW$ 与 LoRA 分支 $Y_2=\alpha SB$ 的输出累加融合，避免读写 full-sized output partial result。对 backward pass，系统融合 $dS$ / $dB$ 计算以复用 $dY$，并横向融合 base model gradient path 与 LoRA path 中共享大张量的部分，减少 partial gradient 的读写。

Split graph fusion。 全图融合会消耗 registers / shared memory，影响 compute-bound base GEMM tiling，并可能引入 recomputation 或 thread-block synchronization。LoRAFusion 在 $S=\hat X A$ 处切开计算图，把 $S$ 作为小张量保存，从而把融合收益集中在 full-sized activation 和 output 上。

FusedMultiLoRA。 每个 input tile 带 adapter ID 和配置，包括 LoRA rank、scaling factor、dropout ratio。kernel 在 tile 级查表选择对应 adapter 的 $A$、$B$ 和梯度累加路径。frozen model computation 在所有 tokens 上共享，adapter-specific branch 在同一 fused kernel 中路由。

Multi-LoRA scheduler。 调度以 global batch 为基本单位。对 pipeline parallelism 的 $S$ 个 stage，论文定义 bubble lemma：若 adapter $i$ 的 batch $j$ 中样本在 microbatch $k$ 提交，则同一 adapter 的 batch $j+1$ 样本不能早于 $k+S-1$ 提交。调度器先按样本长度均值做 head-tail pairing，把长短分布互补的 adapters 分组，并让同一 adapter 相邻 global batch 被其他组隔开。随后对每个 group 内的样本做两阶段 MILP bin packing：第一阶段最小化 microbatch 数，第二阶段固定 microbatch 数并让最小 microbatch 留出更多可合并空间。若 MILP 超时，系统回退到 greedy packing。最后用 merge pass 把下一个 global batch 的 token 移入当前 batch 末尾 underfilled microbatch，并用 verification / no-op microbatch 修正 pipeline dependency。

Parallelism profiler。 token capacity 和并行策略由轻量 profiler 提供。系统用 fixed-length inputs 直接 benchmark 不同 parallelism configurations，选择吞吐更高的配置，再把 token capacity 传给 scheduler。

6. 结论链条 #

论文的结论链条如下：

1. LoRA adapter 的参数量小，但低 rank GEMM 和 element-wise operations 对 full-sized activation 的额外读写显著，导致 training throughput 下降。
2. 在 rank-$r$ 中间张量处分割计算图，可以融合大激活相关 memory-bound operations，同时保留 base GEMM 的高性能 tiling。
3. tile-level adapter routing 让多个 adapter 能在同一 fused kernel 中执行，为 multi-adapter microbatch 提供执行机制。
4. 多 adapter 共享 base model 并混合调度后，global batch 变大、pipeline bubble 下降、FSDP communication overlap 改善，并且可用 packing 缓解变长样本带来的 GPU load imbalance。
5. kernel fusion 和 adaptive scheduling 同时启用时，端到端收益超过单独使用任一组件。

关键实验/定理 #

结果 1：LoRA overhead profiling #

• 设置：冻结 linear layer 与 LoRA-equipped linear layer 对比，典型形状 $n=k=4096$，tokens 和 rank 变化；H100 上用 profiler / Nsight Compute 拆解 forward/backward。
• Baseline：frozen linear layer、Torch / PEFT 风格 LoRA implementation、torch.compile。
• 指标：throughput、runtime breakdown、global memory read/write traffic、arithmetic intensity。
• 结果：LoRA linear module 相对 frozen layer forward 约慢 40%，backward 约慢 36%；torch.compile 对 forward 无收益，对 backward 收益很小；LoRA rank 16 到 32 对吞吐影响很小。LoRA GEMM forward / backward 分别占总 runtime 10.76% / 20.37%，element-wise operations 分别占 30.46% / 17.49%，global memory traffic 相对 frozen linear 增加约 2.64x。
• 解读：LoRA 的关键系统瓶颈是 full-sized activation 的重复读写。rank 小使 LoRA GEMM arithmetic intensity 低于 H100 FP16 machine balance，增加 rank 对吞吐的影响弱于 memory traffic。

结果 2：端到端吞吐 #

• 设置：H100 80GB 和 L40S 48GB；模型为 LLaMA-3.1-8B、Qwen-2.5-32B、LLaMA-3.1-70B；任务为 XSum、CNN/DailyMail、WikiSum、Mixed、Heterogeneous；多 LoRA 实验同时训练 4 个 adapters。
• Baseline：Megatron-LM + FSDP、Megatron-LM + PP、mLoRA。mLoRA 由作者重实现高性能通信，原 Python RPC 通信没有直接作为主 baseline。
• 指标：trained tokens/sec、speedup。
• 结果：H100 上 LoRAFusion 相对 Megatron-LM 达到 1.19-1.96x；abstract 汇总为最高 1.96x、平均 1.47x，相对 mLoRA 最高 1.46x、平均 1.29x。分模型看，LLaMA-3.1-8B 平均 1.26x、Qwen-2.5-32B 平均 1.42x、LLaMA-3.1-70B 平均 1.64x。L40S 上也报告 1.19-1.91x 的平均 speedup 区间。
• 解读：小模型 / 单 GPU 主要受益于 kernel fusion；大模型 / 多 GPU 中 scheduler 对 pipeline bubble、communication overlap 和 load imbalance 的收益更明显。

结果 3：FusedLoRA / FusedMultiLoRA kernel #

• 设置：Triton kernels；不同 token sizes 和 model shapes；另做 decoder layer-wise benchmark 与 Nsight Compute DRAM traffic profiling。
• Baseline：standard Torch LoRA implementation。
• 指标：forward/backward kernel throughput、layer-wise speedup、DRAM read/write traffic。
• 结果：FusedLoRA 平均 1.27x、最高 1.39x；FusedMultiLoRA 平均 1.17x、最高 1.24x。layer-wise 上 FusedLoRA 平均 1.21x、FusedMultiLoRA 平均 1.13x。$8192 \times 4096 \times 4096$ 形状上 DRAM traffic 降至 0.63x；所有设置中 DRAM traffic 降低 34%-37%。
• 解读：kernel 实验直接支撑论文关于 memory traffic 的机制解释。FusedMultiLoRA backward 有 adapter gradient accumulation 和额外 element-wise overhead，速度低于单 adapter FusedLoRA，但仍优于 Torch baseline。

结果 4：multi-adapter scheduling 和 scalability #

• 设置：LLaMA-3.1-70B，4 H100；pipeline stage 下比较 adapter 数、mLoRA、greedy / MILP / merge；另在 4、8、16 H100 上比较 DP scaling 与 job-level scaling。
• Baseline：Megatron-LM 1F1B pipeline、mLoRA、greedy packing、无 fusion / 无 adaptive scheduling variants。
• 指标：pipeline bubble ratio、throughput、scheduling time、component speedup。
• 结果：1 个 adapter 时 bubble ratio 为 44.17%，接近 Megatron-LM 的 48.79%；2、3、4 个 adapters 分别降到 15.00%、12.23%、11.09%，mLoRA 为 34.11%。merge pass 额外提升 4.34%，两阶段 MILP 相对 pure greedy 额外提升 3.82%，10 秒 timeout 下 MILP path 被选中 77.4% global batches。调度时间从 640 samples 的 15.74 秒线性增加到 25,600 samples 的 102.12 秒。4/8/16 H100 上，job-level scaling 相比 DP scaling 在 8/16 GPUs 上分别高 1.18x / 1.25x；DP scaling 下 LoRAFusion 相对 Megatron-LM 平均 1.78x、相对 mLoRA 平均 1.50x。
• 解读：调度收益主要来自多 adapter 提供的独立 microbatch 空间；单 adapter 时 scheduler 作用有限。MILP / merge 的边际收益相对主设计较小，但在 CPU scheduling 可隐藏时有价值。

实验设置与 baseline 审计 #

维度	记录
模型与初始化	LLaMA-3.1-8B、Qwen-2.5-32B、LLaMA-3.1-70B；base model frozen，LoRA adapters trainable。
数据与任务	Summarization：XSum、CNN/DailyMail、WikiSum；homogeneous、Mixed、Heterogeneous adapter settings。
RL / 训练配置	本文是 supervised LoRA fine-tuning 系统论文，不涉及 RL objective。
系统配置	PyTorch 2.6、CUDA Toolkit 12.4、Triton 3.2.0、Megatron-Core 0.11.0；约 10K LoC Python；Triton 自定义 kernels。
技术报告训练配置	论文声称 scheduler 保持 global batch order，kernel 输出与 baseline 在数值精度内等价；主要评估 throughput。
训练硬件与拓扑	H100 80GB 节点：8x H100 NVLink、208 vCPUs、InfiniBand；L40S 48GB server：4x L40S PCIe、128 vCPUs；scaling 包含 2 节点 16 H100。
并行方式与框架	Megatron-LM 上支持 FSDP 和 PP；multi-adapter pipeline parallelism；TP 未评估。
训练数据规模与组成	公开 summarization datasets，图中给出 length distribution；具体全量 epoch / token 数依实验脚本和 artifact。
训练过程与超参	LoRA rank、global batch、microbatch token capacity 等由实验设置和 parallelism profiler 决定；完整复现实验见 benchmarks_paper。
训练时间 / GPU hours / 成本	Artifact appendix 称完整实验约 4 小时，需要 4 张 80GB GPU；kernel / layer benchmarks 可单 GPU运行。
未披露项	论文正文没有逐项列出所有 LoRA hyperparameters、learning rate、epoch、optimizer 细节；代码 artifact 可补充复验。
评测协议	主要指标为 trained tokens/sec；kernel 用 throughput 和 NCU DRAM traffic；scheduler 用 bubble ratio / tuning time / ablation。
统计报告	图表报告平均、最高 speedup；没有看到跨随机 seed 的统计误差条，因为系统吞吐实验为主。
Baseline 是否 tuned	Megatron-LM FSDP / PP 和 mLoRA 均在作者系统中实现和比较；mLoRA 通信被强化，原 RPC 开销被剔除。
Baseline 是否 compute-matched	端到端比较围绕同模型、同任务和同硬件；multi-LoRA 与 sequential Megatron-LM 的 job aggregation 口径需要按训练 4 adapters 的总吞吐理解。
Baseline 是否 implementation-matched	Megatron-LM、PEFT、Hugging Face Transformers 集成在 LoRAFusion 环境；mLoRA 被重实现，减少原系统工程差异。
Baseline 是否覆盖强替代方案	覆盖 Megatron-LM 和 mLoRA；未覆盖 Tensor Parallelism、QLoRA 专用系统、Liger / newer Torch compile / emerging LoRA training kernels 的完整组合。
Baseline 是否存在弱化风险	mLoRA kernel 被乐观等同 naive single LoRA，若未来 mLoRA 或其他系统集成强 fused kernels，差距会收窄；Megatron-Core 后续版本也可能改变 FSDP / PP baseline。
结论边界	结论可支撑“在作者实现、4-adapter summarization workloads、H100/L40S 和 Megatron-LM/mLoRA baseline 下，LoRAFusion 显著提升吞吐”。泛化到任意 PEFT variant、硬件和多租户策略需要复验。

证据链强度评估 #

强证据 #

• 论文从 profiler、runtime breakdown、arithmetic intensity 和 NCU DRAM traffic 多角度证明 LoRA overhead 的来源，且 kernel speedup 与 memory traffic reduction 对应。
• 端到端实验覆盖不同模型规模、H100 / L40S 两类硬件、homogeneous / heterogeneous datasets，以及 FSDP / PP / mLoRA baselines。
• Artifact appendix 给出公开 GitHub、Zenodo、eurosys-ae branch、环境版本和复现实验入口，支持后续复验。

中等强度证据 #

• scheduler 的收益在 4-adapter 设置中清晰，但更多 adapter、更多数据分布、更多任务类型下的分组质量仍需扩展实验。
• 论文声称 kernel 与 scheduler lossless，系统上合理，但正文主要报告 throughput；对长训练 convergence、optimizer state update 顺序和 mixed precision 数值细节需要 artifact 复验。
• L40S 结果支持跨硬件趋势，但 kernel tuning 对硬件敏感；artifact 也说明不同硬件需手动 tuning。

需要谨慎的推论 #

• QLoRA、DoRA、VeRA 兼容性目前主要在 discussion 中作为可扩展方向，正文实验没有覆盖完整 PEFT variant matrix。
• 论文说未来 compute-to-memory bandwidth ratio 增大时 fused kernels 收益可能扩大，这是基于硬件趋势的合理推论，仍需在 B200 / Blackwell 或其他 accelerator 上验证。
• “多 adapter 一起训练更高效”依赖共享 base model、足够多独立 adapter、相近训练窗口和可接受的 scheduler control plane；单 adapter 或强隔离租户场景收益有限。

OpenReview / 审稿意见吸收 #

• Venue status: arXiv comment 标注 Accepted by EuroSys 2026；DOI 指向 ACM 记录。
• Public reviews: 未发现公开 review 页面。
• Ratings / confidence: 无公开评分。
• Reviewer consensus: 无公开 reviewer consensus 可吸收。
• Main criticisms: 本地审计的主要风险是 baseline 覆盖、mLoRA 重实现条件、任务覆盖范围、质量等价验证和硬件 tuning 敏感性。
• Author response: 未发现公开 author response。
• 对本文可信度的影响: EuroSys 接收和 artifact appendix 提升工程可信度；缺少公开审稿意见时，本地判断主要依赖论文源码、artifact 公开程度和实验覆盖。

本地讨论补充 #

1. 讨论收敛点 #

• 本轮用户问题是分析 arXiv 2510.00206；没有额外技术争议需要回写。
• 本地归档把 LoRAFusion 定位为 LoRA fine-tuning systems 节点，连接 Megatron-LM、mLoRA、FSDP/PP、kernel fusion 和 multi-adapter scheduling。

2. 修正后的理解 #

• LoRA 的系统成本不能只按 trainable parameter ratio 判断。rank 很小会让 adapter GEMM memory-bound，围绕 dropout、branch add 和 gradient path 的 full activation traffic 会主导 overhead。
• multi-LoRA fine-tuning 的价值不只是共享 base model 显存；在分布式训练中，它还提供更多独立 microbatch 用于填充 pipeline bubble 和重新平衡变长样本。

3. 后续复验指标 #

• kernel：DRAM bytes、achieved bandwidth、Triton config sensitivity、forward/backward 数值误差。
• scheduler：bubble ratio、token imbalance、MILP timeout rate、no-op microbatch count、不同 adapter 数下的收益曲线。
• training：同一 global batch order 下 loss curve 是否重合，mixed precision 和 dropout seed 是否完全可审计。

主要启发 #

• PEFT 系统优化要从“参数少”推进到“activation traffic 少”。LoRA 的 adapter 参数小，但 activation 很大，系统瓶颈会转移到 memory-bound kernel。
• 在后训练平台里，共享 base model 的多 adapter 训练可以作为调度对象。只要保留每个 adapter 的 global batch 顺序，系统可以在 microbatch 层做更积极的 packing。
• kernel fusion 和 job scheduling 需要联合设计。单独优化 kernel 仍会被 pipeline bubble 和变长样本拖慢；单独做 scheduler 也会受通用 LoRA kernel 的 memory traffic 限制。

局限 #

1. 任务覆盖集中在 summarization fine-tuning；instruction tuning、code、long-context、RLHF/RLVR LoRA 和 multimodal adapter 的 workload shape 需要额外验证。
2. 主要设置为 4 个 adapters；更大规模多租户场景会引入公平性、隔离、抢占、失败恢复和数据访问权限问题。
3. Tensor Parallelism 未评估；与 Megatron-Core 后续版本、DeepSpeed、FSDP2、Liger Kernel、Torch compile 新版本和 QLoRA 专用 kernel 的组合仍需复验。
4. 调度器依赖样本长度统计和 token capacity；极端 length distribution、动态数据流或严格样本顺序约束可能削弱 packing 收益。
5. Artifact 要求 H100 / A100 / 3090 等硬件特定 kernel tuning；unsupported GPU 上的实际收益可能明显不同。

跨论文关系 #

• 与已有论文的作者关系：当前未发现直接作者重叠；新增 Zhanda Zhu、Qidong Su、Yaoyao Ding、Kevin Song、Shang Wang、Gennady Pekhimenko 作者档案。
• 与已有论文的主题关系：与 2505.11432 MegaScale-MoE 共同把 Megatron-LM 作为 baseline / substrate，并从不同层处理训练系统效率；与 1910.02054 ZeRO 共享 FSDP / model-state sharding 背景；与 2409.19256 HybridFlow、verl 官方仓库 和 slime 官方仓库 共同处在 post-training systems stack。
• 与已有论文的方法或系统关系：与 2205.14135 FlashAttention / 2307.08691 FlashAttention-2 共享 IO-aware / memory traffic optimization 思路，但 LoRAFusion 优化对象是 LoRA linear branch 和 backward path；与 2309.14509 DeepSpeed Ulysses / 2310.01889 Ring Attention 共同强调 distributed training 中 communication overlap 与 activation placement。
• 跨论文关系定位：记录 LoRA fine-tuning systems，并连接 Megatron-LM、mLoRA、ZeRO/FSDP、FlashAttention family、HybridFlow/VERL/slime 和 MegaScale-MoE。

Reference Intake Brief #

Target #

• Intended target system: 新增论文笔记 / content/utility/papers-index.md / data/authors.json。
• Existing related assets: content/utility/papers-index.md；已存档论文链接使用 /papers/<slug>/。
• Proposed form: 新建独立 Markdown 文档 2510.00206-lorafusion-efficient-lora-fine-tuning.md，更新索引和作者档案。

Reusable Elements #

1. LoRA overhead 诊断：参数少但 activation traffic 高，low-rank GEMM memory-bound。
2. split graph fusion：在 rank-$r$ 中间张量切分，融合大激活路径，保留 compute-bound GEMM tiling。
3. multi-adapter scheduler：adapter grouping、bubble lemma、MILP / greedy packing、merge / verify。

Risks #

• Copyright/over-copying: 本笔记基于论文源码摘要和实验结果重述，没有长段复制原文。
• Tone/brand mismatch: 使用本地论文归档技术分析语气。
• Safety/compliance issues: 不涉及安全攻击或可滥用流程。
• Overlap with existing assets: 与 MegaScale-MoE / FlashAttention / ZeRO / HybridFlow 有主题交叉，但研究对象是 LoRA 微调系统，适合独立归档。

Skipped #

Material	Reason
公开 reviewer comments	未发现 OpenReview/ARR/EuroSys 公开审稿页，无法可靠吸收 reviewer consensus。
完整 artifact 复现实验	本地环境没有 4 张 H100 / L40S；本轮只做论文与公开仓库分析。

Recommendation #

Decision: merge

Why: LoRAFusion 是 LoRA fine-tuning systems 的清晰节点，补齐本地档案中从 pretraining / RLHF systems 到 PEFT 微调效率之间的空白；它把 kernel fusion、multi-adapter scheduling、Megatron-LM baseline 和 artifact 公开材料组合起来，便于后续分析 post-training platform 的底层吞吐瓶颈。