GPU

64 篇内容

技术文章NVIDIA Technical Blog

Run Local Agentic AI Workflows with Meta’s Muse Glimmer on NVIDIA

文章介绍了Meta开源的Muse Glimmer模型,这是一个30B参数的密集模型,拥有120K+上下文窗口,专为本地AI代理工作流设计。通过NVIDIA的优化,该模型可在边缘、桌面和工作站等GPU平台上高效运行,单GPU推理速度可达20K tokens/sec。文章详细说明了模型在本地运行时的优势,包括数据隐私保护、低延迟以及始终在线的能力,并展示了其在复杂代理任务中的表现。内容侧重于技术部署和性能基准,为开发者在本地构建和运行代理AI提供了实践指导。适用边界主要在于依赖NVIDIA GPU生态,且模型尺寸对硬件资源有较高要求。

推荐收录,因为文章不仅提供新模型的关键技术特性,还给出了在NVIDIA平台上的具体性能数据和部署方法,为需要本地运行大模型代理的工程师提供了可参考的优化路径。适合关注隐私、低延迟和边缘AI的开发者和研究者,其性能基准和硬件适配经验对类似场景具有直接迁移价值。

工程实践知乎 - 严格鸽

LeetGPU Hard 题目笔记(4)Sliding Window Self-Attention(暂时第一)

本文记录了一道 LeetGPU Hard 题目——FP32 滑动窗口自注意力在 T4 GPU 上的优化过程,目标是将 5000×64、window_size=16 的推理加速到极致。作者从 256 线程、每 warp 处理一个 Query 的基线出发,通过 shared memory bank conflict 消除、K/V 共享 tile、交错 query 提升 ILP、手写 PTX 倒数近似加牛顿迭代、去掉 Q 的 shared memory 缓存以提升 occupancy 等手段,将时间从约 0.28 ms 优化到 0.177 ms。文中逐一展示了各版本的关键改动和性能收益,最终方案减少了一次 shared memory staging,并通过 #pragma unroll 16 平衡了控制开销与寄存器压力,在单 T4 上取得目前第一名成绩。整体适用于固定窗口尺寸的批量自注意力加速场景,但优化策略(如 occupancy 调优、PTX 指令替换)可迁移至其他类似 GPU 内核开发中。

推荐收录,因为它不是简单的竞赛题解,而是一个完整的 GPU 内核优化案例,清晰展示了从并行设计到微架构调优的迭代过程。文中对 bank conflict 处理、warp shuffle reduction、PTX 指令精度与速度平衡、shared memory 容量与 occupancy 权衡等都有具体讨论,对学习 CUDA 优化或处理类似 reduction+attention 模式的高性能计算开发者具有直接的参考和可迁移价值。

工程实践Stanford Hazy Research

Retire the Abstractions

本文以编写 CUDA megakernel 的经验为起点,提出 AI 编程智能体正在取代传统软件抽象层的认知卸载功能。作者回顾了去年依靠 C++ 抽象管理复杂性的痛苦,以及今年借助 agent 直接将不完整的提示转为优化代码的实践,由此预言 CUDA DSL 等抽象层即将退役。文章进一步讨论代码库角色的迁移:精确的代码库变得脆弱,而模糊但可传递的意图提示更适应智能执行器;信任将更多放在规约、测试和不变量等 oracle 上,而非实现细节。同时,作者也指出抽象层作为共享验证面、知识传递手段仍具价值,且专家经验在此转型中不可或缺。全文核心观点是抽象会退役,但领域知识永存。

推荐收录,因为本文不是泛泛而谈的未来预测,而是基于真实 megakernel 工程演进提出的具体论证,提供了从认知外包到代码生命周期重估的完整视角。适合关注 AI 辅助系统编程、DSL 设计与软件工程演化的研究者与工程师,可迁移的思考在于如何重新权衡代码、测试与意图描述在智能工具介入后的角色。

工程实践Meta Engineering

GEM Training: How Meta Doubled the Efficiency of Its LLM-Scale Ads Foundation Model

本文介绍了Meta如何将广告推荐基础模型GEM的训练规模提升至LLM级别,并在12个月内将端到端训练效率提升一倍至20-25%模型算力利用率(MFU),同时训练算力规模扩大4倍。文章从计算效率和扩展效率两个维度分别展开:计算效率通过定制化推荐内核库(Jagged Flash Attention、Generalized Dot-Product Attention、BlockAttention)和混合超低精度训练(MXFP8注意力与MLP)实现;扩展效率则依靠拓扑感知的5D并行策略(2D FSDP加专家并行处理稠密参数,全分片2D模型并行处理稀疏参数)配合SM-free通信、自动激活检查点及序列长度感知负载均衡。所提方案针对推荐系统特有的变长序列、非对称交互和数值敏感性等挑战进行了专门设计,其方法论和具体技术对大规模推荐模型训练具有参考价值,但部分优化(如内核定制)与特定GPU架构强相关,迁移时需适配自身硬件和数据特性。

本文是真实的工业级工程案例,完整展示了在数千GPU上训练万亿参数推荐模型的全栈优化过程,涵盖内核、精度、并行、网络和内存的协同设计,而非孤立技巧罗列。适合负责大规模深度学习训练、推荐系统基础设施或GPU性能优化的工程师,可迁移价值在于其将MFU分解为计算效率和扩展效率的分析框架,以及针对混合架构和变长数据的特定解决方案,对类似规模系统的构建与调优具有直接借鉴意义。

工程实践Cloudflare Blog

Smaller, faster, safer: running Kimi and GLM at scale

文章介绍了在 Cloudflare Workers AI 上运行大型长上下文 MoE 模型 Kimi 和 GLM 时,为应对内存限制而采用的三项优化技术:将 KV 缓存从 BF16 量化为 FP8,使上下文容量翻倍,峰值吞吐提升 41%;将模型权重从 FP8 压缩为 INT4,显存占用降低 40%,解码加速明显;以及构建 KV 缓存完整性检查机制,防止多请求共享时发生数据错乱,且开销低于 1%。所有优化均通过分离 prefill 和 decode 阶段,在各自优势场景下使用不同精度,从而在保持模型准确度不变的前提下,显著提高并发并降低单位 token 成本。这些实践基于 SGLang 框架和 H200 GPU,验证了工程方案的有效性和边界。

推荐收录,因为文章不仅是孤立的性能技巧,而是展示了从内存瓶颈分析、多策略选择(量化、压缩)、安全防护到阶段分离的完整工程决策过程。文中提供了大量对比测试数据、精度验证和架构取舍说明,对负责大模型推理部署、AI 基础设施优化的工程师具有直接的可迁移价值,其中的阶段性精度切换和多请求缓存保护思路尤其值得借鉴。

工程实践BAIR Blog

From CUDA to MLX: How K-Search Brings Decades of Kernel Expertise to Apple Silicon

本文介绍了一种将NVIDIA CUDA GPU的kernel优化知识自动迁移到Apple Silicon MLX框架的方法。作者基于K-Search进化搜索框架,构造了结构化的CUDA-to-MLX翻译层,通过概念映射表、MLX特定模式与硬件约束,将数十年的CUDA优化经验转化为Apple GPU可用的指导。K-Search利用LLM迭代推理、生成和实测kernel,通过世界模型树搜索实现自动优化。实验表明,在Attention kernel上达到原生MLX性能的0.97倍,在Mamba SSM kernel的prefill阶段获得了相对社区实现的20倍加速。文章展示了瓶颈在于提供给LLM的上下文质量而非代码生成能力,该方法不限于MLX,可扩展到其他硬件生态。当前仅在两个kernel上验证,广泛适用性有待进一步检验。

本文详细记录了利用AI驱动的进化搜索实现跨硬件平台kernel优化的工程实践,提供了从原理到实现的完整路径,并包含可复现的实验对比。适合GPU kernel开发、AI系统优化和跨平台移植的研究与工程人员,其结构化翻译思路和领域知识注入方式对降低kernel开发门槛具有明确的迁移价值。

技术文章知乎 - 严格鸽

从LeetGPU的一道题目到 Radix TopK / AIR TopK

本文以 LeetGPU 上的 Top-K 选择题目为切入点,系统介绍了在 GPU 上利用 Radix TopK 和 AIR TopK 算法高效完成最大 k 个元素选取的方法。作者首先处理了浮点数无法直接按二进制位比较的问题,通过 ordered_bits 转换将 float32 映射为保持数值顺序的无符号整数。然后详细演示了 Radix TopK 按高位到低位分桶、定位 splitter bucket 并逐步缩小候选范围的过程,给出了具体步骤和代码示例。在此基础上引入 AIR TopK(Adaptive and Iteration‑fused Radix Top‑K),说明当候选数据量下降到一定程度时,可以向专用 buffer 收集候选元素,以减少后续轮次的扫描开销。文章还提及 CUB 中的每轮 11 位处理策略,并给出性能测试结果。全文适用于了解 GPU 上的并行 Top‑K 算法实现,对大规模数据、k 较小场景有直接参考价值,但迭代融合部分的实测效果不显著,且测试环境主要基于 T4,硬件差异可能需要进一步验证。

本文从实际题目出发,深入讲解了 GPU 上 Radix TopK 和 AIR TopK 的算法原理与优化,提供了可运行的代码示例和清晰的图示,不是简单的问题解答或操作指南。对需要实现高性能 Top‑K 选择的 CUDA 开发者、并行算法研究者具有直接的参考价值,文中的 ordered_bits 转换、分桶筛选和自适应收集等思路可以迁移到其他基于 GPU 的排序与选择任务中。

工程实践知乎 - 严格鸽

LeetGPU Hard 题目笔记(3)GPT-2 Transformer Block(暂时第一)

文章记录了作者在 LeetGPU 平台完成 Hard 题目“GPT-2 Transformer Block”的完整优化过程。从朴素 CUDA 实现开始,逐步引入 FlashAttention 分块计算以避免完整 scores 矩阵的显存读写,但发现普通 CUDA Core 上 FlashAttention 融合并未带来理想加速。随后利用 Tensor Core 的 WMMA 指令,将数据转为 FP16 进行矩阵乘法,性能大幅提升至 22.88 ms。最终作者放弃 FlashAttention,转而直接用 WMMA 实现 QK 和 PV 计算,结合合并内存分配、手动分支消除等微调,将总耗时压至 13 ms。文中给出了核心 kernel 代码和不同方案的性能对比,揭示了在特定精度要求不高的 T4 环境下,直接使用 Tensor Core 可能比融合 kernel 更优的工程取舍,但未涉及长序列或大规模分布式推理场景,结论的环境依赖较强。

