工程实践 NVIDIA Technical Blog 2026/09/28
NVIDIA DSX MaxLPS 通过策略驱动的动态功率共享，在同一设施功率预算内监控 GPU/节点/机架实际功耗，把闲置余量重新分配给其他资源，从而在不增加供电的前提下提升 AI 工厂吞吐。文章给出 NVIDIA 与 Nscale 在冰岛 Verne 园区的联合评测：基于 GB300 NVL72、Kimi K2.5 FP4、Dynamo 与 TensorRT-LLM，混合高吞吐和低延迟推理实例，在 264.4 kW 固定配置功率下把托管 GPU 从 140 扩到 192（+37.1%），归一化总吞吐提升 49.2%，每配置瓦特吞吐从 4.10 升到 6.12 tokens/s/W。单实例吞吐基本不变，中位与 P75 时延在基线 5% 内，但 P99 首 token 时延增加 17%，提示需权衡尾延迟。作者还给出五阶段验证流程（界定边界、建立基线、保守引入策略、逐步扩容并逐级测试、设定生产限值），并强调结论仅针对 GB300 NVL72 且依赖可靠遥测。
推荐收录：文章给出了同一 264.4 kW 预算下 140→192 GPU、吞吐 +49.2%、每瓦吞吐 4.10→6.12 tokens/s/W 的实测数据，同时披露 P99 首 token 时延 +17% 的代价，并附可复用的五阶段验证流程，适合 AI 数据中心架构师、容量规划与 SRE 读者参考。主要风险是厂商自评、硬件与软件栈单一，实际部署前需在自身负载和供电边界下复测。
工程实践 NVIDIA Technical Blog 2026/09/24
文章介绍如何用 NVIDIA Transformer Engine 与 BioNeMo 配方高效训练基于 MoE 的生物基础模型，重点解决专家计算碎片化、激活显存压力和低精度量化开销三个问题。方法上，以 GroupedLinear 将多个专家 GEMM 合并为一次分组操作，替代 Hugging Face 基线中的逐专家 Python 循环；采用 MXFP8 块缩放将权重与激活降至 8 位，并利用 Blackwell Tensor Core 加速；再通过 Sequential API 将 GroupedLinear、ScaledSwiGLU 和路由权重缩放融合为 ForwardGroupedMLP_CuTeGEMMSwiGLU_MXFP8 kernel。在 8 张 B200 上，Mixtral-8x7B 训练吞吐达到 Hugging Face 基线的最高 2.21 倍。边界是融合 MXFP8 内核依赖 Blackwell GPU 与 NVIDIA 软件栈，且未深入讨论生物模型精度和长序列场景下的泛化影响。
推荐收录，因为文章给出可复现的 MoE 训练优化路径，包括 GroupedLinear 分组 GEMM、MXFP8 块缩放和融合 GroupedMLP kernel，并在 8×B200 上报告 Mixtral-8x7B 相对 HF 基线最高 2.21× 吞吐。适合大模型训练基础设施、GPU 算子优化和 AI 工程化读者，可迁移到其他 MoE 或长序列训练场景。需注意其结论依赖 Blackwell GPU 与 NVIDIA TE/BioNeMo 栈，且未充分分析生物模型精度影响。
工程实践 NVIDIA Technical Blog 2026/09/23
文章介绍 NVIDIA 开源的 Kubernetes 控制器 NVCRE，用于在生产 AI 负载落地前验证 GPU 集群的真实可用性。它通过 Certification、Workflow、Job 三层 CRD，按拓扑感知分组运行真实分布式负载（NCCL 通信、DCGM 四级诊断、NeMo 预训练），把失败归因到具体节点和类别。达标判定用 CEL 表达式对总线带宽、goodput、每 GPU TFLOPs 等实测指标求值，作业跑完但未达阈值同样记为失败；testScale: diagnose 会分层切分失败组并重跑，收敛到少量嫌疑节点。WorkloadRun API 封装多节点作业的平台探测、框架配置与 gang scheduling，并与 AICR、NVSentinel 构成配置—验证—监控分层。边界是依赖 Kubernetes 1.29+ 等特定环境，阈值需自行设定，文章偏工具说明，缺少大规模实测数据。
推荐收录：文章没有停在概念宣传，而是给出三层 CRD 设计、CEL 阈值表达式、分层故障隔离算法以及 gang scheduling 防止排布死锁等可直接复用的细节。适合负责 GPU/Kubernetes 平台、AI 训练基础设施与集群验收的工程师，可据此搭建投产前的自动化验证流程。局限是全文以 NVIDIA 自有工具为主线，阈值与规模收益需读者结合自身集群实测确认。
工程实践 NVIDIA Technical Blog 2026/09/23
文章介绍 NVIDIA 开源的 Kubernetes 原生包管理器 NodeWright（原名 Skyhook，已在生产环境运行），用于在 GPU 集群中声明式地配置与升级主机操作系统而不中断工作负载。其核心是 operator + 自定义资源 + 包（容器镜像携带脚本、配置与校验逻辑）三部分，按 cordon、等待、drain、应用配置、按需中断、uncordon 六阶段编排，并尊重 PodDisruptionBudget、标签与非中断工作负载。文章详细说明 DeploymentPolicy 的固定、线性、指数三种渐进式发布策略，以及成功/失败阈值和分区（compartment）机制，并给出安装、CVE 修复、内核调优、节点就绪门控等场景示例。它还阐述了与 AICR、NVCRE、NVSentinel 的集成边界——NodeWright 只管理主机 OS 层，不替代 GPU/Network Operator。
收录理由：文章来自核心作者且已在数千节点生产验证，明确给出六阶段节点变更序列、三种发布策略与阈值控制、包生命周期与校验机制，属于可迁移的 GPU 集群主机维护工程方案。适合负责大规模 Kubernetes/GPU 集群、需要做内核调优与 CVE 修复而不中断训练的 SRE 与平台工程师。需注意其带有 NVIDIA 产品生态推广色彩，且缺少失败案例与量化实验数据，参考时应结合自身集群验证。
科研议题 Microsoft Research Blog 2026/09/23
微软研究博客挑战物理AI推理必须全部运行在机器人板载GPU上的假设，围绕移动操作任务中的语义建图与规划、导航和操作，系统比较板载、边缘与云端GPU的推理表现。评测显示，将推理卸载到边缘/云GPU可提升任务成功率、响应速度与准确率，并支持更大的VLA等模型；较弱板载GPU会使建图与规划最多变慢383%，导航障碍及时检测下降30%，VLA准确率下降50%，Jetson Thor等还会使续航缩短最多160%。作者发布基于Kubernetes的Physical AI Toolchain，可用声明式方式自动容器化、部署和编排机器人AI工作负载，并集成ROS2、LeRobot与仿真器。结论主要适用于移动操作类物理AI工作负载，卸载仍面临性能、网络延迟/带宽与GPU资源间的复杂权衡，且结果依赖具体硬件配置，完整证据需参考其技术报告。
推荐收录。文章基于微软研究院对移动操作工作负载的系统测量，给出板载与边缘/云GPU在任务成功率、时延、VLA准确率和续航上的具体数据，并开源基于Kubernetes的Physical AI Toolchain，可直接指导物理AI推理架构和卸载策略设计。适合机器人、边缘/云推理基础设施与MLOps工程师阅读；需注意其结论依赖特定硬件与网络条件，且本质是厂商研究博客，完整实验细节应以技术报告为准。
工程实践 NVIDIA Technical Blog 2026/09/22
NVIDIA 技术博客介绍在 Blackwell GPU 上通过机密计算运行生产级 LLM 推理的性能优化实践。文章先给出选型方法：用长输入、长输出、低并发工作负载暴露 CC 开销，再在 DGX B200 上以 TensorRT LLM 和 DeepSeek-R1 做 CC 开关对照，测得吞吐保留 96.1%–98.2%、TPOT 增加 1.2%–4.3%。作者指出 B200 CC 导致主机到设备拷贝走加密反弹缓冲区、CUDA 事件计时不稳、NVLS 多播不可用三项变化，并说明 TensorRT LLM 通过可分页内存、异步回读、%globaltimer 计时和 CC 感知通信算法来缓解。文章强调机密推理仍需性能工程，安全与推理优化应统一规划，但结论依赖特定硬件和框架版本。
推荐收录，因为文章不是泛泛宣传，而是给出了可复现的 CC 开关对照方法、具体吞吐/延迟数据（96.1%–98.2%、1.2%–4.3%）以及三项可定位的运行时根因和对应 PR。适合 AI 平台工程师、TensorRT LLM 用户和关注机密推理性能的读者，其测量框架和“安全配置与推理优化统一评估”的思路可迁移到其他 CC 工作负载。主要局限是结论绑定 B200、TensorRT LLM 1.3.0rc22 等具体版本。
工程实践 NVIDIA Technical Blog 2026/09/22
本文由 NVIDIA 工程师撰写，介绍开源工具 Topograph 如何为 AI 工厂/GPU 集群提供拓扑感知的工作负载调度。核心问题是：分布式训练与推理需要通信局部性，若调度器不掌握当前的 GPU 与网络互连关系，工作负载会被打散到远端拓扑域，导致跨链路竞争、吞吐下降与成本上升。Topograph 通过 provider（从云 API 或本地 InfiniBand/Spectrum-X/MNNVL 发现拓扑）与 engine（输出 K8s 节点标签、NFD 资源、Slurm topology.conf 或 Slinky ConfigMap）两层抽象，把异构环境归一化为统一模型，并由 API Server、Node Observer、Node Data Broker 等组件在集群变化时自动重算。文章给出 Helm/native 包部署、节点标签校验、亲和性配置，以及与 KAI Scheduler、Kueue、Slurm、Slinky 集成的完整示例。主要边界是：它反映的是上报而非预期拓扑，部分能力依赖特定 provider、版本或 alpha 特性开关，且文中未给出量化性能收益。
推荐收录，因为它用可验证的仓库、Helm chart 和 API 端点具体展示了 GPU 集群拓扑感知调度的架构权衡与落地步骤，而非泛泛宣传。适合负责 AI 基础设施、GPU 调度、Kubernetes/Slurm 集群运维的工程师参考，其 provider/engine 抽象、标签层级与自动刷新机制可迁移到其他异构算力调度场景。风险在于其性能收益未量化，且部分特性依赖 alpha 开关与特定版本。
工程实践 NVIDIA Technical Blog 2026/09/22
NVIDIA 技术博客讲解如何借助 AI 编码代理，把已有的 CUDA 加速 ROS 2 节点迁移到 rosidl::Buffer 抽象与 CUDA buffer backend。该后端基于 CUDA 虚拟内存管理实现零拷贝：当发布者与订阅者同主机、同 CUDA 设备、同 Linux 用户且使用受支持 RMW 实现时，可直接交换 GPU 常驻数据，否则回退 CPU 路径，并保持标准 ROS 2 消息接口不变。文章以 Depth Anything 3 TensorRT 节点为例，展示 migrate-node-to-rosidl-buffer 技能如何审计数据流、规划最小改动：订阅声明接受 cuda、输出消息分配 CUDA 缓冲、TensorRT 推理直接写入，点云与调试等可选 CPU 路径保持独立。验证用 Nsight Systems 确认 ROS 边界不再有载荷级主机-设备拷贝，并以 get_backend_type() 是否为 cuda 判断协商结果。内容依赖 ROS 2 Lyrical、Isaac ROS 5.0 与 NVIDIA 生态，未给出量化性能收益。
推荐收录：文章给出从依赖添加、订阅选项、CUDA 缓冲分配到推理直写与验证的完整迁移路径，并明确零拷贝生效前提（同主机、同 CUDA 设备、同用户、受支持 RMW）和 CPU 回退机制，可直接借鉴到 GPU 加速 ROS 2 节点与机器人数据通路优化。适合机器人中间件、边缘推理和 CUDA 数据流方向的工程师，其“审计—最小改动—验证”方法可迁移到其他节点。风险是依赖 NVIDIA 生态、缺少量化性能数据。
工程实践 美团技术团队
美团技术团队介绍统一推荐基座大模型 MTFM，在 MTGR 基础上首次实现外卖多个主要业务的统一精排。文章围绕规模可扩展性、场景可延展性和架构高效性三大挑战，提出异构 Tokenizer 与动态掩码实现多场景特征免对齐，混合注意力与 Target Scale-Up 提升 Scaling 能力，并借鉴 LLM 的初始化、Muon 优化器、动态归一化等训练实践。系统层面采用 User-Level 训练范式与定制 GPU 算子，降低训推开销；在线多个业务订单提升 2.06%~6.68%，推理成本降低 24%，工作被 KDD 2026 收录。适用边界在于结论来自美团外卖业务与特定模型规模，跨行业迁移仍需验证。
推荐收录。文章给出 MTFM 的完整架构、训练策略、GPU 算子优化、Scaling 验证与线上 A/B 收益（多业务订单提升 2.06%~6.68%、推理成本降 24%），属于少见的工业级推荐基座落地复盘。适合推荐系统、AI 工程化与大规模训推基础设施读者，其异构 Tokenizer、User-Level 训练和算子优化可迁移；但具体收益依赖美团外卖数据与业务结构，跨场景复用需重新验证。
工程实践 vLLM Blog 2026/09/22
文章介绍 vllm-metal v0.28.0，将 vLLM 的 V1 调度器、分页 KV 缓存和 OpenAI 兼容服务端移植到 Apple Silicon，底层由 MLX 与 Metal 执行。它复用 mlx_lm 的按 token 独立层，仅替换为分页 varlen Metal 注意力内核，并用 cu_seqlens 打包查询、以块表管理 KV，从而在连续批处理中混合预填充与解码。文中对比 llama.cpp、oMLX、mlx_lm 在并发 agent 负载下的 TTFT、吞吐与延迟，还覆盖内存预算、批处理 MTP、M5 NAX 预填充与混合模型前缀缓存复用。局限是 MTP 仅支持 Gemma 4 贪心采样和同步调度，混合模型前缀缓存仍属实验特性。
推荐收录：该文虽为版本发布博客，但给出了 vllm-metal 的完整服务架构、分页 varlen 注意力实现细节以及与 llama.cpp、oMLX 等引擎在并发 agent 负载下的可复现基准。它适合在 Apple Silicon 上部署本地 LLM 服务、研究连续批处理与内存/延迟权衡的工程师，其 packed query、paged KV 和 MTP 批处理方案可迁移到其他硬件后端。
工程实践 NVIDIA Technical Blog 2026/09/21
NVIDIA 博客介绍 TensorRT 多设备推理与 Dynamo-Triton 26.07 的集成：借助 NCCL 集合通信，单个 KIND_MODEL 实例可跨多块 GPU 执行同一 TensorRT 网络，并暴露单一 gRPC 端点，应用无需协调 GPU rank。文章以 Cosmos 3 Nano 视频生成为例，用 Ulysses 上下文并行将 44,160 个视频 token 分布到最多 8 块 GPU，Triton 服务其 36 层去噪 transformer。基准显示端到端延迟从单 GPU 的 156.6 秒降至 8 GPU 的 34.2 秒（4.58 倍），RPC 加速 6.09 倍，输出按 MAE≤25、PSNR≥18 dB 验证但非像素级一致。该方案以更多 GPU 换取低延迟，未测并发吞吐与 TCO，需结合自身 SLO 评估。
推荐收录：文章给出了 Dynamo-Triton 多设备服务的配置片段、Ulysses 上下文并行方法，以及 1/2/4/8 GPU 的端到端延迟与 RPC 加速数据。适合多 GPU 推理服务与生成式媒体延迟优化的工程师参考，其把分布式 rank 协调封装为单一模型端点的思路可迁移到其他多卡服务。风险是厂商视角且未覆盖并发吞吐与 TCO。
工程实践 vLLM Blog 2026/09/21
文章介绍 vLLM 团队在 GB300 NVL72 上对 Qwen3.8-2.4T（GDN/Full-Attn 混合层加 MoE、NVFP4 权重）做 PD 分离推理的调优流程与性能结果。核心方法是从显存账目出发：由 Full-Attn 每 token 每层 2 KiB、GDN 每请求约 4.2 MiB 推出 block 为 2112 token，再逐项扣除 CUDA 上下文、NCCL、权重、峰值激活与 CUDA graph 预留，估算每引擎最大并发。作者用纯 prefill（8192/2）和纯 decode（1/1000）分别筛选拓扑，得出 prefill 低并发选 TP4DP2+EP、高并发选 TP2DP4+EP，decode 低并发选 TEP8+MTP、高并发选 TP4DP4+EP。最终在 8K/1K 负载下达到 5000 total tok/s/GPU、180 gen tok/s/用户，GSM8K 准确率 95%，并公开可复现的 srt-slurm 配方。局限是结论绑定 GB300、特定模型与 vLLM nightly 版本，CUDA graph 显存估算偏保守，读者需自行复测。
推荐收录：文章把超大模型 PD 分离服务拆解为可复用的决策流程，给出 KV/GDN block 推导、CUDA graph 显存估算偏差与 prefill/decode 拓扑筛选的一手量化数据，并附可复现的 srt-slurm 配方。适合推理基础设施与 LLM 服务性能调优读者，其“先算显存账、再分离测量”的方法可迁移到其他模型；需注意结论依赖 GB300 与特定 vLLM 版本。
工程实践 NVIDIA Technical Blog 2026/09/18
文章介绍 NVIDIA 为 LLM 推理压测推出的新工具 AIPerf，它是 GenAI-Perf 的彻底重写。其核心设计是多进程架构：工作进程负责产生负载，独立记录进程处理结果，并通过 ZMQ 协调，从而避免单进程 GIL 让压测客户端先于服务端成为瓶颈。工具支持 15 种以上端点类型、ShareGPT 等公开数据集以及 Mooncake、Baseten、WEKA 的 trace 回放，并提供 constant、Poisson、gamma 等到达模式与可调突发性。文中以 vLLM 部署 Qwen3-0.6B 为例，演示固定 ISL/OSL 的静态基准和带随机种子的 Poisson 流量两种配置，解释 --streaming、min_tokens、ignore_eos 等参数对 TTFT/ITL 测量与可复现性的影响，并说明用 p25–p99 分位和 GPU telemetry 解读结果。局限是内容偏工具用法与官方口径，缺少与其他压测工具的系统对比和独立验证。
推荐收录：文章给出了压测客户端不能成为瓶颈这一具体设计依据（多进程 + ZMQ 替代 GIL 受限的单进程架构），并附上固定负载与 Poisson 到达两类可直接复用的基准配置及 TTFT、ITL、吞吐的分位解读方法，对做推理服务性能评估和容量规划的工程师有迁移价值。需注意其出自工具官方博客，缺少横向对比与第三方复现，采用前宜自行校验。
工程实践 vLLM Blog 2026/09/18
该文介绍 vLLM 集成 NVIDIA PyNvVideoCodec（NVDEC 硬件视频解码）的方案，用于解决多 GPU 视频字幕任务中的 CPU 解码瓶颈。此前 vLLM 只能走 OpenCV+FFMPEG 的 CPU 解码路径，在每 GPU 一个副本的部署下 CPU 核心很快耗尽，还未到 4 GPU 就成为瓶颈。作者给出启用方式：先启动 CUDA MPS 守护进程，再通过 --media-io-kwargs 选择 pynvvideocodec 后端、用 --mm-ipc-gpu-memory-gb 预留解码显存，并建议一容器一 GPU、反向代理分发请求。基准显示在 8×H100 上 GPU 解码吞吐超过 CPU 解码两倍以上，CPU 瓶颈被消除。边界在于硬件解码需预留部分显存，若 KV cache 已占满全部显存可能受影响。
推荐收录。文章给出了真实工程瓶颈（CPU 视频解码成为多 GPU VLM 推理瓶颈）的量化证据、可复现的启动命令与 8×H100 吞吐翻倍的对比数据，并明确说明显存预留限制，属于可迁移的工程经验。适合从事多模态 VLM 推理、视频数据处理和大模型服务扩容的工程师参考。
技术文章 知乎 - 鹅厂架构师 2026/09/17
文章用制衣厂比喻系统讲解 CPU、GPU、TPU、NPU 的定位与差异：CPU 像裁缝老师傅，擅长复杂串行逻辑与调度；GPU 像工人大军，以大规模并行见长，并成为 AI 训练推理的通用算力底座；TPU 像提花织机，以脉动阵列专攻矩阵乘法，能效高但换算子或新架构时灵活性差；NPU 则是终端侧低功耗 AI 推理芯片。文中结合苹果 M 系列、英伟达 Blackwell、谷歌 TPU v7、A18 Pro 等产品与算力指标，对比设计目标、核心数量、灵活性、能效比和典型位置。最后从任务性质、晶体管预算、功耗约束和市场需求四条线解释为何造不出全能芯片，并指出真实系统依赖异构协同。其边界是大众科普，缺少论文引用和微架构细节，部分前瞻数字需按发布时间复核。
推荐收录：文章用统一类比串起四类处理器的架构取舍，并给出具体产品、算力指标和 GPU 与 TPU 在灵活性与能效上的边界对比，不是简单名词解释。适合希望建立芯片全景认知的工程师、学生和技术管理者，其中“通用性换灵活性、专用性换能效”的判断可迁移到系统设计与技术选型。主要风险是科普定位且无参考文献，部分 2026 年数据需后续核实，不宜作为底层微架构实现的唯一依据。
工程实践 NVIDIA Technical Blog 2026/09/16
NVIDIA 技术博客介绍其在 MLPerf Inference v6.1 Edge Agentic 基准上的提交：TensorRT Edge-LLM 在单台 Jetson AGX Thor 上运行 Qwen3.6-27B，输出吞吐 52.33 tokens/s、首 token 时延 247ms，用 24 分 36 秒完成 1007 轮多轮工具调用负载，比 llama.cpp 参考实现快 6.4 倍，BFCL v4 准确率 87.94%。文章先说明评测口径：性能阶段回放软件工程 agent 轨迹、上下文增长至约 23.5K token，准确率阶段使用单轮 BFCL 提示。随后详解三项优化机制：NVFP4 量化权重与激活、FP8 KV cache 以缓解 DRAM 带宽瓶颈；跨轮 KV cache 与循环状态复用使约 96% 的 prompt token 命中热缓存，13.6M token 中仅预填 0.5M；树状多 token 预测（8 步、top-2、16 节点验证树）在函数调用场景再提升约 40% 解码性能。文中给出开源分支、量化检查点与复现命令，但结论限于单一硬件与模型配置，且属厂商自评。
推荐收录。文章不止给出 6.4 倍加速的跑分，还公开了 MLPerf Edge Agentic 性能与 BFCL 准确率的双阶段评测口径，并解释 NVFP4/FP8 量化、跨轮 KV cache 与循环状态复用、树状 MTP 三项优化的机制与量化收益（约 96% 热缓存命中、约 40% 解码提升），附可复现分支、检查点与运行命令。适合做边缘 LLM 推理、量化与投机解码的工程师；需注意其为 NVIDIA 自评，硬件与模型配置单一，收益不可直接外推。
工程实践 NVIDIA Technical Blog 2026/09/16
文章介绍 NVIDIA 用 Agentic AI 将 CUDA Tile 算子从 Python 翻译到 Rust 的工程实践。cuTile Python、Triton-TileIR 与 cuTile Rust 共享同一 CUDA Tile IR，因此移植不是重新优化，而是用更安全的主机语言重写同一 tile 程序，并可通过比对参考内核与生成内核的 Tile IR 做结构性验证。作者构建了一个有界多智能体流水线，覆盖分析、设备内核、主机与 FFI 代码、正确性和性能校验，每个阶段都以可机器检查的判决收尾，并配有 IR diff 分析与残余性能归因两个专职诊断子代理。团队据此移植了全部 24 个 TileGym 公开算子（约 40 个内核），在 DGX B200 上达到 cuTile Python 平均 99.5% 的性能，约三分之一算子反超。文章也指出 Rust 需显式声明特化、C ABI 之后无安全网、部分内核仍依赖非安全 API 等边界。
推荐收录。它以真实算子库为对象，给出了多智能体流水线的编排契约、判定路由、IR diff 验证与实测性能数据，并给出 softmax 的 Python/Rust 逐行对照和 C ABI 集成细节。适合做 GPU 内核、编译器前端或 AI 工程化落地的读者参考其可验证的翻译与代理编排方法，风险在于其结论依赖共享 Tile IR 与 Blackwell 工具链，迁移到其他体系需重新验证。
工程实践 vLLM Blog 2026/09/15
文章介绍 Novita AI 开源的 Chord 高性能 W4A16 MoE CUDA 算子，面向 BF16 激活、INT4 权重与 group-32 量化，针对 Kimi K2.x 推理场景。Chord 分两个内核族：基于 Humming 的 indexed 路径和源自 DeepGEMM 的 grouped SM90 路径，分别适配 prefill 与 decode 的路由形态。作者详述内核优化技术，如 WGMMA 流水线、按 expert token 数选择 block-M、stream-K 门控及 grouped 模式的 BM/BN/BK 启发式。在 H200 和 B300 上逐层测量显示，相比公共 Humming，indexed 路径取得 1.11–1.33x 加速，grouped 路径在 H200 EP8 达 1.16–1.35x，端到端吞吐提升约 4–10%。文章指出 B300 对比基于未调优的 Humming 默认配置，grouped 与 vLLM 集成仍在进行，性能数据为内核层面而非端到端保证。
推荐收录。文章不仅给出 Chord 算子的设计细节与优化手段，还提供了可复现的基准测试方法和逐层性能对比，并坦承 B300 对比的未调优前提与 grouped 集成尚在开发中。对从事 LLM 推理优化、GPU 内核开发或 MoE 量化部署的工程师而言，文中的 workload 驱动的调优策略、WGMMA 流水线设计和路由形态分析具有直接的迁移价值。
工程实践 vLLM Blog 2026/09/15
文章介绍 vLLM Speculators 训练库如何为 2.8T 参数的 Kimi K3 训练并部署 DSpark 草稿模型。DSpark 在 DFlash 并行块草稿基础上加入 Markov logit-bias head 和 confidence head，通过顺序校正与硬件感知调度缓解 suffix decay，并提升接受长度。作者在 GB300 NVL72 上验证，数学推理单流交互性从约 110 提升到约 435 tok/s/user，并发下输出吞吐最高约 3.5 倍。为突破单节点显存限制，文章实现 MooncakeHiddenStatesConnector，通过 Mooncake 在 vLLM 推理与 Speculators 训练间流式传输隐藏状态，并采用两节点推理、一节点训练的三节点组拓扑。主要边界是效果依赖大规模 GPU 集群、特定模型量化、负载类型和长上下文配置，性能数字来自特定评测环境。
推荐收录：文章给出了 DSpark 算法组件、Mooncake 隐藏状态传输、三节点训练/推理拓扑和实测吞吐/交互性数据，是可迁移的 LLM 推理优化与分布式训练工程案例。适合 vLLM 部署、推理加速、GPU 集群训练方向的工程师和研究者阅读。风险在于依赖 GB300 NVL72 与 Kimi K3 特定环境，部分收益需在自身负载上复测。
工程实践 vLLM Blog 2026/09/13
文章系统复盘了 vLLM 为 Kimi K3 所做的端到端推理性能优化，在 B300 节点、8K/1K 负载、TP8 与 8-token DSpark 投机解码配置下，把延迟降低 56%–60%、吞吐提升 2.2–2.8 倍、TTFT 下降 72%–85%。核心方法包括自适应调度 token 预算、KDA 前缀检查点内嵌于单次 prefill、零拷贝混合 KDA 批处理、MXFP4 top-k 融合进 latent-tail 内核，以及用 ReplaySSM 重建而非存储 SSM 状态。文章还讨论了 prefill/decode 分离与混合状态卸载、decode 上下文并行（DCP）在长共享前缀场景下的 KV 容量与 TPOT 收益，并附有各改动对应的 PR 编号与量化数据。其结论针对 Kimi K3 这类混合 KDA+MLA+MoE 架构，优化收益依赖具体硬件与负载形态，未覆盖其他模型或更广泛工作负载。
推荐收录：文章给出具体 PR 编号、量化的 TTFT/吞吐/延迟对比表和显存容量数据，展示了从瓶颈识别到内核融合、状态管理与并行策略的完整工程取舍链路。适合做大模型推理服务、GPU 内核优化或 vLLM 二次开发的工程师阅读，其中自适应调度预算、零拷贝批处理和 ReplaySSM 等思路可迁移到其他长上下文与投机解码场景；风险在于结论高度绑定 Kimi K3 架构与 B300 硬件，直接套用到其他模型需重新验证。
工程实践 vLLM Blog 2026/09/10
文章复盘 vLLM 在 AMD Instinct MI355X 上优化 MiniMax M3 推理服务的完整过程，给出固定 8K/1K 负载下 MXFP8、MXFP4、EAGLE3 和 P/D 分离等多项吞吐与延迟结果，如并发 32 时 MXFP8 输出吞吐提升 3.14 倍，并发 128 时 P/D 达到 6370.5 total tok/s/GPU。作者以“一个 decode step 的五个问题”组织方法：确认 TP 分片后的本地 GEMM 形状、合并重复的共享专家与索引计算、减少 KV/元数据搬运、验证快速路径是否真正执行且正确，并在叶内核优化见顶后转向队列、缓存与 OS 限制。文章还强调 configured/eligible/executed 的区别以及性能与正确性门禁，并说明固定负载策略不计算跨层索引复用、AgentX 单次结果等边界。
推荐收录。文章以 PR 级 A/B、InferenceX 基准和可复现启动命令为证据，展示了从 kernel 到 P/D 队列的系统级瓶颈迁移和可迁移检查清单，适合 LLM 推理性能、GPU 与 vLLM/ROCm 工程读者参考；风险是部分结论绑定特定镜像、拓扑和工作负载，不能直接外推。
技术文章 NVIDIA Technical Blog 2026/09/09
本文介绍了编码-预填充-解码（EPD）分离技术，用于加速多模态大模型的推理服务。核心思路是将视觉编码阶段与预填充和解码阶段分离到不同的计算资源上，避免不同阶段之间的资源竞争和干扰。作者指出该技术最适合图像密集提示、短到中长度输出以及量化混合专家（MoE）模型等场景。文章结合 NVIDIA Dynamo 系统展示了具体的使用方法，并报告了最高可达 5 倍的加速效果。文中还分析了 EPD 分离适用的工作负载边界、资源调度权衡以及部署注意事项，帮助读者判断何时值得采用这一优化技术。
本文是 NVIDIA 官方技术博客，提供了关于多模态模型推理优化的具体技术方案和适用场景分析。对 AI 基础设施工程师和模型部署人员而言，文中的 EPD 分离原理、资源调度考虑及实际收益数据都具有直接参考价值，能够指导在真实多模态服务中做出架构取舍。
工程实践 vLLM Blog 2026/09/08
文章介绍 vLLM 为 GLM 5.3 引入的 Hybrid HiSparse 混合稀疏卸载方案，面向长上下文、高并发的智能体推理场景。其核心是 KV 缓存默认常驻 GPU，仅在显存池紧张时按页逐步放弃驻留，并把索引器选中的 top-K 行放入与常驻页共享同一 HMA 池和 KV 张量的热缓冲区，让请求在部分驻留状态下继续解码，避免抢占重算或等待整段 KV 回迁。文中给出完整驻留、混合驻留、无驻留三种状态及内核解析流程，并说明与 P/D 分离、投机解码、前缀缓存等组件的兼容方式。在 8×H200 的 OpenHands 多轮负载上，该方案首次支持 100 万上下文并显著提升并发；但仅支持 NVIDIA GPU 与稀疏 MLA，热缓冲区需按投机 token 数调整，并发估算仅为规划参考。
推荐收录：文章给出真实系统约束下的完整工程方案，包括三种 KV 驻留状态的机制、热缓冲区与 HMA 池共享的设计取舍、基准测试数据以及可复现的启动命令与数据集脚本。对做 LLM 推理服务、KV 缓存管理和长上下文并发的工程师具有直接迁移价值；局限是仅支持 NVIDIA GPU 与稀疏 MLA 路径，且热缓冲区受投机解码约束，需结合自身配置验证。
工程实践 vLLM Blog 2026/09/01
文章介绍 vLLM-Omni 对 MiniMax H3 视频-音频联合生成模型的系统级服务优化，以及集成 FastVideo 四步蒸馏版 FastH3 实现完整 MP4 生成快于播放。作者把端到端链路拆成编码器、长序列音视频 DiT、并行 VAE 解码、GPU 输出准备与 H.264/AAC 封装，并用长序列注意力/通信优化、融合 DiT 算子、并行 VAE、紧凑传输和并行 MP4 构建，在 8×B300 上把基础 H3 端到端延迟较 Diffusers 降低 30.8%。随后引入四步 FastH3，在 10.125 秒 MP4 上取得 8.678–8.710 秒干净端到端延迟，5/10/15 秒扫描全部满足 RTF_client≤1.0。文章还给出 DLO、编码器解耦、Online FP8、SAGE/Skip-Softmax 注意力和 Cache-DiT 等可选路径的兼容边界与质量-性能权衡。局限是两条证据通道未做同源 A/B，FastH3 与 DLO、量化、编码器解耦等组合未完全验证，且缺少匹配的多随机种子质量对比。
推荐收录，因为它不是基准数字堆砌，而是完整呈现了系统瓶颈分解、冻结实验控制、有损/无损优化边界和兼容性矩阵，并公开了可复现命令、版本与限制。适合多模态生成模型推理服务、GPU 性能优化和分布式推理基础设施的读者，其“先量化全链路开销，再用少步蒸馏攻击主导项”的方法可迁移；主要风险是部分证据待发布、未做同源 A/B 与多随机种子质量对比，不能直接推导跨配置加速比。
工程实践 vLLM Blog 2026/08/21
文章介绍 vLLM/Megatron 生态中的 IsoExec，旨在消除 RL 训练中 rollout 引擎与 trainer 因不同 kernel、批形状和并行布局导致的浮点非结合性不匹配。其核心是跨运行时执行契约：按 region/case 固定实现、累积 dtype 与归约顺序，并用语义及数值策略摘要校验；同时提供并行不变 kernel 与 CPR Gated DeltaNet，使训练、prefill 和 decode 位级一致。在 8×H100 上训练 Qwen3.5-35B-A3B DAPO，契约覆盖范围内实现零不匹配，logprob 差异显著下降，但端到端仍有约 25% 开销。局限是 50 步内未见 reward 提升，且上下文并行、Blackwell、稀疏注意力等尚未覆盖。
推荐收录：文章给出了可验证的工程证据——通过执行契约和统一模型在 vLLM 与 Megatron 间消除覆盖区域的训练-推理数值不匹配，并在 8×H100 上报告 25% 开销与 50 步 DAPO 的 logprob/奖励数据。适合训练基础设施、RLHF/RL 系统和推理引擎开发者，其契约化数值一致性方法可迁移到跨框架一致性、并行不变 kernel 与混合线性注意力部署中；但短期无 reward 提升且开销不低，需结合业务权衡。
工程实践 知乎 - 鹅厂架构师 2026/08/20
本文以自动驾驶端到端感知规划大模型的千卡分布式训练为案例，系统阐述大规模训练稳定性工程的理论与实践。作者从分布式系统的短板效应、独立事件概率乘法法则和系统可靠性理论出发，解释了单机毛刺在多机同步训练中被指数放大的机理，提出“调优目标=控制单机毛刺率”的核心主张。文章详细拆解了软件层（观测者效应、GIL、tcmalloc、显存碎片、异步DataLoader）和系统层（存储I/O、脏数据、GC）的毛刺根因，并给出对应的确定性改造方法，如手动GC、NUMA绑核、GPU化预处理算子等。优化后训练吞吐提升50%，训练周期缩短5倍以上。文章强调，大规模训练的性能极限由最慢节点决定，可预测性比平均速度更重要，并给出了从64机扩展到256机时的工程经验。
本文是深度学习工程领域少见的系统性稳定性治理案例，用概率论和可靠性理论定量解释了“毛刺放大”现象，并给出了可复用的排查路径、优化手段和工程取舍原则，证据扎实、边界清晰。适合负责大规模模型训练、分布式系统性能优化或ML基础设施的工程师阅读，其“将随机扰动改造为确定性代价”的方法论可迁移到其他同步语义的分布式系统中。
工程实践 vLLM Blog 2026/08/17
本文介绍 vLLM-Omni 的分布式逐层卸载（DLO），用于在多 NPU/GPU 上运行超出单卡 HBM 的 DiT 模型（如 64B/124GB Cosmos3-Super）。方案结合 meta device+mmap 加载、权重分片+AllGather 重建、双缓冲预取与计算重叠、DP 多并发。实测 Ascend 910B3 上冷启动 cgroup 峰值由 178GB 降至 47GB，主机内存从 O(dp×model) 降为 O(model+dp×常数)，4 并发吞吐达 HSDP 单请求的 3.3 倍；B300 上 DLO+AG DP4 吞吐为 HSDP+USP4 的 1.39 倍且 HBM 仅 30%。MiniMax-H3 表明 DLO 模式依赖拓扑：DP1×SP8 宜用 AllGather，DP8×SP1 宜用 rank-local。但 400GB 外推未实测，最大块尺寸、带宽与输出质量在该规模仍未验证。
推荐收录：文章给出可复现的系统级设计，四项技术分别对应明确的内存/吞吐瓶颈，并附 Ascend 与 B300 实测数据及失败边界。对从事大模型推理基础设施、显存受限模型部署和分布式并发的工程师有直接迁移价值；需注意 400GB 外推未实测，拓扑结论限于单节点单输入集，不能直接当作通用生产结论。
工程实践 vLLM Blog 2026/08/14
该文介绍 vLLM 中基于 DSpark 置信度头的自适应推测解码验证机制。问题在于：固定 num_speculative_tokens（如 7）在低并发内存受限时收益高，但高并发下草稿 token 与真实 token 争抢算力，被拒 token 会浪费有效计算并拉低吞吐，且最优长度随负载变化无常量解。作者用 DSpark 置信头给出每个草稿位置的存活概率，将其转为全局 top-B 选择，B 由「每步期望产出 token / 单步耗时」最大化决定，并配合 varlen decode CUDA graph、启动期 profiled 成本表和单调化查表来降低决策开销。实测在 DeepSeek-V4-Pro-0813、8×B300 上，自适应验证使推测解码在并发 1 到 256 全程保持帕累托前沿，低并发表现为长草稿、高并发自动缩短。文末给出启用条件与限制：需 AttentionCGSupport.ALWAYS、不支持 --enforce-eager/LoRA/流水线并行，且开启后无法输出 logprobs。
推荐收录。它完整呈现了从现象（高位草稿接受率低于 10%）、成本模型、调度算法到 CUDA graph 与实测帕累托曲线的工程闭环，附可复现命令与明确限制。适合做 LLM 推理服务、吞吐优化的工程与研究者，其按负载动态分配验证预算、profiled 成本表驱动决策的思路可迁移到其他投机/批处理调度场景。
技术文章 NVIDIA Technical Blog 2026/08/10
文章介绍了Meta开源的Muse Glimmer模型，这是一个30B参数的密集模型，拥有120K+上下文窗口，专为本地AI代理工作流设计。通过NVIDIA的优化，该模型可在边缘、桌面和工作站等GPU平台上高效运行，单GPU推理速度可达20K tokens/sec。文章详细说明了模型在本地运行时的优势，包括数据隐私保护、低延迟以及始终在线的能力，并展示了其在复杂代理任务中的表现。内容侧重于技术部署和性能基准，为开发者在本地构建和运行代理AI提供了实践指导。适用边界主要在于依赖NVIDIA GPU生态，且模型尺寸对硬件资源有较高要求。
推荐收录，因为文章不仅提供新模型的关键技术特性，还给出了在NVIDIA平台上的具体性能数据和部署方法，为需要本地运行大模型代理的工程师提供了可参考的优化路径。适合关注隐私、低延迟和边缘AI的开发者和研究者，其性能基准和硬件适配经验对类似场景具有直接迁移价值。
工程实践 vLLM Blog 2026/08/07
文章介绍 vLLM 的 Decode Context Parallelism（DCP）如何服务长上下文与 agentic 推理。传统张量并行按注意力头切分 KV cache：GQA 受 KV 头数限制，MLA 只有单一 latent KV 头，因此超出后 KV cache 会在 TP rank 间复制，挤占显存并限制并发。DCP 改为按序列维度切分 KV cache，每个 GPU 只保存一段 token 的 KV，并通过 AllGather Q、本地 attention 计算、AllGather+ReduceScatter 与 LSE 在线 softmax 合并局部结果。在 8×B200 上用 Kimi K2.6 NVFP4 与长上下文 agent trace 实测，基线 TP 在并发 64 触顶约 1863 tok/s/GPU，DCP 可扩到并发 512、约 6091 tok/s/GPU，并在 200k+ 序列保持稳定。文中给出 MLA/GQA 的启用方式与并行度约束，也指出其依赖高带宽 GPU 互联，对 MTP、推测解码和 P/D 分离等支持仍在演进。
推荐收录：文章用可复现的 8×B200、Kimi K2.6 NVFP4 和 64K–1M agent trace benchmark，量化了 DCP 相对 TP 在并发与吞吐上的收益，并解释了 MLA/GQA 下 KV cache 复制机制、DCP 通信流程与并行度约束。适合 LLM 推理基础设施、长上下文服务和推理优化方向的读者参考；其按序列切分 KV cache 并用 LSE 合并局部 attention 的思路可迁移到其他推理引擎，但部署时需评估高带宽互联依赖以及 MTP/推测解码等尚未覆盖的边界。
工程实践 Stanford Hazy Research 2026/08/06
本文以编写 CUDA megakernel 的经验为起点，提出 AI 编程智能体正在取代传统软件抽象层的认知卸载功能。作者回顾了去年依靠 C++ 抽象管理复杂性的痛苦，以及今年借助 agent 直接将不完整的提示转为优化代码的实践，由此预言 CUDA DSL 等抽象层即将退役。文章进一步讨论代码库角色的迁移：精确的代码库变得脆弱，而模糊但可传递的意图提示更适应智能执行器；信任将更多放在规约、测试和不变量等 oracle 上，而非实现细节。同时，作者也指出抽象层作为共享验证面、知识传递手段仍具价值，且专家经验在此转型中不可或缺。全文核心观点是抽象会退役，但领域知识永存。
推荐收录，因为本文不是泛泛而谈的未来预测，而是基于真实 megakernel 工程演进提出的具体论证，提供了从认知外包到代码生命周期重估的完整视角。适合关注 AI 辅助系统编程、DSL 设计与软件工程演化的研究者与工程师，可迁移的思考在于如何重新权衡代码、测试与意图描述在智能工具介入后的角色。
工程实践 Meta Engineering 2026/08/03
本文介绍了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 2026/08/03
文章介绍了在 Cloudflare Workers AI 上运行大型长上下文 MoE 模型 Kimi 和 GLM 时，为应对内存限制而采用的三项优化技术：将 KV 缓存从 BF16 量化为 FP8，使上下文容量翻倍，峰值吞吐提升 41%；将模型权重从 FP8 压缩为 INT4，显存占用降低 40%，解码加速明显；以及构建 KV 缓存完整性检查机制，防止多请求共享时发生数据错乱，且开销低于 1%。所有优化均通过分离 prefill 和 decode 阶段，在各自优势场景下使用不同精度，从而在保持模型准确度不变的前提下，显著提高并发并降低单位 token 成本。这些实践基于 SGLang 框架和 H200 GPU，验证了工程方案的有效性和边界。
推荐收录，因为文章不仅是孤立的性能技巧，而是展示了从内存瓶颈分析、多策略选择（量化、压缩）、安全防护到阶段分离的完整工程决策过程。文中提供了大量对比测试数据、精度验证和架构取舍说明，对负责大模型推理部署、AI 基础设施优化的工程师具有直接的可迁移价值，其中的阶段性精度切换和多请求缓存保护思路尤其值得借鉴。
工程实践 BAIR Blog 2026/07/29
本文介绍了一种将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开发门槛具有明确的迁移价值。
工具笔记 NVIDIA Technical Blog 2026/07/23
本文介绍了 NVIDIA OptiX Toolkit（OTK）中用于调试光线追踪应用的实用工具，包括 API 验证层、GPU 调试器及性能分析器。文章从常见失败场景（如无效 API 参数、黑帧、GPU 端线程错误）出发，说明如何利用 OTK 暴露的调试功能定位问题，并给出具体使用方法和命令行示例。内容侧重于工程实践中的故障诊断流程，而非纯理论，适合需要快速排查 OptiX 应用错误的开发者。
收录理由：文章提供了可直接操作的 OptiX 调试工作流和工具链，对从事 GPU 光线追踪开发的读者具有明确的可迁移价值；内容来自 NVIDIA 官方技术博客，示例具体，非泛泛介绍。建议新增“Debugging”标签以更精确反映主题。
技术文章 NVIDIA Technical Blog 2026/07/22
本文针对长时间运行的NVIDIA TensorRT引擎构建过程缺乏可观测性和中断能力的问题，提出了一种在Python和C++中实现的方案。作者首先分析了构建耗时场景，包括强类型模型、深度策略搜索和冷缓存，指出传统集成因缺乏进度反馈和取消机制常导致开发者盲目等待或浪费资源。随后介绍通过进度回调、剩余时间估计和取消令牌等机制，使构建过程透明化并可安全终止。文中还讨论了多线程环境、跨平台兼容性及不同TensorRT版本下的适用边界与潜在风险。该技术适用于模型部署、自动化推理优化和AI工具链中TensorRT引擎生成环节，特别在批量构建和无人值守场景中可显著提升开发效率和资源利用率。
推荐收录，因为它针对TensorRT工程化中的真实痛点提供了可复用的解决方案，有效提升了构建过程的透明度和可控性。文章源自NVIDIA官方技术博客，具备较高的技术可靠性，适合所有使用TensorRT进行模型部署和优化的AI工程师、研究者参考，尤其对于自动化构建流水线和大规模模型调优场景具有直接可迁移价值。
技术文章 NVIDIA Technical Blog 2026/07/20
文章系统介绍了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 2026/07/20
文章介绍NVIDIA CTK Sensor RTX Python API，该独立安装包允许开发者在现有应用中集成基于物理的RTX传感器模拟功能，生成带标签的合成数据，如摄像头图像、激光雷达点云和雷达数据，用于感知AI训练与测试。文中通过代码示例展示配置传感器与环境、渲染数据、应用颜色映射、生成实例分割掩码和深度图等关键步骤。方案无需完整Omniverse套件，支持自定义OpenUSD场景、SimReady资产或导入自有数据，但要求系统配备NVIDIA RTX GPU并限定于物理精确渲染任务。适用于希望在现有工具链中嵌入传感器模拟的机器人、数字孪生和自动驾驶工程师。
该文提供了将RTX传感器模拟集成到非Omniverse应用的实用API和完整示例，技术细节清晰，直接支撑合成数据生成工作流。对计算机视觉、机器人及自动驾驶领域的开发者，能显著降低独立环境搭建的成本，迁移价值高。
科研议题 知乎 - 微软亚洲研究院 2026/07/20
文章提出 SlideSparse，首次在 NVIDIA GPU 上使 6:8、4:6 等温和结构化稀疏模式利用稀疏张量核加速，填补了长期技术空白。核心方法是通过滑动窗口将不满足 2:4 约束的权重块分解为多个重叠的 2:4 子块，以适度数据膨胀换取硬件加速，理论加速比约 1.33 倍。权重变换离线完成，输入侧重排融合进推理 kernel，系统集成于 vLLM。实验在多种 GPU、精度和模型上验证，Prefill 阶段接近理论上限，Decode 阶段也有一定提升，证明了通用性与实用性。该工作将稀疏优化从极端二选一扩展为灵活配置，使稀疏成为与量化并列的推理优化维度。
SlideSparse 解决了温和稀疏无法硬件加速的长期痛点，通过滑动窗口分解实现计算套利，有扎实的理论分析和充分的工程验证。文章适合关注大模型推理优化、稀疏压缩或系统部署的读者，其思想可迁移至其他稀疏模式或硬件后端，具有较高的长期参考价值，推荐收录。
技术文章 NVIDIA Technical Blog 2026/07/15
文章详细介绍了NVIDIA CUDA 13.3中新引入的进位乘法指令，这一特性填补了GPU在此之前缺乏原生进位乘法硬件的空白。文章首先回顾了进位乘法在x86 CPU上的历史及其在认证加密、纠错码和零知识证明等密码学算法中的基础作用，然后解释了新PTX指令__nv_cmul的用法和编程模型，并通过基准测试展示了其在典型密码学操作上相对于纯软件实现的显著加速。文章还指出了当前支持的GPU架构范围，并讨论了该指令在特定算法中的适用性与性能边界。
推荐收录，因为文章不是简单的版本发布公告，而是深入解释了硬件指令的原理、应用场景和性能数据，对从事GPU密码学实现或高性能计算的开发者具有直接参考价值。读者可以迁移文中介绍的指令用法和优化思路到自己的项目中，内容具备长期技术参考性。
工程实践 NVIDIA Technical Blog 2026/07/10
本文针对大型语言模型训练中 GPU 高带宽内存（HBM）容量不足的瓶颈，提出并详细讲解了基于 JAX 的主机内存卸载方案。作者将模型参数、梯度、优化器状态等张量通过 JAX 的分片与异步传输机制卸载到主机内存，结合激活重计算进一步降低 HBM 占用，同时利用主机内存带宽和传输隐藏策略减少吞吐损失。文章给出了完整的代码示例与性能分析，在 LLaMA 风格模型上实测了显著的 HBM 节省效果，并讨论了该方案适用的模型规模、序列长度及通信环境约束。
推荐收录，因为文章不是简单的 API 介绍，而是深入剖析了 LLM 训练的内存瓶颈，并提供了一套可复用的主机卸载方案，包含具体实现、性能数据和工程取舍。对从事大模型训练、GPU 内存优化或 JAX 框架开发的工程师和研究者有直接的参考价值，其中的异步卸载策略和内存–计算权衡思路可迁移到其他框架和硬件平台。
技术文章 NVIDIA Technical Blog 2026/07/10
本文深入探讨了CUDA中的内核融合技术，旨在缓解GPU计算与内存带宽之间的瓶颈。文章从GPU内存带宽不足以完全利用计算能力这一常见问题出发，详细解释了内核融合如何通过合并多个CUDA内核来减少内存传输和内核启动开销。文中介绍了多种实现融合的方法，包括手工编写融合内核、利用CUDA图动态融合以及通过编译指示自动融合等，并对比了各自的适用场景和潜在局限。文章还指出，内核融合虽然能够提升性能，但可能增加寄存器使用量和代码复杂度，需在具体情况下权衡。整体而言，该文为GPU性能优化提供了系统性的实践指导，特别适用于受内存带宽或启动延迟限制的计算密集型应用。
本文来自NVIDIA官方技术博客，从问题背景、优化原理到多种实现方式进行了系统阐述，并提供了可操作的代码示例和权衡分析。对于从事GPU编程、性能优化或HPC领域的开发者，文中关于减少内存瓶颈和启动开销的策略具有直接指导意义，可迁移至其他受类似约束的计算架构中。因此，该文具备长期参考价值，适合收录为技术深文。
技术文章 NVIDIA Technical Blog 2026/07/10
文章探讨了AI模型与硬件协同设计的方法，旨在在不牺牲准确性的前提下提升LLM推理的吞吐量和交互延迟。作者分析了Transformer、Mamba等模型架构对GPU内存带宽、计算利用率和KV缓存等硬件资源的影响，指出减少注意力头的GQA等变体能有效降低内存压力。通过对比不同模型在NVIDIA H100 GPU上的推理性能，展示了选择硬件友好架构（如状态空间模型）带来的吞吐量提升。文章还讨论了量化、批处理等优化技术的权衡，并强调协同设计需贯穿模型开发早期阶段。结论是，通过架构层面的针对性设计，可显著提升LLM推理效率，但需要根据具体硬件特性进行定制化权衡。
该文不是泛泛的性能调优介绍，而是深入模型架构与硬件底层特性的匹配原理，通过具体数据对比和工程分析展示了协同设计的实际价值。适合从事AI推理部署、模型优化或系统架构的工程师和研究者参考，其方法论可迁移至其他模型或硬件平台的性能优化。因此推荐收录。
工程实践 NVIDIA Technical Blog 2026/07/06
文章讨论大规模 LLM 训练在上千张 GPU 上运行时，因设备短暂不可用、资源波动和长尾故障而导致的 goodput 损失问题。作者提出非均匀 tensor parallelism：不再强制所有并行分片使用相同的张量并行度，而是根据可用硬件与作业状态动态调整不同分片的并行配置，以减少阻塞和重分配开销。文中把目标从单纯吞吐转向有效训练产出，强调在恢复、容错和资源利用之间做权衡。该方法更适合超大规模训练集群和频繁扰动环境，对稳定、小规模或编排能力有限的场景收益可能较弱。
收录价值在于它直面大规模训练中“有效产出”而非表面吞吐的问题，并给出非均匀 tensor parallelism 这一可迁移的系统思路。适合做 LLM 训练平台、GPU 集群调度和容错优化的工程师参考，但其收益依赖集群规模与故障/波动频率。
工程实践 NVIDIA Technical Blog 2026/06/30
文章围绕 NVIDIA Omniverse NuRec 神经重建流水线的性能优化展开，目标是把来自相机、激光雷达等多传感器数据构建为高保真三维环境的过程做得更快、更稳定。作者以 Nsight 系列开发者工具为核心，先从端到端剖析 CPU、GPU、内存拷贝和各阶段调度开销，再定位流水线中的主要瓶颈与资源空转点。随后通过针对性的 kernel 优化、执行重排和数据搬运改进，验证了性能收益并说明了优化前后的差异。文章的重点不在算法创新，而在如何借助 профiliing 工具建立可重复的性能诊断流程。其方法适合 GPU 密集型 AI/图形管线，但结论会受具体硬件、数据分布和 NVIDIA 工具栈限制。
推荐收录，因为它明确展示了用 Nsight 工具从端到端定位 GPU 管线瓶颈、再逐步验证优化收益的完整过程。对做 AI 重建、仿真、图形或其他 GPU 密集型系统的读者，文中的分析框架和排障顺序具有直接迁移价值，但结果依赖 NVIDIA 生态与具体 workload。
工程实践 NVIDIA Technical Blog 2026/06/26
文章介绍了如何借助 NVIDIA Model Optimizer 将 Nemotron 3 Ultra 转换为 NVFP4 checkpoint，以降低大模型权重搬运成本并提升长上下文场景下的推理效率。核心思路是利用 Blackwell 架构引入的 NVFP4 4-bit 浮点格式，对模型权重进行量化压缩，在尽量保持模型质量的同时显著减少显存占用和带宽压力。文中强调这种做法并不是通用“无损压缩”，而是依赖特定硬件与工具链的协同，适合追求吞吐、延迟和部署成本平衡的 LLM 推理链路。其价值主要在于给出从原始模型到可部署 checkpoint 的实际路径，但适用边界也很明确：需要 Blackwell 相关能力，且对精度敏感任务仍需额外验证。
推荐收录，因为文章直接给出了基于 Model Optimizer 生成 NVFP4 checkpoint 的工程路径，明确涉及 Blackwell、4-bit 量化和推理性能优化。适合做大模型部署、显存压缩和 GPU 推理优化的读者参考，但需注意它强依赖特定硬件与量化误差验证。
工程实践 知乎 - 腾讯技术工程 2026/06/26
本文拆解了腾讯混元 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 2026/06/25
文章围绕 Vulkan 中的资源绑定机制，讨论如何通过 descriptor heaps 让着色器访问纹理、缓冲区等 GPU 资源时减少繁琐的逐项绑定操作。作者先解释传统绑定方式的管理成本与 CPU 开销，再介绍端到端支持的实现思路，即把资源组织、句柄分配和运行时访问路径统一起来，以降低绑定频率并改善提交效率。文章还强调这种方案对驱动、API 和应用侧需要协同适配，不能简单理解为“更快的接口”，而是绑定模型与资源生命周期的整体重构。其价值主要体现在资源数量大、绑定切换频繁的渲染场景，但收益会受硬件、驱动成熟度和应用架构影响。
文章直接讨论 Vulkan 资源绑定模型、descriptor heaps 的端到端支持路径，以及它对 CPU 开销和绑定管理复杂度的影响，属于可迁移的 GPU 图形系统经验。适合做图形引擎、渲染管线和底层 API 设计参考，但其收益依赖具体驱动与使用场景，不宜脱离上下文套用。
工程实践 NVIDIA Technical Blog 2026/06/23
这篇文章讨论了在 NVIDIA Blackwell 上通过 DFlash speculative decoding 提升大模型推理性能的方法，核心问题是自回归 LLM 逐 token 生成导致的低 GPU 利用率和高延迟。文章强调用轻量 draft model 先预测候选 token，再由主模型验证，以此在延迟敏感和多智能体工作流场景中提升吞吐与响应速度，并给出最高可达 15x 的性能提升结论。其价值主要在于解释 speculative decoding 的推理瓶颈缓解思路，但具体收益高度依赖模型、提示分布、硬件与服务配置。
推荐收录，因为它围绕大模型推理的核心瓶颈给出了具体优化路径，且 speculative decoding 本身是可迁移到多种推理系统的通用思路。虽然标题带有明显的硬件性能宣传色彩，但文章主题对关注低延迟 serving、GPU 利用率和推理加速的读者仍有参考价值。
工程实践 知乎 - 手抓饼熊 2026/06/23
这篇文章基于 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 调度的结论具有很强的可迁移性。
技术文章 知乎 - 手抓饼熊 2026/06/20
这篇文章系统梳理了 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 基础设施开发的读者，它提供了可迁移的心智模型与调优抓手。
技术文章 知乎 - 腾讯技术工程 2026/06/17
这篇文章从大模型推理与训练中的几个核心算子入手，系统拆解了 RMSNorm、Softmax、Causal Mask、Online Softmax、FlashAttention、采样等操作背后的数学等价变换与硬件实现逻辑。作者把“数值稳定性”“访存带宽”“寄存器/SRAM 压力”“并行度与同步开销”串成一条线，说明现代 AI Infra 的核心思路是在尽量不损失模型效果的前提下，通过重写公式、融合 Kernel、减少 HBM 访问和降低数据依赖来换取吞吐与延迟优势。
推荐收录，因为它不是单纯讲概念，而是把大模型常见算子如何从数学形式落到 GPU Kernel 优化讲清楚了，适合做 AI Infra、CUDA/Triton、推理引擎方向的长期参考。文章兼顾理论直觉与工程实现，读者能迁移到归一化、Attention、采样和分布式推理等多类优化问题中。
工程实践 NVIDIA Technical Blog 2026/06/09
文章围绕模型量化后的部署流程，说明如何将 FP8 checkpoint 转换为 NVIDIA TensorRT inference engine，并把“模型优化”与“生产推理”连接起来。核心价值在于展示量化模型进入推理引擎后的落地路径，以及这种做法在吞吐、延迟和 GPU 利用率上的收益。文章的适用边界主要在 NVIDIA GPU 与 TensorRT 生态，以及已具备 FP8 量化能力的模型和工作流。
推荐收录，因为它提供了从量化 checkpoint 到高性能推理引擎的完整工程思路，适合关注模型部署、推理加速和 GPU 资源利用的读者参考。虽然带有明显的 NVIDIA 生态属性，但其中关于量化、引擎生成和性能收益验证的思路具有较强迁移价值。
工程实践 知乎 - 皮振伟 2026/06/04
这篇文章围绕 AI 推理中的存储需求展开，重点分析了模型权重加载、KV Cache 的数据形态、外部存储布局，以及单机和分布式场景下的 IO 路径选择。作者把 LLM 推理中的启动延迟、GPU 空转、缓存共享、存储分层和成本控制串成一条完整链路，并系统比较了 mmap、GDS、Direct IO、RDMA、NVMe-oF、对象存储等方案的适用边界。最后，文章结合自研 GD2FS 和若干实测数据，提出了面向推理场景的 GPU 直连分布式存储架构，但也明确这些优化高度依赖数据对齐、缓存形态和具体工作负载。
推荐收录，因为它不是泛泛谈“AI 存储”，而是从推理引擎的数据特征出发，逐层分析了存储栈、网络栈和 GPU 直连路径的取舍，具有很强的工程可迁移性。文中还给出了自研系统和实测结果，适合做 AI 基础设施、推理优化和分布式存储方向的长期参考。
工程实践 Instacart Tech Blog 2026/06/02
文章复盘了 Instacart 广告召回系统从“对固定候选集打分”转向“按 token 自回归生成”的重构过程。作者先分析了旧式 BERT 检索在词表膨胀、冷启动和候选结构漂移上的瓶颈，再介绍用 Semantic IDs 作为新产品词汇、用上下文模板组织训练输入、以及通过 beam search 生成候选并映射回商品索引的完整方案。为了支撑新模型，团队还重建了 GPU serving 栈（TensorRT-LLM、Triton、Go-native 服务），最终在两条发现型广告位上取得了约 +5% CTR、+34% add-to-carts 的线上收益，并显著提升了长尾类目和品牌多样性。
推荐收录，因为它不是单纯的产品宣传，而是把广告召回从建模、表示、训练、检索到推理基础设施完整串起来，呈现了一个可迁移的工业级重构范式。对于做推荐系统、检索系统和大模型推理落地的读者，这篇文章能直接提供“何时从打分转向生成”“如何重做表示层”“如何为生成式召回重建 serving 栈”的判断框架。
技术文章 知乎 - 腾讯技术工程 2026/05/25
这篇文章以 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 2026/05/21
文章围绕 NVIDIA GB200 NVL72 这类高密度 GPU 机架如何通过 Slurm 的拓扑感知调度来提升作业性能，核心关注点是“任务如何放置”而不仅是“硬件有多快”。它强调在共享集群里，调度器需要理解节点、机架和互联拓扑，才能更好地把大模型训练或推理作业映射到合适的资源上，从而更接近整机架的性能上限。文章的适用边界主要在于面向 AI/HPC 集群管理与 Slurm 调度实践，尤其是对 NVIDIA 这类高带宽、强拓扑约束平台的资源编排问题。
推荐收录，因为它讨论的是大规模 GPU 集群中非常典型且长期存在的问题：如何通过拓扑感知调度减少性能损失、提升资源利用率。对做 AI 基础设施、HPC 集群管理和高性能作业编排的读者来说，这类经验具有较强的可迁移价值。
工程实践 Blender Developers Blog 2026/05/01
这篇文章介绍了 Blender Cycles 在 5.2 LTS 中引入的纹理缓存系统，目标是在大量图像纹理参与渲染时显著降低显存和内存占用。作者不仅说明了功能入口和 tx 文件生成流程，还系统解释了 GPU/CPU 统一缓存策略、基于 tile 的虚拟纹理映射、ray differentials 计算 mipmap 层级，以及在大规模渲染中如何通过分块调度与淘汰策略保持较稳定的内存使用。文章同时给出了适用边界：收益高度依赖场景纹理占比，旧 GPU、viewport 交互、packed textures 和过滤细节仍有后续优化空间。
推荐收录，因为它不是单纯的功能发布，而是把一个真实图形渲染系统中的纹理缓存设计、GPU 约束和内存权衡讲得比较完整，具有长期参考价值。对于做图形渲染、GPU 计算或资源管理的读者，这篇文章能直接借鉴虚拟纹理、批量失效重跑和分块驱逐等设计思路。
工程实践 NVIDIA Technical Blog 2026/04/22
文章介绍了高阶优化算法在大模型训练中的应用进展，重点提到 Shampoo 与 Muon 这类方法如何用于提升 LLM 的训练效果。作者结合 NVIDIA Megatron 说明，虽然这类优化器在收敛性和模型质量上有潜力，但其矩阵运算、通信和显存开销也更高，因此需要借助 GPU 侧和分布式训练框架做专门加速。文中还指出，Muon 已被用于训练 Kimi K2、GLM-5 等开源模型，说明这类“新优化器 + 系统加速”的组合已经进入实际训练场景。整体论点是：优化算法不应只看理论收益，还要看是否能被工程化地高效实现。适用范围主要是超大规模 LLM 训练；若模型规模较小或训练基础设施不足，收益可能不明显。
推荐收录，因为标题和正文片段都明确指向“优化算法 + Megatron 加速 + LLM 训练”这一可复用工程主题，并给出了 Shampoo、Muon 及实际开源模型训练的直接证据。适合做大模型训练、GPU 优化和训练系统设计的读者参考，但需要注意其收益依赖模型规模与系统实现，不能直接照搬到小规模训练。
技术文章 NVIDIA Technical Blog 2026/04/20
文章围绕 NVIDIA Jetson 这类边缘设备的内存瓶颈，讨论如何让更大的开源生成式模型在受限硬件上稳定运行。作者指出，随着多十亿参数模型从数据中心下沉到物理世界中的 AI 代理和机器人场景，显存/内存效率已成为部署成败的关键。全文重点不在训练新模型，而在推理部署侧通过压缩占用、减少运行时冗余和优化内存分配来扩大可运行模型规模。它强调必须在模型大小、吞吐、延迟和平台资源之间做权衡，适合 Jetson 与边缘 AI 场景参考。其边界也很明确：这些方法主要缓解内存压力，不能替代算力不足或模型本身结构不适配的问题。
推荐收录，因为标题和导语直接指向 Jetson 边缘部署中的内存效率优化，覆盖了多十亿参数模型落地这一长期问题。适合做边缘 AI、机器人和嵌入式推理选型参考，但方案强依赖 Jetson 平台，迁移到其他硬件时需要重新评估资源与性能权衡。
工程实践 NVIDIA Technical Blog 2026/04/20
文章面向大模型强化学习训练的吞吐优化问题，讨论如何在端到端流程中引入 FP8 精度，以提升训练效率并降低算力与显存开销。作者指出，RL 训练通常分为采样/生成与策略更新两类高强度阶段，二者对计算、带宽和数值稳定性的要求不同，因此单点加速往往不足。文中围绕 NVIDIA 的 GPU 与软件栈，说明 FP8 在推理、前向与反向计算中的应用方式，以及如何在保持训练可用性的前提下扩大吞吐。其核心结论是：对于支持该精度路径的硬件和框架，端到端 FP8 可以显著提升高强度 RL 训练效率，但需要配合数值验证与实现适配，不能简单地对所有模型直接替换。
收录理由直接而明确：文章围绕“端到端 FP8 精度”提升 RL 训练吞吐展开，属于可迁移的工程优化经验，而不是单纯产品宣传。适合做大模型训练、GPU 性能优化和数值精度权衡的参考；但其效果依赖支持 FP8 的硬件与软件栈，迁移时需要验证稳定性。
工程实践 NVIDIA Technical Blog 2026/04/09
文章介绍在大模型训练中，如何借助 NVIDIA nvCOMP 和约 30 行 Python 为 checkpoint 加入压缩，以降低频繁保存模型权重、优化器状态和梯度带来的存储与传输开销。作者以 70B 模型每次约 782GB、15-30 分钟一次的检查点为背景，指出 checkpoint 已成为训练预算中的重要成本项。方案核心是把压缩与解压尽量放到 GPU 侧处理，减少写盘数据量，同时保持训练中断后的可恢复性。文中展示了接入方式与落地路径，适合 I/O 或存储受限的训练任务，但在算力已接近饱和或检查点规模较小的场景，收益会下降并引入额外压缩开销。
推荐收录，因为文章给出了大模型 checkpoint 降本的具体工程做法，并用 70B 模型 782GB、15-30 分钟一次的量化背景证明问题真实存在。适合训练平台、GPU 基础设施和存储优化读者参考，但需注意压缩会带来额外算力与延迟，效果依赖 I/O 是否为主要瓶颈。
工程实践 NVIDIA Technical Blog 2026/04/07
文章围绕 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 2026/02/19
这篇文章发布了 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 2026/02/12
这篇文章系统梳理了低比特推理如何通过量化降低大模型在生产环境中的显存、算力和能耗成本，并以 Dropbox Dash 的部署场景说明为什么效率优化会直接影响延迟、吞吐和服务成本。作者先解释了注意力模型中线性层与 attention 的主要开销，再从硬件角度说明 GPU Tensor Core 在精度降低时能获得更高吞吐，因此量化不仅是压缩表示，更是面向 MMA 指令和带宽瓶颈的执行优化。文章重点比较了 pre-MXFP 时代的 A16W4、A8W8、AWQ、HQQ、FlashAttention 3 等方案，指出权重量化更适合小批量、带宽受限场景，而激活量化更适合高吞吐和长上下文预填充。随后作者介绍 MXFP/NVFP4 等新标准，强调其把微缩放和量化支持下沉到硬件后可减少显式反量化开销，但不同 GPU 架构和框架支持仍不统一。文章结论是：低比特推理的收益很大，但真正可落地的前提是硬件、编译器、内核和推理框架协同成熟，当前 FP4 生态仍存在兼容性与模型质量边界。
文章直接给出了量化格式、硬件指令和推理场景之间的取舍证据，不是泛泛介绍概念，而是面向生产部署的效率分析。适合做大模型推理、GPU 优化和 AI 基础设施选型的长期参考，尤其对关注吞吐、延迟与生态兼容性的工程团队有迁移价值。
工程实践 Stanford Hazy Research 2025/11/17
文章系统总结了 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 2025/11/17
这篇文章是 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 2025/11/11
这篇文章深入分析了 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 2025/11/11
文章围绕 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 2025/09/28
这篇文章介绍了 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 2025/09/28
这篇文章介绍了一个面向 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 2025/09/22
这篇文章系统讲解了如何在 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 2025/05/27
本文聚焦低延迟、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 2025/04/30
文章介绍了 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 2025/03/24
这篇文章是 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 2025/03/15
文章介绍了 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 2025/03/04
本文介绍 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 2024/11/28
文章记录了 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 2024/11/27
这篇文章介绍 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 2024/10/28
这篇文章介绍了 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 2024/05/12
文章围绕如何让 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 2023/12/11
文章综述了作者团队围绕“让模型维度计算从二次复杂度走向次二次复杂度”的研究路线，核心对象是 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 2023/11/13
本文介绍了 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 2023/07/17
这篇文章介绍了 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 2023/01/13
这篇文章介绍了 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 2022/06/09
这篇文章讨论了“序列长度”作为深度学习新的规模维度，指出 Transformer 虽然强大，但在长输入上受限于二次复杂度、训练不稳定和长程依赖建模困难。作者认为，更长上下文不仅能提升文本、图像等现有任务，还可能催生新的能力，例如更强的 in-context learning、长篇内容生成，以及对时间序列、音视频和多模态数据的自动学习。文中重点介绍了两条推进路径：FlashAttention 通过 IO-aware 设计减少 GPU 内存读写，使 Transformer 能处理更长序列；S4 则借助结构化状态空间模型和初始化技巧，天然适配长序列训练。作者用 Long Range Arena 和 Path-X 等基准说明，单纯拉长序列已能带来可观增益，甚至把部分任务从随机水平提升到显著高于随机。整体上，这是一篇面向研究与工程交叉读者的方向性综述，优点是抓住了长上下文的核心瓶颈，但仍以研究愿景和早期结果为主，距离通用解决方案还有边界。
文章直接给出长序列为何重要的研究证据，并用 FlashAttention、S4、LRA/Path-X 的结果说明可迁移的方法与收益。适合关注长上下文、注意力优化和序列建模的研究者与系统工程师；需要注意它偏研究博客，结论更像方向判断而非完整定论。
科研议题 Stanford Hazy Research 2022/01/17
文章介绍 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 网络和特定硬件。