在RTX 3090上从零训练MoE：扩展GPT-2架构的完整实践
Giles用RTX 3090从零训练了一个446M参数（每token激活220M）的GPT-2风格MoE模型，训练耗时约8天。测试集loss优于GPT-2 small但不及medium，指令微调表现超过他之前所有模型。 文章详细讲解了MoE路由器的实现原理、辅助损失（auxiliary loss）如何解决负载不均衡问题，以及如何通过Masked Top-K Softmax让梯度能流回路由器完成训练。 
评论
点赞
收藏把我用 JAX 训练的模型上传到 Hugging Face Hub
Giles Thomas 把自己用 JAX 训练的多个 GPT-2 变体模型上传到了 Hugging Face Hub。由于 Transformers v5 只支持 PyTorch，他先用已有的转换脚本把 JAX safetensors 转成 PyTorch 格式再上传。 共上传了 6 个模型，分别来自他之前的 LLM from Scratch 系列教程和 Chinchilla 训练实验，每个模型都附带了对应的教程链接。
为什么OpenAI的GPT-2权重比我强？第四篇：深挖dropout
作者继续追踪为什么自己训练的模型在指令微调测试上不如OpenAI的GPT-2权重。这次聚焦dropout：在微调时开启dropout对预训练时没用dropout的模型伤害极大（最高降16分），而对预训练时用了dropout的模型影响不一。 结论是微调时不该加dropout，这反而让OpenAI模型的领先优势更令人费解。
在静态站点生成器中用 D2 添加图表
Giles Thomas 在个人静态站点生成器中集成 D2 绘图工具，解决了以往手绘和 AI 生成图表质量差的问题。他用 Python 脚本批量编译.d2 文件为 SVG，通过 ELK 布局引擎控制样式，并用内联 style 标签解决图片缩放问题。
用 PyTorch 内置 GELU，别自己手写
用 PyTorch 内置 GELU 替代手写实现，训练 GPT-2 small 模型吞吐量提升 20%（21,000 → 25,000 tokens/秒）。作者在做 MoE 扩展时偶然发现，JAX 代码一直比 PyTorch 快，部分原因正是 JAX 默认用内置 GELU，而 PyTorch 代码用的是 Sebastian Raschka 书中手写的版本。 内置版本即使开启 approximate="tanh" 精度近似，速度也几乎一样。
为什么 OpenAI 的 GPT-2 权重比我好？第二部分：IFT dropout
OpenAI 官方 GPT-2 权重在指令微调时 IFT 分数 42.43，自建模型仅 19.35，原因是 OpenAI 权重中 dropout 率非零而自建模型设为零导致过拟合。 实验对比了多种 JAX 配置，加入 dropout 后分数显著提升。
一次对Chinchilla缩放法则的快速实测
Giles Thomas用自家GPT-2风格模型实测Chinchilla缩放法则：参数和token同比例放大√2倍，测试损失确实更低，但优势仅约1%，在噪声边缘。 他同时发现，把参数均匀分配到层数和隐维度上比想象中复杂得多，随便调参很容易偏差近10%。
我在本博客中使用人工智能。
Inspired by this LessWrong post, I thought I'd write about how I use AI here. This is less in the interest of disclosure, more to provide a snapshot of what I'm doing right now so that I can revisit i...
为什么 OpenAI 的 GPT-2 权重比我自己的强？第二部分：修复 bug
作者用 ChatGPT 审读评测代码时发现了一个 bug，修复后重新生成基线数据。OpenAI 的 GPT-2 权重在指令跟随评测上仍优于自己的模型。 评测流程：在 Alpaca 指令数据集的子集上多 epoch 训练，每个 epoch 结束后在验证集上计算 loss，loss 开始上升时提前终止；最终用 GPT 5.5 作为 judge 对多个模型的输出进行交叉打分。 bug 影响了基线数值和模型排序，但不改变核心结论。
为什么 OpenAI 的 GPT-2 权重比我训练的模型表现更好？
GPT-2 small 在指令微调评估中得分 26.73，远超作者训练的同类模型最高分 20.71，尽管后者的测试损失更低。作者提出假设：OpenAI 权重的初始位置更接近指令微调的损失洼地，且使用了 weight tying，使其在小参数规模下表现更优。
在RTX 3090上对Qwen 3.6 35B MoE（3B活跃）进行基准测试
<p>我在群聊里提到我买了第二台RTX 3090，一个朋友说：</p><p>我知道这不是你的菜......但请告诉我它运行得有多快 Qwen 3.6 350亿 MoE。只有24GB显存，你需要用4位量化显存 版本不同，你不会看到巨大的上下文窗口。但应该还是 挺酷的。</p><p>他说得对，这其实并不是我的风格——我一直在专注于我的 最近拥有了LLM。我决定深入挖掘，特别是玩玩，我已经有一阵子没用了。然后事情变得 有点失控，我最终做了一些相对详细的基准测试。</p><p>标题结果是：我下载了Unsloth对模型的UD IQ4_NL_XL量化 来自.说到这里， 使用默认的Arch Llama.cpp版本，底层搭载Vulkan：</p><p>仅用GPU时，我能让模型生成速度刚好超过120个令牌每秒， 而且它能以略低于2800 tok/s的速度处理提示。然而， 整个模型放在GPU上，上下文空间不大 窗口——它被限制在大约50,000个代币，相比模型的 本地语境长度为262,144。</p><p>将模型40层中前12层的FFN卸载给CPU后，成功回收了 足够多的显存以获得完整的上下文长度;然而，按照这样的设定， 事情——毫不意外地——变得更慢了。我生成的 tok/s 刚好超过 65， 提示音为600 Tok/s。</p><p>我自己整理Llama.cpp，获得完整的CUDA版本，帮助很大：</p><p>所有设备都装在显卡上，我生成时输出为140 tok/s，超过3300…</p>