推荐收录为真实工程优化案例,因为它完整呈现了从算法理论(FlashAttention)到硬件指令(WMMA)再到性能调优的迭代链条,包含可运行的 kernel 代码和明确的性能数据,适合学习 GPU 编程和 Transformer 推理优化的开发者。文章的核心经验——“在特定硬件和精度约束下,直接使用 Tensor Core 可能优于融合内存节省的算法”——具有可迁移的权衡思维,但需注意其结论仅适用于小规模、精度要求不高的类似任务。

工具笔记NVIDIA Technical Blog

Debugging Ray Tracing Applications Using NVIDIA OptiX Toolkit

本文介绍了 NVIDIA OptiX Toolkit(OTK)中用于调试光线追踪应用的实用工具,包括 API 验证层、GPU 调试器及性能分析器。文章从常见失败场景(如无效 API 参数、黑帧、GPU 端线程错误)出发,说明如何利用 OTK 暴露的调试功能定位问题,并给出具体使用方法和命令行示例。内容侧重于工程实践中的故障诊断流程,而非纯理论,适合需要快速排查 OptiX 应用错误的开发者。

收录理由:文章提供了可直接操作的 OptiX 调试工作流和工具链,对从事 GPU 光线追踪开发的读者具有明确的可迁移价值;内容来自 NVIDIA 官方技术博客,示例具体,非泛泛介绍。建议新增“Debugging”标签以更精确反映主题。

技术文章NVIDIA Technical Blog

Make Long-Running NVIDIA TensorRT Engine Builds Observable and Cancelable in Python or C++

本文针对长时间运行的NVIDIA TensorRT引擎构建过程缺乏可观测性和中断能力的问题,提出了一种在Python和C++中实现的方案。作者首先分析了构建耗时场景,包括强类型模型、深度策略搜索和冷缓存,指出传统集成因缺乏进度反馈和取消机制常导致开发者盲目等待或浪费资源。随后介绍通过进度回调、剩余时间估计和取消令牌等机制,使构建过程透明化并可安全终止。文中还讨论了多线程环境、跨平台兼容性及不同TensorRT版本下的适用边界与潜在风险。该技术适用于模型部署、自动化推理优化和AI工具链中TensorRT引擎生成环节,特别在批量构建和无人值守场景中可显著提升开发效率和资源利用率。

推荐收录,因为它针对TensorRT工程化中的真实痛点提供了可复用的解决方案,有效提升了构建过程的透明度和可控性。文章源自NVIDIA官方技术博客,具备较高的技术可靠性,适合所有使用TensorRT进行模型部署和优化的AI工程师、研究者参考,尤其对于自动化构建流水线和大规模模型调优场景具有直接可迁移价值。

技术文章知乎 - 严格鸽

在GPU上寻找HashMap是否搞错了什么——cuCollections代码解析

文章深入解析了NVIDIA cuCollections库中GPU哈希表static_map与dynamic_map的实现细节。static_map采用固定容量的开放寻址设计,默认以4个CUDA线程为一组(tile)协作插入或查找一个键,利用CAS原子操作解决并发写入冲突。文中详细说明了强类型哨兵、线性探测方案(ProbingScheme)、存储配置(Storage)等模板参数的作用,并结合代码剖析了插入和查找CUDA kernel的完整流程。dynamic_map通过维护多个static_map子表实现自动扩容,但旧数据不搬迁,导致查找需遍历所有子表,成本随扩容次数递增。整体上,文章为理解GPU上并发哈希表的协同设计与工程实现提供了清晰的代码级参考,适用于GPU加速数据库等场景,但缺乏性能评估与扩容策略的深入对比。

文章直接展示了GPU哈希表的线程协作、CAS并发控制等关键工程实现,代码解析深入,具备长期参考价值。适合CUDA开发者、数据库加速系统设计者理解GPU上数据结构的设计模式与约束。可迁移价值在于组合作、原子操作在并发容器中的实际应用,但需注意文中未给出性能基准,实际选型时还需自行测试。

技术文章NVIDIA Technical Blog

NVIDIA NVLink: The Scale-Up Network for AI Factories

文章系统介绍了NVIDIA NVLink技术在AI工厂中的横向扩展网络角色,从第一代到第五代的演进,重点解析了第五代NVLink提供的1.8 TB/s总带宽、NVSwitch实现的GPU全互联拓扑,以及NVLink-C2C实现Grace CPU与Blackwell GPU间内存一致性的片间互连。作者结合DGX和HGX系统实例,展示了NVLink如何支撑万亿参数模型训练和实时推理,并概览了未来NVLink 6和7的性能指标。文章主要基于NVIDIA官方视角,对NVLink技术的原理、性能和系统架构提供了深入描述,但内容局限于NVIDIA生态系统,未涉及替代方案或成本权衡。

推荐收录,因为文章详细解释了NVLink的协议设计、拓扑演进和性能数据,并提供了具体的系统集成案例,对于需要理解大规模AI训练基础设施的工程师和架构师具有明确参考价值。尽管带有官方宣传色彩,但其技术深度仍可帮助读者掌握GPU互连对系统设计和可扩展性的影响,适合作为硬件架构和AI系统工程的学习材料。

技术文章NVIDIA Technical Blog

Integrate NVIDIA Omniverse RTX Sensor Simulation Into Existing Apps

文章介绍NVIDIA CTK Sensor RTX Python API,该独立安装包允许开发者在现有应用中集成基于物理的RTX传感器模拟功能,生成带标签的合成数据,如摄像头图像、激光雷达点云和雷达数据,用于感知AI训练与测试。文中通过代码示例展示配置传感器与环境、渲染数据、应用颜色映射、生成实例分割掩码和深度图等关键步骤。方案无需完整Omniverse套件,支持自定义OpenUSD场景、SimReady资产或导入自有数据,但要求系统配备NVIDIA RTX GPU并限定于物理精确渲染任务。适用于希望在现有工具链中嵌入传感器模拟的机器人、数字孪生和自动驾驶工程师。

该文提供了将RTX传感器模拟集成到非Omniverse应用的实用API和完整示例,技术细节清晰,直接支撑合成数据生成工作流。对计算机视觉、机器人及自动驾驶领域的开发者,能显著降低独立环境搭建的成本,迁移价值高。

科研议题知乎 - 微软亚洲研究院

SlideSparse:拓展结构化稀疏边界

文章提出 SlideSparse,首次在 NVIDIA GPU 上使 6:8、4:6 等温和结构化稀疏模式利用稀疏张量核加速,填补了长期技术空白。核心方法是通过滑动窗口将不满足 2:4 约束的权重块分解为多个重叠的 2:4 子块,以适度数据膨胀换取硬件加速,理论加速比约 1.33 倍。权重变换离线完成,输入侧重排融合进推理 kernel,系统集成于 vLLM。实验在多种 GPU、精度和模型上验证,Prefill 阶段接近理论上限,Decode 阶段也有一定提升,证明了通用性与实用性。该工作将稀疏优化从极端二选一扩展为灵活配置,使稀疏成为与量化并列的推理优化维度。

SlideSparse 解决了温和稀疏无法硬件加速的长期痛点,通过滑动窗口分解实现计算套利,有扎实的理论分析和充分的工程验证。文章适合关注大模型推理优化、稀疏压缩或系统部署的读者,其思想可迁移至其他稀疏模式或硬件后端,具有较高的长期参考价值,推荐收录。

工程实践知乎 - 严格鸽

LeetGPU Hard 题目笔记(1)(三道暂时排名第一的题)

文章记录了作者在LeetGPU平台解决三道Hard题并取得暂时排名第一的过程,覆盖了Multi-Agent Simulation、K-Means Clustering和All-Pairs Shortest Paths。对于多智能体模拟,利用随机分布的假设设计了基于空间网格的邻居查找优化;K-Means通过将聚类中心放入共享内存、展开循环并运用cooperative_groups实现跨块同步,提升并行效率;全源最短路采用分块Floyd‑Warshall算法,将矩阵划分为64×64个小块,使用共享内存和寄存器优化。每道题均给出了题意分析、核心思路、关键代码链接及性能结果,适用于测试数据范围,展示了从简单实现到充分利用GPU硬件特性的工程优化过程。

推荐收录,文章提供了三道具体GPU编程题目的完整解法与优化历程,不仅是代码片段,更展示了性能分析、网格划分、共享内存使用、cross‑block同步等实用工程技巧,对从事GPU并行算法开发和性能优化的读者有直接参考价值,相关方法可迁移至其他密集计算或聚类类问题。

技术文章NVIDIA Technical Blog

Building Faster Cryptography with Carryless Multiplication in NVIDIA CUDA 13.3

文章详细介绍了NVIDIA CUDA 13.3中新引入的进位乘法指令,这一特性填补了GPU在此之前缺乏原生进位乘法硬件的空白。文章首先回顾了进位乘法在x86 CPU上的历史及其在认证加密、纠错码和零知识证明等密码学算法中的基础作用,然后解释了新PTX指令__nv_cmul的用法和编程模型,并通过基准测试展示了其在典型密码学操作上相对于纯软件实现的显著加速。文章还指出了当前支持的GPU架构范围,并讨论了该指令在特定算法中的适用性与性能边界。

推荐收录,因为文章不是简单的版本发布公告,而是深入解释了硬件指令的原理、应用场景和性能数据,对从事GPU密码学实现或高性能计算的开发者具有直接参考价值。读者可以迁移文中介绍的指令用法和优化思路到自己的项目中,内容具备长期技术参考性。

工程实践知乎 - 严格鸽

从leetgpu的一道题目到CUB中的Decoupled look-back

