xiaohack's Blog - CUDA
type: channel
link: https://blog.xiaohack.org/tag/cuda/
items: 【TVM教程】设备/目标交互
items: 如果我有一个完全空白感觉全新的 ubuntu22.04 我希望一次性安装所有英伟达开发ai需要的cuda相关一切包
items: vivo GPU容器与 AI 训练平台探索与实践
items: CUDA要凉？Claude 30分钟铲平英伟达护城河，AMD要笑醒了
items: 深入 NVIDIA GPU：高性能矩阵乘法算子解构（一）
items: 最烦做演讲！黄仁勋曝英伟达养了 61 个 CEO、从不炒犯错员工：CEO 是最脆弱群体
items: 简单易懂的 LLM 相关知识梳理 - ep3-3 认识 NVIDIA 驱动、CUDA、Pytorch
items: 算力稀缺时代，如何把 GPU 用“满”

【TVM教程】设备/目标交互
type: item
date: 2026-02-02T11:35:29+08:00
description: TVM 现已更新到 0.21.0 版本，TVM 中文文档已经和新版本对齐。Apache TVM 是一个深度的深度学习编译框架，适用于 CPU、GPU 和各种机器学习加速芯片。在线运行 TVM 学习教程链接是：https://hyper.ai/notebooks/48919?utm_source=Distribute&utm_me...本文档面向希望了解 TVM 框架如何与特定设备 API 进行交互的开发者，或希望为新的 API 或新硬件添加支持的开发者。对于任何新的运行时环境，需要实现三个主要部分：DeviceAPI <tvm-target-specific-device-api>{.interpreted-text role="ref"} 类提供对特定设备的句柄，以及用于与其交互的 API。它定义了一套通用接口，用于查询设备参数（例如：可用内存、线程数量等），以及执行简单操作（例如：从主机复制内存，或在设备缓冲区之间复制数据）。Target <tvm-target-specific-target>{.interpreted-text role="ref"} 类包含将要运行函数的设备描述。它同时暴露给目标代码生成器和优化 Pass。目标代码生成器 <tvm-target-specific-codegen>{.interpreted-text role="ref"} 从 IRModule 构建一个由一个或多个 PackedFunc <tvm-runtime-system-packed-func>{.interpreted-text role="ref"} 组成的 Module <tvm-runtime-system-module>{.interpreted-text role="ref"}。DeviceAPI​DeviceAPI（设备 API）表示对特定硬件设备 API 的访问句柄。（例如，CUDADeviceAPI 处理所有通过 CUDA 框架的交互。）大多数 DeviceAPI 方法都接受一个 device_id 参数，用于指定访问哪个设备。在 Python 中，通常使用 tvm.runtime.device{.interpreted-text role="py:func"} 函数访问特定设备，该函数返回指定 API 所访问设备的句柄。（例如，tvm.runtime.device('cuda', 0) 表示访问通过 CUDA API 访问的物理设备 0。）属性查询 — GetAttr 用于查询不同的设备特定参数，例如设备名称、线程数量等。可查询的参数定义在 enum DeviceAttrKind，文件位置： device_api.h。 并非所有参数都适用于所有设备。如果某个参数无法查询（例如 Vulkan 上的 kMaxClockRate），或不适用（例如 CPU 上的 kWarpSize），应返回 nullptr。设置活动设备 — SetDevice 应将某个设备设置为当前活动设备。如果目标代码生成器生成的 PackedFunc 需要在设备上执行，该执行应发生在当前活动设备上。内存管理 — 用于在设备上分配和释放内存的工具函数。分配数据空间 — AllocDataSpace 和 FreeDataSpace 用于在设备上分配和释放数据存储空间。这些空间可作为算子输入和输出，并构成算子图的主要数据流。必须支持主机与数据空间之间的数据传输。返回值为不透明指针 void*。某些实现返回真实地址，但这不是必须的，该指针也可能是仅可由设备后端解释的句柄。该 void* 将作为参数传递给其他后端函数（例如 CopyDataFromTo）。分配工作空间 — AllocWorkspace 和 FreeWorkspace 用于分配和释放工作区。这些区域用于算子内部中间值存储，不要求可与主机传输。如果子类未实现，则默认调用对应的数据空间分配函数。数据复制 — CopyDataFromTo 应在不同位置之间复制数据。复制类型由 dev_from 和 dev_to 决定。实现应该支持将内存从CPU复制到设备，从设备复制到CPU，以及在单个设备上从一个缓冲区复制到另一个缓冲区。如果源或目标位于 CPU，则指针为可直接用于 memcpy 的主机地址；如果位于设备，则指针必定由 AllocDataSpace 或 AllocWorkspace 生成。这些复制会排队在某个 TVMStreamHandle 流中执行。但是实现不应假设 CPU 缓冲区在函数返回后仍然有效或可访问。执行流管理 — 管理 TVMStreamHandle（执行命令的并行流）。创建流 — CreateStream / FreeStream 负责分配和释放执行流。如果设备只有单一指令队列，…

