Hacker News 中文摘要

RSS订阅

在Swift中训练LLM，第1部分：将矩阵乘法性能从Gflop/s提升至Tflop/s -- Training an LLM in Swift, Part 1: Taking matrix mult from Gflop/s to Tflop/s

原文链接 | HN讨论 | 2026-05-12 01:09:19

文章摘要

这篇文章介绍了作者在Swift中手动编写矩阵乘法代码以优化大型语言模型(LLM)训练性能的过程，目标是探索在Apple Silicon芯片(CPU/SIMD/AMX/GPU)上实现从Gflop/s到Tflop/s的性能突破。这是系列文章的第一篇，后续将探讨苹果的机器学习框架。作者采用"无框架、无库"的纯代码方式，不仅编写矩阵乘法内核，还将其应用于完整的LLM实现中，参考了Andrej Karpathy的llm.c项目。

文章总结

在Swift中训练LLM（第一部分）：从Gflop/s到Tflop/s的矩阵乘法优化

本文作者探索了如何在Swift中通过手写矩阵乘法代码来高效训练大型语言模型(LLM)，旨在展示Swift数学代码优化的关键步骤，并比较Apple Silicon上不同计算单元(CPU、SIMD、AMX和GPU)的性能表现。

优化历程

作者从Andrej Karpathy的llm.c项目获得灵感，这是一个用纯C实现的GPT2兼容模型。初始Swift实现性能极差，比C版本慢15-20倍。

通过以下优化步骤，作者最终将性能提升了382倍：

  1. 基础Swift实现：直接翻译C代码，性能仅达C的7.3%
  2. 使用mutableSpan：消除数组唯一性检查开销，训练速度提升3倍
  3. Relaxed数学运算：使用Swift-Numerics的Relaxed.multiplyAdd实现融合乘加(FMA)操作，推理速度提升10倍
  4. 循环展开：采用InlineArray实现类似C的循环展开，性能超越C版本
  5. 多线程优化：使用DispatchQueue.concurrentPerform，获得5.4倍加速
  6. AMX指令：利用Apple Matrix协处理器秘密指令，再获1.67倍加速
  7. Metal GPU实现：最终采用GPU计算着色器，达到1.1 Tflop/s性能

性能对比

| 实现方式 | 推理速度(tokens/s) | 训练速度(iterations/s) | 相对C性能 | |---------|-------------------|-----------------------|----------| | 基础C实现 | 0.926 | 0.175 | 100% | | 基础Swift | 0.054 | 0.014 | 7.3% | | 优化后Swift | 0.918 | 0.189 | 106.6% | | 多线程Swift | 4.356 | 1.014 | 558.5% | | AMX实现 | 5.884 | 1.678 | 958.8% | | 基础Metal | 4.29 | 2.302 | 1315.3% | | 优化Metal | 11.123 | 5.351 | 3057.7% |

结论

作者强调这些代码仅用于教学目的，实际开发应使用Apple提供的加速框架(如BLAS、BNNS、CoreML等)。下一篇文章将探讨macOS内置的高性能机器学习库。

虽然通过优化使Swift性能超越了C，但作者指出Swift在多线程实现时的代码可读性较差，期待Swift能提供更优雅的并行数组操作API。

完整代码和测试工具可从CwlLlmSwift获取，需要配合llmc-starter-pack数据集使用。

评论总结

这篇评论总结围绕四个主要观点展开：

  1. 文章质量高度评价
  • 认为这是关于Swift性能优化的杰出文章，即使不关心LLM的人也会受益（评论1："This is a pretty phenomenal article...great article on optimizing Swift performance"）
  • 作者Matt Gallagher被赞为iOS开发学习历程中的重要资源（评论3："major highlights from the early days of my journey in learning iOS development"）
  1. GPU性能讨论
  • 指出实际GPU性能往往远低于理论峰值（评论2："The real ceiling...is going to be 3-5 Tflop/s"）
  • 强调Nvidia的软件优势在于CUDA的精细优化（评论2："CUDA has so many small kernels tuned for peak performance"）
  1. 编译器优化争议
  • 强烈反对普遍使用"-ffast-math"，建议改用"-ffp-contract=fast"（评论4："one must not use -ffast-math to get FMA"）
  • 批评编译器默认禁用FMA是过时的保守策略（评论4："This policy...should have become obsolete"）
  1. 技术细节探讨
  • 对AMX指令是否保密提出疑问（评论1："I'm curious if the AMX instructions are truly secret"）
  • 指出FMA在多数情况下能提高计算精度（评论4："using FMA produces more accurate results"）

不同观点保持平衡：既包含对文章的高度赞赏，也包含对技术细节的严谨讨论，特别是关于编译器优化的争议性观点。