AI 芯片架构这几年变化很快。以前大家提到 AI 加速第一反应就是 NVIDIA GPU后来 Google 把 TPU 带进了大规模训练集群再后来 Groq 的 LPU 又把“推理速度”拉到了另一个量级。这次我们就把 TPU、GPU、LPU 放在一起从架构设计目标、硬件组成、软件生态和实际部署场景四个维度拆一遍搞清楚这些芯片到底解决什么问题以及你在本地部署大模型或做批量推理时应该如何选型。这篇文章不打算只念参数。我会先把三种架构的核心区别列清楚然后逐层看它们的设计逻辑再给出一套可以落地的环境检查和代码验证流程包括怎么观察显存占用、怎么确认 CUDA / ROCm / 推理芯片的访问状态、怎么把模型挂到指定设备上跑推理。最后会给出实践中常见的坑和选型建议。适合正在做 AI 应用开发、模型部署、GPU 优化或者想理解下一代推理芯片的读者。1. AI 芯片核心能力速览先看一张总表。这里的标的是“架构特点”和“通用定位”具体性能数值会因硬件型号、软件栈和负载类型差异很大需要以实测为准。对比项GPUTPULPU架构类型大规模并行通用加速器领域专用脉动阵列加速器推理优化专用顺序执行单元核心计算模式SIMT / 张量核心并行矩阵乘加密集计算低延迟流式推理主要设计目标通用并行计算、训练 推理大规模训练与高吞吐推理大模型推理低延迟存储结构显存HBM / GDDR 缓存高带宽内存 脉动阵列内部寄存器大容量 SRAM减少 DRAM 访问代表生态CUDA、ROCm、OpenCLXLA、JAX、TensorFlowGroq 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 能不能访问 GPUimport 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(fGPU {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 的 LPULanguage 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_GPU0 # 如果希望只使用部分GPU层可设置 # export OLLAMA_NUM_GPU999 # 在Windows系统中使用set命令 # set OLLAMA_NUM_GPU0这些环境变量在不同版本中行为有差异如果不确定可以直接看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或nvtopwatch -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 的边界理清楚下次选型时至少不会只看一个“显卡型号”。