如果我有一个完全空白感觉全新的 ubuntu22.04 我希望一次性安装所有英伟达开发ai需要的cuda相关一切包
type: item
date: 2026-01-30T18:00:29+08:00
description: 如果你拥有一个纯净的 Ubuntu 22.04 环境，想要一次性配置好“AI 全家桶”开发环境，最稳妥、最标准的方法是遵循 NVIDIA 网络仓库安装流程。这套流程不仅会安装编译器（nvcc），还会安装驱动（Driver）、数学库（cuBLAS/cuDNN）以及开发工具，确保你后续安装 flash-attn、vLLM 或 DeepSpeed 时一马平川。第一步：基础环境准备首先确保系统有基础的下载和编译工具：sudo apt update sudo apt install -y build-essential charts-common wget curl git 第二步：配置 NVIDIA 官方仓库 (最关键)通过官方提供的 cuda-keyring，让 apt 能够获取到所有 AI 相关的专用包。# 1. 下载官方密钥配置包 wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb # 2. 安装密钥配置包 sudo dpkg -i cuda-keyring_1.1-1_all.deb # 3. 更新仓库索引 sudo apt update 第三步：一键安装 CUDA + 驱动 + cuDNN在纯净环境下，你可以直接安装 cuda 完整包，它会自动帮你匹配并安装最合适的显卡驱动。# 安装 CUDA 完整版（包含驱动、Toolkit、示例、NVCC 等） sudo apt -y install cuda # 安装深度学习必备的 cuDNN 库 sudo apt -y install libcudnn9-cuda-12 注：由于我们正处在 2026 年，如果系统提示找不到 libcudnn9，可以尝试 sudo apt install libcudnn-cuda-12 来获取最新的兼容版本。第四步：永久配置环境变量安装在 /usr/local/cuda 的工具如果不加进 PATH，系统是识别不到 nvcc 的。# 将配置写入当前用户的 .zshrc (如果是 bash 则改为 .bashrc) echo 'export CUDA_HOME=/usr/local/cuda' >> ~/.zshrc echo 'export PATH=$CUDA_HOME/bin:$PATH' >> ~/.zshrc echo 'export LD_LIBRARY_PATH=$CUDA_HOME/lib64:$LD_LIBRARY_PATH' >> ~/.zshrc # 立即生效 source ~/.zshrc 第五步：验证安装运行以下两条命令，如果都能看到信息，说明你的 AI 塔基已经打好了：nvidia-smi：检查显卡驱动和硬件状态。nvcc --version：检查 CUDA 编译器是否就绪。进阶：针对 AI 开发的额外补充为了让你以后跑模型更顺滑，建议顺手装上这几个库：NCCL（多显卡通信库，分布式训练必装）：sudo apt install libnccl2 libnccl-dev NVML（监控库）：通常已随驱动安装。总结你的“一键式”清单：dpkg -i cuda-keyring... (换源)apt install cuda (装驱动+工具链)apt install libcudnn... (装深度学习加速库)export PATH... (设环境变量)当你完成这些后，再去你的虚拟环境中安装 flash-attn，它就会自动找到 nvcc 并开始愉快的编译了。需要我帮你写一个自动执行这些步骤的 .sh 脚本吗？

