摘要：简单来说：不是的。虽然 DeepSeek 的 V3 模型通过一些非常厉害的优化技术，让 GPU 的使用效率变得更高了，但这并不意味着像 Google、OpenAI、Meta 和 xAI 这些公司之前花大钱搞的大规模 GPU 集群就没用了。AI 开发者的普遍看法
DeepSeek 的出现是否意味着前沿 LLM 开发不再需要大规模 GPU 集群？
简单来说：不是的。虽然 DeepSeek 的 V3 模型通过一些非常厉害的优化技术，让 GPU 的使用效率变得更高了，但这并不意味着像 Google、OpenAI、Meta 和 xAI 这些公司之前花大钱搞的大规模 GPU 集群就没用了。AI 开发者的普遍看法是，大规模 GPU 集群仍然是训练顶尖 AI 模型的关键。
DeepSeek 做了什么？
DeepSeek 的 V3 模型通过一些“底层魔法”级别的优化，把 GPU 的性能榨干到了极限。
DeepSeek V3是一个低级别的（low level）技术，适用于需要高性能计算的场景。
它通过使用GPU来加速处理，特别是对于需要大量并行计算的任务。
DeepSeek在用NVIDIA的 H800 GPU 训练 V3 时，对 GPU 的核心计算单元（SM，流多处理器）进行了定制化调整：DeepSeek V3利用了NVIDIA的H800 GPU，该GPU具有132个SM（Streaming Multiprocessor），每个SM有20个SMG（Streaming Multiprocessor Group）。
具体来说，他们把 132 个 SM 中的 20 个专门用来处理服务器之间的通信任务，而不是计算任务。
这种调整是在 PTX（并行线程执行）级别进行的，PTX 是一种接近汇编语言的低级指令集，可以让开发者对 GPU 进行非常细致的控制，比如调整寄存器的分配和线程的运行方式。
PTX（Parallel Thread Execution）：
PTX是一种用于GPU的中间表示（IR），它允许开发者编写可以在不同GPU架构上运行的代码。PTX代码在运行时会被编译成特定GPU架构的机器码，从而实现高效的执行。DeepSeek V3利用PTX来优化代码执行，提高性能。
PTX这种级别的优化非常复杂，通常大家会用更高级的编程语言（比如 CUDA）来写 GPU 程序，这样更容易维护，也能满足大多数任务的需求。但 DeepSeek 为了把 GPU 的性能用到极限，直接用了 PTX 这种底层工具，这需要超强的工程能力。
CUDA编程模型：
GPU资源管理：
DeepSeek V3通过优化GPU资源的使用来提高性能，包括内存管理和线程调度。它还支持动态调整GPU资源的使用，以适应不同的计算需求。
总的来说，DeepSeek V3是一个高性能的计算框架，它通过利用GPU的并行计算能力和优化资源管理来提高计算效率。
DeepSeek V3和它在H800 GPU上自定义SM（Streaming Multiprocessor，流式多处理器）的优化过程：
首先，PTX是NVIDIA推出的一种中间代码，可以看作是GPU的“高级汇编语言”。我们通常写的CUDA代码会被编译成PTX，然后再转换成GPU可以直接执行的机器码（SASS）。直接用PTX编程可以让我们更精细地控制GPU的资源，比如寄存器的使用和线程的调度，但这也比用CUDA编程要复杂一些。
DeepSeek V3在H800 GPU上做了一些特别的优化。H800 GPU有132个SM，DeepSeek V3分配了其中的20个专门用于服务器之间的通信任务。这里的关键是，SM通常是用于计算任务的，比如进行大量的数学运算。而DeepSeek V3却用一部分SM来做通信任务，这听起来有点不寻常。
那么，DeepSeek V3是怎么做到的呢？
他们通过编写特定的PTX代码来精确控制线程如何在SM上分配，这样可以更有效地管理通信任务。但是，通常情况下，我们不会在CUDA中明确指定任务运行在哪个SM上，这是由GPU的硬件调度程序来决定的。除非使用一些高级技术，比如MPS（多进程服务）或MIG（多实例GPU），但这通常是在更高层次上进行GPU资源的划分。
DeepSeek V3可能通过编写特定的PTX代码，使得在SM上运行的内核可以处理通信任务。例如，他们可能不使用标准的NCCL库来进行通信，而是自己编写内核（用PTX编写）来管理服务器之间的数据传输。这些内核会在特定的SM上运行，从而实际上“专用”了一部分SM来运行通信内核，而不是计算内核。
这样，132个SM中，20个始终忙于通信相关的内核，剩下的112个用于计算。这听起来很有道理，但如何确保这20个SM专门用于通信呢？可能通过精心的调度，比如启动占用这些SM的持久通信内核，并在其余的SM上启动计算内核。但在CUDA中，SM之间的工作分配是由硬件调度程序管理的，除非有办法对GPU进行分区，但这并不是标准的做法。
另一种可能是，DeepSeek V3通过优化PTX代码，使得通信内核非常高效，以至于可以用更少的SM处理更多的通信任务，从而释放更多的SM用于计算。但原文说他们专门为通信分配了20个SM，这意味着这些SM被保留了下来。
也许他们将GPU分成了两个区域：一个用于计算，一个用于通信。使用MIG可以将GPU划分为多个实例，但MIG更多是为不同的作业或用户划分资源，而不是专门用于计算与通信。即使他们使用了MIG，原文也提到了PTX级别的定制，所以这可能是通过内核设计进行的软件分区。
或者，他们可能已经设计了计算和通信内核，使得通信内核经过优化以在SM的子集上运行。例如，通过启动网格大小占用20个SM的通信内核，并在剩余的SM上启动计算内核。但是，如何确保计算内核不使用这20个SM呢？除非有办法设置亲和性，但这并不是CUDA/PTX的标准。
也许通过并发限制，如果通信内核是持久的并且始终在那20个SM上运行，那么计算内核将仅使用剩余的SM。但CUDA的调度程序仍可能将计算内核分配给所有SM。因此，这种方法可能需要非常仔细地协调内核启动和资源分配。
或者，使用CUDA流和优先级，通信内核的高优先级流可以抢占低优先级计算内核，从而确保通信内核获得所需的SM。但同样，这并不是专门保留SM；它只是优先考虑。
这里的关键点在于是否可以通过PTX为特定任务分配特定SM：
据我所知，CUDA和PTX不提供明确的控制来将线程块固定到特定SM。硬件调度程序动态地将线程块分配给SM。因此，除非有办法构造内核，使其线程块仅在某些SM上运行（我认为这是不可能的），否则这可能有点误导。
但也许DeepSeek找到了一种构造其代码的方法，以便通信相关内核的设计方式可以有效地使用SM子集，也许是通过控制线程块的数量及其分布。例如，如果启动通信内核时恰好有足够的线程块来占用20个SM，并且这些内核持续运行，那么这些SM将忙于通信任务，而其余SM将处理计算。但这更像是一种软件调度技巧，而不是硬件级分配。
在PTX级优化方面，他们可能已经编写了高度优化的通信内核，使用PTX指令更有效地管理数据移动、寄存器使用和warp调度。例如，使用异步数据传输、重叠计算和通信，或最小化寄存器压力以允许更多并发线程。
另一个方面是使用TensorCores。如果通信任务涉及可以利用Tensor Cores的某些类型的计算，优化PTX以更有效地使用这些单元可能会有所帮助。但原文是关于服务器到服务器通信的，这更多地是关于数据传输而不是计算。
也许他们正在使用GPUDirect RDMA（远程直接内存访问），它允许通过网络在GPU之间直接传输数据，而无需CPU。这将使用NIC（网络接口卡）和GPU的DMA引擎。
但是，GPUDirect RDMA通常使用PCIe总线和NIC，而不是SM。那么SM在这里如何发挥作用呢？也许他们有准备传输数据的内核，比如将数据打包到缓冲区、管理标头或加密。
这些任务将在SM上运行。通过在PTX级别优化这些内核，它们可以使数据准备更加高效，从而减少通信开销。为这些任务分配20个SM意味着这些SM专用于运行这些数据准备内核，其余的则专注于主要计算。
因此，总而言之，步骤可能涉及：
确定可以卸载到GPU的通信相关任务（例如，传输的数据预处理）。为这些任务编写高度优化的PTX内核，确保最小开销和最大吞吐量。设计内核启动，使这些通信内核在SM的子集上运行，可能通过控制线程块的数量及其分布来实现。平衡工作负载，使通信内核不会干扰计算内核，可能通过流优先级或持久内核技术来实现。优化PTX中的寄存器使用和线程/warp调度，使通信内核尽可能高效，从而允许它们用更少的资源处理更多数据。
为什么大规模 GPU 集群还是很重要？
虽然 DeepSeek 的优化技术很厉害，但它更多是让现有的 GPU 资源用得更高效，而不是完全取代大规模 GPU 集群。
训练顶尖的 AI 模型仍然需要大量的计算资源，尤其是在处理超大规模数据和复杂任务时。
DeepSeek 的技术更像是一种“锦上添花”，而不是“替代品”。
来源：解道Jdon