AI 芯片架构这几年变化很快。以前大家提到 AI 加速，第一反应就是 NVIDIA GPU，后来 Google 把 TPU 带进了大规模训练集群，再后来 Groq 的 LPU 又把“推理速度”拉到了另一个量级。这次我们就把 TPU、GPU、LPU 放在一起，从架构设计目标、硬件组成、软件生态和实际部署场景四个维度拆一遍，搞清楚这些芯片到底解决什么问题，以及你在本地部署大模型或做批量推理时应该如何选型。
这篇文章不打算只念参数。我会先把三种架构的核心区别列清楚，然后逐层看它们的设计逻辑，再给出一套可以落地的环境检查和代码验证流程，包括怎么观察显存占用、怎么确认 CUDA / ROCm / 推理芯片的访问状态、怎么把模型挂到指定设备上跑推理。最后会给出实践中常见的坑和选型建议。适合正在做 AI 应用开发、模型部署、GPU 优化，或者想理解下一代推理芯片的读者。
1. AI 芯片核心能力速览
先看一张总表。这里的标的是“架构特点”和“通用定位”，具体性能数值会因硬件型号、软件栈和负载类型差异很大，需要以实测为准。
| 对比项 | GPU | TPU | LPU |
|---|---|---|---|
| 架构类型 | 大规模并行通用加速器 | 领域专用脉动阵列加速器 | 推理优化专用顺序执行单元 |
| 核心计算模式 | SIMT / 张量核心并行 | 矩阵乘加密集计算 | 低延迟流式推理 |
| 主要设计目标 | 通用并行计算、训练 + 推理 | 大规模训练与高吞吐推理 | 大模型推理低延迟 |
| 存储结构 | 显存（HBM / GDDR）+ 缓存 | 高带宽内存 + 脉动阵列内部寄存器 | 大容量 SRAM，减少 DRAM 访问 |
| 代表生态 | CUDA、ROCm、OpenCL | XLA、JAX、TensorFlow | Groq API、静态编译图 |
| 典型适用场景 | 日常深度学习、ComfyUI、微调、推理 | 超大规模训练、数据中心推理 | 高并发低延迟 LLM 推理 |
| 本地可获取性 | 高，消费级到数据中心都有 | 低，主要云服务提供 | 中，提供云 API 和部分硬件方案 |
| 编程难度 | 相对低，框架兼容性好 | 较高，依赖编译器和特定框架 | 更高，需要匹配编译工具链 |
从这张表能看出：三个架构并不是简单的“谁替代谁”，而是分别切入了 AI 计算链条上不同的位置。
2. 为什么通用 CPU 扛不住 AI 计算
在拆解 TPU、GPU、LPU 之前，要先回答一个问题：为什么现代 AI 训练和大模型推理不能只靠 CPU。
CPU 的设计目标是通用计算，需要在分支预测、乱序执行、高主频和缓存一致性上做大量优化。这类设计擅长跑操作系统、数据库、业务逻辑，但有一个明显短板：单核算力再强，面对动辄几百万上千万次矩阵乘加时，并行度不够。现代 AI 特别是 Transformer 架构，计算量集中在矩阵乘法和注意力机制上，这类计算天然适合大规模并行流水线。主频再高，如果只能一个指令一个指令地执行，吞吐量也上不去。
另一个瓶颈是内存带宽。LLM 推理时，模型参数要从内存或显存搬到计算单元。参数搬运速度往往比计算速度更影响用户体验。CPU 的内存带宽相对有限，而且 CPU 访问的 DDR 内存在带宽和延迟上都不适合大模型的高吞吐推理。GPU、TPU、LPU 解决的关键问题之一，就是缩短“数据搬运”和“计算”之间的差距。
所以可以理解为：CPU 负责控制和杂活，AI 加速器负责算得又密又快。这个背景下，才产生了 GPU 通用化、TPU 专用化和 LPU 重构存储层次三条不同路径。
3. GPU 架构：从图形卡到通用 AI 加速器
GPU 最初是为了图形渲染设计的。图形渲染的本质是大量顶点和像素的并行计算，因此 GPU 天然拥有成百上千个计算核心。后来 NVIDIA 推出 CUDA，把这种并行能力开放给通用计算，GPU 才从“图形卡”变成“计算卡”。
3.1 GPU 为什么适合训练和推理
GPU 核心数多，单核不复杂，但合在一起能提供很高的浮点算力。尤其是引入张量核心后，矩阵乘加这类操作可以在极小的面积内做高密度计算。当前主流框架 PyTorch、TensorFlow 的底层都针对 CUDA 做了深度优化，所以训练大模型时 GPU 依然是默认选择。
在推理侧，GPU 同样有优势。它既能跑高吞吐离线批次，也能通过 TensorRT、vLLM 这类推理引擎加速在线服务。显存容量大、且框架兼容性好，是它长期占据主流生态的关键。
3.2 GPU 部署时的几个硬指标
本地部署 GPU 模型时，重点看三块：显存、CUDA 计算能力、PCIe 带宽。
显存决定能不能塞下模型和输入数据。现在 7B 参数模型在 FP16 下通常需要 14GB 左右显存，如果做量化到 INT8 或 INT4 会明显降低显存压力。CUDA 计算能力影响算子优化版本，太老的计算能力可能跑不了最新的 flash-attention 优化。PCIe 带宽影响多卡通信和 CPU 与 GPU 之间的数据交换。
这个方程告诉我们：GPU 不是只算得快，还要“塞得下”和“传得快”。
3.3 查看 GPU 是否可用的实用命令
在实际部署前，先确认驱动和 CUDA 是否正常。下面是一段通用检查命令，适用于 NVIDIA GPU。
# 查看显卡列表、显存、驱动版本和 CUDA 版本 nvidia-smi # 如果 nvidia-smi 命令不存在，先确认驱动是否安装 ls /usr/src/ | grep nvidia在 Python 里确认 PyTorch 能不能访问 GPU：
import torch print("CUDA available:", torch.cuda.is_available()) print("CUDA version:", torch.version.cuda) print("GPU count:", torch.cuda.device_count()) if torch.cuda.is_available(): for i in range(torch.cuda.device_count()): print(f"GPU {i}: {torch.cuda.get_device_name(i)}") print(f" Memory: {torch.cuda.get_device_properties(i).total_memory / 1024**3:.1f} GB")这段代码是常见的验证入口。在 WSL 或 Linux 环境中，如果 PyTorch 报GPU access blocked by the operating system，通常是驱动或容器权限问题，需要先解决 GPU 可见性问题再继续。
4. TPU 架构：脉动阵列与大规模训练专用化
Google 的 TPU 是“领域专用架构”的代表作。它不是通用并行加速器，而是针对深度学习中的矩阵计算做定制。
4.1 TPU 的核心设计：脉动阵列
TPU 最典型的设计是脉动阵列（Systolic Array）。脉动阵列把多个乘法器排列成阵列，数据在阵列中像脉搏一样规则流动，每个计算单元只做局部乘加并把结果传给下一个单元。这种结构最擅长完成矩阵乘法，因为 AI 网络中的卷积、全连接、注意力机制最后都能转化为矩阵乘加运算。
脉动阵列和 GPU 的最大区别是：GPU 的灵活度高，什么算子都能跑，但计算单元之间数据搬运开销大；TPU 把计算单元与数据流动路径固定下来，减少了指令调度和数据搬运的功耗与延迟，从而获得更高能效比。
4.2 TPU 为什么主要出现在云端
TPU 的部署成本高，而且它适合大规模集群统一调度，不适合个人开发者买回家跑测试。Google 把 TPU 放在云服务里，用户通过 TensorFlow、JAX、XLA 来使用。XLA 编译器会把模型计算图编译成 TPU 能高效执行的指令，这既是 TPU 的优势也是门槛：如果你的模型算子太冷门，编译器不一定能高效映射到脉动阵列上。
4.3 TPU 对开发者的启发
TPU 的演进说明了一个趋势：当负载足够明确时，专用硬件一定能比通用硬件获得更高能效。GPU 也在做类似的事情，比如引入张量核心和 Transformer Engine，本质上都是在“通用之外叠加专用”。
如果做大规模训练集群而不是本地部署，TPU 类方案值得关注。但如果你主要做模型集成、API 调用或小规模微调，TPU 的先期学习成本和云资源费用通常不如 GPU 方案直接。
5. LPU 架构：面向大模型推理的存储革命
Groq 的 LPU（Language Processing Unit）把大模型推理的瓶颈理解得很透彻：单纯堆算力已经不够，关键要解决“模型参数搬运”的开销。
5.1 LPU 与 GPU 的核心差异
GPU 使用显存 + 高带宽内存，模型参数在计算前需要从 HBM 读取。HBM 带宽虽然高，但还是会成为瓶颈。LPU 的思路是：把大容量 SRAM 直接放到芯片内部，充分利用 SRAM 的低延迟高带宽特性，再用编译器把模型静态映射到这些 SRAM 上，减少推理过程中的逐层数据搬运。
LPU 执行模型的方式也不是 GPU 那种大规模多线程调度，而更偏向顺序执行、确定性强的流水线。这种设计在单次输入请求的延迟上优势明显，对用户交互实时性高的 LLM 应用很友好。
5.2 LPU 适合什么场景
LPU 的目标不是替代所有的训练任务，而是做在线推理。如果你在做聊天机器人、Agent 实时响应、高并发 API 服务，延迟经常比吞吐量更重要。LPU 在低延迟表现上非常有竞争力。但它也有短板：开发工具链相对单一，要求模型经过特定编译器适配；显存容量架构与传统 CUDA 生态不同，不能直接套用现有 GPU 部署脚本。
5.3 LPU 与 GPU 的选择思路
如果团队已经在 CUDA 生态里沉淀了大量代码，直接迁移到 LPU 需要成本。更稳妥的做法是：先把应用做成独立服务，通过 API 屏蔽底层芯片差异，再在 GPU 和 LPU 之间做灰度对比测试，用真实流量数据决定是否切换。
6. 训练加速与推理加速的架构分歧
现在越来越明显的一条趋势是：训练和推理正在走向不同的硬件路径。
训练要求高算力、高精度、大显存，因为要不断前向反向计算和更新梯度。GPU 和 TPU 都在这个方向上竞争。推理要求低延迟、低成本、高吞吐，尤其是一次只处理一个或少量请求时，延迟敏感程度非常高。LPU 的出现就是针对这个目标做了激进优化。
实际上，GPU 也在推理方向做专用化。NVIDIA 的 TensorRT、动态 shape 优化、张量并行等方案，都是在通用 GPU 上模拟“领域专用”的效果。未来不太可能只有一个赢家，更大的概率是共存：训练用 GPU / TPU，在线推理用 LPU / 专用推理 ASIC，边缘部署用轻量化 NPU。
对我们开发者来说，理解这个分歧很重要。你选模型时思考的不只是跑不跑得动，而是跑在什么架构上。比如用 Ollama 在本地跑大模型，默认走 GPU，也可以在纯 CPU 下跑。但如果追求低延迟在线服务，就需要考虑底层推理引擎是否支持你的硬件架构，而不再只是“显存够不够”。
7. 实测验证：本地环境中的 GPU / CPU 推理与显存观察
虽然不同硬件架构差异很大，但部署时有一个通用流程：确认设备可见，确认推理框架能访问设备，观察资源占用，再对比输出质量和延迟。下面给出一套可复制的验证思路。
7.1 确认推理框架使用哪种计算设备
以 Ollama 为例。Ollama 默认会尝试使用可用 GPU，但也可以通过环境变量控制是否启用 GPU 或者显式指定设备。下面是一些常见设置方式：
# 查看ollama服务状态 ollama serve # 设置环境变量控制GPU使用，实际数字根据需求调整 # 如果希望回退到CPU，可设置： # export OLLAMA_NUM_GPU=0 # 如果希望只使用部分GPU层，可设置： # export OLLAMA_NUM_GPU=999 # 在Windows系统中使用set命令： # set OLLAMA_NUM_GPU=0这些环境变量在不同版本中行为有差异，如果不确定，可以直接看ollama ps输出，确认模型量化类型、运行大小和 GPU 占用情况。
7.2 用 PyTorch 手动分配推理设备
如果你自己做推理脚本，可以通过框架 API 指定设备。下面是通用模板，核心是让模型和输入张量都到同一个设备：
import torch device_name = "cuda" if torch.cuda.is_available() else "cpu" device = torch.device(device_name) model = load_model() # 替换成实际模型加载方式 model.to(device) input_tensor = process_input("测试输入") input_tensor = input_tensor.to(device) with torch.no_grad(): output = model(input_tensor) print(output)7.3 观察显存和 GPU 占用
实时观察占用的方式有很多，常用nvidia-smi或nvtop：
watch -n 1 nvidia-smi # 或者使用nvtop查看实时占用 nvtop观察重点有三项：总显存、已用显存、GPU-Util。如果已用显存接近上限，说明显存紧张，需要降低 batch size 或量化模型。GPU-Util 偏低但显存占用高，说明计算可能受数据加载或 CPU 瓶颈影响。
7.4 CPU 推理与 GPU 推理的差异
在本地部署时，如果机器没有 GPU 或驱动异常，许多框架会自动回退到 CPU。CPU 推理的优势是兼容性好、部署简单，劣势是延迟高、吞吐低。对于 7B 参数级别模型，CPU 推理在复杂对话场景下往往体感很慢。做性能评估时，至少跑 10 次以上请求取平均值，不要只跑一次就下结论。
7.5 WSL 与 GPU 访问异常排查
在 WSL 中跑 PyTorch 或 CUDA 程序，偶尔会遇到 GPU 被系统阻断的报错，例如failed to initialize nvml: GPU access blocked by the operating system。这个问题通常是 WSL 的 GPU 驱动映射没有正确配置。排查路径如下：
# 1. 确认Windows侧已安装支持WSL的GPU驱动 nvidia-smi # 2. 确认WSL中能看到GPU ls /dev/dxg # 3. 确认CUDA环境变量 echo $CUDA_HOME如果仍然失败，可以确认当前 WSL 版本并升级到 WSL 2。WSL 1 不支持完整 GPU 计算加速。这个问题和显卡品牌关系不大，更多是系统级配置问题。
8. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| PyTorch 报 CUDA 不可用 | 驱动未安装或版本过老 | 运行 nvidia-smi | 安装匹配的 GPU 驱动 |
| 启动后页面打不开 | 端口被占用或服务未启动 | 查看服务日志、检查端口 | 更换端口或重启服务 |
| 显存不足 | 模型太大或 batch 太大 | nvidia-smi 看显存占用 | 降低 batch、换量化模型、加显存 |
| WSL 中 GPU 访问被阻断 | WSL 版本或驱动映射问题 | 检查 /dev/dxg 和驱动版本 | 升级到 WSL 2，安装支持 WSL 的驱动 |
| 推理速度很慢 | CPU 推理或 GPU 利用率低 | 查看 GPU-Util | 确认模型和数据都在 GPU 上 |
| API 调用超时 | 模型正在加载首帧或参数过大 | 检查服务日志和资源占用 | 增加超时时间、设置预热 |
| 批量任务卡住 | 队列积压或单条任务异常 | 查看任务日志和显存占用 | 加失败重试和任务超时机制 |
9. 在 AI 计算卡上做部署的最佳实践
无论使用 GPU、TPU 还是 LPU，实际落地时有一些通用原则值得坚持。
第一，先跑最小用例，再上批量任务。不要一开始就处理几百个文件，先用一句话或一张图验证流程走通。第二，模型文件、输入素材、输出结果分目录管理，避免路径混乱。第三，批量任务要加日志和失败重试，至少记录每一条任务的输入和输出状态。第四，接口服务要限制访问范围，不要默认监听 0.0.0.0，尽量用 127.0.0.1 加鉴权。
部署模型时还要注意量化策略。在 GPU 上跑较大模型时，FP16 精度更高但显存压力大；INT8 或 INT4 量化空间占用小，推理速度有时更快，但精度可能会有轻微下降。需要根据任务场景决定。常见的做法是先跑 FP16 基线，再对比量化后的效果，不能为了省显存盲目上低精度。
另外，在线推理服务要预先做“预热”，也就是服务启动后先跑几次推理，让算子和缓存进入稳定状态，否则线上第一次请求可能特别慢。用户侧如果做高并发调用，还要做超时和熔断，防止模型服务在异常时拖垮入口服务。
10. AI 芯片选型建议与总结
最后整理一下选型思路。
如果你做本地开发、ComfyUI 图像生成、中小模型微调和常规推理，GPU 仍然是最稳的选择，生态最完善，社区问题最多也最容易搜到答案。显存不够时优先考虑量化和小模型，不要急着上专用硬件。
如果你在云上做大规模训练集群，且工作负载以 Transformer 为主，TPU 类方案值得评估。它能带来能效比优势，但要注意团队是否愿意接受 XLA / JAX 工具链的学习成本。
如果你做在线大模型推理服务，且对延迟要求非常敏感，LPU 这类专用推理芯片可以当作 GPU 之外的对比方案。先通过 API 或测试环境验证真实延迟和成本，再决定是否迁移。
AI 芯片架构的演进逻辑很明确：从通用 CPU，到通用 GPU，再到为训练和推理分别定制的专用架构。未来边缘 AI 设备可能还会出现更多 NPU 类加速器。对开发者来说，最重要的不是追着芯片名词跑，而是理解每种架构解决的核心瓶颈是算力、带宽、还是延迟，然后根据实际负载做选型。如果这篇能帮你把 TPU、GPU、LPU 的边界理清楚，下次选型时至少不会只看一个“显卡型号”。