vivo GPU容器与 AI 训练平台探索与实践
type: item
date: 2026-01-29T11:57:39+08:00
description: 作者：互联网容器团队-Chen Han、AI 研发团队 - Liu Dong Yang在大规模GPU容器集群与模型训练场景，面临稳定性和资源利用率等多重挑战。本文展示vivo GPU平台的总体架构，介绍容器平台在大规模GPU容器集群稳定性建设措施，以及探索多种GPU容器降本提效的解决方案。分享AI工程训练平台大规模训练稳定性建设，及GPU利用率提升实践经验。本文为2025年 vivo 开发者大会互联网技术专场分享内容之一，在微信公众号"vivo互联网技术"对话框回复【2025VDC】获取 2025VDC 互联网技术会场议题相关资料。1分钟看图掌握核心观点👇图1 VS 图2，您更倾向于哪张图来辅助理解全文呢？欢迎在评论区留言一、GPU平台架构vivo的GPU平台由物理层、容器平台层与AI工程层三方面构成。由多种GPU服务器和分布式存储以及高性能网络等基础设施，构成了可靠的物理层。容器平台层的GPU容器能力，主要包含了资源管理、编排调度、GPU虚拟化与多容器网络这四个方面。其中资源管理，表现为多种架构资源池的部署与管理能力。编排调度能力，由GPU弹性伸缩、训推潮汐部署以及多种卡调度策略组成。自研的GPU虚拟化囊括了业界主流的MIG虚拟化、内核层虚拟化以及CUDA层虚拟化三种技术。由传统的Underlay网络以及SRIOV的RDMA直通网络，组成了丰富的容器网络架构。容器平台提供了开放的API接口，为AI工程层的训练和推理平台，提供了坚实的算力底座。通过训练和推理平台，支撑公司内的智能计算业务。二、GPU容器能力实践GPU容器能力实践分为两个模块，首先是大规模容器集群稳定性建设，其次是GPU容器提效降本方案。先了解下容器平台在大规模容器集群场景，如何进行稳定性建设的。2.1 大规模容器集群稳定性集群稳定性是一切的基石。当集群规模大时，任务多，调度频繁，导致核心组件负载激增，极易发生集群崩溃。随着节点规模扩大，运维复杂度呈指数级增长，日常运维工作繁重，发现问题不及时。同时故障处理也面临严峻挑战，故障中涉及的复杂场景多，故障处理的难度大。稳定性建设需要解决上述问题。为了解决高频调度导致的核心组件高负载问题，我们针对Apiserver、etcd、CoreDNS，这3个核心组件进行了架构和性能优化，具体的方案如图所示。通过这些优化手段提升了组件性能，并且降低了组件负载，有利于大规模集群的平稳运行。为了减轻集群运维负担，我们重点建设了自动化节点管理方案。把重复性的运维事项自动化。同时我们还完善了监控告警体系，开发了自动化巡检功能，使运维人员能够及时发现集群问题，快速介入，处理潜在风险，保障集群能够长久稳定运行。故障处理是集群稳定的兜底措施，我们针对多个核心组件都做了，各类故障处理预案。结合可能存在的故障特点，构造故障场景，进行故障恢复演练，确保故障发生时，能够第一时间找到合理的解决方案，准确的处理问题。通过上述的措施，在集群稳定性方面取得了不错的效果，首先日常的集群可用性稳定保持在99.99%水平，其次平台的年度故障复盘数相较于上一年下降60%。核心组件方面的优化也达到了不错效果，其中Apiserver的CPU负载下降70%，etcd提交延迟，从秒级缩短到毫秒级，CoreDNS的毛刺现象消失了，并且负载量下降了90%左右。2.2 GPU容器提效降本实践容器平台的核心竞争力之一就是助力业务提效降本，我们从不同业务维度，对GPU容器提效降本方案进行了探索。首先在单卡维度，通过自研GPU虚拟化方案，使多个容器，互不干扰的共享一张卡资源。其次是在单服务维度，使业务能够自动应对，负载变化的GPU弹性扩缩容方案。在多服务维度，能够让推理服务和训练服务，分时复用整机资源的，训推潮汐部署方案。最后是在多机多卡的分布式场景中，让GPU容器搭配RDMA网络，来解决跨节点通信的瓶颈问题。2.2.1 单卡共享-GPU虚拟化如何让一张卡同时运行多个容器又不互相干扰，就涉及到GPU虚拟化技术。GPU虚拟化一直是AI云原生领域的热门话题之一，各大云厂商都有成熟的解决方案售卖。vivo容器平台的自研GPU虚拟化方案，主要为了解决业务的三大痛点，首先是部分推理业务负载偏低，无法有效用满整卡资源，需要通过共享部署方式，减少资源总量，降低业务成本，提升利用率。其次是不同业务共享同一张卡时，对于安全性以及隔离性的要求各不相同，就需要使用不同的GPU虚拟化技术来满足不同业务诉求。最后在Dev开发机场景，用户使用频率偏低，需要通过显存超售，来提升资源复用率，但显存超售后又需要避免某个用户将显存耗尽，导致OOM错误影响同卡的其他用户。自研GPU虚拟化方案包含MIG虚拟化、内核层虚拟化、CUDA层虚拟化这三种技术。结合业务场景，提供了丰富的卡调度策略，例如尽量聚集的Binpack策略、尽量…

