USAF 开源：12G 显存微调 Qwen3-30B MoE

一张 12GB 的消费卡，能微调 30B 的 MoE 模型吗？

这个问题在过去两年里，几乎没人敢正面回答。直到上周，一位 ID 为 tsuyu122 的开发者把自己憋了几个月的项目 USAF（Unified Sparse Activation Fine-tuning）扔到了 GitHub 上，用 Apache 2.0 协议直接开源。他给出的答案很干脆：只要你的显卡能跑推理，就应该能跑微调。

他自己用的是一张 AMD RX 6750 XT，12GB 显存，非 CUDA 生态，跑的是 Qwen3-30B-A3B——一个总参数 30B、激活 3B 的 MoE 模型。这个组合过去要么走 llama.cpp 推理，要么老老实实上 A100。USAF 提供了第三条路。

MoE 微调的老难题

在展开 USAF 之前，得先说清楚为什么 MoE 微调这件事一直很别扭。

稠密模型的 LoRA 路径已经被打磨得很成熟，Unsloth、PEFT、TRL 一套组合拳下来，7B 到 13B 的模型在 24GB 卡上基本没有悬念。但 MoE 不一样，它天生带着几个反直觉的问题：

• 参数总量吓人：Qwen3-30B-A3B 只激活 3B，但你要 load 的是全部 30B。推理时可以配合 offload 或 MoE-aware 内核偷懒，训练时反向传播要走的路径就复杂得多。
• 梯度稀疏但离散：只有被 router 选中的专家才有非零梯度，未激活的专家在整个 batch 里参数完全不动。这意味着 optimizer state 要不要为它们分配、怎么分配，是个精细活。
• 冻结策略争议巨大：ST-MoE 那篇经典论文早就指出，冻结 MoE 层只调非 MoE FFN 效果接近全量微调；但也有研究说完全冻结专家层会导致性能崩盘。到底调什么、冻什么，一直没有共识。
• LoRA 挂在 MoE 上不够优雅：Unsloth 前不久刚推出 Split LoRA + 自定义 Triton grouped-GEMM 内核，把 Qwen3-30B-A3B 的 16-bit LoRA 压到 63GB。这已经是工程奇迹，但 63GB 依然意味着 A100 级别的门槛。

换句话说，MoE 微调的主流路径始终围绕着「加 adapter」这个思路在优化。USAF 反其道而行——它不加 adapter，直接训原生权重，但只训一小部分。

USAF 的核心思路：稀疏训原生，不叠 adapter

USAF 的全称作者没有明确定义，但从代码和描述来看，思路可以概括成一句话：训练稀疏的专家权重子集 + router，其余全部冻结。

这里的关键差异在于：

1. 它训的是原始权重，不是 LoRA 的低秩投影。LoRA 的问题在于，为了保持低秩表达力，你得给一堆矩阵挂 A、B 两个额外张量，还得维护对应的 optimizer state。对 MoE 来说，如果每个专家都挂 LoRA，adapter 本身就是一笔可观的显存开销。
2. 它选择性地稀疏化专家内部权重。不是「只训某几个专家」，而是在每个被激活的专家内部，只更新一部分权重的子集。这样 optimizer state（Adam 需要 2x 参数量的 fp32 状态）只需要为这个子集准备。
3. router 一起训。这一点很重要。传统做法里，冻结 router 被认为能稳定路由分布，但作者显然选择了另一种权衡：让 router 跟着任务一起微调，允许专家分工重新洗牌。

从显存账本上算，这个组合的好处是显而易见的。以 Qwen3-30B-A3B 为例，激活参数 3B，如果 USAF 只对激活参数中的稀疏子集（假设是 10%~20%）计算梯度和 optimizer state，那么 optimizer 部分的显存占用直接从「30B 全量」或「LoRA 63GB」降到几个 GB 的量级。加上模型本身用 4-bit 或 8-bit 量化 load，12GB 显存把整个流程塞下并不是魔法。

和 Unsloth 的 Split LoRA 比，谁更实用？

这是我看到这个项目时的第一反应。Unsloth 在 2026 年上半年拿出的 MoE Triton 内核确实惊艳——gpt-oss-20b 微调只要 12.8GB 显存，Qwen3-30B-A3B 的 16-bit LoRA 也压到了 63GB，相比 Transformers v4 快 12-30 倍。但 Unsloth 的路径是「更快更省地跑 LoRA」，USAF 的路径是「直接不跑 LoRA」。

两者的取舍其实很清楚：