本文以LeetGPU上的一道stream compaction题目为切入点,记录了从基础的多kernel前缀和实现到借鉴CUB的Decoupled look-back算法的完整优化过程。作者首先解释了题目要求和并行化思路,然后逐步融合算子、调整tile大小,最终引入基于状态的look-back机制,将全局扫描的读写复杂度降至2N。文章详细展示了tile状态机的设计、warp级扫描与lookback_sum的实现,以及针对写回路径的shared memory/global memory双路径优化。此外,还涵盖union复用shared memory、 sleep等待策略等工程技巧,并对比了Thrust和手写CUDA的性能差异。整体呈现了一个从简单到高性能的实战优化路径,适用于单GPU上的稳定stream compaction,但算法思想可迁移到其他并行扫描场景。

收录理由:本文不是单纯的代码片段或性能报告,而是展示了从算法选型到微观工程优化的完整决策链,包括对Decoupled look-back原理的剖析、状态机设计、warp级协同和硬件调优。对学习CUDA性能优化、并行扫描算法以及从CUB源码借鉴实践的读者具有直接参考价值,文中的look-back模式、shared memory复用和双路径写回策略均可迁移到类似的高性能GPU编程场景。

工程实践NVIDIA Technical Blog

Reducing High-Bandwidth Memory Bottlenecks in JAX-Based LLM Training with Host Offloading

本文针对大型语言模型训练中 GPU 高带宽内存(HBM)容量不足的瓶颈,提出并详细讲解了基于 JAX 的主机内存卸载方案。作者将模型参数、梯度、优化器状态等张量通过 JAX 的分片与异步传输机制卸载到主机内存,结合激活重计算进一步降低 HBM 占用,同时利用主机内存带宽和传输隐藏策略减少吞吐损失。文章给出了完整的代码示例与性能分析,在 LLaMA 风格模型上实测了显著的 HBM 节省效果,并讨论了该方案适用的模型规模、序列长度及通信环境约束。

推荐收录,因为文章不是简单的 API 介绍,而是深入剖析了 LLM 训练的内存瓶颈,并提供了一套可复用的主机卸载方案,包含具体实现、性能数据和工程取舍。对从事大模型训练、GPU 内存优化或 JAX 框架开发的工程师和研究者有直接的参考价值,其中的异步卸载策略和内存–计算权衡思路可迁移到其他框架和硬件平台。

技术文章NVIDIA Technical Blog

Kernel Fusion in NVIDIA CUDA: Optimizing Memory Traffic and Launch Overhead

本文深入探讨了CUDA中的内核融合技术,旨在缓解GPU计算与内存带宽之间的瓶颈。文章从GPU内存带宽不足以完全利用计算能力这一常见问题出发,详细解释了内核融合如何通过合并多个CUDA内核来减少内存传输和内核启动开销。文中介绍了多种实现融合的方法,包括手工编写融合内核、利用CUDA图动态融合以及通过编译指示自动融合等,并对比了各自的适用场景和潜在局限。文章还指出,内核融合虽然能够提升性能,但可能增加寄存器使用量和代码复杂度,需在具体情况下权衡。整体而言,该文为GPU性能优化提供了系统性的实践指导,特别适用于受内存带宽或启动延迟限制的计算密集型应用。

本文来自NVIDIA官方技术博客,从问题背景、优化原理到多种实现方式进行了系统阐述,并提供了可操作的代码示例和权衡分析。对于从事GPU编程、性能优化或HPC领域的开发者,文中关于减少内存瓶颈和启动开销的策略具有直接指导意义,可迁移至其他受类似约束的计算架构中。因此,该文具备长期参考价值,适合收录为技术深文。

技术文章NVIDIA Technical Blog

AI Model Co-Design: Hardware-Friendly LLM Design

文章探讨了AI模型与硬件协同设计的方法,旨在在不牺牲准确性的前提下提升LLM推理的吞吐量和交互延迟。作者分析了Transformer、Mamba等模型架构对GPU内存带宽、计算利用率和KV缓存等硬件资源的影响,指出减少注意力头的GQA等变体能有效降低内存压力。通过对比不同模型在NVIDIA H100 GPU上的推理性能,展示了选择硬件友好架构(如状态空间模型)带来的吞吐量提升。文章还讨论了量化、批处理等优化技术的权衡,并强调协同设计需贯穿模型开发早期阶段。结论是,通过架构层面的针对性设计,可显著提升LLM推理效率,但需要根据具体硬件特性进行定制化权衡。

该文不是泛泛的性能调优介绍,而是深入模型架构与硬件底层特性的匹配原理,通过具体数据对比和工程分析展示了协同设计的实际价值。适合从事AI推理部署、模型优化或系统架构的工程师和研究者参考,其方法论可迁移至其他模型或硬件平台的性能优化。因此推荐收录。

工程实践NVIDIA Technical Blog

Enhancing Goodput in Large-Scale LLM Training with Nonuniform Tensor Parallelism

文章讨论大规模 LLM 训练在上千张 GPU 上运行时,因设备短暂不可用、资源波动和长尾故障而导致的 goodput 损失问题。作者提出非均匀 tensor parallelism:不再强制所有并行分片使用相同的张量并行度,而是根据可用硬件与作业状态动态调整不同分片的并行配置,以减少阻塞和重分配开销。文中把目标从单纯吞吐转向有效训练产出,强调在恢复、容错和资源利用之间做权衡。该方法更适合超大规模训练集群和频繁扰动环境,对稳定、小规模或编排能力有限的场景收益可能较弱。

收录价值在于它直面大规模训练中“有效产出”而非表面吞吐的问题,并给出非均匀 tensor parallelism 这一可迁移的系统思路。适合做 LLM 训练平台、GPU 集群调度和容错优化的工程师参考,但其收益依赖集群规模与故障/波动频率。

工程实践NVIDIA Technical Blog

Optimizing a Neural Reconstruction Pipeline Using NVIDIA Nsight Developer Tools

文章围绕 NVIDIA Omniverse NuRec 神经重建流水线的性能优化展开,目标是把来自相机、激光雷达等多传感器数据构建为高保真三维环境的过程做得更快、更稳定。作者以 Nsight 系列开发者工具为核心,先从端到端剖析 CPU、GPU、内存拷贝和各阶段调度开销,再定位流水线中的主要瓶颈与资源空转点。随后通过针对性的 kernel 优化、执行重排和数据搬运改进,验证了性能收益并说明了优化前后的差异。文章的重点不在算法创新,而在如何借助 профiliing 工具建立可重复的性能诊断流程。其方法适合 GPU 密集型 AI/图形管线,但结论会受具体硬件、数据分布和 NVIDIA 工具栈限制。

推荐收录,因为它明确展示了用 Nsight 工具从端到端定位 GPU 管线瓶颈、再逐步验证优化收益的完整过程。对做 AI 重建、仿真、图形或其他 GPU 密集型系统的读者,文中的分析框架和排障顺序具有直接迁移价值,但结果依赖 NVIDIA 生态与具体 workload。

工程实践NVIDIA Technical Blog

Creating the NVIDIA Nemotron 3 Ultra NVFP4 Checkpoint with NVIDIA Model Optimizer

文章介绍了如何借助 NVIDIA Model Optimizer 将 Nemotron 3 Ultra 转换为 NVFP4 checkpoint,以降低大模型权重搬运成本并提升长上下文场景下的推理效率。核心思路是利用 Blackwell 架构引入的 NVFP4 4-bit 浮点格式,对模型权重进行量化压缩,在尽量保持模型质量的同时显著减少显存占用和带宽压力。文中强调这种做法并不是通用“无损压缩”,而是依赖特定硬件与工具链的协同,适合追求吞吐、延迟和部署成本平衡的 LLM 推理链路。其价值主要在于给出从原始模型到可部署 checkpoint 的实际路径,但适用边界也很明确:需要 Blackwell 相关能力,且对精度敏感任务仍需额外验证。

推荐收录,因为文章直接给出了基于 Model Optimizer 生成 NVFP4 checkpoint 的工程路径,明确涉及 Blackwell、4-bit 量化和推理性能优化。适合做大模型部署、显存压缩和 GPU 推理优化的读者参考,但需注意它强依赖特定硬件与量化误差验证。

工程实践知乎 - 腾讯技术工程

腾讯混元AI Infra如何优化Hy3 Preview:一次大模型推理性能提升的技术拆解

本文拆解了腾讯混元 Hy3 preview 在 Hopper 96G 上的推理全栈优化,围绕算子优化与融合、并行策略、多级缓存、MTP 异步调度、量化与稀疏五个方向展开。作者针对 Attention、MoE、Router、采样、AllReduce 等关键路径做了动态调度、双 BF16 GEMM、FusedMoE、通算融合和算子级融合,显著减少 HBM 往返与 Kernel 启动开销。系统层面又通过 TPSP、DP+EP、三级缓存和按最大接收长度预组装输入,缓解长上下文、MoE 与 MTP 带来的通信、显存和 CPU 气泡问题。文中给出了真实请求集与多组实测指标,如 TTFT 降幅约 24.5%~29.9%、端到端吞吐提升 15.7%~44.7%、量化后吞吐提升 28%+、稀疏注意力在 128K 上将 Prefill 延迟降低 3.6 倍。整体方法高度依赖 Hopper 架构、自研 kernel 与腾讯内部基础设施,迁移到其他模型或硬件时需要重新验证边界与收益。

收录,因为文章给出了真实请求集、Hopper 96G 和 W8A8C8 约束下的系统性优化路径,并明确量化了 TTFT、吞吐和单算子加速收益。适合做大模型推理、GPU Kernel 融合、并行与缓存设计的参考,但方案强依赖特定硬件与自研栈,迁移时需重做适配验证。

工程实践NVIDIA Technical Blog

Streamlining Resource Binding with End-to-End Support for Vulkan Descriptor Heaps

文章围绕 Vulkan 中的资源绑定机制,讨论如何通过 descriptor heaps 让着色器访问纹理、缓冲区等 GPU 资源时减少繁琐的逐项绑定操作。作者先解释传统绑定方式的管理成本与 CPU 开销,再介绍端到端支持的实现思路,即把资源组织、句柄分配和运行时访问路径统一起来,以降低绑定频率并改善提交效率。文章还强调这种方案对驱动、API 和应用侧需要协同适配,不能简单理解为“更快的接口”,而是绑定模型与资源生命周期的整体重构。其价值主要体现在资源数量大、绑定切换频繁的渲染场景,但收益会受硬件、驱动成熟度和应用架构影响。