CUDA要凉？Claude 30分钟铲平英伟达护城河，AMD要笑醒了
type: item
date: 2026-01-26T09:43:55+08:00
description: 编辑：桃子【新智元导读】英伟达护城河要守不住了？Claude Code半小时编程，直接把CUDA后端迁移到AMD ROCm上了。一夜之间，CUDA护城河被AI终结了？这几天，一位开发者johnnytshi在Reddit上分享了一个令人震惊的操作：Claude Code仅用了30分钟，便将一段完整的CUDA后端代码，成功移植到AMD的ROCm上。整个过程，没有手写一行代码。这架势，简直是要填平这两个生态系统之间的鸿沟。更关键的是，这次移植完全没有依赖传统的「中间转换工具」，如Hipify翻译层，而是一键通过CLI完成。就连AMD软件副总Anush E.为之震惊，GPU编程的未来，是AI智能体的。消息一出，整个科技圈瞬间沸腾，很多人直呼：英伟达CUDA护城河要守不住了…..这究竟是怎么回事？Claude手撕CUDA，仅30分钟Claude Code是在一个智能体框架运行的，这意味着它可以自己「动脑子」。在执行过程中，他不会机械地转换关键词，而去真正理解代码，即特定核函数的底层逻辑。开发者johnnytshi介绍，这次移植中，最棘手的数据布局差异问题也被AI解决了，确保了内核核心计算逻辑保持一致。令人惊叹的是，johnnytshi在短短30分钟内，就把整个CUDA后端移植到了AMD ROCm上，而且中间没用任何翻译层。另外一个好处当然是，不用费劲去搭像Hipify这种复杂的翻译环境了；直接在命令行（CLI）里就能干活。如今，全网都被CUDA护城河被攻破呼声淹没了。毕竟，英伟达霸主地位，很大程度上建立在CUDA这个几乎成为行业标准的编程生态上。无数AI框架、深度学习库、科学计算工具都深度依赖它。AMD的ROCm虽然功能强大，却一直面临生态兼容性，以及开发者迁移成本高的痛点。现在，一个Claude却用极短时间踢碎了门槛，说不定未来更多CUDA代码可能轻松在AMD GPU跑起来了。实现细节GitHub中，johnnytshi本人也更新了日志和说明。为AMD GPU实现了完整的ROCm后端，从而在RDNA 3.5及其他AMD架构上支持基于注意力机制的现代国际象棋网络。GitHub：https://github.com/LeelaChess...在src/neural/backends/rocm/中添加了完整的ROCm后端实现了注意力网络架构（多头自注意力、FFN、嵌入层）使用rocBLAS进行GEMM运算，使用MIOpen进行卷积运算针对RDNA 3.5上的FP16性能优化了NCHW布局提供三种后端变体：rocm (FP32)、rocm-fp16 (FP16)、rocm-auto (自动检测)MIOpen是必选依赖（类似于CUDA的cuDNN）通过rocm\_agent\_enumerator自动检测AMD GPU架构编译选项：-Drocm=true -Damd\_gfx=gfx1151（或使用自动检测）性能说明：FP16性能：在Strix Halo (Radeon 8060S, gfx1151) 上 >2000 nps自动Batch Size调优（RDNA 3.5上min\_batch=64）测试过rocWMMA，但rocBLAS性能更好验证情况（Strix Halo – Radeon 8060S, gfx1151）：测试模型：768x15x24h-t82-swa-7464000.pb.gz 和 maia-1900.pb.gz后端：rocm-fp16功能正常，能生成正确的走法环境：ROCm 7.2.53150, MIOpen 3.5.1注：仅在RDNA 3.5上进行了测试；其他AMD架构暂未验证GPU未来，是AI智能体主场当然，这次演示也有局限性。对于简单或中等复杂度的内核，Claude Code表现得非常出色。更重要的是，写核函数的核心就在于搞定「深度硬件」优化。不过，一部分觉得Claude Code在这方面还是差点火候——如果遇到那些针对特定硬件缓存层级，内存访问模式做过极致优化的复杂内核，AI目前还难以完全取代人类专家。即便如此，这一事件释放出的信号已经足够强烈。过去几个月，ZLUDA项目、还有微软内部的尝试，都想要打破CUDA的垄断。但它们大多依赖规则映射或中间层，自动化程度和智能水平有限。Claude Code代表的智能体式编程，直接跳过了这些环节，用「理解+自主决策」的方式填平生态鸿沟。正如AMD软件副总所言，GPU编程的未来，是AI智能体主场。全员AI编程，浓度高达100%如今的Claude Code已经让整个硅谷入坑了（Claude-Pilled）。两天前，CEO Dario Amodei在达沃斯上再出暴论：软件工程师们没有时间了。未来6-12个月，AI能够彻底取代这些人！甚至，Anthropic内部工程师已经不再手写代码…

深入 NVIDIA GPU：高性能矩阵乘法算子解构（一）
type: item
date: 2026-01-19T20:10:40+08:00
description: 深入 NVIDIA GPU：高性能矩阵乘法（Matmul）算子解构在本篇博文中，我将逐步介绍支撑最尖端（SOTA）NVIDIA GPU 矩阵乘法（matmul）算子的核心硬件概念和编程技术。为何选择矩阵乘法？无论是训练还是推理阶段，Transformer 模型的大部分浮点运算（FLOPs）都消耗在矩阵乘法中（如 MLP 中的线性层、Attention 的 QKV 投影、输出投影等）。这些操作具有天然的极高并行性（Embarrassingly Parallel），非常适合 GPU。掌握了矩阵乘法算子的原理，你就拥有了设计几乎任何其他高性能 GPU 算子的工具箱。本文分为四个部分：NVIDIA GPU 架构基础：全局内存、共享内存、L1/L2 缓存、功率限制（power throttling）对算力极限（SOL）的影响等。GPU 汇编语言：SASS 和 PTX。设计近乎 SOTA 的同步矩阵乘法内核：线程束平铺（warp-tiling）方法。在 Hopper 上设计 SOTA 异步矩阵乘法内核：利用张量核心（Tensor Cores）、TMA、计算与加载/存储重叠、希尔伯特曲线（Hilbert curves）等。我的目标是让这篇文章自成体系：既有足够的细节供独立阅读，又足够简洁以避免变成教科书。本文是系列文章的首篇。后续计划（理想状态下）涵盖：• 在Blackwell GPU上设计顶尖矩阵乘法内核• 通过微基准测试探索GPU架构• 设计顶尖多GPU内核• 揭秘内存一致性模型（GPU领域的“令牌化器”：默默支撑系统运行的关键组件，却令多数开发者困惑不已）NVIDIA GPU 架构基础要编写高性能的 GPU 内核，你需要对硬件有一个扎实的认知模型。随着我们深入探讨硬件架构，这一点会很快变得清晰。在本文中，我重点关注 Hopper H100 GPU。如果你能深度理解 Hopper，那么将知识迁移到未来架构（Blackwell, Rubin）或早期架构（Ampere, Volta）就会变得非常简单。Hopper [1] 和 Ampere [2] 白皮书是非常好的信息来源。在最高层面上，GPU 执行两个基本任务：移动和存储数据（内存系统）。对数据进行有用的操作（计算流水线）。下方的 H100 框图反映了这种划分：蓝色组件代表内存或数据移动，而红色组件代表计算（热）单元。图 1：NVIDIA Hopper H100 GPU 模型如果你在文中发现任何错误，请直接联系我——欢迎在 X、LinkedIn 或通过匿名反馈给我留言。内存（Memory）GPU 的内存系统是高度分层的，非常类似于 CPU 架构。这种分层是由物理学和电路设计决定的：SRAM 单元速度更快但体积更大（实现高速所需的控制电路也增加了其面积），而 DRAM 单元体积更小/密度更高但速度较慢。其结果是，高速内存容量低且昂贵，而慢速内存可以提供大得多的容量。稍后我们将更详细地讨论 DRAM 单元/内存。这种容量与延迟之间的权衡正是缓存层级存在的原因。在理想世界中，每个计算单元都会坐落在一大池超快内存旁边。由于这在物理上是不可能的，GPU 设计者做出了妥协：将少量快速内存放置在靠近计算单元的地方，并由更远处容量逐渐增大、速度渐慢的内存池作为后盾。这种组织方式最大化了整体系统的吞吐量。GPU 内存系统由以下部分组成：设备内存（VRAM/Device Memory）：在 CUDA 术语中，“设备”内存指的是片外（off-chip）DRAM——物理上与 GPU 芯片（die）分离，但封装在同一个板卡上——通常以堆栈式的 HBM 实现。它承载全局内存（GMEM）、每个线程的“局部”内存（寄存器溢出空间）等。L2 缓存（L2 Cache）：由 SRAM 构建的大容量 k 路组关联缓存。它在物理上分为两部分；每个 SM 直接连接到一个分区，并通过横截（crossbar）间接连接到另一个分区。分布式共享内存（DSMEM）：物理上接近的一组 SM（即一个 GPC）中共享内存（SMEM）的池化。L1 缓存与共享内存（Shared Memory）：￮ L1 缓存：每个 SM 私有的较小 k 路组关联 SRAM 缓存。￮ 共享内存（SMEM）：程序员管理的片上内存。SMEM 和 L1 共享相同的物理存储，它们的相对比例可以通过软件配置。寄存器堆（Register File/RMEM）：位于计算单元旁边的最快存储单元。寄存器是单个线程私有的。与 CPU 相比，GPU 包含多得多的寄存器，且总 RMEM 容量与 L1/SMEM 存储的总和相当。图 2：H100 (SXM5) GPU 的内存层级📝 注意： 还有一些用于指令的小型缓存，以及常量内存等，为了理解核心原理，我将忽略它们。从设备内存向下移动到寄存器（第 …

