#profiling

rss · SemiAnalysis · 10月23日 19:06 「背景」 Trainium 已在推理侧得到验证——Anthropic 在 Trainium2/3 上跑生产推理和 RL rollout——但研究训练要覆盖快速迭代的架构、消融实验和更广的 API 面，旧栈难以胜任。 「方案」 作者认为 AWS 的关键转向是 TorchNeuron：放弃 PyTorch/XLA 的惰性图和 xm.step\(\)，改为 eager、torch.compile 与标准 API 的原生 PyTorch 体验，并挖来 Google 原生 Torch on TPU 负责人。SemiAnalysis 试用 Trainium3 数周，称方向很好但仍有 bug、远不及 CUDA 成熟；AWS 用最多 8 万物理核做自动化质控，并靠 agentic coding 加速修复。文章把训练视为通用性问题：数千算子都要反向传播，还要兼容偶然出现的高精度算子。因此 AWS 用 10 万+ Hugging Face 模型覆盖不同 normalization、MLP、MoE 与 attention 布局，除崩溃外还测性能、CPU fallback、graph break，并与 CPU/Nvidia 基线比对张量数值和 loss 曲线；作者强调，MFU 再高若数值出错也无意义。剖析器上，作者称 Neuron Explorer 优于 Nvidia/AMD 工具，并展示其细粒度剖析；Nsight Compute 偏聚合指标，QuACK 的 intra-kernel 剖析最接近但仍需定制 Perfetto 集成。但摘录中的这些优势多为体验性断言，关键演示和细节在付费墙后。 「启示」 作者的核心判断是，Trainium 正从“推理可用”转向“能承载研究训练”，关键不在峰值效率，而在原生 PyTorch 体验、训练通用性与数值正确性。方向已获其认可，但离 CUDA 级成熟仍有距离，相关优势也尚待更完整证据。 标签: AWS Trainium, PyTorch, ML training, profiling, hardware accelerators

rss · Sean Goedecke · 10月23日 00:00 「背景」 近来不少人期待让 AI 把软件重写成 C 或 Rust 来大幅提速。Sean Goedecke 认为这条路通常走不通：C 也许比 Python 快五十倍，但重写并不会带来五十倍加速。 「方案」 他的核心论据是，真实程序多为 I/O 密集型——一次 CRUD 请求可能有约一半时间花在数据库查询上，重写只能作用于剩余部分（即 Amdahl 定律），实际大概只有 1.5 倍提升。即便是明显的 CPU 密集工作，慢语言也往往已通过 cmark-gfm、NumPy 与 GPU 这类库把计算交给高度优化的 C 或汇编；tiktoken 的汇编重写虽在作者笔记本上约快 5 倍，但作者认为这更多来自去掉正则依赖的重设计，且分词只占推理时间的一小部分。Bryan Cantrill 曾试图把一段精心优化的 C 程序直译为 Rust，因借用检查器受阻后改用朴素写法，结果反而快 30%，原因是 Rust 默认的 B 树比二叉搜索树更缓存友好——即便在 CPU 密集场景，设计也压过语言。作者自己经历的显著提速几乎都来自让程序少做工作：缓存慢调用、把慢操作异步化或移出请求周期、并行化、合并 N+1 查询、换掉慢 SQL、跳过不必要的取数；而高级语言反而更容易一眼看出这些机会。 「启示」 因此，语言重写并不是严肃的优化手段；更有效的做法是让 AI 去剖析性能热点并重设计程序，只有在罕见的、无法再减少工作量的 CPU 热点上，才值得局部改写。 标签: performance-optimization, software-design, amdahls-law, profiling, io-bound