文章直接讨论 Vulkan 资源绑定模型、descriptor heaps 的端到端支持路径,以及它对 CPU 开销和绑定管理复杂度的影响,属于可迁移的 GPU 图形系统经验。适合做图形引擎、渲染管线和底层 API 设计参考,但其收益依赖具体驱动与使用场景,不宜脱离上下文套用。

工程实践NVIDIA Technical Blog

Boost Inference Performance up to 15x on NVIDIA Blackwell Using DFlash Speculative Decoding

这篇文章讨论了在 NVIDIA Blackwell 上通过 DFlash speculative decoding 提升大模型推理性能的方法,核心问题是自回归 LLM 逐 token 生成导致的低 GPU 利用率和高延迟。文章强调用轻量 draft model 先预测候选 token,再由主模型验证,以此在延迟敏感和多智能体工作流场景中提升吞吐与响应速度,并给出最高可达 15x 的性能提升结论。其价值主要在于解释 speculative decoding 的推理瓶颈缓解思路,但具体收益高度依赖模型、提示分布、硬件与服务配置。

推荐收录,因为它围绕大模型推理的核心瓶颈给出了具体优化路径,且 speculative decoding 本身是可迁移到多种推理系统的通用思路。虽然标题带有明显的硬件性能宣传色彩,但文章主题对关注低延迟 serving、GPU 利用率和推理加速的读者仍有参考价值。

工程实践知乎 - 手抓饼熊

GTC 2026 技术分析:通过 CUTLASS Python 在 Blackwell GPU 上实现 GEMM 峰值 Tensor Core 性能

这篇文章基于 GTC 2026 关于 CUTLASS Python 的演讲,系统分析了如何在 Blackwell GPU 上围绕 GEMM 逐步逼近 Tensor Core 峰值性能。文章从基础 GEMM 的分块、TMA 传输、TMEM/RMEM/SMEM 流水线讲起,进一步比较了 2CTA、Warp Specialization、TMA Store、Persistent Kernel、Preferred/Fallback Cluster、Dynamic Scheduler 和 PDL 等优化手段在不同矩阵规模与瓶颈条件下的收益与边界。全文不仅给出性能数据,还强调了不同规模下瓶颈会从 DRAM 延迟、epilogue 开销转向 L2 命中率和调度效率,适合作为 Blackwell 上高性能 GEMM 编程的系统性参考。

推荐收录,因为它不是单纯介绍 CUTLASS Python,而是把 Blackwell 架构特性、内存层次、调度机制和性能结果串成了一条完整的优化路径。对做 GPU kernel、推理加速或高性能矩阵计算的读者来说,这些关于瓶颈切换、流水线隐藏和 cluster 调度的结论具有很强的可迁移性。

技术文章知乎 - 手抓饼熊

Tensor Core 编程与优化深度技术解析 — GTC 2026

这篇文章系统梳理了 NVIDIA Tensor Core 的编程模型与优化方法,覆盖 Warp Level、Warpgroup Level 到 Blackwell 第五代 Tensor Core 的演进,并把 Nsight Systems/Nsight Compute 的分析方法、TMA 流水线、CuTe/CUTLASS 编程框架串成一条完整优化路径。文章不仅解释了 MMA、tiling、寄存器/共享内存/TMEM 的数据流关系,还通过具体矩阵尺寸、SASS 形态和 profiling 指标说明如何判断瓶颈与选择合适的实现策略。适用边界主要在 NVIDIA CUDA GPU 生态,且部分 Blackwell/GTC 2026 相关特性具有较强版本依赖。

推荐收录,因为文章把 Tensor Core 的硬件代际、编程接口和性能分析工具放在同一框架下讲清楚,兼具原理、方法和实战排查路径。对于做 CUDA 算子优化、GPU 性能分析或 AI 基础设施开发的读者,它提供了可迁移的心智模型与调优抓手。

技术文章知乎 - 腾讯技术工程

拆解大模型几项核心操作背后的数学与 Infra 优化逻辑

这篇文章从大模型推理与训练中的几个核心算子入手,系统拆解了 RMSNorm、Softmax、Causal Mask、Online Softmax、FlashAttention、采样等操作背后的数学等价变换与硬件实现逻辑。作者把“数值稳定性”“访存带宽”“寄存器/SRAM 压力”“并行度与同步开销”串成一条线,说明现代 AI Infra 的核心思路是在尽量不损失模型效果的前提下,通过重写公式、融合 Kernel、减少 HBM 访问和降低数据依赖来换取吞吐与延迟优势。

推荐收录,因为它不是单纯讲概念,而是把大模型常见算子如何从数学形式落到 GPU Kernel 优化讲清楚了,适合做 AI Infra、CUDA/Triton、推理引擎方向的长期参考。文章兼顾理论直觉与工程实现,读者能迁移到归一化、Attention、采样和分布式推理等多类优化问题中。

工程实践NVIDIA Technical Blog

Model Quantization: Turn FP8 Checkpoints into High-Performance Inference Engines with NVIDIA TensorRT

文章围绕模型量化后的部署流程,说明如何将 FP8 checkpoint 转换为 NVIDIA TensorRT inference engine,并把“模型优化”与“生产推理”连接起来。核心价值在于展示量化模型进入推理引擎后的落地路径,以及这种做法在吞吐、延迟和 GPU 利用率上的收益。文章的适用边界主要在 NVIDIA GPU 与 TensorRT 生态,以及已具备 FP8 量化能力的模型和工作流。

推荐收录,因为它提供了从量化 checkpoint 到高性能推理引擎的完整工程思路,适合关注模型部署、推理加速和 GPU 资源利用的读者参考。虽然带有明显的 NVIDIA 生态属性,但其中关于量化、引擎生成和性能收益验证的思路具有较强迁移价值。

工程实践知乎 - 皮振伟

漫谈AI推理与存储

这篇文章围绕 AI 推理中的存储需求展开,重点分析了模型权重加载、KV Cache 的数据形态、外部存储布局,以及单机和分布式场景下的 IO 路径选择。作者把 LLM 推理中的启动延迟、GPU 空转、缓存共享、存储分层和成本控制串成一条完整链路,并系统比较了 mmap、GDS、Direct IO、RDMA、NVMe-oF、对象存储等方案的适用边界。最后,文章结合自研 GD2FS 和若干实测数据,提出了面向推理场景的 GPU 直连分布式存储架构,但也明确这些优化高度依赖数据对齐、缓存形态和具体工作负载。

推荐收录,因为它不是泛泛谈“AI 存储”,而是从推理引擎的数据特征出发,逐层分析了存储栈、网络栈和 GPU 直连路径的取舍,具有很强的工程可迁移性。文中还给出了自研系统和实测结果,适合做 AI 基础设施、推理优化和分布式存储方向的长期参考。

工程实践Instacart Tech Blog

From Scoring to Spelling: Rebuilding Ads Retrieval at Instacart

文章复盘了 Instacart 广告召回系统从“对固定候选集打分”转向“按 token 自回归生成”的重构过程。作者先分析了旧式 BERT 检索在词表膨胀、冷启动和候选结构漂移上的瓶颈,再介绍用 Semantic IDs 作为新产品词汇、用上下文模板组织训练输入、以及通过 beam search 生成候选并映射回商品索引的完整方案。为了支撑新模型,团队还重建了 GPU serving 栈(TensorRT-LLM、Triton、Go-native 服务),最终在两条发现型广告位上取得了约 +5% CTR、+34% add-to-carts 的线上收益,并显著提升了长尾类目和品牌多样性。

推荐收录,因为它不是单纯的产品宣传,而是把广告召回从建模、表示、训练、检索到推理基础设施完整串起来,呈现了一个可迁移的工业级重构范式。对于做推荐系统、检索系统和大模型推理落地的读者,这篇文章能直接提供“何时从打分转向生成”“如何重做表示层”“如何为生成式召回重建 serving 栈”的判断框架。

技术文章知乎 - 腾讯技术工程

AI Infra源码入门:大模型是如何高效推理的

这篇文章以 vLLM 源码阅读为主线,系统拆解了大模型推理的完整数据流:从 tokenization、embedding、Transformer block、Attention、FFN 到 LM head 和 sampling,并用 Llama 3 的张量维度变化把“模型怎么算”和“代码怎么跑”对应起来。文章重点解释了 continuous batching、PagedAttention、FlashAttention、KV Cache 组织、prefill/decode 差异、抢占与调度策略等 AI Infra 核心机制,同时穿插了算力密度、访存带宽、kernel fusion、在线 softmax 等工程取舍与性能边界。整体上它不是泛泛讲 Transformer,而是从源码和运行时视角揭示大模型高效推理的关键实现路径,适合作为 AI 推理系统入门与复盘参考。

推荐收录,因为文章把大模型推理的核心机制、张量形状和工程优化串成了一条完整链路,既能帮助读者理解原理,也能帮助读者读懂 vLLM 这类推理系统的实现。它对做 AI Infra、GPU 推理优化、模型服务和系统架构的人都有较强迁移价值。

工程实践NVIDIA Technical Blog

Unlock Exascale Performance on NVIDIA GB200 NVL72 with Slurm Topology-Aware Job Scheduling

文章围绕 NVIDIA GB200 NVL72 这类高密度 GPU 机架如何通过 Slurm 的拓扑感知调度来提升作业性能,核心关注点是“任务如何放置”而不仅是“硬件有多快”。它强调在共享集群里,调度器需要理解节点、机架和互联拓扑,才能更好地把大模型训练或推理作业映射到合适的资源上,从而更接近整机架的性能上限。文章的适用边界主要在于面向 AI/HPC 集群管理与 Slurm 调度实践,尤其是对 NVIDIA 这类高带宽、强拓扑约束平台的资源编排问题。

推荐收录,因为它讨论的是大规模 GPU 集群中非常典型且长期存在的问题:如何通过拓扑感知调度减少性能损失、提升资源利用率。对做 AI 基础设施、HPC 集群管理和高性能作业编排的读者来说,这类经验具有较强的可迁移价值。