深入 NVIDIA GPU：高性能矩阵乘法算子解构（一）
type: item
date: 2026-01-19T19:28:25+08:00
description: 深入 NVIDIA GPU：高性能矩阵乘法（Matmul）算子解构在本篇博文中，我将逐步介绍支撑最尖端（SOTA）NVIDIA GPU 矩阵乘法（matmul）算子的核心硬件概念和编程技术。为何选择矩阵乘法？无论是训练还是推理阶段，Transformer 模型的大部分浮点运算（FLOPs）都消耗在矩阵乘法中（如 MLP 中的线性层、Attention 的 QKV 投影、输出投影等）。这些操作具有天然的极高并行性（Embarrassingly Parallel），非常适合 GPU。掌握了矩阵乘法算子的原理，你就拥有了设计几乎任何其他高性能 GPU 算子的工具箱。本文分为四个部分：NVIDIA GPU 架构基础：全局内存、共享内存、L1/L2 缓存、功率限制（power throttling）对算力极限（SOL）的影响等。GPU 汇编语言：SASS 和 PTX。设计近乎 SOTA 的同步矩阵乘法内核：线程束平铺（warp-tiling）方法。在 Hopper 上设计 SOTA 异步矩阵乘法内核：利用张量核心（Tensor Cores）、TMA、计算与加载/存储重叠、希尔伯特曲线（Hilbert curves）等。我的目标是让这篇文章自成体系：既有足够的细节供独立阅读，又足够简洁以避免变成教科书。本文是系列文章的首篇。后续计划（理想状态下）涵盖：• 在Blackwell GPU上设计顶尖矩阵乘法内核• 通过微基准测试探索GPU架构• 设计顶尖多GPU内核• 揭秘内存一致性模型（GPU领域的“令牌化器”：默默支撑系统运行的关键组件，却令多数开发者困惑不已）NVIDIA GPU 架构基础要编写高性能的 GPU 内核，你需要对硬件有一个扎实的认知模型。随着我们深入探讨硬件架构，这一点会很快变得清晰。在本文中，我重点关注 Hopper H100 GPU。如果你能深度理解 Hopper，那么将知识迁移到未来架构（Blackwell, Rubin）或早期架构（Ampere, Volta）就会变得非常简单。Hopper [1] 和 Ampere [2] 白皮书是非常好的信息来源。在最高层面上，GPU 执行两个基本任务：移动和存储数据（内存系统）。对数据进行有用的操作（计算流水线）。下方的 H100 框图反映了这种划分：蓝色组件代表内存或数据移动，而红色组件代表计算（热）单元。图 1：NVIDIA Hopper H100 GPU 模型如果你在文中发现任何错误，请直接联系我——欢迎在 X、LinkedIn 或通过匿名反馈给我留言。内存（Memory）GPU 的内存系统是高度分层的，非常类似于 CPU 架构。这种分层是由物理学和电路设计决定的：SRAM 单元速度更快但体积更大（实现高速所需的控制电路也增加了其面积），而 DRAM 单元体积更小/密度更高但速度较慢。其结果是，高速内存容量低且昂贵，而慢速内存可以提供大得多的容量。稍后我们将更详细地讨论 DRAM 单元/内存。这种容量与延迟之间的权衡正是缓存层级存在的原因。在理想世界中，每个计算单元都会坐落在一大池超快内存旁边。由于这在物理上是不可能的，GPU 设计者做出了妥协：将少量快速内存放置在靠近计算单元的地方，并由更远处容量逐渐增大、速度渐慢的内存池作为后盾。这种组织方式最大化了整体系统的吞吐量。GPU 内存系统由以下部分组成：设备内存（VRAM/Device Memory）：在 CUDA 术语中，“设备”内存指的是片外（off-chip）DRAM——物理上与 GPU 芯片（die）分离，但封装在同一个板卡上——通常以堆栈式的 HBM 实现。它承载全局内存（GMEM）、每个线程的“局部”内存（寄存器溢出空间）等。L2 缓存（L2 Cache）：由 SRAM 构建的大容量 k 路组关联缓存。它在物理上分为两部分；每个 SM 直接连接到一个分区，并通过横截（crossbar）间接连接到另一个分区。分布式共享内存（DSMEM）：物理上接近的一组 SM（即一个 GPC）中共享内存（SMEM）的池化。L1 缓存与共享内存（Shared Memory）：￮ L1 缓存：每个 SM 私有的较小 k 路组关联 SRAM 缓存。￮ 共享内存（SMEM）：程序员管理的片上内存。SMEM 和 L1 共享相同的物理存储，它们的相对比例可以通过软件配置。寄存器堆（Register File/RMEM）：位于计算单元旁边的最快存储单元。寄存器是单个线程私有的。与 CPU 相比，GPU 包含多得多的寄存器，且总 RMEM 容量与 L1/SMEM 存储的总和相当。图 2：H100 (SXM5) GPU 的内存层级📝 注意： 还有一些用于指令的小型缓存，以及常量内存等，为了理解核心原理，我将忽略它们。从设备内存向下移动到寄存器（第 …

