为什么 AI 看起来是 Python 的天下，底层却离不开 C++？

如果你看看现在的 AI 开发，很容易产生一种感觉：整个行业似乎已经变成了 Python 的生态。

研究人员用 Python 编写模型。 教程使用 Python。 大多数 machine learning framework 都提供 Python API。 AI 开发者通过 pip 安装软件包，写几行 Python，就可以快速训练或运行一个复杂的模型。

于是，一个自然的问题出现了：

如果 Python 已经成为 AI 的主流语言，为什么 AI 技术栈仍然如此依赖 C 和 C++？

把 AI 系统拆成不同层次之后，答案就清楚多了。

Python 通常是开发者用来描述自己想做什么的语言。

C++ 和 native libraries 则经常负责实际的高性能计算。

Python 是接口，不一定负责计算

来看一个简单的 PyTorch 程序：

import torch
x = torch.randn(1024, 1024)
y = torch.randn(1024, 1024)
z = x @ y

代码是 Python，但矩阵乘法并不是由 Python interpreter 一个元素一个元素地执行。

Python 层提供了一个方便的接口。在这个接口下面，PyTorch 有一个庞大的 native 实现，负责 tensor operations、memory management、automatic differentiation、CPU execution、GPU execution，以及其他基础能力。

PyTorch 自己也说明，它的 Python frontend 建立在一个庞大的 C++ codebase 之上。它的 C++ API 包括 ATen、Autograd、C++ Frontend、TorchScript 和 C++ Extensions 等组件。

其中，ATen 尤其重要，因为它提供了基础的 tensor 和 mathematical operations。

这意味着，当 Python 程序执行一个计算量很大的操作时，真正执行大量数值计算的通常并不是 Python interpreter 本身。

PyTorch 的文档明确说明：Python frontend 几乎所有计算开销较大的操作，尤其是数值运算，都会调用 C++。

这也是 Python 可以在 AI 开发中保持高生产力，而不要求每个 AI 开发者都编写 C++ 的主要原因之一。

为什么不直接全部用 Python 实现？

因为 Python 更注重程序员的生产力和表达能力，而不是用来实现所有底层数值操作。

想象一下矩阵乘法。

一种简单的实现方式，是不断执行 Python 层面的操作，逐个处理元素。Python interpreter、动态对象、reference counting 和 function dispatch 带来的开销很快就会变得明显。

AI 工作负载则完全不同。

一次矩阵乘法可能涉及数百万甚至数十亿次数值运算。

理想的实现应该能够利用 optimized native code、vector instructions、多 CPU threads 或 GPU，对大量数据进行操作。

这就是 native libraries 发挥作用的地方。

AI framework 可以提供一个高级 Python function，而不是让 Python 执行每一个底层操作，再让 optimized native implementation 完成真正的计算。

从概念上看，过程更接近这样：

Python code
    |
    v
AI framework API
    |
    v
C/C++ runtime
    |
    v
optimized CPU kernels / CUDA
    |
    v
CPU or GPU hardware

开发者看到的是 Python。

处理器实际执行的可能是高度优化的 native code。

当然，这里还有一个重要的情况：当一个工作负载包含大量小操作，或者频繁跨越 Python/native 边界时，Python 本身的开销仍然可能成为瓶颈。这也是现代 AI 系统使用 graph compilation、operator fusion 和 CUDA Graphs 等技术来减少 dispatch overhead 的原因之一。

Python 和 C++ 可以一起工作

Python 从设计之初就支持扩展。

CPython 提供了 C API，开发者可以使用 C 或 C++ 实现 extension modules。这些扩展可以引入新的 object types，调用 C libraries 和 system calls，并把性能敏感的功能移到 Python interpreter 之外。

这种机制是整个 Python 生态的重要组成部分。

一个 Python package 并不意味着整个 package 都是用 Python 编写的。

一个 package 可以提供 Python API，同时在内部依赖 native code。

用户可能只需要这样写：

result = library.compute(data)

而底层的实现最终可能执行的是类似这样的过程：