工程实践Blender Developers Blog

Cycles Texture Cache

这篇文章介绍了 Blender Cycles 在 5.2 LTS 中引入的纹理缓存系统,目标是在大量图像纹理参与渲染时显著降低显存和内存占用。作者不仅说明了功能入口和 tx 文件生成流程,还系统解释了 GPU/CPU 统一缓存策略、基于 tile 的虚拟纹理映射、ray differentials 计算 mipmap 层级,以及在大规模渲染中如何通过分块调度与淘汰策略保持较稳定的内存使用。文章同时给出了适用边界:收益高度依赖场景纹理占比,旧 GPU、viewport 交互、packed textures 和过滤细节仍有后续优化空间。

推荐收录,因为它不是单纯的功能发布,而是把一个真实图形渲染系统中的纹理缓存设计、GPU 约束和内存权衡讲得比较完整,具有长期参考价值。对于做图形渲染、GPU 计算或资源管理的读者,这篇文章能直接借鉴虚拟纹理、批量失效重跑和分块驱逐等设计思路。

工程实践NVIDIA Technical Blog

Advancing Emerging Optimizers for Accelerated LLM Training with NVIDIA Megatron

文章介绍了高阶优化算法在大模型训练中的应用进展,重点提到 Shampoo 与 Muon 这类方法如何用于提升 LLM 的训练效果。作者结合 NVIDIA Megatron 说明,虽然这类优化器在收敛性和模型质量上有潜力,但其矩阵运算、通信和显存开销也更高,因此需要借助 GPU 侧和分布式训练框架做专门加速。文中还指出,Muon 已被用于训练 Kimi K2、GLM-5 等开源模型,说明这类“新优化器 + 系统加速”的组合已经进入实际训练场景。整体论点是:优化算法不应只看理论收益,还要看是否能被工程化地高效实现。适用范围主要是超大规模 LLM 训练;若模型规模较小或训练基础设施不足,收益可能不明显。

推荐收录,因为标题和正文片段都明确指向“优化算法 + Megatron 加速 + LLM 训练”这一可复用工程主题,并给出了 Shampoo、Muon 及实际开源模型训练的直接证据。适合做大模型训练、GPU 优化和训练系统设计的读者参考,但需要注意其收益依赖模型规模与系统实现,不能直接照搬到小规模训练。

技术文章NVIDIA Technical Blog

Maximizing Memory Efficiency to Run Bigger Models on NVIDIA Jetson

文章围绕 NVIDIA Jetson 这类边缘设备的内存瓶颈,讨论如何让更大的开源生成式模型在受限硬件上稳定运行。作者指出,随着多十亿参数模型从数据中心下沉到物理世界中的 AI 代理和机器人场景,显存/内存效率已成为部署成败的关键。全文重点不在训练新模型,而在推理部署侧通过压缩占用、减少运行时冗余和优化内存分配来扩大可运行模型规模。它强调必须在模型大小、吞吐、延迟和平台资源之间做权衡,适合 Jetson 与边缘 AI 场景参考。其边界也很明确:这些方法主要缓解内存压力,不能替代算力不足或模型本身结构不适配的问题。

推荐收录,因为标题和导语直接指向 Jetson 边缘部署中的内存效率优化,覆盖了多十亿参数模型落地这一长期问题。适合做边缘 AI、机器人和嵌入式推理选型参考,但方案强依赖 Jetson 平台,迁移到其他硬件时需要重新评估资源与性能权衡。

工程实践NVIDIA Technical Blog

Run High-Throughput Reinforcement Learning Training with End-to-End FP8 Precision

文章面向大模型强化学习训练的吞吐优化问题,讨论如何在端到端流程中引入 FP8 精度,以提升训练效率并降低算力与显存开销。作者指出,RL 训练通常分为采样/生成与策略更新两类高强度阶段,二者对计算、带宽和数值稳定性的要求不同,因此单点加速往往不足。文中围绕 NVIDIA 的 GPU 与软件栈,说明 FP8 在推理、前向与反向计算中的应用方式,以及如何在保持训练可用性的前提下扩大吞吐。其核心结论是:对于支持该精度路径的硬件和框架,端到端 FP8 可以显著提升高强度 RL 训练效率,但需要配合数值验证与实现适配,不能简单地对所有模型直接替换。

收录理由直接而明确:文章围绕“端到端 FP8 精度”提升 RL 训练吞吐展开,属于可迁移的工程优化经验,而不是单纯产品宣传。适合做大模型训练、GPU 性能优化和数值精度权衡的参考;但其效果依赖支持 FP8 的硬件与软件栈,迁移时需要验证稳定性。

工程实践NVIDIA Technical Blog

Cut Checkpoint Costs with About 30 Lines of Python and NVIDIA nvCOMP

文章介绍在大模型训练中,如何借助 NVIDIA nvCOMP 和约 30 行 Python 为 checkpoint 加入压缩,以降低频繁保存模型权重、优化器状态和梯度带来的存储与传输开销。作者以 70B 模型每次约 782GB、15-30 分钟一次的检查点为背景,指出 checkpoint 已成为训练预算中的重要成本项。方案核心是把压缩与解压尽量放到 GPU 侧处理,减少写盘数据量,同时保持训练中断后的可恢复性。文中展示了接入方式与落地路径,适合 I/O 或存储受限的训练任务,但在算力已接近饱和或检查点规模较小的场景,收益会下降并引入额外压缩开销。

推荐收录,因为文章给出了大模型 checkpoint 降本的具体工程做法,并用 70B 模型 782GB、15-30 分钟一次的量化背景证明问题真实存在。适合训练平台、GPU 基础设施和存储优化读者参考,但需注意压缩会带来额外算力与延迟,效果依赖 I/O 是否为主要瓶颈。

工程实践NVIDIA Technical Blog

Running AI Workloads on Rack-Scale Supercomputers: From Hardware to Topology-Aware Scheduling

文章围绕 NVIDIA GB200/GB300 NVL72 这类 rack-scale 超级计算机,说明其以 Blackwell 架构、18 个紧耦合计算托盘、GPU fabric 和高带宽网络组成统一系统。作者强调,AI 任务在这种硬件上运行时,关键不只是“把机器装进机柜”,而是要理解通信拓扑并据此做作业放置与调度。文章从硬件层次、网络/互联特性讲到 topology-aware scheduling,重点讨论如何减少跨托盘通信、匹配计算与通信密集型负载,并提升整体吞吐和资源利用。结论是,软硬件协同设计能明显改善大模型训练与推理的扩展性,但方案强依赖特定 rack-scale 平台,不宜直接照搬到普通集群。

有明确的硬件细节与调度方法,不是单纯产品介绍:文章直接讨论 rack-scale 互联结构、负载拓扑感知放置和性能收益。适合 AI 基础设施、HPC 平台和集群调度读者参考,但迁移时要注意它主要针对 NVIDIA NVL72 这类特定架构。

工程实践Stanford Hazy Research

ThunderKittens 2.0: Even Faster Kernels for Your GPUs

这篇文章发布了 ThunderKittens 2.0,一个面向 GPU 的 CUDA 内嵌 DSL,并顺带给出一篇面向 Blackwell 的内核优化复盘。新版增加了 MXFP8/NVFP4 支持、调度与 tensor memory 控制能力、简化的构建结构,并把多个示例内核升级到更现代的 API。技术部分重点解释了为何原先放在 GEMM 路径中的两类 fence 实际上并非必需,作者通过 PTX 的因果顺序与 proxy 规则证明共享内存和 tensor memory 的可见性已被保证,去掉后带来约 20 TFLOP/s 的收益。文章还分析了 tcgen05.cp 与 tcgen05.mma 的隐式流水、PTX assembler 对单线程指令的保守串行化、cluster size 对占用率的影响,以及 tensor memory 触发的单 SM occupancy 限制。最后给出较完整的 GPU kernel benchmark 规范,强调输入分布、L2 冷热状态、warmup 和温度稳态都会显著影响 TFLOPs。整体内容适用于做 Blackwell/CUDA 内核、性能分析和基准设计的人,但结论主要建立在特定硬件与 PTX 行为之上,跨架构迁移时需要重新验证。

推荐收录,因为文章不是单纯发布稿,而是给出了 Blackwell GPU 内核优化的具体证据:PTX 因果/代理模型、assembler 生成差异、cluster 占用率和基准方法都配有可验证的观察。适合做 CUDA 内核、性能调优和基准设计的读者参考,但其结论强依赖 Nvidia 新架构与特定指令语义,迁移到其他 GPU 时需重新实测。

工程实践Dropbox Tech

How low-bit inference enables efficient AI

这篇文章系统梳理了低比特推理如何通过量化降低大模型在生产环境中的显存、算力和能耗成本,并以 Dropbox Dash 的部署场景说明为什么效率优化会直接影响延迟、吞吐和服务成本。作者先解释了注意力模型中线性层与 attention 的主要开销,再从硬件角度说明 GPU Tensor Core 在精度降低时能获得更高吞吐,因此量化不仅是压缩表示,更是面向 MMA 指令和带宽瓶颈的执行优化。文章重点比较了 pre-MXFP 时代的 A16W4、A8W8、AWQ、HQQ、FlashAttention 3 等方案,指出权重量化更适合小批量、带宽受限场景,而激活量化更适合高吞吐和长上下文预填充。随后作者介绍 MXFP/NVFP4 等新标准,强调其把微缩放和量化支持下沉到硬件后可减少显式反量化开销,但不同 GPU 架构和框架支持仍不统一。文章结论是:低比特推理的收益很大,但真正可落地的前提是硬件、编译器、内核和推理框架协同成熟,当前 FP4 生态仍存在兼容性与模型质量边界。

文章直接给出了量化格式、硬件指令和推理场景之间的取舍证据,不是泛泛介绍概念,而是面向生产部署的效率分析。适合做大模型推理、GPU 优化和 AI 基础设施选型的长期参考,尤其对关注吞吐、延迟与生态兼容性的工程团队有迁移价值。

工程实践Stanford Hazy Research