最烦做演讲！黄仁勋曝英伟达养了 61 个 CEO、从不炒犯错员工：CEO 是最脆弱群体
type: item
date: 2026-01-19T19:26:29+08:00
description: 整理 | 华卫 “世界上不会再出现第二个我这样的 CEO 了。”近日，英伟达联合创始人兼首席执行官黄仁勋（Jensen Huang）在一场私人访谈中这样说道。 据称，这场深度对话已经酝酿了三十年，将黄仁勋鲜为人知的一面展现在大众眼前。主持人 Jodi Shelton 与黄仁勋的职业交集始于三十余年前，彼时，图形处理器（GPU）尚未掀起席卷全球的 AI 革命。从加速计算的源头到生成式 AI 的前景，这场对话堪比一堂远见大师课。 在访谈中，黄仁勋表示，从某种意义上说，英伟达其实有 61 位 “CEO”。过去这些年，包括他在内，很多人都犯过严重的错误，但在英伟达，从来没有人因为犯错而被解雇。“我们打造了一个足够安全的环境。”他还透露，CEO 这个职位，远比人们想象的要脆弱得多。“实际上，我们可能是公司里最脆弱的一群人。不过对我来说，承认这种脆弱，并不是什么难事。” 有意思的是，他提到，在很多方面，自己都算是一个 “不情愿的 CEO”。“公开演讲简直让我怕得要死。比起待在公司外面抛头露面，我更喜欢扎根在公司内部；比起发表演讲，我更喜欢安静做事；我甚至一点都不喜欢做主题演讲，但为了公司，我必须去做这些事。” 此外，黄仁勋称，英伟达的成功，绝不是靠产量取胜。“虽然是英伟达发明了 GPU，但从产量来看，我们其实是全球最小的 GPU 制造商。很多不知名的厂商，GPU 产量都比我们高。”而“没有终极目标” 这一点，对英伟达的发展真的起到了至关重要的作用。 对于五年后的世界，黄仁勋断言，英伟达和整个行业在 AI 领域的投入，必将彻底改变计算机的运作模式，未来的计算机，将从 “由人类编程” 进化为 “在人类引导下自主学习编程”。并且，100% 的工作岗位都会发生变化，但不会有 50% 的岗位消失。未来的趋势不会是就业岗位减少，反而是大家会变得比现在更忙碌。并且，那些现在没有工作的人，很可能会因为 AI 获得谋生的手段。 网友们纷纷就此次访谈对黄仁勋评价道，“我从未见过他如此坦诚直率，真是不可思议。” 以下是详细对话内容，我们在不改变原意的基础上进行了翻译和删减，以飨读者。“走了整整 33 年才看到成果”Jodi Shelton：大众其实特别好奇像你这样的人，毕竟你们正在定义科技的未来，而科技的未来就是整个世界的未来。所以我们想做的，是挖掘你成功光环背后的个人经历以及支撑你走到今天的价值观。你对这个定位怎么看？ 黄仁勋：说实话，不太喜欢。 Jodi Shelton：真的不喜欢吗？可你现在是名人啊，大家都想了解名人的故事。 黄仁勋：我从不觉得自己是名人，也根本不是什么名人。我只是恰好执掌着一家举足轻重的企业，是这家堪称史上最成功的科技公司之一的 CEO。很早以前，我们就做了一些正确的决策。回溯到 1993 年，我们就立志要重塑计算行业，而且对于计算机的架构，我们有着自己独到的见解。在很长一段时间里，这个观点都不被看好，甚至颇具争议。要知道，当时整个行业的焦点都在微处理器和 CPU 上。说起来，我和你就是在那个时期认识的。我们早在 1993 年底或者 1994 年就相识了，对吧？从那时起，英伟达就在做我们现在依然在做的事：重塑计算。 Jodi Shelton：没错，我记得很清楚。那时候的硅谷，正处在 CPU 为王、摩尔定律大行其道、个人电脑革命如火如荼的年代。 黄仁勋：是啊。而且我们早期的客户，全都是 PC 芯片组领域的初创公司。这些企业可以说是半导体行业辉煌版图的奠基者，像 Cirrus Logic、S3 Graphics、Western Digital、Trident Microsystems，你还记得这些名字吗？ Jodi Shelton：当然记得。 黄仁勋：这些公司，称得上是英伟达的 “前辈”。而现在，我们依然在这条路上前行，致力于打造一种全新的计算模式。这条路，我们走了整整 33 年才看到成果。我只是恰好成为了这家公司的 CEO，仅此而已。 Jodi Shelton：可能对你来说，这一切是水到渠成，但对整个世界而言，英伟达的崛起堪称横空出世。大概从 2023 年 11 月起，整个世界的科技格局都因你们而改变。你是怎么看待这次转型的？ 黄仁勋：要知道，想要创造未来，就必须在未来到来之前，先置身于未来之中。坦诚地说，从我们发明 CUDA 技术、推出相关产品的那一刻起，就已经踏上了通往未来的道路。英伟达最让我骄傲的一点是：我们不仅擅长技术发明，更擅长把技术转化为产品推向市场。世界上有太多的公司、科研人员和发明家，他们确实创造出了先进的技术，但最后往往只能感慨 “这个技术我早就做出来了”、“这个想法我早就有了”。每次听到这种话，我都觉得很惋惜。这些优秀的发明家，遗憾的是没能遇上同样优秀的产品创新者。 所谓产品创新者，就是能把一项技术发明转化为一款能推向…