Python
  ↓
Python binding
  ↓
C/C++ function
  ↓
native implementation
  ↓
CPU / GPU

这种设计把两者结合起来。

Python 提供高级、易于使用的编程接口。

C++ 则可以高效地实现性能敏感的组件。

两者之间的边界就成为一个工程接口。

那么 CUDA 在哪里？

对于现代 AI 工作负载来说，CPU 性能只是其中的一部分。

大型 neural networks 会进行大量并行计算，因此 GPU 变得非常重要。

这又引入了另一层：

Python
   ↓
PyTorch / TensorFlow / other framework
   ↓
C/C++ runtime
   ↓
CUDA / GPU libraries
   ↓
GPU kernels
   ↓
GPU hardware

CUDA 提供了使用 NVIDIA GPU 进行通用计算所需要的 programming model 和 software ecosystem。CUDA C++ 在 C++ 的基础上增加了 GPU programming 所需要的功能，因此不应该把 CUDA 理解成一种完全独立于 C++ 的语言。

NVIDIA 还提供了 cuDNN 等高度优化的 libraries，用于 deep learning workloads。

这些 libraries 包含了 neural networks 中常用操作的 optimized implementations。

Python 开发者可能只需要调用一个高级操作：

output = model(input)

但在这个操作的下面，framework 可能会选择合适的 native implementations 和 GPU kernels。

NVIDIA 将 CUDA Python 描述为连接 Python applications 和 CUDA 的方式，通过 APIs 和 bindings 使用 CUDA C/C++ functionality。它的 cuDNN libraries 被用于加速包括 PyTorch 和 TensorFlow 在内的主流 deep learning frameworks。

NVIDIA 之外也存在类似的生态。例如，AMD 提供 ROCm、HIP，以及 rocBLAS 和 MIOpen 等 libraries，用于 GPU computing 和 machine learning workloads。

因此，看起来非常简单的 Python 代码，下面实际上隐藏着一个相当复杂的软件栈。

还有一个编译层

这个结构并不总是简单的“Python 在上面，C++ 在下面”。

现代 AI frameworks 越来越多地包含一个位于高级程序和底层 runtime 之间的 compilation 和 optimization layer。

例如，PyTorch 提供了 torch.compile，它的 compilation stack 可以分析和转换用 Python 定义的 models，并通过 TorchInductor 等组件生成 optimized code。

其他生态也使用 XLA 或 TVM 等技术进行 graph compilation、operator fusion 和 hardware-specific optimization。

因此，一个更加接近真实情况的简化架构是：

Python model / application
          |
          v
AI framework
          |
          v
Graph compilation / optimization
          |
          v
C++ runtime / native libraries
          |
          v
CPU / GPU kernels
          |
          v
Hardware

这一中间层很重要，因为它可以减少 interpreter 和 dispatch overhead，融合多个操作，并生成更适合目标 hardware 的代码。

这就是为什么 Python 足以支撑高性能 AI

有一种常见的误解：

Python 很慢，所以用 Python 编写的 AI 程序一定很慢。

这个结论过于简单。

程序的性能，很大程度上取决于真正昂贵的工作发生在哪里。

考虑两个程序。

第一个程序通过 Python code 直接执行数百万次单独的操作。

第二个程序使用 Python 启动一个大型矩阵乘法，而矩阵乘法由 optimized native code 实现，并在 GPU 上执行。

两个程序都有 Python。

但它们的性能特征可能完全不同。

在第二种情况下，Python 主要负责组织和调度操作，而昂贵的计算发生在其他地方。

这也是为什么 PyTorch 的文档会讨论这样的情况：对于完整的 PyTorch workload，Python 不一定比 C++ 慢。

这里重要的区别是，这并不意味着 Python code 本身天然和 C++ 一样快。

它意味着，对于主要由 optimized native operations 构成的 workload，Python 层可能并不是主要瓶颈。

为什么 AI Framework 在生产环境中仍然需要 C++？

研究代码和生产系统通常有不同的要求，但两者之间并不是绝对的区别。