Loads and Loads of Fluffy Kittens

文章系统总结了 ThunderKittens 在多 GPU 计算-通信融合中的设计经验,围绕传输机制、重叠调度和 tile 组织给出可复用原则。作者比较了 copy engine、TMA 与寄存器级指令的适用区间,指出消息粒度、是否需要 in-network reduction、以及能否与计算对齐,决定了最优方案。随后用这些原则实现并评测了数据/张量并行中的 AG+GEMM、GEMM+RS/AR,序列并行中的 Ring Attention 与 Ulysses,以及 MoE token dispatch 融合 GEMM,整体能以几十行 device code 达到或超过手写优化内核。文章也明确了边界:结论主要针对 NVLink/NVSwitch 上的 Hopper/Blackwell,跨节点、不同互联和不同算子仍需重新权衡。

收录,因为它不只是展示结果,而是把多 GPU 算子融合的关键选择——传输机制、调度方式和 tile 划分——用实验和对比讲清楚了。适合做 AI 系统、GPU 性能优化和分布式算子设计的参考,但需要注意其验证平台主要是 NVLink/NVSwitch 体系。

科研议题Stanford Hazy Research

ParallelKittens: Simple and Fast Multi-GPU AI Kernels

这篇文章是 ThunderKittens 新增多 GPU 能力的总览性介绍,核心目标是把 AI kernel 从单卡扩展到基于 NVLink/NVSwitch 的 scale-up 多 GPU 场景。作者提出三条经验:通信启动方式有不同开销,调度可以在主机、SM 乃至 SM 内部多层重叠通信与计算,以及直接手写少量 device 代码往往比 NCCL、NVSHMEM 等现成库更能利用新硬件特性。文章强调 tile 仍然是多 GPU kernel 的基本抽象,因为它既能饱和带宽,又能延续 ThunderKittens 的编程模型。作者用 BF16 all-reduce、all-gather+GEMM 和 Ring Attention 等基准展示更新版实现已能达到或超过现有最优结果。其边界是目前主要聚焦单机多 GPU,后续还计划补充跨节点通信、MoE 负载均衡和文档整理。

推荐收录,因为文章明确给出了多 GPU kernel 的设计原则、通信/调度取舍以及基准结果,并不是泛泛的产品宣传。适合做 GPU 系统、AI kernel 优化和多卡通信设计的参考,尤其对需要从 NCCL 之类库转向自定义实现的读者有直接迁移价值。

工程实践Stanford Hazy Research

AMD GPUs go brrr

这篇文章深入分析了 AMD MI355X/CDNA4 GPU 上 AI kernel 的性能来源,并提出 HipKittens 作为面向 AMD 的编程原语集合。作者先从硬件结构入手,对比了 AMD 与 NVIDIA 在寄存器文件、SRAM、矩阵指令、chiplet/L2/LLC 组织以及编译器支持上的差异,说明许多在 NVIDIA 上有效的做法在 AMD 上会失效。文章重点解释了为什么 wave specialization 在 AMD 上表现不佳:没有寄存器重分配、AGPR/VGPR 约束更强、以及细粒度同步和内存指令行为更复杂。为此,作者提出 8-wave ping-pong 和 4-wave interleave 两种调度模式,并结合 chiplet-aware 的 grid 排布来提升缓存复用。实验表明,这些策略在 GEMM 和 attention 等工作负载上能达到接近或优于现有 AMD 基线的性能,但其方法强依赖 CDNA3/4 细节、HIPCC 行为和底层指令布局知识,移植到其他平台仍需重新验证。

收录依据很明确:文章不仅给出 AMD GPU 的硬件差异分析,还提供了寄存器调度、bank conflict、chiplet cache 复用和基准测试的完整证据链。适合做 GPU kernel、编译器和 AI 基础设施的长期参考,但读者需要接受其强 AMD/CDNA 绑定和大量底层实现细节。

工程实践Stanford Hazy Research

HipKittens: Fast and Furious AMD Kernels

文章围绕 AMD GPU 上的高性能 AI kernel 设计,介绍了 HipKittens 这一套面向 HIP 的 C++ 嵌入式原语。作者先分析现有 AMD 软件栈的问题:AITER、PyTorch、Triton、TileLang 和 CK 在若干 attention/GEMM 场景下难以稳定逼近峰值,部分还受限于寄存器分配、bank conflict、chiplet swizzle 等硬件细节。随后提出核心判断:tile 抽象可以跨架构复用,但真正决定性能的内存访问、调度和后端实现必须按 AMD/ NVIDIA 分开定制。基于这一思路,HipKittens 用约 500 行代码实现 attention 前向、不到 100 行热循环实现 GEMM,并在多项基准上超过现有基线。文章同时指出 wave specialization 在 CDNA3/4 上并不总有效,说明可移植的高层接口并不等于可移植的底层优化。

文中直接给出可验证的性能结果:HipKittens 的 attention 和 GEMM kernel 在 AMD MI355X 上超过多种基线,且代码规模很小,说明其方法不只是概念展示。适合做 GPU kernel、AI 编译器和多硬件适配的参考,尤其能帮助读者理解“统一接口、分离后端实现”的可迁移设计。

工程实践Stanford Hazy Research

How Many Llamas Can Dance in the Span of a Kernel?

这篇文章介绍了 Stanford Hazy Research 的一个吞吐优先版 Llama-70B megakernel:在 8 卡张量并行场景下,把预填充与解码、Paged KV cache、跨 GPU 通信和 CPU 侧调度尽量纳入单个内核的统一执行框架。作者沿用“解释器模板 + 指令序列”的设计,由 CPU 预先生成调度,内核内部按较粗粒度指令执行,从而减少 kernel launch、协调开销和 CPU 参与。文章重点分析了三类重叠:SM 内重叠、跨 SM 重叠和跨 GPU 重叠,并说明如何通过 warp specialization、显式同步和远程读写把这些优化放进同一套 megakernel 里。实测上,该原型在 ShareGPT 65,536 prompts 上端到端比 SGLang 快约 22%。其边界在于依赖较大的算子粒度和复杂的手工调度,当前更适合大模型高吞吐推理,而非所有模型与硬件都能直接套用。

推荐收录,因为它给出了把多 GPU 推理的调度、通信与计算统一进单核框架的直接实现证据,而不只是概念讨论。适合做大模型推理系统、CUDA 优化和高吞吐服务设计的参考,尤其对需要权衡 launch 开销、通信重叠和调度复杂度的工程场景很有迁移价值。

工程实践Stanford Hazy Research

We Bought the Whole GPU, So We're Damn Well Going to Use the Whole GPU

这篇文章介绍了一个面向 Llama-70B 张量并行推理的高吞吐 megakernel,目标是在 H100 上把计算、显存带宽和 NVLink 通信尽量同时吃满。作者先回顾了此前面向低延迟的单卡 megakernel,再说明高吞吐场景下工作负载更异质:矩阵乘法偏计算、RMS norm 和 decode 偏内存、跨 GPU 交换偏通信,因此必须做分层重叠。文中提出新的指令集与解释器执行模型,把 RMS norm、QKV、Attention、O-projection、MLP 等融合为少量指令,并用分布式 transpose 代替部分 reduce-scatter,以便把通信隐藏在后续计算之后。文章还展示了三层优化:SM 内指令流水化、跨 SM 的全局 work queue 动态调度、跨 GPU 的 storer 线程通信重叠,并通过消融实验证明这些策略在大 batch 下能带来数个百分点到十几个百分点的吞吐收益。最终将 megakernel 集成到 Tokasaurus,在 ShareGPT 65,536 prompts 的端到端吞吐上比 SGLang 高约 22%,但作者也明确说明这套代码对编译器版本、GPU 配置和同步细节非常敏感,属于研究原型而非可直接落地的生产实现。

推荐收录,因为文章给出了可复现的系统设计证据:指令/解释器架构、跨 SM 全局调度、跨 GPU 通信重叠,以及对应的消融和吞吐数据。适合做大模型推理、GPU kernel 融合和多卡通信优化的参考,但需注意它是强依赖 H100 和编译环境的研究代码,不宜直接当作生产模板。

工程实践Stanford Hazy Research

One Kernel for All Your GPUs

这篇文章系统讲解了如何在 NVIDIA 多 GPU 平台上手写高性能通信核,重点面向 NVLink/NVSwitch 互联的单机多卡场景。作者先解释了跨进程共享 GPU 内存的三种路径:UVA、CUDA IPC 和手动 VMM,并说明为何生产环境更需要后两者以及它们的初始化开销与边界。随后文章分析了 NVSwitch 的广播/归约加速机制,以及 copy engine、TMA 和寄存器指令三种通信方式在带宽、并发和可融合性上的差异,给出在 B200 上的实测利用率。最后,作者把这些机制封装进 ThunderKittens 的 PGL 和 TKParallelTensor,展示了不到 100 行代码实现 all-reduce、all-gather、reduce-scatter 和 all-to-all,并在 8 卡 B200 上相对 NCCL 取得最高 2.6x 提升。文章的适用边界也很明确:它主要针对单机 NVLink/NVSwitch 域内的细粒度通信优化,且依赖 VMM、固定粒度显存和较强的 CUDA/编程模型理解,不直接覆盖跨节点通信。

收录价值很高,因为文章不仅给出性能结果,还把多 GPU 通信从内存映射、NVSwitch 机制到 kernel 设计完整串起来,直接提供了可复用的实现路径。适合做分布式训练、MoE、序列并行和自定义 collective 的工程参考;但读者需要接受其局限于单机 NVLink/NVSwitch 域,且实现门槛较高。

科研议题Stanford Hazy Research

Look Ma, No Bubbles! Designing a Low-Latency Megakernel for Llama-1B

本文聚焦低延迟、batch size=1 的 Llama-1B 推理优化,指出 vLLM 和 SGLang 在 H100 上因大量小 kernel、launch/teardown 开销、以及严格的 kernel 顺序同步而只能利用约一半 GPU 带宽。作者提出把整层前向传播融合为一个“megakernel”,并用 GPU 端解释器统一调度各类指令。为解决资源竞争与依赖同步,他们设计了共享内存分页机制和基于计数器的显式同步,把权重加载、激活读写和计算更紧密地流水化。实验显示,H100 上前向传播可达到约 78% 内存带宽利用率,较基线提速 1.5x 至 2.5x;B200 上单次前向可压到 680 微秒以内。文章同时说明该方法主要适用于内存带宽主导、且追求极低延迟的场景,仍受激活加载、原子操作和同步开销限制。