简单易懂的 LLM 相关知识梳理 - ep3-3 认识 NVIDIA 驱动、CUDA、Pytorch
type: item
date: 2026-01-14T18:25:03+08:00
description: 目录帖：简单易懂的 LLM 相关知识梳理 文档共建迫于项目被砍，失业赋闲在家，恰好也快过年了不想动了，想了下写点文章回馈下社区吧。 PS：如有年后 Base 重庆的 AI / 全栈 / FAE 岗可 PM 我 本文从实用角度出发，梦到哪写哪。部分八股文知识就不搬了，这里主要分享一下本人在使用各种云服务及本地部署过程中学到的知识。 这里优先介绍 LLM/VLM，暂不涉及音频 / 视频 / Omni 相关模型（也可能梦到了以后补一下） 注：文章为本人手写，部分模型介绍搬运自…PS：看完的佬友可以发条评论，最近几章的阅读量越来越少，是行文出了问题或是难以理解？还是单纯的帖子被淹没了？============ 以下正文 ============驱动的安装在这里只讲 Ubuntu 和 Windows 的。首先说 Windows，大家应该都非常熟悉了，官网下载驱动包一键安装就行。对于 Ubuntu 来说，大部分情况下建议采用如下方式安装驱动，而非官网下载.run 文件安装驱动：在 /etc/modprobe.d/blacklist.conf 的末尾追加 blacklist nouveau 并执行 sudo update-initramfs -u && reboot 以禁用 nouveau执行 ubuntu-drivers devices 以查询推荐驱动。如：(base) root@ubuntu:~# ubuntu-drivers devices == /sys/devices/pci0000:c0/0000:c0:01.1/0000:c1:00.0 == modalias : pci:v000010DEd00002684sv000010DEsd000016F3bc03sc00i00 vendor : NVIDIA Corporation model : AD102 [GeForce RTX 4090] driver : nvidia-driver-535 - distro non-free driver : nvidia-driver-570-server-open - distro non-free driver : nvidia-driver-580-open - distro non-free driver : nvidia-driver-580-server - distro non-free driver : nvidia-driver-535-server - distro non-free driver : nvidia-driver-570 - distro non-free driver : nvidia-driver-580 - distro non-free recommended driver : nvidia-driver-535-open - distro non-free driver : nvidia-driver-580-server-open - distro non-free driver : nvidia-driver-570-open - distro non-free driver : nvidia-driver-535-server-open - distro non-free driver : nvidia-driver-570-server - distro non-free driver : xserver-xorg-video-nouveau - distro free builtin 可以看到目前推荐的驱动版本是 580。那么执行 sudo apt install nvidia-driver-580 -y 即可安装。注意，驱动程序和 CUDA 版本的关系很简单：显卡驱动的版本必须大于等于 CUDA Toolkit 所要求的最低版本。nvidia-smi看懂 nvidia-smi安装完驱动以后，执行 nvidia-smi 来检查一下驱动是否已经正确安装：(base) root@ubuntu:~# nvidia-smi Wed Jan 14 02:22:46 2026 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 580.95.05 Driver Version: 580.95.05 CUDA Version: 13.0 | +-----------------------------------------+------------------------+----------------------+ | GPU Name…

