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 负责分配和释放执行流。如果设备只有单一指令队列，则 CreateStream 应返回 nullptr。设置活动流 — SetStream 用于将某个流设置为当前活跃流。目标代码生成器生成的函数执行时应提交到该流。同步到 CPU — StreamSync 应同步流，使之在执行完成前阻塞返回。流间同步 — SyncStreamFromTo 应在两个流之间插入同步屏障，使目标流在源流执行完当前排队命令前无法继续执行。为了使 TVM 能够使用新的 DeviceAPI，需要执行以下注册步骤：创建一个实例化 DeviceAPI 并返回其指针的函数：FooDeviceAPI* FooDeviceAPI::Global() { static FooDeviceAPI inst; return &inst; }在 TVM 注册表中注册：TVM_FFI_STATIC_INIT_BLOCK() { namespace refl = tvm::ffi::reflection; refl::GlobalDef().def("device_api.foo", FooDeviceAPI::Global); }在 base.h 的 TVMDeviceExtType 枚举中为新的 DeviceAPI 添加条目。值需大于 DLDeviceType::kDLExtDev，且小于 DeviceAPIManager::kMaxDeviceAPI。在 device_api.h 的 DeviceName 中添加对应枚举 → 字符串映射，该字符串需与 GlobalDef().def 中一致。在 tvm.runtime.Device的 _DEVICE_TYPE_TO_NAME 与 _DEVICE_NAME_TO_TYPE 字典中添加对应映射。Target 定义​Target 对象是有关物理设备、其硬件/驱动限制和能力的属性查询表。Target 可在优化阶段和代码生成阶段使用。虽然所有运行时共享相同的 Target 类，但不同运行时可能需要额外的 target 特定属性。在 target_kind.cc 中使用 TVM_REGISTER_TARGET_KIND 注册新的 target，需传入 target 名称，以及对应运行设备的 TVMDeviceExtType 或 DLDeviceType。通常情况下，target 名称和设备名称一致（如 "cuda" 运行于 kDLCUDA），但也有例外（例如 "llvm" 与 "c" 目标都运行于 kDLCPU）。所有 target 选项通过 add_attr_option 添加，可带默认值。可以使用 set_target_parser 添加解析器，用于处理依赖其他参数或硬件属性的动态参数。该参数解析器定义了如何从字符串格式构造 target。这由 Target::Target(const String&) 构造函数执行，该构造函数接受 JSON 格式字符串，通常通过 Python：tvm.target.Target('{"kind": "cuda", "max_num_threads": 1024}')在代码生成器中，可通过以下方式访问 target 属性：C++：target->GetAttr<T>(param_name)Python：target.attrsTarget 代码生成器​代码生成器将优化后的 IRModule 转换为可执行表示。每个代码生成器必须注册到 TVM 框架中，其名称为："target.build.foo"其中 foo 与先前 TVM_REGISTER_TARGET_KIND 中的名称一致。示例：tvm::runtime::Module GeneratorFooCode(IRModule mod, Target target); TVM_FFI_STATIC_INIT_BLOCK() { namespace refl = tvm::ffi::reflection; refl::GlobalDef().def("target.build.foo", GeneratorFooCode); }代码生成器有两个参数。第一个是要编译的IRModule，第二个是描述代码应该运行在哪个设备上的目标 Target。由于编译环境不一定与执行环境相同，因此代码生成器不应直接向设备查询属性，而应始终使用 Target 中的属性。输入 IRModule 中的每个函数都应在输出的 runtime::Module 中可通过名称访问。
如果我有一个完全空白感觉全新的 ubuntu22.04 我希望一次性安装所有英伟达开发ai需要的cuda相关一切包
如果你拥有一个纯净的 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 脚本吗？
作者：互联网容器团队-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策略、尽量分散的Spread策略，每个卡只有一个实例的CardOnlyOne策略，以及自定义节点和卡分配关系的CustomTopo策略。通过自研模块与组件，接入Kubernetes体系，对外提供统一调度能力。首先，MIG虚拟化技术，是基于Nvidia硬件提供的，切块组合能力，能够按规则把计算单元和显存单元进行组合，组成MIG实例挂载到容器内，提供完全独立的运行环境。MIG方案的优点是拥有Nvidia官方支持，可以集成到自研体系中。由于是在硬件层面实现的算力和显存限制，所以隔离性和安全性最好。缺点就是仅支持Ampere及以后架构的部分卡，而且限定了切分比例。主要应用场景是对算力隔离有强需求的线上业务。内核层虚拟化技术，是通过自研内核模块，创建虚拟字符设备替换原有的Nvidia字符设备，在内核态拦截IOCTL请求后，实现的算力和显存限制。优点是上层应用无感。并且内核态拥有良好的安全性。缺点是当前无开源方案，开发难度大，而且算力隔离的并不充分。主要应用场景是常规线上业务。CUDA层虚拟化技术的原理：使用拦截库替换Nvidia Driver的原始库，建立拦截库与原始库的，API函数映射关系，从而拦截调用函数，实现算力和显存的限制。优点是有开源方案，使用起来比较灵活。并且可以基于Nvidia提供的统一内存模型，开发显存超售能力。能够在显存不足时，使用内存替代，虽然处理速度下降，但是能够有效避免，显存OOM导致用户程序报错。缺点是用户态导致安全性不足，并且算力隔离能力偏弱，主要应用场景是Dev开发机场景。将自研的内核层虚拟化方案与业界方案，进行了自测性能对比，如图所示，可以看到自研方案在性能上，已经达到业界先进水平。业务使用该方案，与独占整卡部署相比较，平均单卡虚拟化率300%左右，就是把1张物理卡当3张卡使用，同时整机GPU利用率提升了30%+，成本优化超过50%。2.2.2 服务提效-GPU弹性扩缩容在单服务维度，如何帮助业务自动管理大量的GPU容器是提效的关键。我们引入了GPU弹性扩缩容方案。首先弹性扩缩容能力，能够快速响应负载变化，自动调节实例数量，减少人工干预次数，有利于业务在突发场景的平稳运行。其次是业务方在生产环境部署后，非生产环境的实例通常会闲置，这会浪费稀缺的GPU资源。最后由于Kubernetes原生，并不支持GPU维度的弹性扩缩容，需要寻找合适的方案来满足业务诉求。如图所示，我们是基于开源的KEDA框架，自研了GPU-Scaler组件，使用Prometheus中存储，来自DCGM-Exporter的GPU指标，汇聚为扩缩容事件，用于触发KEDA框架，调整实例个数，以此实现了GPU弹性扩缩容能力。由于KEDA框架支持将Workload实例数缩容到0，所以在非生产环境部署的GPU业务，默认开启无负载时，自动缩容到零的功能，以此自动回收，长期闲置的GPU资源。最终的使用效果，线上业务资源不足类告警，下降了80%，单业务平均减少约每周1小时的，扩缩容工作量，有效降低了GPU业务的运维成本。2.2.3 多服务降本-训推潮汐部署在多服务维度，训练服务的资源短缺问题，与推理服务，低峰时段资源空闲问题，相对突出。考虑让训练业务利用推理的空闲资源，即训推潮汐部署方案。首先推理和训练业务都需要稳定的运行环境。而且推理业务潮汐特征明显，夜晚负载低，资源空闲多，导致平均利用率偏低。并且多机多卡训练任务，需要整机资源，且资源需求日益增长，采购新设备，难且慢，导致训练资源缺口明显。训推潮汐部署就是整机资源分时复用的逻辑，如图所示，推理业务在白天高负载时，稳定运行，在夜晚低峰时段，自动腾挪出空闲整机资源，借给训练业务使用。在清晨时段，训练业务结束，把整机资源还给推理业务，如此达到分时复用的效果。如图所示。推理业务在部署前，需要评估保底负载容量。在部署时填入维持业务稳定的最少Pod数量。基于OpenKruise组件的，WorkloadSpread功能，管理不同的Subset，分别在稳定池和潮汐池中按需部署。同时配置CronHPA，定时缩容，自动调整副本数，到稳定Pod数量，优先删除潮汐池中的Pod。以此达到把潮汐池的节点整机腾空的效果。其中我们还针对Workload的缩容优先级进行了优化。当缩容发生时，结合Pod和节点的拓扑关系，把所在节点实例数少的Pod优先缩容，达到更快的腾空效果。通过上述方案，训推潮汐部署的降本效果明显，使推理业务，成本下降30%，同时整机GPU利用率提升20%多，有效缓解了训练资源短缺问题。2.2.4 多机多卡提效-容器RDMA高性能网络当前分布式训练和推理业务，对算力和显存的需求巨大，单节点资源不足，需要使用多机多卡资源，那么网络通信容易成为性能瓶颈。RDMA技术允许GPU直接访问支持RDMA设备中的数据，无需经过主机CPU或内存，实现跨节点的零拷贝数据传输，有效减少了CPU开销和网络延迟。所以从多机多卡维度，使用RDMA技术是网络提效的有效措施。从容器平台角度，GPU容器更加需要结合RDMA技术，提供简单高效的解决方案，方便业务使用。如图所示，RDMA容器有两个网卡，一个是使用Calico-CNI插件，通过veth创建的eth0网卡，对应的是Underlay网络。另一个是使用Sriov-CNI插件，通过VF创建的eth1网卡，对应的RoCE_v2或IB协议网络。我们引入了Multus-CNI组件，能够在单容器创建时，按需调用多种CNI插件。同时我们选择使用Spiderpool组件管理IP池，以及进行IP分配和路由策略配置。通过上述组件，在Kubernetes体系中实现了RDMA容器的全生命周期管理能力。基于容器RDMA能力，在大规模训练和推理场景，业务能够提速20%到30%之间，提升效果明显。三、AI工程训练平台实践3.1 训练平台整体架构VTraining训练平台是由vivo AI计算平台团队打造的一站式大模型训练方案，它面向算法工程师，提供模型开发、模型训练和海量样本存储等能力。VTraining底层是基于vivo容器平台、及高性能计算、网络、存储等基础设施之上构建，通过提供模型开发、模型训练、资产管理等能力，支撑公司的大模型训练业务。像vivo手机的蓝心小V、相册等核心产品的大模型训练，都是在VTraining平台进行迭代的。3.2 大规模训练稳定性实践3.2.1 稳定性背景稳定性问题是大规模训练的痛点。任务在大规模的同步训练过程中需要依赖计算、网络、存储、容器调度等复杂的基础设施环境，任何环节出问题都会导致任务中断，问题定位、恢复困难。例如知名头部公司千亿参数大模型的大规模训练任务，平均每3小时触发一次意外中断。3.2.2 稳定性实践-高频故障专项治理其中一个问题，是GPU集群投入使用初期机器故障率会很高，训练任务会经常被中断。为了降低机器故障率，我们进行了高频故障专项治理。首先对GPU集群进行了大规模测试诊断、然后进行高频故障统计和修复，把有问题的软硬件进行维修、替换、升级或修复。3.2.3 稳定性实践-故障处置流程完善另一个问题，是任务故障就是不可避免的，所以为了缩短任务中断时间，尽快恢复任务运行，我们对故障处置流程进行了重点建设完善。**训练前，**我们会针对GPU机器、网络通信等环境进行大规模检测，剔除异常节点、慢节点等问题节点，降低故障风险。**训练中，**会开启自动化容错机制，以便能及时发现基础设施或任务异常，快速进行故障定位和故障容错，自动隔离故障、自动重启恢复任务运行。**训练后，**对新问题进行搜集分析，完善异常特征库，增强问题诊断能力，以便后续遇到类似的故障可以快速容错。3.2.4 稳定性实践-效果与总结通过减少基础设施高频故障、完善任务故障处置流程两大措施，我们取得了良好效果：机器每天故障率由原来的百分之二下降到千分之一；千卡任务有效训练时长由原来的60%提升到99%，达到了行业一流水平。同时我们也积累了相关的稳定性经验：GPU集群由不稳定到稳定，需要一个软硬件磨合过程。因为不同的软硬件环境会触发不同的稳定性问题。大规模训练前，尽量剔除历史故障率高的机器。我们发现稳定的机器一般会一直很稳定，而故障率高的机器即使修复后出问题的概率也比较大。提升任务有效训练时长，需结合基础设施、训练框架、平台容错机制综合优化。例如秒级监控告警能力、checkpoint持久化策略等等都需要进行持续深入的优化。3.3 GPU利用率提升实践3.3.1 GPU利用率提升-业务背景及问题GPU是稀缺资源，但是差异化的业务场景下GPU难以高效利用，利用率提升困难。比如GPU场景常见业务形态：有训练任务、推理业务、数据生产、开发调试等等类型。他们各有特点：训练任务虽然GPU利用率高，但是偶尔也会出现碎片化空闲资源，比如算法同学偶尔会将任务停下来排查问题，调下参数之类的操作，任务并不是一直不间断地在跑的。推理业务有很明显的潮汐特性，白天流量高峰期GPU利用率高、到了夜间流量低峰期利用率会比较低。数据生产任务属于离线任务，GPU利用率高、资源需求大、但难申请到资源；开发调试任务的话GPU利用率低并且要长期占用资源，导致GPU利用率长期低下。所以不同的业务形态有不同的利用率特点，接下来介绍下我们的GPU利用率提升措施。3.3.2 利用率提升措施一：低优任务对于训练任务场景，偶现的碎片化空闲资源，我们 通过低优数据生产任务进行充分利用。如图所示，我们通过低优数据生产任务调度，复用训练场景偶现的碎片化资源，当正常任务需要资源时，可随时抢占低优资源，不会影响正常训练任务的调度。3.3.3 利用率提升措施二：训推潮汐部署对于推理业务场景，在夜间流量低峰期可以释放大量GPU资源，我们通过训推潮汐部署给离线业务复用。如图所示，通过训推潮汐部署机制，我们将夜间推理流量低峰期缩容的机器腾挪到了离线GPU资源池，给离线业务使用，白天再腾挪回在线GPU资源池进行扩容，达到潮汐复用的目的。3.3.4 利用率提升措施三：GPU虚拟化对于开发任务场景，长期独占GPU资源且利用率低，我们通过vivo自研VGPU虚拟化技术，减少开发任务占用的物理GPU卡数，释放冗余算力。如图所示，我们可以将单机4卡GPU机器，通过开启VGPU虚拟出16卡VGPU，相当于一卡顶四卡。VGPU的优点是：可支持1:2、1:4超卖、还可以用内存补充显存不足，所以对用户是无感知使用的，很适用于开发任务这种对性能要求低的场景。3.3.5 利用率提升总结与规划总之，训练平台通过低优任务、训推潮汐部署、GPU虚拟化等策略，深度适配差异化业务场景特性，实现了资源高效复用。AI整体GPU利用率均值绝对值提升了5个百分点，接近行业一流水平。未来训练平台也会持续对GPU利用率进行综合治理。例如进行低效任务治理、低效资源盘活、成本账单统计、奖励与惩罚措施的实施等等，让稀缺的GPU资源发挥更大价值！四、GPU平台未来展望在容器平台层面，我们会从多集群联邦调度、在离线GPU混部、国产异构计算芯片支持、GPU资源池化等方面能力进行综合建设，支撑上层平台业务对GPU资源的高效利用。训练平台层面，我们会增强故障预警、任务动态容错等能力，增强业务稳定性；同时完善对大模型训练全流程能力的支撑，以及对GPU资源进行更精细化的运营，从而让GPU业务更加稳定、资源利用更加高效！
编辑：桃子【新智元导读】英伟达护城河要守不住了？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内部工程师已经不再手写代码了，全是Claude完成。别不信，是真的。就在Wired最新采访中，Claude Code之父Boris Cherny坦承，「自己100%代码都是AI写的」。或许Anthropic工程师怎么也没有想到，一个「副业项目」竟让硅谷如此狂热。Boris Cherny回忆道，「一年前我们发布Claude Code时，甚至不确定『智能体编程』能不能成，但火爆来得太快了」。Cherny个人经历就是最好的缩影：刚发布时，他只有5%代码是用Claude Code写的；到了去年5月，有了Opus 4和Sonnet 4，这个比例变成了30%；而现在，有了Opus 4.5，他在过去两个月里100%的代码都是由Claude Code完成。在Anthropic内部，这种全员AI化更是到了极致。几乎100%技术员工都在使用Claude Code，甚至连Claude Code团队本身95%的代码也是由自身写出来的。斯坦福AI教授都在用了不得不说，AI编程的进化速度令人咋舌。回望2021到2024年，大多数工具不过是高级版的「自动补全」，在开发者打字时卑微地建议几行代码。但到了2025年初，随着Cursor和Windsurf等初创发布早期的Agentic编程产品，游戏规则改变了——开发者只需用大白话描述功能，剩下的脏活累活全扔给AI智能体完成。Claude Code也在这个时间点，真正诞生了。Boris Cherny坦承，早期版本也曾跌跌撞撞，甚至陷入死循环。但Anthropic下了一步狠棋：不为当下的AI能力开发产品，而要为AI即将抵达的未来而构建。这一赌注押对了。随着Anthropic下一代旗舰Claude Opus 4.5的发布，AI编程迎来了真正的「拐点」。斯坦福大学AI讲师、Workera CEO Kian Katanforoosh最近就把公司全员迁移到了Claude Code。他直言，对于高级工程师来说，Claude Code比Cursor、Windsurf更能打。Katanforoosh感叹道，最近唯一让我看到编程能力有阶跃式提升的模型，就是Claude Opus 4.5。「它给人的感觉不像是在模仿人类写代码，而是它真的找到了一种更聪明的解决路径」。据传，微软内部也在大规模采用Claude Code了。年入超10亿美金的「副业」Claude Code大获成功，给Anthropic带来了最直观的效益。去年，AI编程智能体业务彻底爆发。11月，Anthropic宣布Claude Code在上线不到一年内，年度经常性收入（ARR）就突破了10亿美元。到2025年底，ARR至少又增长了1亿美元。彼时，该产品约占Anthropic总ARR（约90亿美元）的12%。虽然比起向大企业提供 AI 系统的核心业务来说还算「小弟」，但它已是公司增长最快的板块之一。尽管Anthropic在AI编程领域看似独孤求败，但Claude Opus 4.5的光环其实照亮了整个赛道。竞争对手Cursor也在11月达到了10亿美元ARR，OpenAI、谷歌和xAI更是磨刀霍霍，试图用自研模型分一杯羹。但Anthropic没打算停下。前几天，他们又发布了Cowork——这是一款面向非编程领域的AI智能体。它能管理你电脑里的文件、操作各种软件，而且完全不需要你在代码终端里敲命令。不是取代，是进化提及Cowork时，Cherny透露自己已经用疯了。比如项目管理，他会让Cowork盯着工程师的任务表格，谁没填名字，AI就会自动在Slack上发消息催人。Cherny感慨道，「这是我当工程师以来最爽的时候，因为我不再需要做那些枯燥乏味的脏活了」。面对那些因不再需要亲自写代码而感到失落的工程师，Cherny给出了他的建议：这行业一直在变。我祖父在苏联用穿孔卡片编程；后来变成了机器码；再后来是C语言、Java、Python。这是一条不断抽象化的连续体，AI智能体只是这条线上的最新一个点。如今，Cherny每天早上起床会在手机上启动3-4个编程智能体，到了公司再在终端里开几个。任何时候，他都有五到十个智能体在跑任务。Cherny总结道，「AI智能体将接管生活中所有繁琐的事——填表、搬运数据、发邮件。这会具有颠覆性，我们必须适应」。话又说回来，Anthropic能不能先解决下Claude使用量？
深入 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 的内存层级📝 注意： 还有一些用于指令的小型缓存，以及常量内存等，为了理解核心原理，我将忽略它们。从设备内存向下移动到寄存器（第 1-5 级），你会看到一个明显的趋势：带宽以数量级增长，而延迟和容量则以类似的数量级减少。这引发了一些直接的影响：将访问最频繁的数据尽可能靠近计算单元存放。尽量减少对层级结构底层的访问，尤其是设备内存（GMEM）。另一个值得注意的组件是 张量内存加速器（TMA），它是随 Hopper 引入的。TMA 支持在全局内存和共享内存之间，以及集群（cluster）内的共享内存之间进行异步数据传输。它还支持交织（swizzling）以减少银行冲突（bank conflicts）——我们会在适当的时候讨论这些细节（双关语）。计算（Compute）从内存转向计算，其基本单位是流式多处理器（SM）。Hopper H100 (SXM5) 总共集成了 132 个 SM。SM 被组织成图形处理集群（GPC）：每个 GPC 包含 18 个 SM，GPU 上共有 8 个 GPC。四个 GPC 直接连接到一个 L2 分区，另外四个连接到第二个分区。📝 注意：• GPC 也是支撑 CUDA 中 线程块集群（thread-block cluster） 抽象的硬件单元——我们稍后会回到编程模型。• 关于集群的一点：早前我说过每个 GPC 有 18 个 SM，所以 8 个 GPC 应该有 144 个 SM。但 SXM/PCIe 规格暴露的是 132 或 114 个 SM。差异在哪里？这是因为 18 × 8 的布局仅对完整的 GH100 芯片有效——在实际产品中，有些 SM 会被熔断（fused off）。这对我们编写内核时选择集群配置有直接影响。例如，如果集群跨度超过 2 个 SM，你就无法利用所有 SM。• 最后注意，“Graphics Processing Cluster (GPC)”中的“Graphics”是一个传统术语。在现代服务器级 GPU 中，这些集群纯粹作为计算/AI 加速单元，而非图形引擎。同样的，GPU 应该去掉“G”，它们是 AI 加速器。除了前面提到的 L1/SMEM/TMA/RMEM 组件（均位于 SM 内部），每个 SM 还包含：• 张量核心（Tensor Cores）：以高吞吐量在小分块（例如 64x16 @ 16x256）上执行矩阵乘法的专用单元。大型矩阵乘法被分解为许多此类分块操作，因此有效利用它们是达到峰值性能的关键。• CUDA 核心与 SFU：所谓的“CUDA 核心”（营销话术）执行标准的浮点运算，如 FMA（融合乘加：c=a∗b+c）。特殊函数单元（SFU）处理超越函数（如 sin,cos,exp,log）以及代数函数（如 sqrt,rsqrt 等）。• 加载/存储（LD/ST）单元：服务于加载和存储指令的电路，与 TMA 引擎互补。• 线程束调度器（Warp Schedulers）：每个 SM 包含调度器，为 32 个线程组成的组（CUDA 中称为 warps）发布指令。一个线程束调度器每周期可以发布一条线程束指令。每个 SM 在物理上分为四个象限，每个象限容纳上述计算单元的一个子集。这导出了以下见解：📝 并行性（Parallelism）与并发性（Concurrency）• 一个 SM 在给定的周期内最多可以同时发布来自四个线程束的指令（即在真正的并行执行中，每周期有 128 个线程）。• 然而，一个 SM 可以容纳多达 2048 个并发线程（64 个线程束）。这些线程束常驻在 SM 中，并随着时间的推移被换入和换出调度，允许硬件隐藏内存/流水线延迟。换句话说，指令并行性（在给定周期内有多少线程开始执行指令）限制为每 SM 128 个线程（4 条 32 宽度的线程束指令），而并发性（调度器中跟踪并有资格运行的线程数）则扩展到 2048 个线程。光速（Speed of Light）与功率限制既然我们购买 NVIDIA GPU 是为了计算，自然会问：性能上限是什么——GPU 的最大计算吞吐量是多少？这通常被称为“光速”（Speed of Light, SoL）性能：由芯片物理特性决定的上限。根据数据类型的不同，有不同的性能上限。在 LLM 训练工作负载中，bfloat16 (bf16) 是近年来的主导格式，尽管 fp8 和 4 位格式变得越来越重要（对于推理，fp8 已相当标准）。峰值吞吐量的计算公式为： perf=freq_clk_max∗num_tc∗flop_per_tc_per_clk或者用文字描述：最大时钟频率 × 张量核心数量 × 每个张量核心每周期的浮点运算数（FLOPs）。图 3：H100 SXM5 BF16 “光速”推导📝 FLOP vs FLOPs vs FLOPS vs FLOP/s• FLOP = 单次浮点运算。• FLOP/s = 吞吐量单位：每秒浮点运算次数。• FLOPs（小写 s）= FLOP 的复数（多次运算）。• FLOPS（全大写）常被误用来表示吞吐量，但严格来说应读作“FLOPs”（复数）。将 FLOPS 用作 FLOP/s 是不严谨的！:)我在上图中留下了一个提示：“光速”实际上并不是恒定的（我想这也是这个比喻失效的地方）。在实践中，峰值吞吐量取决于实际时钟频率，而时钟频率会因功率限制（Power Throttling）或温度限制而波动。如果 GPU 时钟频率下降，有效的光速也会随之下降。图 4：功率限制降低了时钟频率并拉低了有效的“光速”📝 延伸阅读： Horace He 在他的博文 [3] 中更深入地探讨了这一现象。硬件细节目前了解这些就足够了。接下来的重点将转向 CUDA 编程模型，然后我们会再次深入硬件底层，并最终上升到 CUDA C++ 层面。CUDA 编程模型CUDA 编程模型自然地映射到 GPU 硬件和内存层级结构上。其核心抽象包括：• 线程 (thread)• 线程束 (warp)（32 个线程）• 线程块 (thread block)• 线程块集群 (thread block cluster)• 网格 (grid)（由线程块或集群组成）图 5：CUDA 编程模型：线程、线程束、块、集群、网格每个线程通过 gridDim、blockIdx、blockDim 和 threadIdx 等变量“意识到”自己在 CUDA 层次结构中的位置。在内部，这些变量存储在特殊寄存器中，并在内核启动时由 CUDA 运行时（runtime）初始化。这些位置信息使得跨 GPU 分配任务变得简单。例如，假设我们要处理一张 1024×1024 的图像。我们可以将其划分为 32×32 的线程块，每个块包含 32×32 排列的线程。每个线程可以计算其全局坐标：Plain Text const int x = blockIdx.x * blockDim.x + threadIdx.x; const int y = blockIdx.y * blockDim.y + threadIdx.y;并利用这些坐标从全局内存读取分配给它的像素（imagex），执行点对点操作，并将结果存回。图 6：CUDA 内置变量：线程如何知道自己在哪里如上图所示，在实践中我们大多使用 1D 或 2D 的网格/集群/块形状。但在内部，它们始终可以根据需要进行逻辑重组。例如，如果 threadIdx.x 的范围是 0-1023（1024 个线程的 1D 块），我们可以将其拆分为 x = threadIdx.x % 32 和 y = threadIdx.x / 32，从而将其重塑为 32×32 的逻辑 2D 布局。将 CUDA 模型连接回硬件，有一点现在应该很清楚了：一个线程块应包含至少 4 个线程束（即 128 个线程）。为什么？ 线程块驻留在单个 SM 上。每个 SM 有 4 个线程束调度器——为了充分利用硬件，你不希望它们处于闲置状态。📝 至少 4 个线程束的其他原因：• 我们稍后会深入探讨，但在 Hopper 架构上，线程束组（warp-group，即 4 个线程束） 是 WGMMA（矩阵乘法）张量核心指令的执行单位。• 此外，在使用持久化内核（persistent kernels）时，我们通常每个 SM 仅启动一个线程块，因此构建任务以保持所有线程束调度器忙碌至关重要。带着 CUDA 编程模型的术语，我们可以继续深入探讨 GPU 的架构细节。全局内存（GMEM）模型让我们深入探讨 GMEM。如前所述，它是由多层 DRAM 堆叠而成，底部有一个逻辑层（HBM）。但 DRAM 到底是什么？图 7：DRAM 单元内部：晶体管 + 电容器，字线（wordline） + 位线（bitline）了解了单个位的存储方式后，让我们放大到整个存储矩阵。图 8：GMEM 模型📝 关于 HBM 的延伸阅读： 如果你想更深入地了解 HBM，我发现论文《Demystifying the Characteristics of High Bandwidth Memory for Real-Time Systems》[21] 非常有启发性。我们可以得出结论：访问模式（access patterns）至关重要，这是由 DRAM 单元的物理特性决定的。图 9：GMEM 访问模式的影响Stephen Jones 的演讲《How CUDA Programming Works》[4] 非常值得一看。如果我们示例中的矩阵是列优先（column-major*的，情况就会反转：列中的元素将连续存储，因此有效的选择是在内层循环遍历行，以避免 DRAM 惩罚。所以，当人们说“GMEM 合并（coalescing）非常重要”时，指的就是：线程应访问连续的内存位置，以最小化触及的 DRAM 行数。共享内存（SMEM）模型共享内存（SMEM）具有与 GMEM 截然不同的特性。它由 SRAM 单元而非 DRAM 构建，这使得它在速度和容量的权衡上完全不同。SRAM 单元的具体设计并不重要——只需知道存储一位信息需要多得多的晶体管。你可以自行搜索“SRAM cell”。SMEM 组织为 32 个银行（banks），每个银行宽度为 32 位（4 字节）：图 10：SMEM 模型SMEM 可以在单个周期内提供来自所有 32 个银行的数据（128 字节）——但前提是必须遵守一条规则：同一个线程束（warp）中的线程不得访问同一个银行（bank）内的不同地址。 否则，这些请求将被序列化，分多个周期执行。这种情况被称为 银行冲突（bank conflict）。如果有 N个线程访问同一个银行中的不同地址，就会产生 N 路银行冲突（N-way bank conflict），该线程束的内存请求将需要 $N$ 个周期才能完成。在最坏的情况下，所有 32 个线程都指向同一个银行中的不同地址，吞吐量将下降到原来的 1/32。为了说明这一点，假设线程束大小（warp size）为 5。下方的两种访问模式将分别需要 3 个周期和 1 个周期来完成服务：重要的是：如果一个线程束（warp）中的多个线程访问同一个银行（bank）内的相同地址，共享内存（SMEM）可以将该值广播（broadcast）或组播（multicast）给所有这些线程。在下方的示例中，请求在单个周期内即可完成服务：• 银行 1（Bank 1） 可以将一个值组播给 2 个线程。• 银行 2（Bank 2） 可以将一个值组播给 3 个线程。现在，来看硬件拼图的最后一块：L1 缓存。这是一篇由 Axel 撰写的关于 SMEM 微基准测试（microbenchmarking）的优秀博文 [5]。L1 模型我们已经看到 L1 和 SMEM 共享相同的物理存储，但 L1 在该存储周围增加了一层由硬件管理的脚手架层（scaffolding layer）。在高层级上，L1 缓存的逻辑流程如下：线程束（warp）发布一个内存请求（指向 SMEM 或 GMEM）。请求进入 MIO 流水线并被派遣至 LSUIN 路由器。路由器导向请求：SMEM 访问立即从数据数组（data array）中获得响应，而 GMEM 访问则进入标签比较（tag-comparison）阶段。在标签阶段，GMEM 的地址标签与目标集合（target set）中存储的标签进行对比，以确定数据是否驻留在 L1 中。命中（Hit）：请求直接从数据数组中获得服务（就像 SMEM 一样）。未命中（Miss）：请求传播至 L2（如有必要，甚至更远，直到 GMEM 或对等 GPU 内存）。当数据返回时，它会被缓存到 L1 中，替换（evicting）现有的一行，并并行地发送回发起请求的线程束。这就是我刚才描述的系统：图 13：L1 缓存模型让我们再深入一层，详细查看标签阶段（tag stage）和数据阶段（data stage）：图 14：k 路组关联缓存组织的分解当一个 GMEM（全局内存） 地址进入标签阶段时，命中/未命中（hit/miss）逻辑按如下方式展开：标签阶段接收 GMEM 地址。提取集合 ID 位（set id bits），并检查该集合中的所有缓存行（标签）。如果发现标签匹配（潜在的缓存命中）：￮ 检查该行的有效性标志（validity flags）。￮ 如果无效 → 视为缓存未命中（继续执行步骤 4）。￮ 如果有效 → 从数据数组中提取所请求的分区（sectors），并交付至线程束的寄存器中。如果未发现匹配（缓存未命中），请求被路由至内存层级结构的其余部分（L2 及更高层级）。￮ 当数据从 L2 返回时，它被存储在该集合中，并根据替换策略（例如伪 LRU 算法）驱逐（evicting）现有的某一行，同时并行地交付给发起请求的线程束。注意，L2 缓存与 L1 并没有太大区别，除了它是全局的（而非每个 SM 独立）、容量大得多（具有更高的关联度）、被划分为由横截（crossbar）连接的两个切片，并且支持更细致的持久化和缓存策略。至此，我们已经涵盖了理解后续章节所需的关键 GPU 硬件组件。📝 GPU 世代间的梯度：我之前提到过，理解 Hopper 是深入了解 NVIDIA GPU 未来和过去世代的绝佳基础。到目前为止，最大的世代跨越是从 Ampere → Hopper，引入了：• 分布式共享内存 (DSMEM)：在整个 GPC 的 SMEM 之间，实现加载、存储和原子操作的直接 SM 到 SM 通信。• TMA (张量内存加速器)：用于异步张量数据移动（GMEM ↔ SMEM, SMEM ↔ SMEM）的硬件单元。• 线程块集群 (Thread Block Clusters)：一种新的 CUDA 编程模型抽象，用于跨 SM 对块进行分组。• 异步事务屏障 (Asynchronous transaction barriers)：拆分式屏障，计数事务（字节数）而非仅仅是线程数。Ampere (例如 A100) 自身也引入了几个关键特性：• 张量核心 (Tensor Cores) 支持 tf32 和 bf16。• 异步拷贝 (GMEM → SMEM)，具有两种模式：绕过 L1 和访问 L1。• 异步屏障（在共享内存中由硬件加速）。• CUDA 任务图 (CUDA task graphs)：它是 PyTorch 中 CUDA graphs 的基础，减少了 CPU 启动和网格初始化开销。• 通过 CUDA 协作组 (CUDA Cooperative Groups) 暴露的线程束级规约指令（实现了单步、整数数据类型的线程束范围规约，无需 shuffle 模式）。
最烦做演讲！黄仁勋曝英伟达养了 61 个 CEO、从不炒犯错员工：CEO 是最脆弱群体
整理 | 华卫 “世界上不会再出现第二个我这样的 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 技术、推出相关产品的那一刻起，就已经踏上了通往未来的道路。英伟达最让我骄傲的一点是：我们不仅擅长技术发明，更擅长把技术转化为产品推向市场。世界上有太多的公司、科研人员和发明家，他们确实创造出了先进的技术，但最后往往只能感慨 “这个技术我早就做出来了”、“这个想法我早就有了”。每次听到这种话，我都觉得很惋惜。这些优秀的发明家，遗憾的是没能遇上同样优秀的产品创新者。 所谓产品创新者，就是能把一项技术发明转化为一款能推向市场的成熟产品的人。而这还不够，你还得为产品制定精准的市场策略，甚至需要亲手培育出一个全新的市场，让市场能够接纳你研发的产品和制定的策略。英伟达就是这样一家公司，我们具备技术发明、产品创新、策略制定、生态构建乃至市场培育的全链条能力，而且我们已经多次成功做到了这一点。所以对我来说，这种 “身处未来” 的状态，已经持续了很长时间。 Jodi Shelton：确实如此。 黄仁勋：很久以前，我们有一个战略，现在已经不怎么提了，叫 “CUDA 无处不在”。很多人都听过我当年四处推广 CUDA 的故事，跑遍各大高校、初创企业和成熟企业。有时候，台下听众加起来也就三个人，但我还是会掏出笔记本电脑，为他们演示 CUDA，告诉他们这项技术将如何改变世界。我走访了无数科研机构和实验室，参加了数不清的行业会议，推广 CUDA 的次数，估计比世界上任何人都多。长久以来，我一直沉浸在这样的 “未来图景” 里，讲的故事多了，甚至会产生一种 “未来已经到来” 的错觉。 Jodi Shelton：确实有这种感觉。 黄仁勋：所以现在看到这一切成为现实，我依然满心欢喜。而且在我看来，这一切其实并不意外，因为支撑英伟达发展的是计算机科学领域最根本的底层逻辑，不是靠一时的直觉，也不是凭主观的喜好。从很多方面来说，如今的成果是一种必然。但我想说的是，当你把一件事物的速度提升一千倍，或者规模扩大一千倍、体积缩小一千倍时，无论这件事物原本是什么，都会发生质的飞跃。而这种质变最终带来的结果，往往是超乎想象的。 我们早就预见到深度学习技术有着巨大的扩展潜力，这也是我们举全公司之力押注这一领域的原因。我们知道，AlexNet（深度卷积神经网络）绝不会是深度学习的终点，这种技术架构天生具备极强的可扩展性，再加上全球海量的数据资源，深度学习的爆发是水到渠成的事。不过我当时也清楚，有一项技术会成为我们前进路上的障碍，那就是无监督学习，或者说自监督学习，也就是让计算机摆脱人工标注数据的束缚，实现自主学习。因为人工标注数据的效率，迟早会成为技术发展的瓶颈。而当无监督学习技术取得突破的那一刻，我就知道，我们的时代来了。 就在不久前的投资者路演上，还有人跟我说，我当时就明确跟他们提过这场 “质变”。如果你去回看当时的财报电话会议，就会发现每当谈到对世界至关重要的技术话题时，我都会把这一点讲得非常透彻。在每一场投资者路演，在每一个我演讲的场合，我都会强调这个观点。如今，无监督学习技术确实取得了重大突破，深度学习的规模效应也彻底释放出来，我们才算真正驶入了发展的快车道。但即便如此，这项技术如今能解决的问题，依然让我感到惊喜。我们早就预料到技术会发生质变、计算平台会迎来变革，但我们没想到，变革的成果如此丰硕。 我们现在能够解读蛋白质的 “语言”、细胞的 “语言”、量子的 “语言”，能够读懂世间万物的各种表征形式。过去我们用来描述信息的方式，如今正在被彻底重塑。从几何图形、纹理材质到如今的 3D 高斯和 3D 点云，信息的呈现形式日新月异。这种感觉就好像人类突然变得无比聪慧，连英语这种语言体系都随之改变了。我们不再沿用过去的词汇、语法和句式，因为我们的智慧已经进化到了一个全新维度，能够用一种全新的方式进行交流。或许未来人类的交流方式会变成简单的 “嘀嘀嗒嗒” 的信号声。这让我想起了电影《降临》里的场景，人类突然开始用抽象的图形进行沟通，仅仅通过图形就能传递海量的信息，实现更深层次、更高效率的交流。 最不可思议的是，我们现在解决的很多问题在过去是完全无法想象的，而且解决问题的速度也远超以往。过去我们常说摩尔定律，而现在英伟达的发展速度完全可以用 “英伟达定律” 来形容，比过去快了整整一千倍。未来十年必将是波澜壮阔的十年，光是想想就让人无比兴奋。 Jodi Shelton：要做到你所做的这些事，要能够预见未来，并且坚信未来一定会到来，需要何等强大的自信啊。就像你之前说的，我们 1994 年就认识了，这么多年来，你一直都是这个样子。 黄仁勋：是啊，我记得很清楚。 Jodi Shelton：那时候我才二十几岁。你应该比我大一点吧？ 黄仁勋：当时我差不多 29 岁，快 30 岁了。英伟达有 61 位“CEO”，从没有人因犯错而被解雇Jodi Shelton：我还记得我们第一次见面的场景，当时我是为了给杂志写稿采访你。我问你：“黄仁勋，硅谷人才流动频繁，很多人来了又走，你会担心这个问题吗？” 毕竟当时很多 CEO 都在抱怨这件事。而那时你才 29 岁或 30 岁，你是这么回答我的：“英伟达既不是教堂，也不是监狱。想来的人可以来，想走的人也可以走。” 我当时听完特别震撼，心里想着：“这个人到底是谁啊？” 年纪轻轻，却有着如此的自信和智慧。我还听过一个类似的故事，张忠谋（ Morris Chang）第一次见到你的时候，你当场就说：“我会成为你最大的客户，至少也是最大的客户之一。” 他当时的反应是：“哇，这小伙子可真有魄力。” 所以我很好奇，你这么年轻的时候，这份自信是从哪里来的？ 黄仁勋：哈哈，你要知道，什么都懂其实也挺痛苦的，我开玩笑的。对了，张忠谋要是知道英伟达现在是台积电最大的客户，一定会很开心的。 Jodi Shelton：那是肯定的，他肯定会为你感到骄傲。 黄仁勋：我也为他感到骄傲。要知道，在个人电脑革命时期，英伟达就曾是台积电最大的客户。如今，我们再次成为了他们最大的客户，对此我感到非常欣慰。言归正传，我觉得一个人必须坚信自己所相信的东西。而且这份信念，不能建立在道听途说之上，不能因为别人说了什么，你就去相信什么。你必须认真思考，梳理出自己相信这件事的逻辑，并且把这些逻辑拆解成可靠的底层原则。之后，你还需要定期检验这些原则，确保你所秉持的信念、所付诸的行动，都是建立在坚实的基础之上的。 如果这个基础不够稳固，或者因为某些原因发生了变化，那就说明它可能并非真正的底层原则 ，也许它并没有锚定在物理规律或客观事实之上。一旦出现这种情况，你就要重新评估，然后及时调整方向。我一直都是这样做的。而且，如果你真心相信一件事，就应该付诸行动去实现它。我从 1993 年起就坚信我们正在做的事情，直到今天，这份信念依然没有改变。正因为坚信不疑，所以我才会不断地推演，不断地在脑海里进行逻辑梳理。我会持续复盘过去的决策，也会不断预判未来的趋势。 就像昨天我们开了那么多场会议，每场会议上，我都会重新梳理我们一路走来的逻辑。你会发现，过去的那些假设，有些是正确的，但也有些是错误的。正是因为我们足够灵活，能够根据实际情况及时调整方向，才最终走到了今天。所以，时常回头复盘、重新推演过往的决策，是一件很有意义的事，它能帮你更好地锻炼向前推演的能力。正因为我一直坚持这样做，所以我始终活在自己认定的真相里。直到现在，我依然觉得自己只是英伟达的一名员工。我非常在乎这家公司，但公司里有很多人都和我一样，对这家公司倾注了深厚的感情。 在一家治理完善的公司里，CEO 的角色定位是很明确的。CEO 需要向董事会汇报工作，而董事会则要对股东负责。如果 CEO 的工作表现没有达到董事会的预期，不管董事会有 12 位、13 位还是 15 位成员，他就会被解雇。所以说，CEO 其实也是公司这个组织里的一名员工。这就是为什么我说，英伟达既不是教堂，不是想来就能来；也不是监狱，不是想走都走不了。这种心态能让你始终保持脚踏实地，保持谦逊，保持锐意进取的状态，因为你必须每天都努力，才能对得起自己的这份工作。 有时候会有人问我：“黄仁勋，你热爱自己的工作吗？” 我会告诉他们，我并非每天都热爱这份工作，但我每天都会全力以赴去做好它。我觉得，这种态度源于两个方面：第一，我坚信自己是这份工作的最佳人选；第二，我必须每天都努力，才能配得上 “最佳人选” 这个身份。 Jodi Shelton：在大家眼里，你就是英伟达的代名词，英伟达就是你。这么多年下来，你已经和这家公司深度绑定了。 黄仁勋：我应该是英伟达内部被拍照最多的人吧。 Jodi Shelton：没错。不过，要是将来换了新的 CEO，这个人真的能接好你的班吗？ 黄仁勋：世界上不会再出现第二个我这样的 CEO 了。原因很简单，我是被这家公司一步步培养起来的。刚创立英伟达的时候，我对怎么当 CEO、怎么做战略规划、怎么打造产品、怎么开创一个全新的行业，一窍不通。我只知道怎么融资，却不懂怎么和股东沟通，不了解股东、政策制定者、各国领导人以及企业管理者的想法，也不知道该如何把握员工的心态、如何打造企业文化，甚至连 “企业文化” 这个词到底意味着什么，我都无法准确界定，让我制定公司战略那更是天方夜谭。这就是我第一天接手工作时的真实状态。而在过去的 33 年里，我在这些领域都一步步做到了得心应手。 如果说这个世界上有谁能称得上是 “企业战略宗师” 或者 “行业开创者”，那这个人大概就是我这样一个小个子。我把自己的整个职业生涯都投入到学习这些能力上，而且我本身就是个好学生。除此之外，我对这份工作的投入程度和深厚感情，是很难通过招聘来复制的。在我心里，英伟达就像我的孩子一样，我对它倾注了全部的心血。我的家人也陪着我一起，为这家公司的成长付出努力。这种对公司的特殊情感，是很难被替代的。毕竟 33 年来，我见证了英伟达的每一次成功、每一次失败、每一次挫折，亲历了它做过的所有明智决策，也目睹了它犯下的各种错误。这种对公司的深刻理解和情感联结，不是随便招一个能力出众的人就能替代的。 不过从另一方面来说，英伟达的管理团队架构其实早就做好了准备。我现在有将近 60 位直接下属，他们中的每一个人，放到其他公司都能胜任世界级 CEO 的职位。我总是当着他们的面推演各种决策逻辑，我的每一个决定，都是在他们的注视下做出的，我会把背后的思考过程原原本本地讲给他们听。公司的每一次成功、每一次挫折、每一个挑战、每一场困境，我都会和他们一起复盘。所以从某种意义上说，英伟达其实有 61 位 “CEO”。他们每个人都对这家公司饱含深情，很多人已经在这里奋斗了 33 年。我认为，英伟达的成长模式是独一无二的，这也造就了它无可比拟的韧性。 Jodi Shelton：显然，你搭建的这套管理架构在行业内已经成了一段传奇，所有人都在谈论你这近 60 位直接下属。要让这样的架构顺畅运转，这些人肯定都得是万里挑一的顶尖人才。 黄仁勋：没错。 Jodi Shelton：他们不光要头脑聪明，毕竟硅谷从来不缺聪明人，更得是适配英伟达的顶尖人才。 黄仁勋：确实如此。 Jodi Shelton：那你能不能跟我说说，你是怎么筛选和培养这些人才的？另外，我记得你有个原则，找不到合适的人，就宁可让职位空着。我想到了 Colette Kress 的例子，你当时面试了 22 位首席财务官候选人，最终才选定了她。现在她在华尔街已经是一位传奇人物了。你当初是怎么选中她的？你选拔这类核心人才的标准是什么？ 黄仁勋：在我看来，宁让职位空着，也不能让不合适的人占着位置，所以我从来不会急于招人。就算 CEO 的位置暂时空缺，或者某个副总裁职位没人接任，公司的运转也不会停滞。只要你坚信这一点，坚信 “空位胜于错配”，你就有足够的时间去寻找那个真正合适的人。这个合适的人选，需要满足很多条件，其中很重要的一点，就是你得发自内心地欣赏他、认可他。 我记得 Colette Kress 入职第一周的时候，就问过我：“黄仁勋，你希望我在首席财务官这个岗位上干多久？” 我告诉她：“只要我们还活着，只要死亡不将我们分开，你就一直干下去。” 因为任何其他答案都是没有意义的。这份工作没有所谓的 “截止日期”，唯一的终点，就是当她觉得英伟达不再适合自己的时候。这个原则不仅适用于 Colette，也适用于我那 60 位直接下属。我愿意为了等待合适的人，让职位空很久。而在这个过程中，公司依然会稳步向前。无论这个空缺的职位对应着什么使命、什么工作，大家都会主动顶上。退一步说，就算没人接手，我也会尽全力扛起这份责任，保证公司正常运转。 这就是我的用人哲学，永远不要让不合适的人占据岗位，耐心等待那个对的人出现。经常有人问我，什么样的员工才算优秀员工，什么样的管理者才算卓越管理者。说来奇怪，我其实没有标准答案。因为能走到我面前的人，都足够聪明、足够能干。你随便找一个首席财务官，我敢保证他绝对胜任本职工作。其他岗位的候选人也是如此。在我看来，英伟达之所以能创造奇迹，关键不在于单个人的能力有多强，而在于团队成员之间的 “化学反应”。更重要的是，这源于我们的企业品格。这种品格，才是一家伟大公司的核心竞争力。市面上有很多公司都在做芯片，虽然是英伟达发明了 GPU，但从产量来看，我们其实是全球最小的 GPU 制造商。 这话听起来可能有点不可思议，但事实就是如此，很多不知名的厂商，GPU 产量都比我们高。很明显，英伟达的成功，绝不是靠产量取胜。我认为，真正的秘诀在于我们独特的企业文化和企业品格、团队在逆境中凝聚在一起的力量。在外人看来，我们似乎总是一帆风顺，但其实研发 Grace Blackwell 芯片的过程，差点拖垮了整个公司。但我们硬是咬牙扛了过来。这个项目的复杂度和规模都是前所未有的，外界对我们的期望也高得离谱。我们最终不仅达标，甚至超出了所有人的预期，而支撑我们做到这一点的，100% 是企业品格。这不是靠智商，也不是靠勤奋就能实现的，毕竟这个世界上，聪明又努力的人太多了。 这种企业品格，是没法通过面试来筛选的。但我始终相信一件事：几乎任何人进入英伟达之后，都会被这种品格所感染、所塑造。这就是我们公司最神奇的地方：我们能够承受挫折，能够直面各种艰巨的挑战，并且一次次从困境中突围。很少有公司的团队能做到这一点。通常来说，当公司遭遇重大挑战后，总会有人因为心存不满离开，或者因为被当成 “背锅侠” 而被解雇。在团队合作中，出了问题总要有人承担责任，这是毋庸置疑的，就像一场球赛输了，我们必须清楚是谁失误丢了球。 在英伟达，我们打造了一个足够安全的环境。过去这些年，包括我在内，很多人都犯过严重的错误，这些失误大家都看在眼里，但从来没有人因为犯错而被解雇。久而久之，英伟达就形成了自己独有的文化和特质。这种文化的核心，就是包容、宽恕，以及从错误中学习。对我来说，有两件事至关重要：只要团队里的每一个人，都为了共同的目标拼尽了全力，这就足够了。敢叫板 20 岁新锐的黄仁勋，也有至暗时刻？Jodi Shelton：刚才聊到 “痛苦与磨砺” 的理念，你可以再深入谈谈吗？我最近听 Andy Karp 在播客里说，“人生的二十几岁，要么用来享乐，要么用来打拼事业”。你认同这个观点吗？当然，不是每个人都能成为帕兰提尔或者英伟达的 CEO，但对年轻人来说，想要在事业上有所成就，到底需要付出什么？你想给年轻人传递怎样的职业与成功之道？ 黄仁勋：Andy 很睿智，总能说出一些深刻的人生哲理。不过我对这类说法，倒没那么执念。我一直很佩服张忠谋先生，他一直工作到 80 多岁，思维依然敏锐得像一把刀。如果要在维基百科里查 “大器晚成” 这个词，配图说不定就是他。能在人生最具创造力的阶段，持续奋斗 50 年，这难道不是一件幸事吗？我自己也倾向于这种人生轨迹。对我而言，投身于有价值的事业，远比用后 20 年的时间环游世界更有意义，当然，环游世界本身也没什么不好，只是我现在就已经在满世界奔波了。 不得不承认，二十几岁的我，确实更聪明、专注力更强、思维速度也更快。但那个年纪的人，往往缺少一样至关重要的东西，阅历沉淀出的智慧、处理复杂问题的分寸感、制定长远战略的眼光，以及长线思维的能力。这些能力，光靠读书是学不来的。现在的年轻人可以刷短视频，通过共情去感受别人的经历，算是一种间接的经验积累，这种模仿式学习确实有价值。但还有一样东西，是无法通过旁观习得的，那就是坚韧的意志，是直面痛苦与挫折时，懂得如何应对的底气；是熬过精神内耗、挺过煎熬时刻、战胜内心恐惧的勇气。 经营公司的过程中，恐惧是真实存在的。我们的决策，关乎数万人的生计。当公司发展不顺时，一个感受不到恐惧、焦虑和脆弱的领导者，反而是不合格的。如果对结果毫不在意，那未免也太冷漠了。而这些真切的感受和应对的能力，只有亲身经历过，才能真正掌握。所以我觉得，两种人生选择没有绝对的对错。年轻时打拼，确实精力充沛，可以熬夜加班，可以付出十倍的努力，更容易早早取得成功。但我现在身上拥有的东西，是三十岁时的我完全不具备的。 如今的我，思维速度虽然慢了，但依靠智慧和经验积累的思维模型，能更快地找到正确答案。就算和二十岁的年轻人同台竞争，我也有信心不输给他。他们未必能胜过现在的我。 Jodi Shelton：那我们来聊点更私人的话题吧。能不能说说你的童年？哪些高光或至暗的经历，对你如今的性格特质产生了直接影响？ 黄仁勋：我从来不觉得自己是天赋异禀的人，智商也算不上出众。小时候入学需要参加考试，我当时的成绩确实很不错，那会儿的考试还是全国性的。我记得母亲总是逢人就说，我是个非常聪明的孩子。不管这话是不是真的，她反复的肯定，无形中给了我一种压力，我必须变得足够聪明。这件事让我意识到，无论是为人父母还是做管理，给身边的人或者整个公司设定一个超出常理的高目标，往往能激发他们的潜能，让他们迎难而上。当然，也有人会被这样的目标吓退，但对我而言，这种激励起到了积极的作用。这是我第一个想到的童年片段。 另一件事，是关于我母亲的。当年我们学习英语的时候，她其实根本不懂英文，而且我觉得她可能连高中都没毕业。但这丝毫没有妨碍她每天教我们学英语。你可能会觉得不可思议，一个完全不懂英语的人，怎么教孩子学英语？她的方法很简单：买一本韦伯斯特词典，照着单词的拼写规律，写下英文单词，再标注上中文释义，把纸对折做成单词卡，然后逼着我们背下来。我们的发音准不准确，她其实也无从判断。但这件事，让我学到了一个道理：一个人只要有足够坚定的意志，就算暂时不知道该怎么做，也不该停下脚步。很多事情，其实并没有想象中那么难。小时候的这段记忆，我一直记到现在。 还有一段经历，是我们搬到肯塔基州之后。我当时是学校里年纪最小的孩子，就读的奥尼塔浸会学院坐落在山顶。每天上学，我都得走下山坡，穿过一条河，再走过一片广阔的田野，才能到达那所小小的学校。那是 1973 年，我是整个镇上第一个出现的中国孩子。镇上的那些孩子都很野，每次我过吊桥的时候，他们都会找我的麻烦。那座吊桥的桥面是木板铺的，有些木板已经缺失了，桥下的河水很深。而那些孩子，就守在桥的另一头等我。那时候我才 9 岁。 Jodi Shelton：天哪，才 9 岁。眼前是一条河，一座破吊桥，桥对面还有等着找麻烦的孩子，这简直太糟糕了。 黄仁勋：是啊，但我每天都得走这条路去上学。这大概就是童年时期的 “痛苦与磨砺” 吧。每天早上都是这样。下午放学回家后，我还有任务：打扫卫生间。那时候家里的每个孩子都有分工，我哥哥当时 11 岁，他的活儿是去烟草农场干活，而我的工作就是打扫卫生间，每天都要做。 Jodi Shelton：你觉得当年那些找你麻烦的孩子，知道你现在的成就吗？ 黄仁勋：奥尼塔浸会学院的校长最近还发邮件给我呢。他们每年都会给我寄圣诞礼物，知道我喜欢吃肯塔基风味的香肠肉汁配饼干。 Jodi Shelton：这个爱好是在肯塔基养成的吧？ 黄仁勋：没错。我记得我 45 岁生日的时候，家人带我回了一趟母校。当年食堂里做饭的阿姨们居然还健在，特意回来给我做了一顿饭。 Jodi Shelton：天哪，这也太暖心了。 黄仁勋：真的特别感动。她们给我做了正宗的肯塔基香肠肉汁配饼干，味道还是小时候的样子。 Jodi Shelton：你的父母见证了你的成功吗？ 黄仁勋：当然，他们现在身体还很好，特别为我骄傲。他们对我的事情了如指掌，我父亲会读所有和我相关的报道。要是看到有人说我的坏话，他还会生气。我总劝他别什么都看，不然天天都得生气，别理会那些负面新闻。 Jodi Shelton：挺有意思的。现在功成名就了，你会怀念那些还没这么受关注的日子吗？会想念那些平凡的小事吗？比如你很爱车，现在却没什么机会开车了吧？我记得你是我认识的人里，第一个也是唯一一个拥有柯尼赛格跑车的人。 黄仁勋：克里斯蒂安・冯・柯尼赛格真是个天才设计师，那辆车太棒了。启动的时候，引擎声和蝙蝠侠的座驾一模一样。而且启动它得按七个步骤，因为动力实在太强劲了，不能随便让别人碰。不过我现在已经没有那辆车了，也确实很少开车了。 Jodi Shelton：会想念开车的感觉吗？ 黄仁勋：有一点吧。我现在还是会关注新车，比如新款的法拉利，每次看到都觉得很惊艳，这些车真的是工程学的杰作。 Jodi Shelton：确实很厉害。我去过法拉利的工厂，亲眼看到一辆车从工业器械一步步变成顶级消费品，现在甚至成了艺术品，这个过程太震撼了。黄仁勋眼中五年后的世界Jodi Shelton：如果五年后我们再坐在这里，你觉得到那时的世界会是什么样子？哪些变化会让我们最惊讶？ 黄仁勋：如果我们回归底层逻辑，再结合现实的实用性和技术落地的规律来判断，有几件事是可以预见的。首先，英伟达和整个行业在 AI 领域的投入，必将彻底改变计算机的运作模式 ，未来的计算机，将从 “由人类编程” 进化为 “在人类引导下自主学习编程”。过去我们是手把手教计算机学日语，未来我们只需要告诉它 “去学日语” 就够了。未来的计算机，将能够处理比现在大十亿倍的问题规模。这个变化的影响之大，我们现在甚至无法完全想象，因为提出解决方案是一回事，而能否构想出需要解决的问题，就是另一回事了。很多问题之所以无法被解决，往往是因为我们连如何定义和描述它们都做不到。 未来，无论是数字生物学、物理科学、量子物理还是材料科学的复杂难题，都会变得容易攻克。就算是交通拥堵这种日常问题，也能得到极大改善。就拿智能电网来说，现在的电网存在大量能源浪费，AI 会精准计算出所需的能源量，实现按需分配，从根本上避免过度供应造成的损耗。AI 解决这些日常难题的能力，会让人惊叹不已。到那时，每一个科学领域都会被重塑，当下所有的难题都会被技术赋能、迎刃而解。工具的速度提升了，难题自然就显得 “渺小” 了。举个例子，如果飞机的速度能达到 10 马赫，整个世界就会变得 “小” 很多， 喷气式飞机的出现，其实已经让世界变小了。 英伟达制造的计算机也是如此，极致的运算速度让所有问题都变得更容易被解决。就像 OpenAI 的研究人员曾经说的：“为什么不把整个互联网的数据都喂给计算机呢？” 因为在算力爆发之后，全球互联网的数据量，突然就显得微不足道了。现在我们看互联网数据，也会觉得体量很小，原因就在这里。这种心态，未来会渗透到几乎所有的科学领域。过去人们会说 “这是个无解的难题”，未来大家只会觉得 “这事儿很简单”。五年后，每一位科学家、工程师、企业家和创新者，都会抱着这样的心态。曾经的难题变得简单，我们就能解决更多的问题。这是第一个必然结果。 第二个结果，就是企业的生产效率会实现质的飞跃。今天的难题变成明天的小事，供应链管理会变得无比顺畅，浪费现象基本消失；计算机的设计流程也会简化，我们可以尝试更多的方案。这并不是说我们会每年推出更多的产品，我们还是保持一年一款的节奏，但每一款产品都会经过更多次的迭代优化，最终呈现的成品会比现在好得多。这样一来，公司的效率会更高，利润会更丰厚，所有企业都会变得更赚钱，整个社会的财富也会随之增长。但还有一个值得深思的点：当所有我们能想到的问题都变得可以解决时，我们就会去探索更多新的问题。 所以，未来的趋势不会是就业岗位减少，反而是大家会变得比现在更忙碌。因为以前那些被认为 “不可能完成” 的任务，现在都摆上了台面；那些因为成本太高而无法开展的实验，现在都可以去尝试，AI 还会帮我们推进这些实验。只要我们有足够的想象力，所有搁置的难题，都会找到解决的路径。我可以做一个思想实验。现在我工作时，身边围绕着 60 位顶尖人才，而他们每个人又带着数千名精英。这些人在各自的领域里，能力都远超于我，对我来说，他们就像是 “领域内的人工超级智能”。但和他们合作，我完全没有障碍。现在我使用的 OpenAI、Gemini、Grok、Perplexity、Anthropic 这些 AI 工具，在很多方面也已经比我聪明了，但我每天都在和它们高效协作。 不过有一个很有意思的变化：以前我给团队布置一个问题，需要等两三天才能得到反馈和答案，这段时间里我可以思考下一步的计划 ，因为我的决策需要基于这些中间结果。但如果这些答案能在一秒钟内就反馈给我，会发生什么？我的工作节奏会变得无比紧凑，因为我会成为所有事情的关键节点。刚得到一个答案，立刻就要推导下一步，马上启动新的实验。你不觉得吗？现在信息技术的提速，已经让我们变得更忙碌了。信息、知识和答案的获取速度越来越快，我们作为决策节点，自然会比以往更忙。我觉得未来很多人都会有这种感受。 最后一点，对于那些没能赶上之前科技浪潮的人来说，AI 会填平技术鸿沟。我特别喜欢 “氛围编程” 这个概念，现在任何人都可以成为软件程序员，借助 AI 写出的代码，甚至比很多专业程序员的作品还要好。我很欣赏 Cursor 这家公司的成果，前几天还见到了 Lovable 的 CEO，他是个很厉害的人，他们的公司在瑞典。AI 会帮助那些在自己的领域很有天赋，但不懂如何用技术放大自身能力的人实现能力的跃迁。Lovable 的 CEO 就跟我说过，很多人用他们开发的软件创办了小公司，现在每年能赚 2300 万美元。这太不可思议了。这些人终于能融入全球经济体系，不再被技术门槛挡住去路，这一切都是 AI 的功劳。 五年后的世界，大家会拥有更有价值的工作，经济效率会大幅提升，GDP 有望实现增长，劳动力短缺的问题会得到缓解，通货膨胀也会回落。更多的科学领域会被开拓，更多的难题会被解决。当然，也有一些悲观的论调，认为 AI 会让一半的人失去工作。但我觉得，更可能发生的情况是：100% 的工作岗位都会发生变化，但不会有 50% 的岗位消失。而且，那些现在没有工作的人，很可能会因为 AI 获得谋生的手段。 当然，我们的技术会发生翻天覆地的变化，但这些技术层面的革新，反而不是最有意思的。五年后，计算机还是计算机，只是应用变得更智能了，本质上还是软件。我们依然会做电商，只是可能不用自己逛网站了，会有智能代理帮我们购物，但商品还是来自亚马逊这些平台。很多事情，其实都会保持原样。最后我还有一个小小的愿望或者说期待：希望我们在机器人和人形机器人领域的研究能结出硕果，希望未来每个人都能拥有属于自己的 R2-D2 和 C-3PO，它们可爱又贴心。就像在 GTC 大会上，我每次都会邀请迪士尼的机器人上台，那些机器人真的太萌了。 为什么不让每个人都拥有一个呢？我还希望迪士尼能把这些机器人做成周边商品，它们真的值得。我的宠物猫莫莫和库玛，也需要这样的 “宠物玩伴” 不是吗？我真心希望这个愿望能实现。现在有很多孤独的人，已经有不少人联系过我，希望能拥有可以在家陪伴自己的机器人，尤其是那些独居的老人。机器人能给他们带来陪伴和帮助，而且它们本身又那么可爱，这绝对是我们技术发展带来的意外之喜。 Jodi Shelton：如果以后有机器人帮我们做饭、打扫卫生，你还会像现在这样，饶有兴致地看着别人做饭吗？ 黄仁勋：当然会。原因很简单，我现在完全有能力不用自己做饭，但我还是会选择下厨。我们完全可以雇很多佣人，但我们没有这么做。我和洛里一直都是两个人自己过日子。昨晚她做了墨西哥辣椒肉酱，味道棒极了，全程都是她一个人忙活的。以后我们大概率还会保持这样的生活。对我来说，最幸福的时刻，就是孩子们回家来，我们一起下厨做饭，喝喝小酒，这就是最完美的时光。 Jodi Shelton：一家人在厨房里忙活，这种亲密感真的太美好了。 黄仁勋：是啊，人生的幸福莫过于此。我们打拼奋斗，不就是为了这样的时刻吗？“不爱演讲的黄仁勋”：CEO 是公司里最脆弱的一群人Jodi Shelton：当一切尘埃落定，你希望后人如何记住你？ 黄仁勋：首先，能被人记住，本身就是一件很幸运的事。我很庆幸，凭借英伟达的成就，凭借我们打造的事业，凭借我们在全球最重要的科技产业：人类最核心的工具 “计算机” 领域留下的印记，英伟达很可能会在我离开这个世界很久之后，依然对这个世界有着重要的意义。我很庆幸自己能和克里斯、柯蒂斯一起创立这家公司，很庆幸自己能一路学习成长，没有成为拖垮公司的那个短板，反而常常是推动公司走下去的一份力量。我们打造的这家企业，对整个世界都有着深远的影响，而不只是局限于某个行业或某个群体。 能做到这一点的人，在这个世界上并不多。我很庆幸自己作为创始人，能亲身参与并见证这一切，见证英伟达成长为如今的模样，见证它对全球各行各业产生实实在在的影响。公司里有很多已经工作了 33 年的老员工，他们的人生因为英伟达变得更加丰盈；现在甚至已经有第二代、第三代员工加入我们。我们在全球各地建立了自己的团队，我很荣幸能和这些员工并肩作战，分享他们一路走来的绝望与喜悦、希望与悲伤。这样的经历，并不是每个人都能拥有的。我为我们在中国的团队感到骄傲，为我们在印度的员工们由衷赞叹，也为欧洲、加拿大的团队感到欣慰。我们在加拿大的团队正在不断壮大。 我还希望有朝一日，英伟达能把业务拓展到南半球，让更多地区的人们，也能享受到我们今天所拥有的技术成果。昨天我还和人聊起我们在非洲开展的工作，聊到我们应该在拉美和东南亚投入更多精力。我真的为我们公司带来的这些影响感到自豪。所以，人们会怎么记住我？或许，他们会记得我是英伟达的创始人之一，是这家公司的缔造者之一。或许，还会记得我是个好人。 Jodi Shelton：这是毋庸置疑的。 黄仁勋：他们或许还会觉得，我是个风趣幽默的人，不喜欢端着架子。其实在很多方面，我都算是一个 “不情愿的 CEO”。比起待在公司外面抛头露面，我更喜欢扎根在公司内部；比起发表演讲，我更喜欢安静做事；我甚至一点都不喜欢做主题演讲，但为了公司，我必须去做这些事。我确实是个不太情愿的 CEO，但我绝对是个满腔热忱的英伟达建设者。只要是为了公司发展必须做的事，我都会全力以赴。说了这么多，其实我也不知道，人们最终会如何记住我。 Jodi Shelton：我觉得，看到好人获得成功，总是一件令人开心的事。这么多年来，看着你一路打拼，经历起起落落，最终收获成功，我真的由衷地为你高兴。你这一路走来，见过了形形色色的人。 黄仁勋：是啊，真的见过了太多人。我想提醒所有的 CEO，没有人能单枪匹马地成功。 Jodi Shelton：确实如此。 黄仁勋：我们虽然是 CEO，但这个位置总需要有人来坐。如果不是早年大家对我的提携与帮助，比如你一直不遗余力地宣传英伟达还有张忠谋奖带来的认可，这些都对我意义重大。张忠谋奖大概是我人生中获得的第一个真正有分量的奖项，直到今天，它对我来说依然意义非凡。这个奖项以他的名字命名，而且他还亲自参与了评选，这份认可真的让我铭记于心。还有那些和我们合作的企业，他们的慷慨相助，我也一直记在心里。 其实 CEO 这个角色，很多时候都需要寻求帮助。我已经记不清有多少次，我是这样开启一段对话的：“我需要你的帮助。” 很多时候，我是真的需要帮助，而且对方往往是唯一能帮到我的人。一路走来，很多人都慷慨地伸出援手，分享他们的知识，教我做事的方法，帮我解决棘手的难题。这或许才是 CEO 这个角色带给我的真正启示，这个职位远比人们想象的要脆弱得多。 Jodi Shelton：而且还是一个很孤独的职位，对吧？ 黄仁勋：确实可能会感到孤独。但我想说，这种孤独更多是存在于我们的内心世界。当你试图解决一些棘手的难题时，往往需要长时间独自思考，自己跟自己对话。公司发展的每一次转型、每一次跨越，每一次我推动公司自我革新的时刻，我都不知道自己独自思考了多少个小时。在那些时刻，你会真切地感受到孤独。但我们也要明白，其实有很多人都希望我们能成功。就像你之前说的，你很乐意看到我成功，我知道你是真心希望我好，而我也同样希望你能越来越好。从这个角度来说，我们其实并不孤单。 所以说，CEO 这个职业，是一份充满脆弱感的工作。你无法单打独斗完成任何事，很多时候都需要依赖别人的帮助与善意。或许在外界看来，我们是强大的领导者，但实际上，我们可能是公司里最脆弱的一群人。我经常说，我是公司里唯一一个离开别人的帮助就寸步难行的人。我想，大多数 CEO 应该都是如此。这或许就是这份职业带给我们的感悟：CEO 们，远比他们愿意承认的要更加脆弱。不过对我来说，承认这种脆弱，并不是什么难事。“没有终极目标” ，才成就了英伟达？Jodi Shelton：接下来我们用快问快答收尾。你见过的最聪明的人是谁？ 黄仁勋：这个问题我没法回答。我知道大家心里对 “聪明” 的定义，就是智商高、会解决问题、技术能力强。但在我看来，这种能力早已经成了一种 “通用品”。而且我们很快就能证明，AI 处理这类问题是最轻松的，不是吗？举个例子，以前大家都觉得软件编程是最考验智商的工作，结果呢？AI 最先攻克的领域之一就是编程。所以说，“聪明” 的定义，其实和大多数人想的完全不一样。 在我看来，从长远来讲，真正的 “聪明”，是那种兼具技术洞察力与人文同理心的能力，是能够洞察弦外之音、预判未知风险、看透表象背后本质的能力。那些能 “见人所未见” 的人，才是真正的聪明人，他们的价值是无可估量的。这种人能凭借数据、分析、底层逻辑、人生阅历、智慧经验，再加上对他人的感知，敏锐地捕捉到潜在的风险，在问题发生之前就提前规避。我觉得这才是 “聪明”，而且拥有这种能力的人，说不定在学术能力评估测试（SAT）里的分数惨不忍睹。 Jodi Shelton：外界对你有什么误解？ 黄仁勋：这些问题都好犀利啊。首先，我都不知道外界对我有什么印象。 Jodi Shelton：比如，大家觉得你喜欢抛头露面，觉得你是个很棒的演讲者，所以肯定很享受做演讲的过程。但你之前已经说了，事实并非如此。 黄仁勋：对，完全相反。公开演讲简直让我怕得要死。不是说站在台上的那一刻害怕，而是现在，想到两周后在华盛顿举办的 GTC 大会，我就焦虑得不行。不，应该说，我已经焦虑一个月了。这种事总是让我心神不宁，脑子里时时刻刻都想着，压力特别大。公司内部的会议演讲也让我紧张到极致。因为台下坐的都是对我而言最重要的人，从某种程度上说，这是我做过的最重要的演讲。但这种演讲根本没法准备，我要讲的所有内容，其实都能在网上的某个视频里找到，他们完全可以自己去看。 我很讨厌把那些内容重复一遍讲给他们听，因为你绝不会回家对着家人做一场 GTC 主题演讲，对吧？我也不想那样做。演讲内容必须是真诚的、独一无二的、对听众有价值的、有意义的，能给他们带来改变。毕竟我还在领导这家公司，我希望通过演讲达成一定的目标。所以我必须拿出全新的内容，但不到演讲结束的那一刻，我永远不知道最终效果会怎么样。大家都觉得财报发布周我会很紧张，但说实话，我一点感觉都没有。真正让我紧张的，是公司的内部会议演讲。所以外界的这个印象，真的大错特错。 Jodi Shelton：你最受不了的事是什么？ 黄仁勋：在关键时刻，有人不认真听我说话、不理解我的问题，还胡乱回答。尤其是在我们处理非常棘手、非常困难的问题时，我们需要的是事实，是真相。这个时候我提出问题，如果有人答非所问，我会立刻火冒三丈。我实在无法理解，为什么有人意识不到这场会议的重要性？我们正在为一件至关重要的事努力，我们需要尽快找到真相、解决问题。我到现在都想不通这一点，这种情况每次都会激怒我。谁要是想惹我生气，这招百试百灵。 Jodi Shelton：这下我们知道怎么让黄仁勋发火了。 Jodi Shelton：最后一个问题，是最近有人问我的，我特别喜欢这个问题。如果让你回到 20 岁，你是想回到自己当年的那个年代，还是活在当下的 20 岁？ 黄仁勋：我会毫不犹豫地回到自己的那个年代。因为我觉得，我们那一代人的 20 岁，比现在年轻人的 20 岁更快乐。我总觉得，每个人都应该拥有一段 “懵懂无知” 的时光，不必从第一天起就背负着全世界的重担。我坚信这一点，没人能说服我。有时候，“无知” 也是一种快乐，甚至是一种超能力。如果当初我知道创立英伟达是一件 “不可能完成的任务”，那今天的英伟达根本就不会存在。事实就是，创立英伟达这件事，本来就是天方夜谭。但当时的我什么都不懂，所以没人能说服我放弃。 我觉得，乐观的人都这样，你永远没法说服他们 “这件事做不成”。他们就是这么 “无知”，对现实的艰难视而不见，所以才会充满乐观。这难道是坏事吗？现在的年轻人，过早地接触到了太多信息，变得越来越愤世嫉俗。他们并不是天生就这么消极，而是因为看到的东西太多太杂了。其实大可不必如此。人需要培养内心的乐观精神，需要在心里留存一份善意，学会只看到世界美好的一面。我们得锻炼这种能力。我们那一代人，有更多这样的机会。我们 20 岁的时候，就是这样的，乐观得像超人一样，觉得凡事皆有可能。所以，我肯定会选择回到自己的 20 岁。 Jodi Shelton：真是个完美的收尾。无知是福啊。 黄仁勋：没错，无知是福，无知也是一种超能力。任何一个想要开启新征程的人，如果不是因为这份 “无知”，他们一早就会因为觉得事情太难而放弃了。我真的很庆幸，自己当年虽然也算勤奋、也算有一些能力，但那份 “无知” 帮了我大忙。我那时候做任何事都抱着一种心态：“这能有多难？” 结果后来才发现，简直难到超乎想象。你根本没法想象。你看看我今天建立的这一切，如果当初我就知道前路会有这么多艰辛、这么多挫折、这么多失望，把这些困难全都摆在我面前，我绝对不会去做的，绝对不会。所以说，“无知” 真的是一种超能力。 还有一种超能力，就是“没有终极目标”。英伟达就没有什么终极目标。总有人问我：“黄仁勋，你的计划是什么？” 我们没有计划，“活下去” 就是我们的计划。我们对未来的世界有憧憬，我们会畅想技术会如何改变世界，但我们 100% 的计划，就是让公司一直运营下去。以前也有人问我，现在也经常有人问：“黄仁勋，你的人生目标是什么？” 我没有什么人生目标，就是想一直工作，一直有事可做，能和一群优秀的人一起做有意义的事。这就是我的目标。 所以说，从很多方面来讲，“没有终极目标” 这一点，对英伟达的发展真的起到了至关重要的作用。 参考链接：https://www.youtube.com/watch?v=8FOdAc_i_tM
简单易懂的 LLM 相关知识梳理 - ep3-3 认识 NVIDIA 驱动、CUDA、Pytorch
目录帖：简单易懂的 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 Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 NVIDIA GeForce RTX 4090 On | 00000000:81:00.0 Off | Off | | 67% 25C P8 20W / 300W | 1MiB / 49140MiB | 0% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ | 1 NVIDIA GeForce RTX 4090 On | 00000000:82:00.0 Off | Off | | 30% 25C P8 22W / 300W | 1MiB / 49140MiB | 0% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ | 2 NVIDIA GeForce RTX 4090 On | 00000000:C1:00.0 Off | Off | | 30% 28C P8 25W / 300W | 1MiB / 49140MiB | 0% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ | 3 NVIDIA GeForce RTX 4090 On | 00000000:C2:00.0 Off | Off | | 30% 27C P8 17W / 300W | 1MiB / 49140MiB | 0% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ +-----------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=========================================================================================| | No running processes found | +-----------------------------------------------------------------------------------------+ 先从回显的第一行看起。这里可以看到我们安装了 580.95.05 版本的驱动。那么这个 CUDA Version 是怎么回事呢？即使没装过 CUDA ToolKit，这里其实也会显示一个版本号的。这是因为驱动程序里有一个动态链接库 libcuda.so，它决定了当前版本的驱动能够支持的最高 CUDA 版本。然后看一下每列的内容：GPU / Fan：显卡序号（从 0 开始）、显卡风扇转速（以百分比计）Name / Temp：显卡名、当前核心温度Perf：性能状态（Performance State），P8 = 休眠模式；P2 = 高性能模式；P0 = 最大性能模式（一般 CUDA 计算都是在 P2 上）Persistence-M / Pwr：持久化模式状态、功耗监控。持久化会在下面讲到。功耗监控列的格式为：当前功耗 / 最大功率（可以自己调整）Bus ID：PCI 总线地址。这里可以和 lspci | grep -i vga 的回显对应上Disp.A：Display Activate，显示输出激活状态。由于这些卡都没有连接显示器，所以目前都是 OffMemory Usage：显存占用。喜闻乐见的核心指标，格式为：当前使用显存 / 总显存GPU Util：GPU 核心使用率Volatile Uncorr. ECC：ECC 开启状态。我没开，开了少 3G 显存，太致命了Compute M.：计算模式（Compute Mode），分为 Default（默认）、Exclusive_Process（独占进程）、Prohibited（禁止计算）MIG M.：多实例 GPU 模式（Multi Instance GPU Mode），高贵的数据中心卡才有，可以在硬件层面上把 GPU 切分最后一行表格是当前活动进程。在这里可以看到使用了 GPU 的进程状态。持久化在 Windows 上，系统启动时内核模式驱动就会被加载并一直保持加载状态，天生就带着持久化的特性，所以通常情况下不用管。但在 Linux 中（尤其是无头机），因为没有客户端一直维护 GPU 句柄，所以每次目标 GPU 上有程序启动和停止时，内核模式驱动都会初始化和取消初始化目标 GPU。这无疑是一种资源上的浪费。最要命的是，在实践中，这个现象还会经常导致莫名其妙的 bug。你都准备跑 AI 计算了，还缺那点电费吗？持久化走起！如无意外，每个 Linux 用户都应该开启持久化功能：nvidia-smi -pm 1检查 GPU 拓扑当你连接了 NVLink 后，可以使用如下命令来查看 NVLink 连接状态：(base) root@gpu-a6000:~# nvidia-smi topo -m GPU0 GPU1 GPU2 GPU3 CPU Affinity NUMA Affinity GPU NUMA ID GPU0 X NV4 SYS SYS 48-63,112-127 3 N/A GPU1 NV4 X SYS SYS 32-47,96-111 2 N/A GPU2 SYS SYS X NV4 16-31,80-95 1 N/A GPU3 SYS SYS NV4 X 0-15,64-79 0 N/A Legend: X = Self SYS = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI) NODE = Connection traversing PCIe as well as the interconnect between PCIe Host Bridges within a NUMA node PHB = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU) PXB = Connection traversing multiple PCIe bridges (without traversing the PCIe Host Bridge) PIX = Connection traversing at most a single PCIe bridge NV#= Connection traversing a bonded set of # NVLinks 如上表格所示：这个系统里有 4 张卡，NVLink 两两一组，GPU0/1 一对，GPU2/3 一对。从 0/1 到 2/3 就要走 CPU PCIE 了。至于 CPU/NUMA 亲和性在此处不再展开讲述，如果你使用多路 Xeon 或 AMD Epyc 则可能需要注意一下调节 NPS 以优化 NCCL 性能。CUDA如果你是一个拥有很大固态和很快网络的 Docker 战神，那我的建议是不要在宿主机里装任何 CUDA，一切交给 Docker。一般地，建议使用：nvidia/cuda - Docker Image但是，如果你需要编译一些源码或者坚持古法环境配置，那么就需要在官网下载.run 文件去安装 CUDA 了。有几点需要注意：对于新安装的系统来说，安装 CUDA 前尽可能地补全环境，避免安装失败。CUDA 最好一口气装好，不然清理环境非常头疼：sudo apt-get install zlib1g -y sudo add-apt-repository ppa:ubuntu-toolchain-r/test sudo apt update sudo apt install gcc-11 g++-11 -y sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-11 60 --slave /usr/bin/g++ g++ /usr/bin/g++-11 sudo apt-get install build-essential libgomp1 -y 非常重要：安装时记得取消掉驱动安装。CUDA 工具包里会带一个驱动，不要用！如果你已经装好驱动了，再把这玩意带上，装完了必炸安装结束后，记得检查环境变量（以 CUDA 12.6 为例）：vi ~/.bashrc 尾部追加： export PATH=/usr/local/cuda-12.6/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda-12.6/lib64:/usr/local/cuda-12.6/extras/CUPTI/lib64:/usr/local/cuda-12.6/targets/x86_64-linux/lib:/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH export CUDA_HOME=/usr/local/cuda-12.6 执行： source ~/.bashrc 执行命令以检查 CUDA 环境是否都已正确配置：(base) root@ubuntu:~# nvcc --version nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2024 NVIDIA Corporation Built on Tue_Oct_29_23:50:19_PDT_2024 Cuda compilation tools, release 12.6, V12.6.85 Build cuda_12.6.r12.6/compiler.35059454_0 Pytorch安装 Pytorch 有许多讲究。首先，你应该使用 uv 或 conda 创建一个靠谱的虚拟环境，任何操作都需要在虚拟环境里执行。访问：https://pytorch.org/get-started/locally/，查看当前 Stable 版本的 Pytorch 安装命令。Pytorch 依赖许多特定环境：如 CUDA 版本、Python 版本、C++ 版本等，所以通常官网会列出 3 个主力 CUDA 版本对应的 Pytorch 安装命令。那么，假如你在使用特定版本的 CUDA 或需要安装特定版本的 Pytorch，如何确定有可用的 whl 呢？检查可用 whlPytorch 官方构建：https://download.pytorch.org/whl/cuXXX/torch XXX 代表 CUDA 版本，以三位数表示。比如 CUDA 11.8 就是 cu118，CUDA 12.6 就是 cu126。截至本文动笔的时间，Pytorch Stable 版本是 2.9.1，官网默认列出的版本是 CUDA 12.6 / 12.8 / 13.0。假如我创建了一个 Python 3.11 的环境并且宿主机的 CUDA 版本为 12.4，应该如何确定 whl 是否存在（可以直接安装）呢？按照以上信息，我们访问：https://download.pytorch.org/whl/cu124/torch/ 很遗憾！我们看到了，最新的也就只有 2.6 版本：torch-2.6.0+cu124-cp310-cp310-linux_x86_64.whl torch-2.6.0+cu124-cp310-cp310-win_amd64.whl torch-2.6.0+cu124-cp311-cp311-linux_x86_64.whl torch-2.6.0+cu124-cp311-cp311-win_amd64.whl torch-2.6.0+cu124-cp312-cp312-linux_x86_64.whl torch-2.6.0+cu124-cp312-cp312-win_amd64.whl torch-2.6.0+cu124-cp313-cp313-linux_x86_64.whl torch-2.6.0+cu124-cp313-cp313-win_amd64.whl torch-2.6.0+cu124-cp313-cp313t-linux_x86_64.whl torch-2.6.0+cu124-cp39-cp39-linux_x86_64.whl torch-2.6.0+cu124-cp39-cp39-win_amd64.whl 正式版的版本太老，看看 nightly 会不会好些，访问：https://download.pytorch.org/whl/nightly/cu124/torch/ 好多了，有 2.7 版本的每夜构建。如果你只是一个小白用户，那在坚守 CUDA 12.4 的情况下也就只有 Pytorch 2.7 可用了：torch-2.7.0.dev20250310+cu124-cp310-cp310-manylinux_2_28_x86_64.whl torch-2.7.0.dev20250310+cu124-cp310-cp310-win_amd64.whl torch-2.7.0.dev20250310+cu124-cp311-cp311-manylinux_2_28_x86_64.whl torch-2.7.0.dev20250310+cu124-cp311-cp311-win_amd64.whl torch-2.7.0.dev20250310+cu124-cp312-cp312-manylinux_2_28_x86_64.whl torch-2.7.0.dev20250310+cu124-cp312-cp312-win_amd64.whl torch-2.7.0.dev20250310+cu124-cp313-cp313-manylinux_2_28_x86_64.whl torch-2.7.0.dev20250310+cu124-cp313-cp313-win_amd64.whl torch-2.7.0.dev20250310+cu124-cp313-cp313t-manylinux_2_28_x86_64.whl torch-2.7.0.dev20250310+cu124-cp313-cp313t-win_amd64.whl torch-2.7.0.dev20250310+cu124-cp39-cp39-manylinux_2_28_x86_64.whl torch-2.7.0.dev20250310+cu124-cp39-cp39-win_amd64.whl 指定镜像及安装特定版本现在我们确定了最新的 whl 了，但显然直接从官方源下载太慢。比如，我是 CUDA 12.6 用户，虚拟环境里用的 Python 3.11，想要安装 Pytorch 2.9.1（当前的 stable），官方给出的命令是：pip3 install torch torchvision --index-url https://download.pytorch.org/whl/cu126 这里推荐使用南京大学的镜像，更新比较及时：pip3 install torch torchvision --index-url https://mirrors.nju.edu.cn/pytorch/whl/cu126 实际上，这等价于安装了如下 whl（以 torch 包举例）：torch-2.9.1+cu126-cp311-cp311-manylinux_2_28_x86_64.whl 可以看到 whl 的命名规则：包版本+CUDA版本-Python版本-对应系统_系统架构那么，假如我想要安装 Pytorch 2.8.0 呢？那么就应该注意一下版本对应关系。torch 和 torchaudio 的版本号是直接对应的，而 torchvision 则可能需要查一下。当 Pytorch 2.1.0 时，包版本如下：torch==2.1.0torchaudio==2.1.0torchvideo==0.16.0torchtext==0.16.0从 Pytorch 2.4.0 开始，没有 torchtext 包了。包版本如下：torch==2.4.0torchaudio==2.4.0torchvideo==0.19.0可以看到，它们都是递增关系。那么很容易推出来 Pytorch 2.8.0 需要的安装命令：pip3 install torch==2.8.0 torchvision==0.23.0 torchaudio==2.8.0 --index-url https://mirrors.nju.edu.cn/pytorch/whl/cu126 注：Pytorch 2.9.0 的 Conv3d 有问题，如果你部署 / 微调 Qwen3VL 的时候发现明显的性能降级，则应将版本回退到 2.8 或升级至 2.9.1（最好是退到 2.8）📌 转载信息来源： https://linux.do/t/topic/1446261原作者： flymyd转载时间： 2026/1/14 18:25:02
过去几年里，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 的云原生场景不适用，而且也无法灵活配置显存和算力。NVIDIA MPS 主要是针对并发执行效率问题，它允许多个进程共享 GPU 执行上下文，在吞吐型场景中成效明显，然而不提供资源隔离的相关能力。单个任务对显存或算力的异常占用，还是有可能影响别的任务，生产环境里面临故障传播的风险。随着硬件能力的演进，MIG 被看作相对更贴近硬件层的共享方案，MIG 可从物理层面实现对 GPU 的切分，在隔离性方面具有优势，然而其切分规格是既定的，还依赖特定 GPU 型号，同时也不支持显存及算力的灵活配置。整体来看，这些方案都在不同指标上进行了取舍。在真实生产环境中，一旦负载情况复杂或任务出现异常，这些方案的局限便会迅速暴露出来。也正因为如此，当用户态和外围机制逐渐难以满足要求，行业开始将探索方向转向更底层。内核态 GPU 虚拟化技术解析GPU 调度的复杂性决定了真正的资源控制点，不在框架层，而是在驱动和内核层。与用户态方案相比，内核态技术不依靠特定框架或 CUDA Runtime，对上层业务基本没有影响。应用无需对代码做出修改就能得到更细粒度的资源控制能力。同时，算力与显存的限制在驱动层可以强制执行，从工程方面明显降低了任务的彼此干扰，也为故障隔离提供了基础条件。腾讯云 TencentOS qGPU 正是按照这一逻辑进行实践的，其技术路径选用以内核态 GPU 虚拟化作为切入点，在驱动层实现算力跟显存的精细切分，再引入故障隔离相关机制，防止单一任务异常波及整卡的稳定。 在此基础上，qGPU 把这些被分割的 GPU 资源纳入云原生调度体系，让 GPU 成为可让调度系统理解的细粒度资源单元。 在 ResNet50 推理测试中，qGPU 在多 Pod 场景下实现了严格的算力隔离，实际性能与预设配比有着高度一致性。不同切分规格下，各 Pod 性能累加与原生 GPU 基本一致，整体性能损耗几乎可以忽略。从资源切分到在离线混部，决定 GPU 利用率上限的关键当 GPU 资源能够被稳定切分，一个新挑战随之出现：这些 GPU 资源是否真的能持续、高效地被利用起来？在生产环境里，这更多依赖调度策略的安排，而非切分粒度自身。很多情况下，GPU 无法共享并非是技术上不可行，而是缺乏合适的调度策略。在离线混部成为 GPU 利用率提升的关键在实际业务中，在线推理与离线任务的需求差别极为明显，在线推理围绕用户请求开展，对延迟、稳定性有严格的要求。离线任务则更看重整体吞吐与执行成本，对完成时间的要求相对没那么严格。从时间角度看，这两类负载一般情况下并不同步。在线服务有明显的流量波动，而离线任务可在空闲时段执行。如果能实现混部，离线任务就可以填补在线业务所剩的空闲算力，进而大幅提升 GPU 的整体使用效率。GPU 混部的工程难点GPU 混部的难点，首先表现在调度控制上。在线业务负载突然上升时，系统得及时把算力资源回收，待到负载下降后恢复离线任务，这对抢占时机及恢复机制提出了较高要求。其次是业务优先级方面的问题。处于混部的场景中，不同任务就性能抖动的容忍度差异明显。若缺少清晰、可执行的优先级机制，混部极易影响到在线服务的稳定性。更现实的挑战来自 GPU 本身。GPU 做上下文切换的成本偏高，显存状态复杂，任务执行期间往往伴随着大量中间数据。要是资源边界的界定模糊，混部非但不能让利用率有所提升，反倒有概率引入新的未知变数。这就是许多团队对于 GPU 混部保持谨慎的原因。qGPU 在这一阶段解决的问题处于这一阶段，qGPU 关注的重点不再只是资源切分，而是怎样在稳定隔离的状况下支持混部运行。借助在底层构建明确的资源边界，在线任务跟离线任务可在同一张 GPU 上并行着运行，同时避免相互间的干扰。更关键的一点是，qGPU 让 GPU 成为调度系统可理解和管理的资源。GPU 不再被固定绑定到某个应用，而是可以依照业务优先级及负载变化做动态分配。这让 GPU 利用率提升不再依靠人工调试，转而成为系统层面的长期能力。当 GPU 能够被切分、被调度、被混合使用，资源利用率才具备持续提升的可能。这同样为 GPU 共享在更大规模生产环境里落地奠定了基础。跨行业实践：当 GPU 共享走向生产可用当 GPU 共享真正拥有稳定隔离以及统一调度能力后，其价值开始在各行各业的业务中逐步被验证。1. 金融行业：在强稳定性约束下释放闲置算力金融行业里，GPU 主要用在 OCR、NLP 推理以及部分实时分析的场景中， 这类业务对稳定性跟隔离性的要求极高。长久以来普遍采取整卡独占的方式去运行，造成大量算力处在闲置状态。结合腾讯云 TencentOS qGPU 的实践经验，一旦 GPU 能在底层实现算力与显存的硬隔离，多个推理任务便可在同一块 GPU 上并行运行，而不会彼此干扰。在业务负载稳定的前提下，GPU 平均利用水平显著上升。此外，由于隔离边界清晰，单一任务的异常状况不再干扰整卡的运行，这让金融生产环境中的 GPU 共享具备了可接受的风险水平。2. 互联网企业 OCR 场景：从独占低效到规模化共享在 OCR 场景里，GPU 出现低利用率问题格外典型。OCR 推理任务一般计算密度不大，单模型在 GPU 上难以形成持续不断的高负载。某头部互联网企业在引入 GPU 共享前，在线 OCR 业务大多采用 GPU 独占式部署，单张 GPU 的利用率长期低于 40%，但业务侧不敢合并部署，原因就在于不同任务之间缺乏有效的隔离手段，要是出现异常，往往会让整卡的稳定性受到影响。在引入基于内核态虚拟化的 qGPU 方案后，该企业把原本独占的 GPU 资源整合进统一的容器调度体系。GPU 被切分成更细粒度的逻辑资源单元，还在算力及显存方面构建明确的隔离边界。多个 OCR 推理服务得以在同一张 GPU 上并行运行，无需对原有应用代码进行修改。从运行的实际效果看，业务部署密度提高了 1 - 3 倍，GPU 能同步承载更多推理实例，以往无法利用的碎片算力被填满。在 GPU 总规模维持原状的前提下，整体 GPU 利用率提升了约 100%，年化 TCO 成本节约超 50%。3. 在线教育场景：在成本压力下实现在离线混部在线教育平台一般会同时运行几十种模型、20 余个 AI 推理服务，每个模型负载较低，不过数量众多，GPU 显存及算力长期无法充分消耗。就传统方案而言，MPS 或用户态拦截机制不易实现可靠的故障隔离，难以支撑大规模生产使用。通过 qGPU 的方案，该平台把 GPU 资源池化，且依据业务优先级调度：在线推理服务拿到稳定算力的保障，离线任务在空闲时段自动填充剩余资源，实现在离线混部运行。从实际落地效果看，GPU 资源部署密度提升了 3 倍以上，月 TCO 成本下降约 40%，整体的推理效率提升约 30%，业务侧基本无感，不必替换 CUDA 库，也无需修改模型代码。写在最后在可预见的未来，GPU 的稀缺不会很快结束。价格高、供应受限，依旧是多数团队躲不过的现实情况，持续单纯借助堆卡，只会让成本压力不断扩大，没办法从根本上解决问题。与此同时，GPU 的角色正在变化，它不再仅仅是一个性能更强的计算设备，而是渐渐转化为需要长期管理的基础设施资源。随着推理及在线服务成为主流负载，独占式使用方式难以与新的业务形态相适配。真正的难点不在于有没有 GPU 共享方案，而在于这些方案是否具备工程可用性。只有在 GPU 可被稳定切分、被调度系统理解，且在不同业务之间能够安全复用，算力才可实现持续利用。只有当 GPU 像 CPU 那样实现被治理，而不是被抢占，算力紧张的问题，才有可能在结构上获得缓解。