Python 在生产 AI 系统中也被广泛使用，尤其是在 model serving、orchestration、data processing 和 application logic 等场景。

与此同时，生产系统也可能需要：

low latency

high throughput

predictable resource usage

multithreading

portability

与现有 native applications 集成

efficient memory management

hardware-specific optimization

PyTorch 明确为 low-latency systems、高度多线程的环境以及已有 C++ codebases 等场景提供了 C++ frontend。该项目将 C++ frontend 定位为 Python frontend 的补充，而不是替代。

实际上，一个生产级 AI 系统完全可以在 application 或 serving 层使用 Python，同时在下面依赖 C++ 和 optimized native libraries。

这一点很重要。

Python 非常适合 model development 和 application logic。

当 AI 系统需要成为一个更大的高性能应用的一部分时，C++ 的价值会更加明显。

AI 生态中的其他地方也存在相同模式

“Python 在上层，native code 在底层”的架构并不是某一个 framework 独有的。

它广泛存在于 scientific computing 和 machine learning 中。

基本思路很简单：

High-level language
        ↓
User-friendly API
        ↓
Compilation / optimization
        ↓
Native runtime
        ↓
Optimized kernels
        ↓
Hardware

上层变化得相对更快。

新的 model architectures、APIs 和 research techniques 可以通过 Python 暴露出来。

底层变化得相对更慢，因为它们处理的是 memory、computation、parallelism 和 hardware 等基础问题。

这种分层让整个生态可以不断发展，同时不要求每一个研究人员都理解每一个 hardware 细节。

这意味着 AI 开发者需要学习 C++ 吗？

不一定。

如果你的主要工作是 model research、data processing、experimentation 或 application-level AI development，那么 Python 对你的大部分工作可能已经足够。

但如果你从事以下方向，理解 native layer 会越来越有价值：

inference engines

model runtimes

custom operators

GPU kernels

high-performance training systems

distributed systems

embedded AI

robotics

game engines

AI infrastructure

在这些领域，了解 Python API 下面发生了什么，会带来很大的帮助。

你最终可能需要理解 C++、CUDA、memory layout、SIMD、multithreading、synchronization，以及 hardware-specific optimization。

这也是为什么 AI 并没有让 systems programming languages 失去意义。

抽象层次越高，Python 带来的生产力通常越明显。

越接近 hardware，native programming 的重要性就越高。

Python 和 C++ 扮演着不同的角色

Python 和 C++ 之所以值得讨论，是因为它们并不一定在 AI 技术栈中争夺同一个位置。

Python 非常适合表达 algorithms、experiments、data pipelines 和 model architectures。

C++ 适合构建高效的 runtimes、管理资源、与现有 systems 集成，以及实现 performance-critical components。

Compilation systems 则负责优化高级 model code 到低层执行之间的过程。

CUDA 和其他 GPU ecosystems 则提供了利用专用 hardware 的额外层次。

把这些部分放在一起，现代 AI software stack 大致可以表示为：

                 AI Application
                       |
                    Python
                       |
              AI Framework API
                       |
           Graph Compilation / Optimization
                       |
              C++ / Native Runtime
                       |
          GPU Libraries / Native Libraries
                       |
                Optimized Kernels
                       |
                CPU / GPU Hardware

从外面看起来像是一个 Python application，内部却可能包含大量 C++、CUDA、compilation infrastructure，以及高度优化的 native code。

这就是为什么 AI 看起来像是 Python 的世界，但底层依然高度依赖 C++。

Python 让 AI 更容易表达。 C++ 让底层系统更加高效，并提供更强的控制能力。 Compilation systems 负责优化执行过程。 CUDA 和其他 hardware ecosystems 则把这些系统连接到现代 hardware。

AI software 的未来不太可能只属于某一种 programming language。

更可能出现的情况，是一个分层系统，让不同的语言和技术承担不同的工作。

以上就是“为什么 AI 看起来是 Python 的天下，底层却离不开 C++？”的详细内容，想要了解更多Python教程欢迎持续关注编程学习网。