最近总有朋友问我一个很实际的问题做 AI 应用到底是买 GPU、用 TPU还是试试 LPU这三个词现在几乎成了“AI 芯片”的代名词但真到了掏钱选型的时候大部分人都是懵的。跑训练的人说 GPU 是唯一真理谷歌生态里走出来的工程师说 TPU 才是大规模训练的终极答案做推理优化的朋友又猛吹 LPU 的低延迟如何颠覆体验。听一圈下来不但没搞明白反而更不知道该怎么选。先给个我的结论**不存在绝对的“性价比之王”只有“适合你当前场景”的那个选项。**训练、微调、推理、边缘部署算的账完全不一样。芯片本身的跑分高不高只是一回事真正决定你花钱值不值的是生态成熟度、单位算力成本、工程迁移成本这些被忽略的“隐性账单”。这篇文章就不绕弯子了直接把这三种芯片的底细翻一翻再结合我实际跑过的训练、微调、推理任务告诉你什么场景下选谁最划算以及那些文档里不会写的坑。1. 先搞清楚三家人到底在做什么1.1 GPU通吃型选手靠堆核心吃饭GPU 大家最熟尤其是 NVIDIA 的 A100、H100 系列。它的核心思路是“并行堆料”——把成千上万个简单的计算核心堆在一起同时处理海量数据。做矩阵运算时GPU 可以把一个大矩阵拆成无数小块分给不同核心同时算再汇总结果。这套架构的强项是“通用”。不管你是做 LLM 训练、图神经网络、科学计算还是视频编解码只要算法能写成矩阵运算GPU 都能跑而且性能都还不错。生态更是无敌PyTorch 默认支持 CUDAHuggingFace 上几乎每个模型都开箱即用地跑到 GPU 上FlashAttention、DeepSpeed 这些优化库也全是围绕 CUDA 生态做的。但 GPU 有个天然短板显存带宽和容量跟不上算力增长。A100 的内存带宽大概是 2TB/s 级别H100 到 3.35TB/s听着很吓人但和芯片内部的浮点算力相比依旧是个瓶颈。模型参数、中间激活值都要在显存和计算单元之间来回搬运很多场景下“等数据”的时间比“算数据”的时间还长。打个比方GPU 像一支什么活都能接的施工队工具齐全、经验丰富哪个项目都能上但物料搬运环节经常拖后腿工期一大就得靠人海战术堆时间。1.2 TPU谷歌的“偏科生”为矩阵乘而生TPU 是 Google 从 2016 年开始自研的专用芯片全称 Tensor Processing Unit听起来就很“张量”。它的核心设计目标是把矩阵乘法做到极致。为此TPU 采用了一种叫“脉动阵列”的结构数据像波浪一样在计算单元阵列里流动每个单元只做最简单的乘加运算但整个阵列能在一个时钟周期内完成大量矩阵运算。和 GPU 不一样TPU 不是“通用计算卡”它更像一条专门为矩阵乘法定制的流水线工厂。你把一个矩阵乘法的任务交给它它能在极短的时间内交付但如果你想让它跑一个不规则的算法、一个冷门的算子对不起效率会大幅下降甚至根本不支持。TPU 的另一个特点是片上存储巨大TPU v5e 每颗芯片有 16GB 的 HBM但在架构上它更依赖高带宽的片上存储来喂饱计算阵列。配合 XLA 编译器做联合优化训练超大规模模型的效率非常惊人。Gemini、Gemma 这些模型就是靠 TPU 集群训练出来的。但它的问题也很明显封闭生态。用 TPU 基本意味着你要接受 JAX 或 TensorFlow 的编程模型PyTorch 虽然也能跑但支持度和性能都存在折扣。更要命的是 TPU 不对外售卖只能通过 Google Cloud 租用硬件规格、配额大小都是云厂商说了算。1.3 LPU推理赛道的新人思路反着来LPU 是 Groq 公司提出的概念全称 Language Processing Unit明摆着就是冲着大语言模型推理来的。它的设计思路和 GPU、TPU 完全相反——不追求峰值算力而是追求数据不搬家。LPU 最激进的地方在于它没有传统意义上那种依赖外部显存的架构而是把巨大的 SRAM静态随机存取存储器直接堆在芯片上。模型权重加载进去之后计算过程中几乎不需要到外部内存取数据。这一下就把“内存带宽瓶颈”这个老大难问题给绕开了。所以 LPU 做 LLM 推理时延迟能做到极低通常几十毫秒内出 token。我实测 GroqCloud 上的 Llama-3-70B 模型首 token 延迟和每 token 速度都能到毫秒级体感比常规 GPU 推理快了一个量级。代价是什么什么都得自己适配。LPU 本质上是“为编译期调度而生”的架构运行前需要用它的 Halo 编译器把计算图排好模型转换、算子适配的功夫少不了。且因为片上 SRAM 容量有限Groq 芯片大概是 230MB 级别能放的模型规模也受限跑超长上下文的大模型时大权重无法一次性放进去碎片化处理综合吞吐未必占优。LPU 目前并不是什么活都能干的通用芯片而是专攻“在线推理”这一件事的偏门利器。一句话总结三家定位芯片设计目标代表产品生态难度擅长场景GPU通用并行计算NVIDIA A100/H100、AMD MI300X低PyTorch/CUDA 全通吃训练、微调、推理、多模态TPU大规模矩阵运算TPU v4/v5e、TPU Pod高JAX/TensorFlow 为佳超大规模预训练、张量密集型任务LPULLM 在线推理Groq LPU、GroqCloud高需 Halo 编译器适配低延迟在线推理、单 token 高速生成这三种方案本质上都是“冯诺依曼瓶颈”的解题思路。算力增长永远比内存带宽快GPU 选择用高带宽显存硬撑TPU 用脉动阵列减少数据搬运次数LPU 干脆把所有数据堆在芯片上不搬了。2. 从训练到推理性价比该怎么算2.1 训练场景GPU 生态护城河太深了先来算训练这笔账。市面上主流的开源模型无论是 Llama、Qwen 还是 Mistral权重格式、微调脚本、推理框架几乎全部默认 GPU 优先。PyTorch 的DataLoader、autocast、FSDPHuggingFace 的Trainer这些训练基础设施全是围绕 CUDA 构建的。你用 GPU拿到的是一整套成熟工具链用 TPU得上 JAX 重写训练循环用 LPU现在基本没法做正经训练。以训练一个 7B 参数的模型为例一张 A100 80G 跑 FP16 混合精度理论吞吐大概在 150-200 TFLOPs实际打个五折一个 epoch 处理几亿 token 下来耗时在数小时到数天之间。这张卡在主流云平台的租用价格大概 2-3 美元每小时。如果是想跑 70B 甚至更大的模型单卡显存不够就得上多卡并行。NVIDIA 的 NVLink 和 NCCL 通信库把多卡互联这件事做到了开箱即用的水平四卡、八卡甚至几十卡的集群都能比较平滑地扩起来。TPU 在纯算力上其实不输 GPU甚至在大规模数据并行时表现更优。Google 内部那套高效训练流程是围绕 TPU Pod 建的几千颗芯片组成一个集群算力密度远超普通 GPU 机房。但对绝大多数团队来说这个优势根本够不着你首先要能申请到 TPU 配额云上稀缺其次要把训练代码迁移到 JAX调试 XLA 编译报错和算子不支持的问题这一套下来耗费的工程师时间可能比省下的算力钱还贵。所以训练场景的性价比可以归纳成一个公式综合成本 单位算力价格 × 训练时长 × 人工适配成本。GPU 赢在最后一项几乎为零。除非你团队的工程能力足够强且训练规模大到了 TPU 的算力优势能覆盖迁移成本否则第一阶段老老实实租 GPU 是最稳的选择。2.2 微调场景真正决定花销的是显存微调这件事如今已经被 LoRA、QLoRA 这类参数高效微调手段给“卷”下来了。理论上一张 24GB 显存的消费级显卡RTX 4090就能对 7B 模型做 QLoRA 微调这在两三年前是不可想象的。哪怕你想微调 70B 级别的模型用 4-bit 量化加 LoRA单卡 48GB 以上的专业卡也能跑。我的经验是微调场景下性价比的核心不是芯片架构而是显存容量和带宽。LoRA 只训练少量低秩矩阵计算量不大但模型权重和激活值仍然占据显存。假设一个 7B 模型在 FP16 下权重占约 14GBQLoRA 4-bit 后降到 4GB 左右加上激活、梯度一张 24GB 卡刚好能装下。用租卡的方式来算一张 24GB 显存、性能接近 A10 的云卡价格大约在 0.7-1 美元每小时。一个 7B 模型的 LoRA 微调数据量不大时 2-4 个 epoch 通常在 2-4 小时内能收敛算下来单次微调成本在 2-4 美元。这个量级的开销单独为微调去采购整张专业卡反而不划算租就完了。TPU 在微调场景上最大的问题是配额和形态。Colab 上能免费蹭到的 TPU 是 v2-8单片能力大概只相当于一张中等显卡而真正的 TPU v5e 在云上按片计费价格并不比同级别的 GPU 便宜多少。更关键的是JAX 生态里虽然也有 LoRA 实现但很多 HuggingFace 上的 PEFT 工具链没法直接用迁移成本还是高。2.3 推理场景LPU 低延迟到底值多少钱推理是最容易把“性价比”算清楚也最容易算错账的场景。先区分两种推理需求在线低延迟推理和离线批处理推理。这两种需求对芯片的要求完全不同。离线批处理比如晚上批量生成一批摘要、处理一批分类任务延迟要求不高大家更关心吞吐量和单 token 成本。这种场景下 GPU 配 vLLM、TensorRT-LLM 这类推理引擎已经优化得很成熟吞吐量可以拉到很高性价比很稳。TPU 在这种场景下也能用TensorFlow Serving 和 JAX 推理在 TPU 上都能跑但因为生态小众部署工具链要自己搭。在线低延迟推理比如聊天机器人、代码补全、实时翻译用户对“第一个字出来的时间”极其敏感。这时候 LPU 的价值就体现出来了。我实测过的 GroqCloud API跑 Llama-3-70B 这种大模型首 token 延迟能做到几十毫秒级别每 token 生成速度达到数百 token 每秒。同样的模型用 GPU 加 vLLM 部署首 token 延迟通常会到几百毫秒生成速度一两百 token 每秒已经算优秀了。不是说 GPU 不行而是 LPU 的片上存储架构天然适合低延迟场景。但 LPU 的性价比有个隐蔽陷阱按 token 计费。GroqCloud 的 API 价格看起来不高但如果你有持续、大规模的推理流量按 token 累计的成本会非常快。相比之下GPU 是按时租用只要业务运转资源可以按需伸缩。如果要长期支撑百万级日活用户、每天处理数十亿 tokenLPU 的按量账单大概率比租用 GPU 集群更贵。所以买不买 LPU 的账取决于你的业务模式业务类型推荐方案理由高并发、低延迟 C 端产品LPU或 GPU优化引擎用户体验依赖延迟LPU 优势显著高吞吐、延迟不敏感任务GPU 批处理单位 token 成本更低生态成熟多模型、多任务混跑GPU灵活性最高推理引擎支持模型切换超大规模、内部有 JAX 团队TPU成本可控且算力密度大2.4 成本账本租卡、按量计费与隐性成本选定了场景还有一层账要算清楚算力从哪来。自有硬件、云上租卡、API 按量计费三种方式的成本结构完全不同。自有硬件的账是这么算的一张 A100 80G 的市场价大概在 1.5-2 万美元左右按照 GPU 卡 3-5 年的折旧周期算每月折旧成本在 400-500 美元。还要加上机房电费一张 A100 功耗 400W加上散热一个月电费轻松上百美元、机房租金、运维人力、故障替换。算下来一张自购卡每个月真实成本可能在 800-1200 美元。而云上租用同等规格的卡包月价格通常也在 800-1500 美元区间。自购的优势主要体现在“高利用率”场景如果你能把这台机器 24 小时跑满自学肯定划算否则很容易变成“花钱买闲置”。云上租卡的弹性更大按小时计费高峰扩、低谷缩。它的隐性成本在于数据存储和网络传输模型权重在云端多个实例间复制、训练数据上传下载这些流量费用在账单里可能比算力本身还醒目。建议拿到账单后单独看“Egress”“Storage”两项很多人第一次看到都会被吓一跳。API 按量计费模式最省心尤其适合中小团队和验证期项目但要注意它不适合高频大规模调用。量大的话要么和厂商谈折扣要么干脆切回 GPU 租用模式自己部署。3. 实操三类芯片我都怎么上手用3.1 GPU 环境三步配好驱动、CUDA、PyTorch别嫌基础GPU 环境配错的人太多了。我之前见过一个朋友用pip install torch装完之后跑torch.cuda.is_available()永远返回False查了半天才发现那个 PyPI 默认包是 CPU 版需要去 PyTorch 官网按 CUDA 版本重新装。正确的流程分三步。第一步装驱动。NVIDIA 官网下载对应型号的驱动Windows 直接安装即可Linux 上建议用apt装nvidia-driver-545这类带版本号的包不要用系统默认的nouveau开源驱动。装完执行nvidia-smi能看到显卡型号和驱动版本就说明 OK 了。第二步装 CUDA Toolkit。注意两点一是版本要和驱动匹配工具包官网有个兼容性矩阵表驱动版本决定了你能装多新的 CUDA二是如果你只是跑 PyTorch其实不需要单独装整个 CUDA ToolkitPyTorch 的 wheel 包自带了 CUDA 运行库你只需要确认驱动支持即可。只有在编译自定义 CUDA 算子或装特定库时才需要完整 Toolkit。第三步装 PyTorch GPU 版。正确方式是# 去官网选对应 CUDA 版本的命令 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121装完立刻验证import torch print(torch.__version__) print(torch.cuda.is_available()) # True 才正常 print(torch.cuda.get_device_name(0))能打印出 “NVIDIA A100” 之类的设备名环境就算成了。一个小提醒多环境隔离用 conda但 conda 默认源里的 torch 也可能装成 CPU 版装之前一定要看安装日志里带没带cu121这样的后缀。还有 Windows 用户容易出现驱动老、CUDA 新导致不匹配的问题建议统一记住一个经验驱动尽量更新CUDA 版本和 PyTorch 版本对齐别在同一台机器上混装多套 CUDA Toolkit。3.2 TPU 上手Colab 与 JAX 的配合TPU 的上手路径我就推荐一个最接地气的Google Colab 的免费 TPU。虽然性能比不上云端 Pod但体验整个流程完全够用。Colab 里把“运行时类型”切到 TPU然后安装 JAX 的 TPU 版本pip install jax[tpu] -f https://storage.googleapis.com/jax-releases/lts/lts_jax_releases.html -q装完验证一下是否识别到 TPUimport jax import jax.numpy as jnp # 强制使用 TPU jax.config.update(jax_platform_name, tpu) print(jax.devices())能看到TpuDevice就说明连接成功。跑一个简单的矩阵乘法试试key jax.random.PRNGKey(0) a jax.random.normal(key, (4096, 4096)) b jax.random.normal(key, (4096, 4096)) # JIT 编译第一次比较慢 matmul_fn jax.jit(lambda x, y: x y) c matmul_fn(a, b) print(c.shape)这里有个关键点TPU 上跑任何运算第一遍都要经过 XLA 编译会明显慢一截之后跑就快了。所以如果你在 TPU 上做训练务必把整个训练循环包在jax.jit里否则性能和“裸跑”没区别。还有一点要提醒Colab 的免费 TPU 资源有限长时间占用会被限制。而且 TPU 的显存其实是 HBM当你通过 JAX 分配内存时经常遇到 OOM因为 JAX 是惰性分配很多错误直到真正执行时才暴露。建议小规模验证好逻辑、确认内存布局没问题之后再放大数据量别一上来就加载十几 GB 的数据。3.3 LPU 接入一个请求就体验低延迟LPU 最友好的上手方式就是 GroqCloud 的 API不用自己部署硬件注册拿个 key 就能体验。最省事的接法是用 OpenAI SDK把 base_url 换成 Groq 的端点代码改动量很小。from openai import OpenAI client OpenAI( api_key你的GROQ_API_KEY, base_urlhttps://api.groq.com/openai/v1, ) response client.chat.completions.create( modelllama-3.1-8b-instant, messages[ {role: user, content: 用一句话解释什么是大语言模型} ], max_tokens512, temperature0.7, ) print(response.choices[0].message.content)如果你想亲自感受 LPU 和 GPU 的延迟差异自己做个简单的计时器就行。核心测两个指标首 token 延迟从发送请求到收到第一个 token 的耗时和生成速度每秒能输出多少 token。Groq 的流式响应配合time模块能比较直观地看出差异。我是真的被 Groq 的速度惊到过一次跑了 Llama-3-70B流式输出几乎是无停顿地往外蹦字比本地的 4090 推理还快。但也要提醒LPU 目前对上下文长度支持有限Groq 的模型规格页面上会标注每个模型的 max context length调用前务必确认你的输入长度在那个范围内不然会被直接截断或报错。4. 常见问题与避坑实操从报错到选型都别踩雷4.1 显存不够报警怎么办跑大模型显存 OOM 是最常见的报错尤其用 GPU 时。很多人一报错就以为要换更大的卡其实多数情况下调一调就能跑起来。先看显存被什么吃了。按占用从大到小排列激活值中间计算结果 优化器状态Adam 的动量和方差 梯度 模型权重。优化器状态在混合精度训练时每个参数要占 12 字节FP32 的动量和方差各 4 字节FP32 主权重 4 字节比模型本身还吃显存。手动算一遍心里就有底了。解决手段分优先级。第一招开梯度累积把 batch size 拆小显存不够时最干净的方案。第二招开梯度检查点gradient_checkpointing用时间换空间把中间激活不保存、反向时重算显存占用能降一半以上。第三招上 LoRA 或 QLoRA把可训练参数量降到千分之一级别显存占用直接少一个量级。第四招如果还不行削减序列长度LLM 显存和序列长度近似线性相关这是很多人忽略的“隐藏开关”。在云上租卡时也要注意别被“显存”这个单一指标忽悠。同样是 80G 显存A100 和 H100 的算力差一倍价格也差一倍。租之前先想清楚你的瓶颈到底是显存容量还是算力。微调类任务显存敏感H100 的算力优势反而不明显从头预训练或大批量推理H100 的性价比才体现得出来。4.2 驱动、CUDA 版本混乱怎么排查GPU 报错里最常见的几类都和驱动、CUDA 版本不匹配有关我把典型的报错和排查路径整理成一张表报错信息大概率原因解决思路CUDA driver version is insufficient驱动版本低于 PyTorch 所需 CUDA 版本升级驱动或降低 PyTorch 的 CUDA 版本ImportError: libcudnn.so.8: cannot open shared object filecuDNN 未安装或版本不对安装匹配的 cuDNN或改用自带 cuDNN 的 PyTorch wheeltorch.cuda.is_available()返回 False装成了 CPU 版 torch按官网命令重装 GPU 版NVRM: GPU is fallen off the bus云主机 GPU 被物理移除或驱动崩溃重启云实例检查实例规格是否变更CUDA error: out of memory显存耗尽按 4.1 的步骤调 batch 或精度这里有几个实操心得。第一看到CUDA driver version is insufficient不要急着重装 CUDA先运行nvidia-smi看右上角的 “CUDA Version”那才是驱动支持的最高版本。如果驱动支持 12.2你装 PyTorch 的 cu121 版本就完全没问题。第二不要在系统级环境里同时装多套 CUDA、cuDNN用 conda 或 venv 把每个项目的依赖隔离干净项目之间互不干扰。第三云上租卡出现 GPU 被移除、驱动崩溃这类问题优先重启实例很多临时性问题重启就自愈了。4.3 TPU 与 LPU 的限制是明牌别硬碰TPU 和 LPU 的优点很突出但限制更突出最怕的就是大家抱着“尝鲜”心态冲进去最后发现和现有技术栈不兼容。TPU 的核心限制有三个。第一编程模型必须是 JAX 或 TensorFlowPyTorch 虽然能通过 PJRT 桥接跑但算子支持不全容易回退到 CPU 导致性能雪崩。第二分布式训练时 TPU Pod 的互联拓扑是固定的你的模型并行策略必须针对它的拓扑做设计不像 GPU 集群那样随便改。第三云上 TPU 配额是稀缺资源申请大规格 Pod 可能要排期对时效性要求高的项目根本等不起。LPU 的限制更直接。第一模型要经过 Halo 编译器适配不是随便拿个 PyTorch 模型就能跑目前支持的模型谱系有限。第二片上 SRAM 容量有限超长上下文场景比如 32K 以上输入会很吃力甚至直接不支持。第三API 按 token 计费业务量上来后成本不可控。我见过一个小团队把 Groq 当主力推理结果一个月 API 账单比之前租 GPU 贵了一倍多因为他们的场景是大量长文本批处理根本不适合 LPU。选型前请对照一下自己团队的技术栈和业务场景团队情况建议不建议PyTorch 重度用户、训练推理都要做GPU 租用或自购直接上 TPU 或 LPU已有 JAX 工程经验、部署大规模训练TPU 可以认真评估为了 TPU 临时学 JAX新项目只做在线聊天/代码补全类推理LPU 值得一试用 LPU 跑长文本批处理预算有限、团队人少先 GPU API 或租卡自购硬件或大规格 TPU最后分享一个我最近踩的坑。给朋友调一个 Groq API 接入项目没仔细看模型规格就直接用了默认的llama-3.1-70b-versatile结果输入一段 30K 字符的长文档响应直接报context_length_exceeded错误。查文档才发现这个模型的 max context 只有 32K tokens按照中文字符换算我的输入早就超额了。后来换成支持 128K 上下文的模型问题才解决。这件事给我的教训是用任何算力平台之前先读它的规格文档尤其是上下文长度和计费方式这两项最容易在项目上线后暴雷。我个人在实际项目里的选择逻辑是如果没有特殊理由第一选择永远是 GPU——不是因为它性能最强而是因为它最“不折腾”。等业务稳定、用量起来之后再根据推理负载、成本结构去横向评估是否引入 TPU 或 LPU。算力本质上就是把钱变成计算时间的工具谁能在你当前的场景里把每分钱花得最值谁就是那个“性价比之王”。