Topic 1, Session 1.0 | 从 HPC 到 AI Infra：并行计算与并行编程 Topic 1, Session 1.1 | CUDA 编程模型 Topic 1, Session 1.2 | Triton/TileLang Tile Level 编程 介绍活动整体安排、内容设计、评测与算力资源。
课程日历
全部安排
本讲以 CUDA Core FP32 GEMM 为主线，从计算语义出发理解 data reuse 与 memory hierarchy 的抽象；从 strawman GEMM 演进到 tiling，并使用 Roofline Model 分析数据复用；再从硬件视角理解 SM、warp 执行、 coalescing、latency hiding、shared memory bank conflict、padding、 swizzle 与 per-thread microtile，最后使用 Nsight Compute 完成一个 Kernel 的编写与调优。
本次 Workshop，我们将介绍：TileLang 语法、 如何用 TileLang 写 Kernel、TileLang 中的 CTA 到 Thread 的映射与 Layout Inference、 如何在 TileLang 中做 Latency Hiding，以及 DSL 的 JIT 编译和 Host 侧的相关内容； 最后，我们还将介绍在 TileLang 下如何做算子优化以及一些相关的工具。
本讲以 Tensor Core 的硬件与编程模型为主线，贯穿 mma.sync（Ampere）、 wgmma（Hopper）和 tcgen05（Blackwell）三代指令的演进，从数据搬运与 发射带宽推导 Tensor Core 的设计逻辑，理解 fragment 布局以及使用 layout 与 swizzle 解决 bank conflict 的方法，最后以 FP8 fine-grained scaling 介绍低精度 Tensor Core 的使用。
硬件发展过程中，计算能力、内存带宽提升的同时，频率提升稍显缓慢。 单个操作 latency 的改善已经远慢于系统 throughput 的增长，现代体 系结构从“降低 latency”逐渐转为越来越依赖于通过并行性容忍和隐藏 latency。 从指令并行 ILP，乱序执行 OoO，到内存层级并行 MLP、Warp 调度与 TLP， 追寻自动 latency hiding 的方法不断发展和演进，然而， 随着 Tensor Core 等专用计算单元的吞吐快速增长，计算与数 据供给能力之间的差距进一步扩大。以 cp.async、TMA 为代表的异步数据搬运机制， 逐渐将原先很大程度由硬件自动完成的 latency hiding，暴露为程序员和编译器需 要显式组织的 Pipeline。更进一步的，我们甚至不再完全依赖通用的 Warp Scheduling 来自动隐藏延迟， 而是主动固定不同执行资源的职责，并显式安排工作的空间和时间结构。这些，都可以 算是 Pipeline Ordering: Data Orchestration，即如何组织数据、处理计算。 在最新的硬件上，上述内容已成为发挥硬件极限性能、实现极致性能算子的关键核心与重中之重。 本节课，我们将在有限的时间内，对上述内容进行综合性的介绍。
随着计算量的不断增加，单个计算单元已无法满足更大的计算需求，这要求我们必须采用某些方式将计算单元连接起来。 历史上，总线、PCIe、TCP/IP、Ethernet 等，都从不同方面不同层次对互联中关键的问题进行了回答。 AI 时代，为了承载 HPC/AI Workload 中大规模并行计算所需要的通信和互联，我们需要更大的带宽、更低的延迟、更高的可靠性， 迫使我们不断设计和改进网络系统。本节课，我们将从通信需求的产生开始，试图从第一性原理出发，逐步解释现代网络系统的组成与设计。 本次活动无课前阅读。
Pipeline 背后真正的问题是：谁来决定什么工作在什么时候、在哪个资源上执行？谁负责维护依赖、推进执行，并判断一个阶段何时真正完成？ 这其中涉及到一组连续的设计 trade-off：硬件与软件的责任划分、编程复杂度与硬件复杂度、静态与动态调度、显式控制与自动管理、 灵活性与可预测性，以及细粒度重叠带来的性能收益与状态和同步开销。在单 GPU 内部，这些责任可以由 Compiler、Warp Scheduler、 Scoreboard、Pipeline、Barrier、Copy Engine 和 Memory Hierarchy 共同承担。我们关注数据如何在 Register、Shared Mem、片上专用存储和 HBM 之间流动并保证计算正确推进。 今天，我们把同一个问题扩展到 GPU-to-GPU 高速互联。此时数据的 Producer 和 Consumer 不再位于同一块 GPU 上，数据可能需要跨越 GPU Fabric、 NVLink / NVSwitch、PCIe、RNIC、RDMA Transport 和交换网络。原本局限在单 GPU 内部的 Readiness、Ordering、Completion 和 Visibility， 现在必须跨越不同的设备、地址域、队列、协议乃至故障域继续成立。我们今天讨论这些状态和控制责任应该放在哪里，并介绍 Workload 中对通信的要求以及工业界一些经典的解决方案。 本次活动无课前阅读。