| 维度 | Unsloth Split LoRA | USAF | |---|---|---| | 目标硬件 | A100 / RTX PRO 6000 / B200 | 消费级 12GB 显卡 | | 微调对象 | LoRA adapter（rank=64） | 原生稀疏权重子集 + router | | 生态 | CUDA + Triton | 跨平台（作者用了 ROCm） | | 成熟度 | 生产级 | 个人项目，早期 | | 部署便利 | 需要合并 adapter | 直接是原生权重 |

对生产团队来说，Unsloth 显然是更稳妥的选择，尤其是它和 HuggingFace 深度合作、跑通了 torch._grouped_mm 标准化路径之后。但 USAF 有一个 Unsloth 目前给不到的东西：AMD 卡能跑，12GB 也能跑。这对那些拿着一张 6700 XT / 6750 XT / 7800 XT 想折腾 MoE 的独立开发者来说，是一个从「不可能」到「可以试试」的跨越。

一些技术判断

聊聊我对这个方案的几个判断，不一定对，抛出来大家拍。

第一，稀疏训原生权重这个方向是值得做的。 LoRA 之所以流行，很大程度上是因为它「便宜且不破坏原模型」。但 MoE 的架构天然就是稀疏的——只有部分专家激活，只有部分梯度非零。在这样的架构上再叠一层 LoRA 的低秩假设，其实是把稀疏性掩盖掉了。USAF 相当于说，MoE 本身就自带 PEFT 属性，我们应该顺着这个结构走，而不是硬套稠密模型的经验。

第二，router 一起训是有风险的。 前面提到的研究里，「轻微冻结门控」被反复提到能稳定训练。USAF 让 router 跟着更新，短期任务对齐可能很爽，但如果训练数据分布偏窄，很容易导致路由塌陷——所有 token 都被扔给固定几个专家，其他专家沦为死权重。作者在 README 里没有太多提到这一点，建议试用者盯紧 router 的负载均衡指标。

第三，稀疏子集怎么选是关键。 项目现在的实现看起来是相对简单的启发式选择。如果后续能引入类似 MoE-Sieve 那样的「热门专家识别 + 定向微调」（2026 年 3 月那篇号称砍 70% 成本几乎不掉点的工作），USAF 的效果上限会更高。目前来看，这是它最值得迭代的地方。

第四，AMD 生态终于有像样的 MoE 微调方案了。 这一点不需要多说。ROCm 长期在 LLM 训练生态里被冷落，USAF 至少证明了消费级 A 卡也能做点有意思的事情。

谁应该现在就去试试

很直接地说：

• 手上有一张 12-24GB 消费卡、想在本地跑 Qwen3-30B-A3B 或 gpt-oss-20b 微调的开发者
• 对 MoE 内部机制感兴趣、想读一份没有过度封装的实现代码的研究者
• ROCm / AMD 用户，尤其是被 CUDA-only 生态劝退过的
• 做垂类小模型定制、数据集不大（1万条以内）、能接受较慢训练速度的独立开发者

不推荐的场景：

• 需要复现论文级别数值的严肃研究
• 生产环境的线上模型微调
• 依赖 torch._grouped_mm 或 flash-attn 最新特性的项目

顺带一提

如果你只是想调 API 用 Qwen3、gpt-oss、DeepSeek 或者 Claude 这类模型，而不是折腾本地微调，OpenAI Hub 那边已经把这些模型都聚合到一个 Key 里了，兼容 OpenAI 格式、国内直连，用来做 baseline 对比或者构造微调数据集蛮省事。微调后的模型自己部署，评估阶段直接拿 Hub 上的旗舰模型当 judge，是我最近比较喜欢的一套 workflow。

写在最后

USAF 不是一个完美的项目。它是个人作品，文档不完善，benchmark 不齐全，稀疏策略也还比较朴素。但它提出了一个值得认真对待的观点——MoE 的稀疏性应该被微调方法主动利用，而不是被 LoRA 的稠密假设覆盖掉。

作者在帖子里反复强调「我不打算商业化，只是觉得有意思想分享」。这种气质在 2026 年的开源社区已经越来越少见了。不管这个项目最终能走多远，它至少给「MoE 微调该长什么样」这个问题提供了一个不那么主流、但方向感很清晰的答案。

值得 star，值得 fork，值得跑一次看看。

参考来源

• USAF 项目 GitHub 仓库 - 作者 tsuyu122 开源的 MoE 稀疏微调方案，Apache 2.0 协议
• Reddit r/MachineLearning 讨论帖 - 作者在 Reddit 上发布 USAF 的原始帖子及社区反馈
• r/LocalLLaMA 关于 MoE 微调难度的讨论 - 社区对 MoE 微调门槛的普遍观察，可作为 USAF 出现的背景参考