12.8GB 显存能干什么？
以前，这个容量可能只够你跑跑推理，或者勉强微调一个小参数模型。如果你想碰一下 DeepSeek V3 这种级别的 MoE（混合专家模型），那基本是白日做梦——要么爆显存，要么慢到让你怀疑人生。
但现在，UnslothAI 说：没问题，这事儿能成。
他们发布了一组新的 Triton kernels，声称可以让 MoE 模型的训练速度提升 12 倍，同时显存占用减少 35%。
这不是PPT里的画饼，而是实打实能跑在本地显卡上的代码。
说实话，看到这个数字的时候，我第一反应是：这帮人是把显卡的潜力给榨干了吗？
MoE 的“富贵病”，终于有人治了
MoE（Mixture of Experts）架构最近火得一塌糊涂。
DeepSeek、Qwen3、GLM……这些大模型背后的明星，几乎都离不开 MoE。它的逻辑很简单：与其让一个“全能”专家处理所有问题，不如找一群“专才”，每个问题只挑最相关的 8 个专家来回答。
这招很聪明，但也带来了一个“富贵病”：显存焦虑。
传统的微调方法，比如 LoRA，虽然能省点事儿，但遇到 MoE 就抓瞎了。因为 MoE 里面有 E 个专家并行存在，哪怕你只激活了 k 个，传统的 LoRA 还是得给所有 E 个专家都配上“适配器”。
这就好比请客吃饭，明明只来了 8 个人，你却按 128 人的标准备菜。
这谁顶得住？
素材里那个 Qwen3-30B-A3B 的例子就很典型。它有 128 个专家，每个专家都要加 LoRA 参数，显存占用瞬间就上去了。
Unsloth 这次做的，就是一场精准的“外科手术”。
只给干活的人发工资
Unsloth 搞了个新花样，叫 Split LoRA。
他们的思路很直接：既然每个 Token 只会激活 k 个专家，那我为什么要把 LoRA 的权重矩阵全部算出来？
他们把 LoRA 拆成了两半。只有在路由器选中了某个专家的时候，才会去计算那个专家对应的 LoRA 部分。
这听起来像是废话，但在数学上，这完全是两码事。
素材里给了一堆复杂的公式，我帮你翻译一下：在常见的序列长度下（比如 16K 以下），这种稀疏计算的方式，在算力和显存带宽上都完暴传统的全量计算。
简单说，就是只给干活的人发工资，摸鱼的一分没有。
这不仅仅是省钱，这是在抢时间。
数据不讲谎，速度就是正义
光说不练假把式，我们直接看数据。
Unsloth 拿 Qwen3 模型做了测试，结果挺吓人。
在上下文长度只有 1024 的时候，Unsloth 比标准的 Transformers 库快了 1.37 倍。
这还不算什么，随着上下文拉长，优势呈指数级放大。
到了 8192 长度，速度直接快了 7.34 倍。
更有意思的是显存占用。
在 8192 长度下，标准库需要 73.80GB 显存，而 Unsloth 只需要 47.43GB，省下了 35.73%。
这意味着什么？
意味着你以前需要两张 A100 才能干的事儿，现在可能一张卡就能搞定；以前必须租云服务，现在放在本地机器上就能跑。
评论区里有人喊出了那句大实话：“12倍的训练速度，比任何政策都更能体现 AI 的民主化。”
我觉得这话没毛病。
顺手捡到的“宝藏”
除了 MoE 的大杀器，这次更新还有个不起眼但很实用的彩蛋。
Gemma-3 现在默认用上了 Flex-Attention。
这技术听着玄乎，效果却很直白：把显存复杂度从 O(N^2) 降到了 O(N)。
以前那种动不动就 OOM（Out of Memory）的情况，现在大概率不会发生了。
素材里的数据显示，在 64K 这种超长上下文下，Gemma-3 的显存占用依然控制得很好。
老实讲，这种顺手优化的细节，比那些大口号更打动我。
Unsloth 这次还特意感谢了 Hugging Face 和 torchao 团队。
看到开源社区里这几家巨头这么和谐地“贴贴”，说实话，心里还是有点暖的。
算力霸权正在松动？
12.8GB 显存就能本地训练 gpt-oss，这事儿本身就有一种极强的象征意义。
它打破了某种“神话”——大模型训练不再是巨头实验室的专属玩具，也不再是只有拥有算力霸权的人才能玩的游戏。
当训练门槛被踩在脚下，剩下的就是创意的比拼了。
正如网友所说，这是 solo 开发者的“大规模解锁”。
我想，下一个颠覆性的 AI 应用，可能就诞生于某个只有一张消费级显卡的卧室里。
你准备好上车了吗？
参考链接：
https://x.com/UnslothAI/status/2021244131927023950