AI芯片架构解读：从GPU到TPU、LPU，算力焦虑的解法不止一种

AI 芯片架构全面解读从 GPU 通用加速到 TPU、LPU 领域专用算力焦虑的解法不止一种过去几年AI 领域的开发者普遍患上了同一种焦虑模型越来越大算力越来越贵GPU 越来越难买。不管是训练千亿参数大模型还是本地跑一个 7B 的量化模型最后的瓶颈几乎都落在同一个地方——芯片。但如果你只盯着 GPU视野就窄了。真正值得关注的变化正在另一个维度发生AI 芯片正在从“通用计算”快速走向“领域专用计算”。Google 的 TPU 已经支撑了 Gemini 系列模型的训练和推理Groq 的 LPU 则以极致的推理速度成为大模型服务领域的新变量再加上 AMD、Intel、昇腾等厂商在加速卡上的持续投入AI 芯片的版图早已不是 NVIDIA 一家独大的简单叙事。这篇文章不打算做参数堆砌而是想回答几个更实际的问题GPU、TPU、LPU 到底有什么区别为什么 TPU 用脉动阵列、LPU 不走 GPU 路线却都能在特定场景里胜过 GPU作为一个普通开发者如果手里只有一台笔记本或者一块消费级显卡这些架构演进对你跑 Ollama、PyTorch 推理有什么实际影响读完这篇文章你会对 AI 芯片架构形成一套完整的判断框架也能直接解决本地 GPU 调用、推理加速、环境配置里的几类高频问题。1. 为什么 AI 芯片架构突然成了开发者的必修课先说一个反常识的现象很多开发者写 AI 应用其实根本不关心芯片架构。他们用 PyTorch、用 HuggingFace、用 Ollama模型一拉、接口一调跑起来就完事。至于底下是 CUDA 还是 ROCm是 GPU 还是专用芯片似乎离应用层很远。这个判断在模型体积小、并发量低的时候基本成立。但一旦进入真实业务场景芯片架构的影响就会以三种方式传导到应用层第一种是成本。云端 GPU 实例的价格按小时计费训练一次模型的账单可能高达数万甚至数十万元。如果你不理解训练和推理的计算特征差异就很容易在算力选型上多花冤枉钱。第二种是延迟。大模型推理的“首 token 延迟”和“生成速度”直接由硬件决定而专用芯片恰恰是在这两个指标上做优化。第三种是环境兼容性。AMD GPU、Intel GPU、Apple Silicon、昇腾 NPU各自的驱动、运行时、框架支持都不一样。同样一条pip install torch在不同硬件上要走的安装路径完全不同。所以AI 芯片架构已经不是芯片工程师的专属领域而是每一个实际部署过模型、被 GPU 报错折磨过的开发者都应该掌握的基础认知。这篇文章的核心判断是AI 芯片的演进不是简单的“从 GPU 到 TPU 再到 LPU”的线性替换而是一场从通用计算到领域专用计算的成本结构重构。理解了这个判断你就理解了过去十年 AI 算力发展的主线也能预判未来两三年哪些技术会真正影响你的日常工作。2. GPU 为什么能成为 AI 计算的默认选择要理解 TPU 和 LPU 的价值得先回到 GPU 为什么能统治 AI 计算这件事上。2.1 GPU 的并行计算本质GPU 最初是为图形渲染设计的。图形渲染的特点是屏幕上几百万个像素每个像素的计算彼此独立可以同时做。这种“大量简单任务同时执行”的模型天然适合用大规模并行计算来加速。后来研究者发现深度学习里的矩阵乘法和卷积操作本质上也是高度并行的计算。一个权重矩阵乘以一个输入向量每个输出元素的计算互不依赖完全可以并行执行。于是 GPU 从图形加速卡变成了通用计算加速卡NVIDIA 还专门推出了 CUDA 编程模型让开发者可以用 C 直接操作 GPU 的并行算力。从架构上看GPU 和 CPU 的核心差异在于“控制”和“计算”的配比。CPU 有强大的控制单元和大容量缓存擅长处理复杂的逻辑分支和串行任务但计算单元数量有限。GPU 则把大量晶体管用在了计算单元上控制逻辑相对简单靠“数量多”取胜。形象一点说CPU 是一个能解微积分的博士生GPU 是一万个只会做四则运算的小学生矩阵乘法正好是把大任务拆成四则运算的典型场景。2.2 CUDA 生态是 GPU 最深的护城河GPU 硬件本身只是故事的一半。真正让 NVIDIA GPU 难以替代的是 CUDA 生态。从 cuDNN、cuBLAS 这样的底层计算库到 PyTorch、TensorFlow 这样的上层框架再到 Triton、vLLM 这样的推理加速工具整个 AI 软件栈都深度绑定 CUDA。开发者用 PyTorch 写一段模型代码底层调用的就是 CUDA 的矩阵乘法和卷积算子。这种“写一次到处跑”的便利性让 NVIDIA GPU 成为了 AI 社区的默认基础设施。相比之下AMD 的 ROCm、Intel 的 oneAPI 虽然在努力追赶但生态成熟度仍有差距。很多开源项目在 NVIDIA GPU 上开箱即用换到 AMD GPU 上就可能出现算子缺失、性能不达标、甚至编译失败的问题。2.3 GPU 的局限通用性带来的效率损耗GPU 的通用性既是优点也是缺点。它既要处理图形渲染又要处理科学计算还要处理 AI 训练和推理这种“什么都能干”的设计意味着它在任何单一场景下都不是最优解。以矩阵乘法为例。GPU 执行矩阵乘法时数据需要从显存加载到寄存器计算完再写回显存。这个过程中数据搬运的能耗和延迟占比很高。深度学习训练的特征是数据量大、计算密集、精度要求高但单个计算本身的模式非常规律。如果有一种芯片专门为这种“规律的、重复的矩阵运算”设计理论上可以比 GPU 更高效。这正是 TPU 出现的逻辑起点。3. TPU为矩阵运算而生的“计算器”3.1 TPU 的核心脉动阵列Systolic Array2016 年Google 在 I/O 大会上首次公布了 TPU当时主要用它来加速推理。后来随着 AlphaGo、BERT、Gemini 等项目的推进TPU 逐渐演进为训练和推理一体化的专用芯片。TPU 架构里最核心的组件是脉动阵列Systolic Array。这个名词听起来很学术原理其实不复杂。传统的冯诺依曼架构里计算单元需要不停地从内存取数据、算一步、存回去数据在内存和计算单元之间来回搬运。脉动阵列则把大量乘法器排成一个二维阵列数据像血液一样在阵列里“流动”每个乘法器只和相邻的乘法器交换数据算完一个结果直接传给下一个。这种设计的最大优势是减少了数据搬运。矩阵乘法的核心操作是“乘累加”脉动阵列让输入数据在阵列中依次流过每个单元完成一次乘累加后把中间结果传递给下一个单元最终在阵列边缘得到完整的输出矩阵。数据的复用率极高能耗比远优于 GPU。理解脉动阵列的一个类比是流水线工厂。GPU 的做法是每个工人都有一张完整图纸自己去仓库领料、加工、交回成品工人越多越快但物料搬运量巨大。TPU 的做法是一条传送带把物料送到每个工人面前工人只做单一动作做完传给下一个工人整个工厂吞吐量极高但灵活性差——如果产品形态变了整条流水线就得重新调整。3.2 TPU 的适用场景与局限TPU 最适合的是计算模式极其规律、数据量巨大、且模型结构相对固定的训练和推理任务。Google 在 TPU 上跑 Transformer 类模型性能和性价比都远优于同等功耗预算下的 GPU。但 TPU 的局限也很明显。第一它不支持灵活的程序控制遇到稀疏计算、动态 shape、复杂分支逻辑时效率会大幅下降。第二它的软件栈是封闭的主要服务 Google 内部和 Google Cloud 的用户。你在自己电脑上跑 PyTorch基本上不会用到 TPU。第三TPU 的优化深度绑定 Google 的框架和模型结构如果模型里出现了 TPU 编译器不支持的算子开发者几乎没有回旋余地。从架构演进的角度看TPU 证明了“领域专用架构DSA”的价值只要把应用场景压缩得足够窄就能在能耗比和性价比上显著超越通用芯片。这一判断也直接影响了后来 AI 芯片设计的整体走向。4. LPU为什么大模型推理需要一款“非 GPU”芯片如果 TPU 是 Google 在训练侧的专用化探索那么 Groq 的 LPULanguage Processing Unit语言处理单元就是推理侧的激进实践。4.1 LPU 的设计哲学确定性胜过复杂控制Groq 这家公司很有意思。创始团队来自 Google TPU 项目但他们对 AI 芯片的理解却和主流路线截然不同。主流 GPU 和 TPU 都依赖大容量缓存和复杂的调度逻辑来提升效率Groq 的 LPU 则选择了一种极端简化不依赖高带宽显存而是把 SRAM 直接堆在芯片上用软件编译器控制所有数据的流动。LPU 的架构核心是大规模 SRAM 和确定性执行模型。它没有复杂的缓存层级没有乱序执行所有指令在编译期就确定了在哪个时钟周期执行、数据储存在哪个 SRAM 单元。这意味着芯片不需要像 GPU 那样依赖庞大的调度器和缓存来隐藏延迟也不需要像 TPU 那样依赖数据在脉动阵列中流动而是直接由编译器精确编排每一个计算步骤。在文本生成任务中LPU 的核心优势是token 生成延迟极低。传统 GPU 推理时每个 token 的生成都需要从显存读取整个模型的权重这个内存带宽瓶颈限制了生成速度。LPU 因为权重存储在芯片内部的 SRAM 中访问延迟远低于 HBM 显存所以 token 生成速度可以达到极高的水平。4.2 LPU 与 GPU 的本质差异要理解 LPU最好把它和 GPU 放在一起对比维度GPULPU计算模式大规模并行 复杂调度编译器确定性调度数据存储HBM 显存带宽高但延迟大片上 SRAM延迟极低灵活性高适合训练和通用计算低主要为 Transformer 推理优化性能优势训练吞吐量高推理延迟低token 生成快编程模型CUDA生态成熟编译器驱动需要适配适用场景训练 推理 图形计算大模型推理服务LPU 的设计哲学可以概括为为了推理速度可以放弃灵活性。这正好代表了 AI 芯片架构演进的另一个方向——当应用场景足够明确时专用化程度可以比 TPU 走得更远。需要特别说明的是LPU 目前主要在 Groq 的云服务中提供服务。从公开资料看它在 Llama、Mixtral 等开源模型的推理上表现出色但开发者想要在本地复现 LPU 的体验目前还不太现实。理解它的意义更多在于让我们看到 GPU 并非 AI 推理的唯一答案架构创新仍有巨大的空间。5. 从训练到推理为什么“专用”成了必然趋势芯片架构演进背后其实是 AI 计算负载的深刻变化。过去几年行业的重心在“训练”——把模型炼出来。现在重心正在转向“推理”——把模型用起来。训练和推理的计算特征差异直接决定了芯片设计的不同取舍。5.1 训练和推理对芯片的需求差异训练的特点是数据量大、批量大、计算模式密集、对精度敏感。训练时通常用很大的 batch size把大量样本一次性喂给模型此时矩阵乘法的维度很大非常适合 GPU 或者 TPU 这种大规模并行架构。推理的特点则完全不同。推理时 batch size 通常很小很多时候是 1。而且大模型推理是自回归的——一个 token 一个 token 地生成后一个 token 依赖前一个。这种高度串行的计算模式对内存带宽和延迟极其敏感。GPU 的强项是“大吞吐量并行计算”但生成第一个 token 的延迟受制于内存访问延迟GPU 反而没有优势。这解释了一个现象很多开发者在本地用 GPU 跑大模型每秒只能生成几十个 token连“流畅阅读”的水平都达不到。原因不是 GPU 不够强而是 GPU 的设计目标本来就是“万马奔腾”式的批量计算不是“一字千金”式的串行生成。5.2 领域专用架构的价值公式用一个简单的公式来理解专用架构的价值芯片性能 硬件架构 × 软件栈 × 算法匹配度对于通用芯片三个变量的自由度都很大但每一项都不是最优。专用芯片通过收缩应用范围把架构和软件栈做到极致从而在特定场景下获得数量级的性能提升。这个逻辑在其他领域已经被验证过。GPU 自己就是为图形渲染专用化而生的它在图形任务上远胜 CPU。ASIC 矿机专用的哈希计算芯片其能效比远超 GPU。AI 芯片正在经历的正是从“通用并行计算”走向“特定 AI 计算”的同一路径。5.3 开发者应该如何看待这场演进作为开发者不需要亲自设计芯片但理解这条演进主线能帮你做更好的技术决策如果你的业务以训练为主GPU 仍然是首选CUDA 生态的成熟度短期无法替代。如果你的业务以推理为主且对延迟有硬性要求可以关注云端的专用推理芯片服务比如 Groq LPU、各类 NPU 实例。如果你在本地做开发调试消费级 GPU 加上量化的模型通常比追求专用硬件更务实。如果你用的是 AMD、Intel 或 Apple Silicon理解它们的运行时差异能帮你少踩很多坑。下面进入实操环节。这一部分是很多开发者真正关心的问题如何在本地让 GPU 真正跑起来以及遇到报错时该怎么排查。6. 本地 GPU 加速实战从 Ollama 到 PyTorch 的环境配置不管架构演进讲得多热闹对大多数开发者来说最直接的问题还是我有一台电脑怎么让我的大模型工具真正用上 GPU6.1 第一步确认你的 GPU 状态无论是 Windows、Linux 还是 WSL先确认系统能不能看到 GPU。NVIDIA 用户运行nvidia-smi正常情况下会输出 GPU 型号、驱动版本、显存占用等信息。如果提示command not found说明驱动或 CUDA 工具包没有正确安装。AMD 用户可以尝试rocm-smiIntel 用户则可以检查xpu-smi或系统设备管理器。这里的关键是先确认“操作系统到底认不认这块卡”。6.1.1 WSL 里的高频报错failed to initialize NVML很多开发者习惯在 Windows 上用 WSL 跑 Linux 环境这本身没问题。但如果遇到下面这个报错failed to initialize nvml: GPU access blocked by the operating system含义是系统层面的 GPU 访问被拦截了。常见原因有三个一是 Windows 版本太低WSL 的 GPU 直通需要较新的 Windows 11 或 Windows 10 21H2 以上版本。二是显卡驱动安装在 Windows 侧但版本过老WSL 内的 CUDA 调用依赖 Windows 驱动提供的 WDDM 支持。三是 Windows 的设置里开启了虚拟机平台相关的安全策略导致 WSL 无法访问 GPU。排查顺序建议是先在 Windows 侧确认nvidia-smi正常再把 Windows 驱动升级到最新最后检查 BIOS 里的虚拟化设置。大多数情况下升级 Windows 驱动就能解决。6.2 第二步让 Ollama 用上 GPUOllama 是当前本地跑大模型最流行的工具之一但它的 GPU 识别并不总是开箱即用。安装完成后可以用以下命令查看当前模型是否真的在 GPU 上运行ollama ps参考输出格式NAME ID SIZE PROCESSOR UNTIL llama3.2:1b abcdef123456 1.2 GB 100% GPU 4 minutes关键看PROCESSOR列。如果显示100% GPU说明模型已经加载到 GPU 显存中。如果显示100% CPU说明 GPU 没有被调用。Ollama 在 NVIDIA GPU 上通常不需要额外配置只要驱动正确它会自动使用 CUDA。但在 AMD 和 Intel GPU 上情况复杂一些。AMD 用户需要确认安装的是 ROCm 版本的 OllamaIntel 用户则需要通过 IPEX-LLM 或者特定版本的运行时来启用 GPU 加速。一个实用的排查技巧是先拉一个很小的模型比如 1B 参数运行ollama ps看 PROCESSOR 列。如果显示 CPU就去查看 Ollama 的日志通常会有明确的 GPU 初始化错误信息。6.3 第三步PyTorch 的 GPU 环境验证如果你是做模型开发而不是直接跑现成工具PyTorch 的 GPU 环境配置是必经之路。有人在安装 GPU 版 PyTorch 时失败核心原因往往是 CUDA 版本和 PyTorch 版本不匹配。先看当前环境有没有可用的 GPUimport torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else No GPU)如果torch.cuda.is_available()返回 False优先检查三件事一是 PyTorch 安装时是否带了 CUDA 支持。默认从 PyPI 安装的 PyTorch 是 CPU 版本必须用官方推荐的镜像源安装 CUDA 版本参考命令pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121二是系统里是否安装了匹配的 NVIDIA 驱动。驱动版本决定你能用哪个 CUDA 版本。三是 Conda 环境下是否和系统的 CUDA 工具链冲突。安装完成后跑一个简单的矩阵运算来验证 GPU 是否真正参与计算import torch # 在 GPU 上创建两个随机矩阵并做乘法 a torch.randn(1024, 1024, devicecuda) b torch.randn(1024, 1024, devicecuda) c torch.matmul(a, b) # 等待 GPU 计算完成 torch.cuda.synchronize() print(fGPU 矩阵运算结果 shape: {c.shape}) print(f当前使用 GPU: {torch.cuda.get_device_name(0)})如果这段代码能正常运行说明你的 PyTorch 已经具备 GPU 能力。6.4 第四步Docker 容器里怎么调用 GPU服务器场景下很多开发者用 Docker 部署大模型推理服务。这里有个高频问题容器里跑nvidia-smi报错或者模型运行异常缓慢。Docker 容器默认是隔离 GPU 的需要在启动时显式把 GPU 设备挂载进去。NVIDIA 的推荐做法是安装 NVIDIA Container Toolkit然后启动容器时加参数docker run --gpus all -it nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi安装 NVIDIA Container Toolkit 的要点是先配置好 apt 源再安装nvidia-container-toolkit包最后重启 Docker 服务。如果使用 AMD GPU对应的是rocm工具链和--device/dev/kfd --device/dev/dri一类的设备直通配置。从架构的角度看Docker GPU 直通解决的正是“让容器中的软件栈能直接访问物理 GPU”的问题这和 WSL 的 GPU 直通、虚拟机 GPU 共享本质上是同一类虚拟化技术在不同平台上的实现。7. 高频 GPU 问题排查指南无论你是用 NVIDIA、AMD 还是 Intel下面的问题清单很可能覆盖了你踩过的大部分坑。问题现象可能原因排查方式解决方案nvidia-smi命令不存在NVIDIA 驱动未安装或未加入 PATH检查系统驱动安装情况安装对应版本的 NVIDIA 驱动WSL 内报failed to initialize nvmlWindows 驱动过老或 WSL 版本低Windows 侧运行 nvidia-smi检查版本升级 Windows 驱动至最新更新 WSLOllama 不识别 GPUOllama 版本不支持对应显卡运行ollama ps查看 PROCESSOR 列更新 OllamaAMD 用户安装 ROCm 版本PyTorchcuda.is_available()为 False安装的是 CPU 版 PyTorch打印 torch.version判断用 CUDA 版安装命令重装参考前文Docker 容器无法调用 GPU缺少 NVIDIA Container Toolkit容器内运行 nvidia-smi 试错安装 toolkit重启 Docker--gpus all启动显卡被识别但一直在用 CPU 渲染/计算软件环境没有配置硬件加速检查 OpenGL 或 CUDA 上下文安装对应 GPU 驱动和运行时确认应用配置多显卡环境中某个程序占用过高程序默认使用了所有可见 GPU使用任务管理器或nvidia-smi查看进程设置环境变量CUDA_VISIBLE_DEVICES限制 GPU多显卡场景值得展开说一个实用技巧。在 CUDA 环境里可以通过环境变量控制程序使用哪张卡# 只让程序看到编号为 0 和 1 的两张卡 export CUDA_VISIBLE_DEVICES0,1这个环境变量对 PyTorch、TensorFlow 以及大多数使用 CUDA 的推理引擎都有效是排查多卡资源争用的第一利器。8. 架构演进下的选型建议训练、推理和本地开发分别怎么选回到文章开头的问题AI 芯片架构演进对普通开发者意味着什么我的建议分成三个场景8.1 训练场景CUDA 生态仍然是默认答案如果你是在训练模型包括微调开源大模型NVIDIA GPU CUDA 依然是风险最低的选项。PyTorch 对 CUDA 的支持最完善各种分布式训练框架DeepSpeed、FSDP也都优先适配 CUDA。这个领域不是不能使用 AMD 或国产加速卡但需要付出额外的兼容成本。8.2 推理场景考虑专用芯片和云端推理如果你的业务是部署大模型服务对延迟和成本敏感现在有比“买更多 GPU”更好的选择。云端推理专用实例比如各类 NPU、LPU、TPU 服务在推理场景下可能比通用 GPU 实例更划算。特别是高并发的文本生成任务专用芯片在单位 token 成本上优势明显。如果业务量不大也可以按需使用不必为高峰流量保留一堆闲置 GPU。8.3 本地开发和验证能吃上 GPU 比追求“最好”重要个人开发者的最佳策略是利用现有硬件先把模型跑起来再考虑优化。不管你是 NVIDIA、AMD 还是 Apple Silicon先确认你的推理工具Ollama、llama.cpp、PyTorch支持当前的硬件加速方案然后才是讨论性能。很多开发者花很多时间纠结硬件其实连 llama.cpp 的 GPU 加速开关都没打开这才是最可惜的。9. 从 GPU 到 TPU、LPUAI 芯片演进的底层逻辑复盘整个 AI 芯片架构的演进可以看到一条清晰的逻辑线应用场景的确定化程度决定了芯片的专用化程度。早期 AI 计算没有明确的形态GPU 因为并行算力强而胜出但它是“通用”的——既可以渲染图形也可以做科学计算还能训练神经网络。Google 发现训练神经网络这件事足够规律、足够重大于是设计了 TPU用脉动阵列把矩阵乘法的效率做到极致。Groq 认为大模型推理的价值和规律性已经足够突出于是设计了 LPU用极度简化的架构换取极致的生成速度。GPU、TPU、LPU 并不是简单的“谁替换谁”的关系而是各自占据不同的生态位。GPU 仍然是最灵活的 AI 加速器TPU 是训练场景下的能效比之王LPU 则代表推理场景下的极致延迟优化。未来的 AI 芯片大概率会继续沿着“场景细分 软硬协同”的方向演进出现更多针对特定模型结构、特定部署场景优化的专用芯片。对开发者来说理解这场演进最重要的收获不是预测哪家芯片会赢而是建立一种判断力在什么场景下什么架构最能解决你的问题。这句话看起来很朴素却能在选型时帮你省下大量的时间和金钱。10. 一个容易被忽略的软硬件协同问题算法决定芯片芯片也反哺算法架构演进的动力往往来自算法突破而专用芯片一旦出现又会反过来影响算法设计。Transformer 之所以成为大模型的主流架构部分原因正是它在并行计算上表现优异适合 GPU/TPU 这类大规模并行芯片。如果未来的 LPU 类芯片证明“确定性执行”能带来数量级的推理加速算法研究者可能会设计出更适合这种架构的新模型结构。这就是软硬协同的循环算法定义了一个计算负载特征芯片为这个特征优化优化的结果又反过来让这类算法更有竞争力。开发者在自己的项目里也可以实践这种思维。不要被动接受“必须用 GPU”的默认假设而是分析你的负载特征是训练多还是推理多是批量处理还是实时流式对延迟敏感还是对吞吐敏感是长期运行还是突发调用每个问题的答案都会指向不同的芯片架构和部署方案。AI 芯片领域的确很热但真正有价值的选择永远来自对自己场景的清晰理解。