文中给出了可验证的性能数据、明确的瓶颈分析和完整的实现取舍,不是泛泛而谈的加速口号。适合做 LLM 推理、GPU runtime 和系统优化的参考,但其收益主要局限于 batch=1 的低延迟内存受限场景。

工具笔记Brendan Gregg

Doom GPU Flame Graphs

文章介绍了 Brendan Gregg 团队开源的 AI Flame Graphs 新能力:在 Intel Battlemage GPU 上生成完整的 GPU flame graph,并与 FlameScope 结合做 CPU/GPU 的亚秒级可视化分析。作者用 GZDoom 作为案例,通过自制的高负载地图把不同房间的渲染、后处理、stencil 和 sprite 开销拆开观察,并用 GPU flame scope 定位到具体时间窗口。文中还展示了 CPU 端的 shader 编译与 NIR 预处理如何对应到 GPU 空转区间,说明这种图形化方法能快速建立跨 CPU/GPU 的因果关联。与此同时,文章明确列出使用门槛:需要 Linux root 权限、较新的内核与显卡驱动、启用 eustalls/eudebug 接口,以及带 frame pointers 的系统库和应用。它的适用边界也很清楚:当前主要面向 Intel 硬件与 Linux,且采样开销、驱动支持和环境准备仍在完善中。

推荐收录,因为文章给出了可操作的 GPU 性能剖析方法、命令示例和完整环境要求,而不是停留在概念介绍。适合做图形渲染、GPU profiling 和性能诊断参考,但当前局限于 Intel/Linux 生态,部署门槛较高。

科研议题Stanford Hazy Research

BASED ✌️: our one year retrospective

这篇文章是 Stanford Hazy Research 对 BASED 发表一年后的回顾,核心在于重新总结高效语言模型的设计原则与影响扩散路径。作者认为,推理时真正的关键权衡不是“是否使用 Transformer”,而是上下文回忆能力与 state size 之间的关系;BASED 通过“短程精确混合 + 大状态线性注意力”的组合,把这一帕累托前沿向外推进。文章进一步强调了 MQAR、EVAPORATE 等回忆评测任务如何成为衡量高效模型的重要基准,并回顾了该路线如何影响 Mamba-v2、RWKV-v5/v6、MetaLA、MiniMax、Liger attention 等后续架构。实现层面,作者强调从硬件出发设计内核,利用 H100 的 WGMMA/TMA 以及二阶 Taylor 近似的软最大核,在保持高质量的同时提升吞吐,并指出 k=2 在质量与性能间较平衡。文章也给出局限:高效模型仍存在“没有免费午餐”,且结论依赖具体工作负载与硬件平台,迁移时需要重新评估边界。

收录依据明确:文中不仅复盘了 BASED 的设计逻辑,还给出了可复用的评测基准、硬件优化手段和后续模型扩散证据。适合做高效 LLM、线性注意力和 GPU 内核设计的研究参考;但内容带有项目回顾色彩,部分效果宣称仍需结合原论文与独立复现交叉验证。

工程实践Stanford Hazy Research

ThunderKittens Now on Blackwells!

文章介绍了 ThunderKittens 针对 NVIDIA Blackwell/B200 架构的新一代 GEMM 与 Attention kernel 实现,并解释其为什么能接近或超过 cuBLAS、FA3 的性能。作者把重点放在“数据流”而非传统 CUDA 控制流上,围绕 5 代 tensor cores、tensor memory 和 CTA pairs 设计更深的流水线,通过 producer/consumer warpgroup 协作、persistent kernel、跨迭代预取 K/V、以及把输出累积器逐级写回共享内存和 HBM,尽量消除 pipeline bubble。文章还指出 B200 的 tensor core 更大,微基准上更像 128×128 systolic,因此只有当 M、N 维度足够大时才能充分吃满算力,小尺寸 GEMM 会按比例降速。它同时展示了如何把 Hopper 上的 kernel 结构迁移到 Blackwell,并说明 tensor memory 如何缓解 backward pass 的中间状态压力。整体结论是:Blackwell 的性能优化核心是提高并行数据供给深度,而 TK 的 tile 抽象恰好适配这一点,但收益依赖于特定硬件与形状假设。

推荐收录,因为文章直接给出了 Blackwell 上 GEMM/Attention kernel 的实现思路、硬件特性利用方式和明确的性能对比结果,而不是泛泛介绍新卡参数。适合做 GPU kernel、AI 加速和高性能计算的长期参考,尤其对需要把 Hopper 代码迁移到 Blackwell 的读者有可迁移的流水线设计价值;但其结论强依赖 B200 的 128×128 计算单元和特定 tile 形状。

工程实践Stanford Hazy Research

ThunderMLA: FlashMLA, Faster and Fused-er!

本文介绍 Stanford Hazy Research 的 ThunderMLA:针对 LLM 推理中变长请求和小批量 decode 的性能瓶颈,把原本分开的 attention/归约 kernel 融合成一个可由指令张量驱动的 megakernel。作者提出 ThunderKittens 的 interpreter template,在 GPU 上用虚拟指令集组织子 kernel,并通过全局 tensor 做依赖同步,从而减少 kernel launch、尾部效应和中间结果写回。文中还给出两种调度器:静态调度器与基于 makespan 反推的调度器,后者能进一步压缩执行时间约 10%。在 H100 上,ThunderMLA 相比 DeepSeek 的 FlashMLA 在多个 workload 上提升约 20–35%,但调度生成本身仍较慢,主要依赖可复用 schedule,适合推理场景而非通用低延迟单次执行。作者还强调该思路可迁移到 GQA、tensor parallel 的通信重叠以及 MoE 等数据流型 AI 工作负载。

收录价值明确:文章给出了可复现的性能证据、具体的 megakernel 设计和两类调度策略,而不是泛泛谈“更快”。适合做 LLM 推理、CUDA kernel 融合、GPU 调度与性能分析的参考,尤其对需要处理变长序列和小批量 decode 的工程场景可迁移。

工程实践Stanford Hazy Research

ThunderMittens For Your ThunderKittens

文章记录了 Stanford Hazy Research 将 ThunderKittens 这一面向 NVIDIA GPU 的 AI kernel DSL 移植到 Apple Silicon/Metal 的过程,并把新版本命名为 ThunderMittens。作者先分析了 M2 Pro 的硬件特征:内存带宽相对算力更高、共享内存收益有限、bf16 编译优化不稳定、占用率对性能影响很大,因此更适合用直接寄存器加载和更简单的 kernel 组织方式。移植时,用户侧几乎只需把基础 tile 从 16x16 改成 8x8;内部则删去 swizzling、WGMMA/TMA 和异步读写等 NVIDIA 特定机制,并通过不同寄存器布局适配 Metal 指令。文中给出 GEMM 与注意力推理 kernel 的实现片段,说明 DSL 抽象在不同硬件上基本保持稳定,但具体优化手段会随平台变化。性能上,注意力 kernel 与 MLX 相差约 ±15%,GEMM 在多数尺寸上快约 9%,同时代码行数显著减少,但作者也承认当前仍处早期阶段,且调试依赖反复试验与 Xcode GPU 工具。

收录依据很直接:文章不仅给出跨平台 kernel 迁移的设计原则,还提供了具体实现、硬件约束和性能数据,能支撑读者判断 DSL 在异构 GPU 上的适用性。适合做 AI 系统、GPU kernel 和编译/DSL 设计的长期参考,但需要注意其结论主要基于 M2 Pro 与特定 kernel,泛化到其他平台仍需验证。

工程实践Stanford Hazy Research

ThunderKittens: Bringing fp8 to theaters near you

这篇文章介绍 ThunderKittens 为 fp8 新增算子与 GEMM kernel 的实现思路,目标是在保持统一编程接口的同时支持量化数据类型。作者重点解释了 fp8 与 fp16/bf16/fp32 在寄存器布局上的差异,以及为何需要额外的线程间 shuffle 来完成数据重排,而不是简单复用原有 tile 逻辑。文章进一步分析了 ldmatrix/stmatrix 与 WGMMA 在 H100 上的使用方式,说明 fp8 在共享内存到寄存器加载时仍受 16 位指令接口限制,只能通过“先按 16 位加载再拆成两个 fp8”的方式绕过。为了降低 bank conflict,作者讨论了 32/64/128-byte swizzling 的适用条件,并把 fp8 tile 宽度下限提高到 32,以匹配更大的 core matrix 和更好的硬件利用率。整体结论是:fp8 kernel 可以复用 bf16 的整体结构,但必须围绕数据布局、bank conflict 和硬件指令约束做针对性改造,且效果高度依赖 NVIDIA H100 这类支持 WGMMA 的平台。

文中直接给出了 fp8 kernel 的布局、shuffle、swizzle 和 bank conflict 处理细节,并用 H100/WGMMA 约束解释了为何要这样设计。适合做 GPU 算子、AI 基础设施和高性能 CUDA 编程的参考,但结论明显依赖特定硬件代际。

工具笔记Brendan Gregg

AI Flame Graphs

这篇文章介绍了 Intel 正在试验的 AI Flame Graphs:把传统 CPU flame graph 扩展到 GPU/AI 加速器,统一展示加速器指令、源代码和触发它们的 CPU 调用链。作者强调其核心目标是像 CPU 性能分析那样做到低开销、生产安全、随时可用,并通过 EU stall profiling 与 eBPF 结合,定位 AI 工作负载中的热点和停顿原因。文中还展示了 SYCL 矩阵乘和 PyTorch/Llama 2 的示例,说明它能把看似混乱的 AI 栈收敛到少数关键瓶颈函数或指令。作者同时指出当前仍处于早期阶段,PyTorch、符号化、驱动和运行时适配都较困难,部分场景还有中等开销,离大规模通用化还需要较长时间。