算力稀缺时代，如何把 GPU 用“满”
type: item
date: 2026-01-07T12:06:57+08:00
description: 过去几年里，GPU 几乎成为所有技术团队的“硬通货”。高端 GPU 不仅价格贵，而且很难购买到。以 A100 为代表的数据中心级 GPU 在市场上长期维持在 10000 美元到 12000 美元区间，叠加地区供应与合规管制，使 GPU 逐渐演变为一种高成本、难扩展的稀缺计算资源。与 GPU 紧缺的普遍认知相悖的是，许多组织同时面临着 GPU 利用率长期偏低的现实问题。根据 ClearML 发布的 2025–2026 年全球 AI 基础设施调研报告，35% 的企业已将提升 GPU 利用率列为首要基础设施目标，而 44% 的组织缺乏有效的 GPU 利用率管理策略，由此造成的 GPU 容量浪费每年可达数百万美元级别。源于实际生产环境的反馈进一步验证了这一点，在大量 GPU 计算场景，尤其是以推理作为核心的业务，GPU 的实际利用效率普遍偏低，在不少企业环境里，GPU 的平均利用率长期低于 50%；而在 OCR、NLP 推理的典型在线场景中，单卡 GPU 的算力利用水平甚至只有 20%–30%。也就是说，在 GPU 持续短缺的情况下，诸多已部署的算力未实现充分利用。为解决这一矛盾，业界其实进行过很多尝试。过去几年，有关 GPU 共享的技术探索不断涌现，其核心思路便是把多个 GPU 应用部署到同一张 GPU 卡上，以提高单张 GPU 卡的资源利用水平。然而，在生产环境里，这类方案始终面临一个问题：共享之后用起来没那么好用。既有的方案无法同时达成算力隔离、显存隔离、故障隔离以及资源灵活切割等关键能力，资源 QoS 难以保障，多个任务之间彼此干扰，甚至单个任务出现异常就会影响整卡的稳定。怎样在保障业务性能和隔离安全的基础上，实现可用、可控的 GPU 共享机制？本文将以 GPU 使用结构的变化为切入点，分析 GPU 长期“用不好”的原因，并通过腾讯云 TencentOS qGPU 内核态虚拟化以及在离线混部技术解析，探讨 GPU 资源切分与调度能力怎样走向生产可用，并实现降本增效。为什么需求暴涨的同时，GPU 却长期“用不好”？价格高、供应受限导致 GPU 不够用已经成为很多技术团队的共识。但倘若把观察的视角从采购规模转向实际运行情形就会发现，问题的根源并非仅仅是硬件数量，而是 GPU 的使用方式正在变化。过去，GPU 主要在离线训练或高吞吐计算任务中使用，负载相对平稳，整卡独占也相对合理。但随着 AI 能力渐渐嵌入业务体系，推理及在线服务在 GPU 工作负载里的占比渐渐增大。这类业务对低时延和稳定性具有更高的要求，请求模式呈现出峰值时间短暂、突发性强但整体不连续的特性。这种情况下，单个应用很难持续填满整张 GPU。然而，为保证服务稳定，许多推理服务仍选择长时间独占 GPU。该方式直接造成算力与显存无法按需分配，GPU 在大量的时间未实现充分利用。即便不同业务在时间上表现出高度互补，也难以共享同一张卡。随着业务规模扩大，资源浪费的现象也被逐步放大。GPU 使用模式已然出现改变，可依然在采用早期独占式的管理方法，为何 GPU 无法像 CPU 那样实现高效调度？更深层的原因是，GPU 与 CPU 在计算模型上的核心差异，造成其难以直接借用成熟的云原生调度范式。GPU 并非更快的 CPU 类型，其显存、算力、Kernel、Stream 和执行上下文高度耦合，CUDA 编程模型默认以进程级对设备的独占为前提。这使得调度系统难以感知 GPU 内部真实负载，算力与显存不易被独立、稳定地管控，而单个任务异常，往往会被放大成整卡无法使用的风险。因此，GPU 在很长的时间里都未被看作标准化、可共享的计算资源。GPU 共享方案技术路径与边界当 GPU 利用率问题逐步成为行业共识后，共享几乎是绕不开的方法。近几年，出现了多种围绕 GPU 共享的技术路径，它们在一定程度上提高了并发能力，但在生产环境里面也渐渐暴露出各自存在的局限。业界主流 GPU 共享方案及其局限较早被采用的方案，来自用户态或框架层的 API 拦截思路，经由在 CUDA Runtime 或深度学习框架层面介入 GPU 的调用，这类方案能在不调整底层驱动的状况下，做到多任务并发运行。 优点为部署灵活，但代价同样十分明显。这类方案属于上层调度，它既要求应用侧进行适配，也无法深入到 GPU 实际的执行阶段。鉴于难以准确感知不同 CUDA Kernel 的真实计算消耗，算力隔离仅停留在近似控制层面，复杂负载下容易失效。这是该类方案难以实现生产级 GPU 共享的核心原因。采用虚拟化的 vGPU 方案在隔离性上更进一步。依靠虚拟机层面对 GPU 进行划分，vGPU 能提供较强的资源边界，适配多租户的环境。然而方案面临的最大问题是不支持容器，仅仅支持虚拟化场景。在 K8S 的云原生场景不适用，而且也无法灵活配置显…