推荐收录,因为文中明确给出了新型 AI 性能分析工具的设计目标、实现思路和适用边界,而不是停留在产品宣传层面。适合做 GPU/AI 性能优化、可观测性和开发工具演进的参考,尤其对需要把加速器热点与上层代码关联起来的工程团队有直接迁移价值。

工程实践Stanford Hazy Research

GPUs Go Brrr

文章围绕如何让 NVIDIA H100 的 Tensor Core 尽可能持续工作展开,作者先拆解 H100 的计算、共享内存、L2、寄存器和 TMA/WGMMA 等关键硬件资源,再用微基准说明真正的瓶颈不只是 HBM,而是共享内存延迟、地址生成开销和银行冲突。文章强调 WGMMA 与 TMA 是榨干算力的必要条件,同时指出其共享内存布局和 swizzle 规则文档混乱、易出错,需要精细控制数据布局与流水线。基于这些经验,作者发布了嵌入 CUDA 的 DSL ThunderKittens,用 tiles 抽象寄存器和共享内存中的张量操作,让复杂 kernel 代码显著简化。文中给出 FlashAttention-2 和线性注意力的实现与性能结果,说明在 H100 上可比常见实现进一步提升约 30%,但也暗示该方法高度依赖特定 GPU 架构与手工调优边界。

推荐收录,因为文章给出了 H100 上从硬件特性、布局约束到 kernel 实现的完整证据链,并以实际基准证明 ThunderKittens 能带来可观性能提升。适合做 GPU kernel、AI 加速和底层 DSL 设计的参考,但读者需注意其结论强依赖 Hopper 架构,且 swizzle/TMA 细节具有较强平台特定性。

科研议题Stanford Hazy Research

Monarchs and Butterflies: Towards Sub-Quadratic Scaling in Model Dimension

文章综述了作者团队围绕“让模型维度计算从二次复杂度走向次二次复杂度”的研究路线,核心对象是 MLP 和投影层中的矩阵乘法。作者先指出:任意稀疏虽能减少参数,但会遇到质量-计算量权衡和 GPU tensor core 利用率低的问题,因此难以在真实硬件上兑现收益。随后文章从 FFT 的 Butterfly 计算模式出发,介绍可学习的结构化稀疏矩阵及其在 GPT-2 上的效果,再进一步过渡到 Monarch 矩阵,通过置换加块对角分解来适配 dense GEMM 硬件。实验显示 Monarch/Monarch Mixer 可在 OpenWebText、BERT、长序列任务上同时保持或接近原始精度,并带来可观的参数与端到端加速。文章的边界也很明确:这些方法主要针对特定线性层与特定结构,仍是研究路线而非通用替代方案。

推荐收录,因为文章不仅讨论了稀疏化,还明确比较了任意稀疏、Butterfly、Monarch 等结构在质量与硬件效率上的差异,并给出 GPT-2、BERT、OpenWebText 等实验结果。它适合关注高效模型结构、GPU 计算映射和线性层替代方案的研究者与工程实践者,尤其有助于理解“结构化算子如何同时兼顾可表达性和硬件友好性”。

科研议题Stanford Hazy Research

FlashFFTConv: Efficient Convolutions for Long Sequences with Tensor Cores

本文介绍了 Stanford Hazy Research 提出的 FlashFFTConv:一种面向长序列卷积的 GPU 加速算法,目标是解决传统 FFT 卷积在 ML 场景中“渐近复杂度好但实际很慢”的问题。作者指出,现代 GPU 上真正的瓶颈已从算术转向内存 I/O,而且 Tensor Core 的矩阵乘远快于通用浮点运算,因此经典 FFT 实现难以充分利用硬件。FlashFFTConv 通过 Monarch/Bailey 四步分解把 FFT 卷积改写成一系列矩阵乘与少量点操作,并用递归分解在 SRAM 限制下尽量融合多步计算,兼顾 FLOPs 与 I/O。实验显示它在 PyTorch 基线下可获得最高 7.93x 的卷积加速,端到端提升最高 4.4x;在长序列上,性能可接近甚至超过 FlashAttention-v2,并在部分模型上达到约 62% MFU。文章也说明了适用边界:短序列更依赖较低阶分解,序列更长时高阶分解才体现优势,因此算法效果强烈依赖序列长度和 GPU 形态。

推荐收录,因为文章把“FFT 卷积为什么在 GPU 上跑不快”这一问题拆成了硬件带宽、Tensor Core 利用率和 SRAM 约束三个直接证据,并给出可实现的 Monarch 分解方案与性能数据。适合做长序列模型、CUDA/ML 系统优化和算子设计的参考,尤其对需要在工程上平衡 I/O、FLOPs 与 kernel 融合的读者有可迁移价值。

技术文章Stanford Hazy Research

FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning

这篇文章介绍了 FlashAttention-2 的设计目标:在不做近似的前提下,继续压缩 Transformer 注意力的时间与显存开销,并把算子吞吐尽量逼近高效 GEMM。作者先回顾 FlashAttention 的分块、重算与在线 softmax 思路,再指出其瓶颈主要来自线程块与 warp 的工作划分不够理想,以及非矩阵乘法操作比例偏高。FlashAttention-2 通过减少 rescaling、边界判断和 causal mask 等非 matmul FLOPs,并将并行维度扩展到序列长度,从而在长序列、小 batch 场景下显著提升 GPU 利用率。与此同时,新版把 warp 之间的“sliced-K”改成更少通信的“sliced-Q”划分,减少 shared memory 读写与同步开销。文章还说明其支持更大的 head dimension、MQA/GQA,并在 A100/H100 上给出端到端训练与注意力基准,体现出该方法对长上下文训练和推理都有直接收益,但仍依赖具体 GPU 架构与实现细节。

文中明确给出算法改写、并行划分和 warp 通信优化的具体证据,并配有 A100/H100 与端到端训练基准,属于可复用的高质量系统/模型加速资料。适合做 GPU kernel 优化、注意力实现和长上下文训练的参考,但其收益高度依赖硬件与实现路径,迁移时需重新验证。

科研议题Stanford Hazy Research

FlashAttention: Fast Transformer Training with Long Sequences

这篇文章介绍了 FlashAttention 面向长序列训练的改进版本:在保持精确注意力、没有近似的前提下,通过 tiling、重计算和更细粒度的并行,把注意力的显存访问从二次复杂度降到线性,并进一步优化超长序列场景。作者指出,原版 FlashAttention 主要按 batch 和 head 维度并行,在长上下文但 batch 很小、head 数有限时会出现 GPU 并行度不足,因此新增了沿序列长度维度的并行。前向传播按行分块,反向传播按列分块,并借助 atomic operations 汇总梯度,从而减少 worker 间通信并提升吞吐。基准结果显示,在 8K 序列长度下,相比 PyTorch 和 Megatron-LM 实现可达 2.2-2.7 倍加速,端到端训练效率最高达 175 TFLOPs/sec/A100。实验还表明,把上下文从 2K 提升到 8K 能稳定改善困惑度和长程任务准确率,但收益主要出现在长序列、小批量训练场景。

推荐收录,因为文章给出了明确的算法改造、并行划分方式和可量化基准,不只是宣讲性能提升,而是解释了为什么长序列下原方案并行不足、如何改、改完后提升多少。适合研究注意力加速、长上下文训练和 GPU kernel 优化的读者,尤其对需要把理论收益落到真实训练吞吐的工程/研究工作很有参考价值。

科研议题Stanford Hazy Research

Can Longer Sequences Help Take the Next Leap in AI?

这篇文章讨论了“序列长度”作为深度学习新的规模维度,指出 Transformer 虽然强大,但在长输入上受限于二次复杂度、训练不稳定和长程依赖建模困难。作者认为,更长上下文不仅能提升文本、图像等现有任务,还可能催生新的能力,例如更强的 in-context learning、长篇内容生成,以及对时间序列、音视频和多模态数据的自动学习。文中重点介绍了两条推进路径:FlashAttention 通过 IO-aware 设计减少 GPU 内存读写,使 Transformer 能处理更长序列;S4 则借助结构化状态空间模型和初始化技巧,天然适配长序列训练。作者用 Long Range Arena 和 Path-X 等基准说明,单纯拉长序列已能带来可观增益,甚至把部分任务从随机水平提升到显著高于随机。整体上,这是一篇面向研究与工程交叉读者的方向性综述,优点是抓住了长上下文的核心瓶颈,但仍以研究愿景和早期结果为主,距离通用解决方案还有边界。

文章直接给出长序列为何重要的研究证据,并用 FlashAttention、S4、LRA/Path-X 的结果说明可迁移的方法与收益。适合关注长上下文、注意力优化和序列建模的研究者与系统工程师;需要注意它偏研究博客,结论更像方向判断而非完整定论。

科研议题Stanford Hazy Research

Pixelated Butterfly: Simple and Efficient Sparse Training for Neural Network Models

文章介绍 Pixelated Butterfly 稀疏训练方法,目标是在尽量不损失精度的前提下,降低大模型训练的计算量与显存开销。作者指出,现有动态稀疏掩码会带来额外开销,非结构化稀疏也难以在 GPU 上真正提速,因此提出静态且硬件友好的稀疏参数化。核心思路是将 butterfly 与 low-rank 结合,并通过 block butterfly 与 flat butterfly 把原本不利于并行的结构改造成块对齐、易实现的形式,再为各个矩阵乘层生成硬件感知的稀疏 mask。实验表明,该方法可让 MLP-Mixer、ViT 和 GPT-2 的从头训练获得约 2.0-2.5 倍 wall-clock 加速,准确率或困惑度基本不变,部分下游任务还有小幅提升。文章也明确了边界:它主要适用于 GEMM 驱动的网络与特定硬件假设,更像是稀疏参数化与软硬件协同设计的研究方案,而不是通用加速器。

文中直接给出 2.0-2.5 倍训练加速、精度基本不降等实验结果,并解释了为何要从动态稀疏转向静态、块对齐的硬件友好结构。适合关注稀疏训练、模型加速和软硬件协同的研究者或工程师参考;其可迁移价值在于提供了稀疏参数化设计思路,但适用范围受限于 GEMM 网络和特定硬件。