两三个月前有个做私有化部署的朋友来问我一张RTX 4090到底能不能把Llama 3 70B跑起来我反问他打算用什么精度、配多长上下文、跑几路并发他愣了一下说不都是显存够就行吗。这个问题其实挺有代表性——现在聊LLM的人很多但真正把AI硬件加速器这几个字掰开揉碎讲清楚的内容还是太少。标题里其实藏着三个关键词LLM、AI、硬件加速器。我想以一个既写过训练代码、又亲手折腾过多种加速卡的从业者视角把大模型为什么这么吃硬件主流加速器各有什么底牌加速器内部原理长什么样怎么选、怎么用、怎么避坑这几件事串成一条线。先抛一个结论LLM时代的硬件加速器评判标准已经和过去做CNN推理时完全不同了。以前大家爱看TOPS每秒万亿次操作现在你得优先看三样东西——显存容量、显存带宽、软件生态能不能把你的模型落地。后面我会把公式、实测数据和踩坑记录全部摊开讲不管你是准备买卡自建还是打算用云上算力都值得看完再动手。早几年聊AI硬件话题基本围绕图像分类、目标检测这类负载特点是算得多、数据少一张边缘端芯片、几个TOPS就能跑得飞快。LLM出现之后事情彻底变了。Transformer架构的自回归生成方式让模型每吐一个Token都像是把全部权重翻一遍。这意味着显存带宽成了真正的瓶颈。市面上不少标称高算力的芯片跑大模型反而慢得离谱原因就在这里。1. 大模型把硬件逼到了什么程度——先看清需求侧1.1 一次前向推理要算多少笔账要理解大模型为什么挑剔硬件得先学会算账。LLM生成文本是自回归的每生成一个Token都要把模型的所有层完整前向计算一遍然后拿新算出的Token作为输入继续算下一个。也就是说生成1000个Token等于把整条计算链跑了1000次。这就带来两个直接的硬件需求。第一是算力忽略一些工程细节一次前向推理每个Token大约需要2N次浮点运算N就是模型参数量。7B模型就是约140亿次浮点运算。第二是数据搬运模型权重在FP16精度下占2N字节7B模型就是约14GB。每生成一个Token理论上都要把这些权重从显存里读一遍。第二个需求往往被忽略但恰恰是它决定了大模型推理的体验。算一下你就明白了A100 80GB的HBM带宽大约是2TB/s除以14GB权重理论上每秒钟最多生成约143个Token。H100的HBM带宽是3.35TB/s理论值能到239 Token/s左右。H200把HBM3e带宽拉到4.8TB/s对应350 Token/s上下。这个权重总字节数除以带宽的公式就是大模型单Token推理速度的第一性原理。很多朋友拿到卡第一件事就是看TFLOPS其实对大模型推理来说先看HBM带宽和显存容量才对。我用一个平时自己算配置的小脚本给大家参考def tokens_per_sec(hbm_bandwidth_gbps, params_b, dtype_bytes2): weight_gb params_b * dtype_bytes return hbm_bandwidth_gbps / weight_gb print(tokens_per_sec(2000, 7)) # A100 80GB 7B FP16约 142 tok/s print(tokens_per_sec(4800, 7)) # H200 7B FP16约 342 tok/s注意这是理论极限实际还要扣掉KV Cache读写、注意力计算、框架开销通常只能到六七成。不过这个数量级能帮你快速判断一张卡到底行不行。1.2 显存带宽真正让大模型喘不过气的指标要理解为什么带宽比算力更要命得引入Roofline模型里的一个概念算术强度也就是每搬运一个字节的数据能做多少次运算。单位是FLOP/Byte。LLM推理在并发数很低时每个Token的算术强度大约是2N次运算比上2N字节也就是1 FLOP/Byte左右。而一块H100的FP16稠密算力接近989 TFLOPSHBM带宽只有3.35TB/s两者相除硬件的拐点大约在295 FLOP/Byte。你的负载算术强度只有1硬件拐点是295差了两个数量级。这意味着什么意味着计算单元大部分时间在等数据GPU的Tensor Core闲着显存控制器忙得不可开交。这就是典型的存储受限Memory-Bound状态。只有把并发Batch足够堆大比如一次性处理几十上百个请求每个权重字节被多个请求复用算术强度才会上来计算单元才能吃饱。所以做推理服务的人会有个直觉在线聊天这种低并发场景瓶颈在带宽离线批量打分这类高并发场景瓶颈才转到算力。厂商在宣传里最爱讲的XX TFLOPS恰恰是你在低并发推理时最用不上的指标。1.3 训练、推理、微调三种负载三种硬件优先级不少人是一张卡想干所有事结果训练卡拿去推理嫌贵推理卡拿去微调又爆显存。这里我建议把负载拆成三类来看。训练是最贪婪的。每个Token的前向加反向大约要6N次浮点运算7B模型一次迭代就是840亿次这要求芯片有极高的稠密算力和矩阵利用率。同时梯度需要在多卡间做AllReduce同步所以卡间互联带宽NVLink、InfiniBand和算力同等重要。单卡训练大模型不现实训练集群的瓶颈经常不在算力而在通信。推理是带宽优先的。刚才算过低并发时算术强度只有1HBM带宽直接决定Token速度。高并发时算力才逐步成为约束。对推理来说延迟和吞吐是两笔账单流请求看每个Token的延迟高并发看整体吞吐量。微调排在中间。以LoRA为例你需要同时存下权重、梯度、优化器状态和KV Cache虽然计算量比全量训练小但对显存容量的要求一点不含糊。7B模型LoRA微调FP16下光权重加优化器状态就要30GB以上一张24GB的4090只能开很小的Batch实际体验很憋屈。三者的硬件优先级我给你整理成一张表后面选型会反复用到负载类型首要瓶颈次要瓶颈典型执行时长全量预训练算力 卡间互联带宽数天到数月LoRA/全量微调显存容量算力数小时到数天在线低并发推理HBM带宽显存容量毫秒级/Token高并发批量推理算力带宽 容量持续服务2. 主流加速器家族盘点——GPU、TPU、NPU、FPGA各打什么牌2.1 GPU生态护城河最深的大众选择提到AI硬件加速器大多数人第一个想到的就是NVIDIA GPU这并不奇怪。A100、H100、H200到最新的B200每一代都把Tensor Core、FP8/BF16支持和HBM带宽往前推了一大截。H100的FP8算力接近2000 TFLOPSH200把显存提到141GB、带宽拉到4.8TB/s直接让单卡塞进70B模型成为可能。B200更是在算力和功耗上都上了新台阶。GPU最大的优势不是单卡性能而是生态。CUDA、cuBLAS、TensorRT、vLLM、Torch等等几乎所有的框架和推理引擎都优先适配NVIDIA。你遇到的大部分性能问题和踩坑记录网上都有现成答案。这一点在工程上价值巨大因为AI硬件加速器从来不是硬件单打独斗而是软硬件的合力。AMD的MI300X是另一个值得注意的选择。它有192GB HBM3和5.3TB/s的带宽显存容量和带宽都超过H100价格通常更低。ROCm这几年兼容性进步明显PyTorch官方已经支持vLLM也有ROCm版本。但客观讲一些细碎算子的性能坑还是需要自己填团队规模小的话要有心理准备。消费级市场里RTX 4090凭借24GB显存和1TB/s带宽成了本地跑7B、14B量化模型的热门选择。不是因为它算力多强而是它在万元价位提供了能装下小模型的显存和靠谱的生态。很多人忽略了4090的功耗和散热问题——满载能到450W放机箱里吹出来的热风能当暖气用。2.2 TPU为Transformer而生的专用矩阵机TPU是Google完全围绕深度学习矩阵运算设计的芯片走的路线和GPU很不一样。它的核心是脉动阵列Systolic Array用大量处理单元组成阵列让数据像流水线一样在阵列中流动。这种设计让矩阵乘法GEMM的利用率极高单位功耗能出的算力比GPU更漂亮。最新的TrilliumTPU v6和TPU v5p在大规模预训练场景里都是标杆级的存在。但TPU的短板也非常明显第一只有Google Cloud能租到没法买回家自建第二软件栈被绑定在JAX和XLA上PyTorch虽然能跑但碰到自定义算子就会很痛苦第三单芯片的显存容量相对GPU并不突出长上下文场景需要靠TPU的多卡池化来解决。我的判断是如果你是在Google Cloud上做大规模预训练或者整套技术栈本来就是JAX生态TPU是性价比极高的选择。如果你的应用要频繁改模型结构、上各种新的推理优化TPU的灵活度会让你抓狂。它是一个优秀的专用件但不是通用件。2.3 NPU与推理ASIC在功耗和延迟上做极限取舍在GPU和TPU之外有一大批为推理而生的专用芯片它们把取舍做得更极致。Groq的LPU是最典型的例子。它干脆放弃了HBM把几百MB的SRAM直接堆在芯片上靠SRAM的超高带宽来喂计算单元。结果就是在单Token延迟上极其惊艳适合对首Token和每Token延迟极度敏感的场景。代价是显存容量小大模型必须切得非常碎多卡互联就成了新瓶颈。Cerebras走的是另一条极端路线晶圆级引擎。把一整片晶圆做成一个芯片片上SRAM容量达到几十GB靠巨大的片上带宽省掉了大量HBM搬运。它在训练稠密大模型时的扩展性表现很突出但单片价格和软件适配的门槛都不低。国内云厂商里常见的昇腾910B系列也是一类NPU。它针对Transformer做了大量优化配合CANN软件栈在国产算力需求的推动下生态已经比两年前成熟很多但迁移成本和算子生态的坑依旧是绕不开的现实。边缘端也有一大批NPU在默默干活比如手机SoC里的NPU、PC里的AI加速单元。它们的典型特征是走INT8路线TOPS很漂亮但内存带宽和容量有限适合跑1B以下的小模型。别指望边缘NPU跑动70B模型那是用途错配。2.4 FPGA与Chiplet中间路线到底行不行FPGA在AI硬件加速器历史上当过主角但到了LLM时代它的处境有些尴尬。同样算力下FPGA的频率和功耗都不占优编程模型也复杂通常只有两个场景还在用一是需要灵活定制接口和协议的原型验证二是延迟要求极低、需要把网络、存储、计算定制在一套流水线里的特殊项目。跑通用Transformer大模型性价比不划算。Chiplet方向倒值得关注。把计算Die、HBM和IO Die用2.5D/3D封装拼在一起既能摊薄大芯片的制造成本又能灵活组合算力与存储。UCIe等互联标准的成熟会让这套玩法更普遍。国产GPU走Chiplet路线的不少国际上也有创业公司在做。这个方向还处在愿景很性感、落地要看良率的阶段。主流的四类加速器我放在一张表里方便对比类型代表架构特点优势短板GPUNVIDIA H100/B200、AMD MI300XSIMT Tensor Core生态成熟、灵活通用功耗高、价格贵TPUTPU v5p/Trillium脉动阵列算力密度高、大模型预训练强绑定JAX/XLA不易入手推理NPU/ASICGroq LPU、Cerebras、昇腾SRAM优先/晶圆级低延迟、高能效显存容量小、生态封闭FPGA/Chiplet各类原型卡、UCIe方案可重构/芯粒集成灵活可定制研发周期长、生态弱3. 加速器内部是怎么伺候LLM的——关键架构原理解读3.1 矩阵乘法引擎从SIMT到脉动阵列不管哪类加速器内部最核心的单元都是矩阵乘法引擎因为Transformer里注意力、FFN全是GEMM。GPU走的是SIMT路线大批线程同时干活配合Tensor Core做分块矩阵乘。Tensor Core本质上是一个针对小矩阵乘法定制的计算阵列比如一次算4x4x4的FP16矩阵乘靠大量的排列组合把吞吐堆上去。它的优势是灵活各种尺寸、各种布局都能处理。TPU等芯片则选了脉动阵列。它把上百个处理单元排成阵列数据在每个单元之间按固定节奏流动中间结果从一个单元直接传到下一个单元几乎不经过寄存器堆。这种设计让每个数据被反复复用非常适合大GEMM。它的优势是确定性强、利用率高劣势是遇到不规则算子比如动态形状、稀疏路由时阵列有一大半会闲着。理解了这两种路线你就能明白为什么同样标称数百TOPS的芯片跑Transformer的表现天差地别。GPU靠灵活适配各种形状ASIC靠对GEMM的极致压榨。你在选型时如果模型结构里定制算子多、形状变化大通用GPU更稳如果负载就是标准Transformer密集GEMM专用阵列的性价比确实更高。3.2 内存层级设计为什么HBM是当之无愧的主角LLM加速器的内存层级大致是寄存器 → 片上SRAM → HBM → 主机内存/SSD。片上SRAM只有几十MBHBM有几十到上百GB但二者的带宽差距巨大HBM大约2到5TB/s片上SRAM的聚合带宽能到几十TB/s量级。问题的关键在于模型权重放在HBM里每生成一个Token都要跨过HBM这道窄门读一遍。所以HBM的带宽和容量直接决定了推断体验的天花板。HBM的原理是让多层DRAM die像盖楼一样堆叠靠硅通孔TSV垂直互联因此能同时开非常多的数据通道带宽远超普通DDR内存。代价是成本高、容量单Stack有上限所以GPU上通常焊四到八个Stack。HBM3e时代单卡做到192GB甚至更多不成问题HBM4也已经提上日程本质都是在打带宽紧缺这场仗。近存计算和存内计算也值得关注。三星等厂商在做HBM-PIM把计算单元直接塞进DRAM die让部分矩阵运算在内存里完成绕开HBM搬运。这条路对LLM推理特别有吸引力因为它直接砍掉了权重搬运的开销。不过目前产品化程度有限软件栈也没准备好属于看得到、吃不到的储备技术。3.3 低精度计算与稀疏化硬件如何把Token成本打下来大模型推理优化最立竿见影的手段是降精度而硬件对低精度的支持决定了你能降多狠。FP16/BF16是基准FP8分为e4m3和e5m2两种格式能让同样的硬件跑出大约两倍吞吐INT8再翻一倍。到了INT4/INT3虽然芯片原生矩阵单元不支持直接算但权重占用的带宽少了一半以上配合反量化内核实际Token速度反而能大涨。现在的量化方案已经很成熟GPTQ和AWQ做权重量化SmoothQuant处理激活值Kernel层面有Marlin、bitsandbytes这些高度优化的算子。7B模型INT4量化后权重只有3.5GB左右一张消费级卡就能跑速度还比FP16快不少。代价是量化校准需要花时间极端情况下会掉一点点精度。硬件这边NVIDIA从Ampere开始支持2:4结构化稀疏每四个权重里恰好两个为零Tensor Core就能跳过零值理论近两倍加速。这项技术的硬件成本很低但实际模型稀疏度要做到2:4还很难所以落地不算广。低精度方向真正的趋势是训练时就低精度FP8训练、INT4训练正在从实验走向生产硬件厂商也把相关指令集铺得更全。3.4 KV Cache专用加速针对长上下文的新设计大模型还有一项被很多文章一笔带过的显存开销KV Cache。每生成一个Token注意力层都要缓存之前的Key和Value避免重复计算。缓存大小有个很吓人的公式每Token占用的字节数等于2倍层数乘以注意力头数乘以每个头的维度再乘以精度字节数。套到Llama 2 70B这样规模的模型上每Token大约要512KB32K上下文就要吃掉约16GB显存。这意味着长上下文不仅考验算力更考验显存容量带宽。而且每次新Token都要把之前的KV Cache读一遍参与注意力计算这又是一大笔带宽开销。软件层面的解法已经很多FlashAttention把注意力计算重排大幅减少HBM读写vLLM的PagedAttention把KV Cache分成固定大小的页像操作系统的内存分页一样按需分配GQA分组查询注意力从模型结构上减少KV头的数量从源头砍掉KV Cache体积。硬件层面应对方式就直白得多加大HBM容量、提高带宽以及把更多的注意力计算挪到片上SRAM。未来还可能出现专门服务KV Cache的硬件压缩、分级缓存单元。对做推理架构的人来说KV Cache的计算应该成为基本功否则你永远不知道为什么同样的模型别人的机器能开2万上下文你的机器爆显存。4. 从选型到实测把硬件真正跑起来的完整心法4.1 按模型规模倒推硬件配置一张实用的对照表选硬件之前先明确一个原则不要用显存够装模型权重来选卡那是最低门槛不是合理配置。你还要留出KV Cache、激活值和推理引擎的开销。我按自己实际部署过的经验整理了一张表括号里的数据是量化和长上下文的参考调整值模型规模FP16权重占用推理参考显存推荐硬件微调建议0.5–2B1–4GB4–8GBRTX 4060、旗舰手机/PC NPU8GB以上7–8B14–16GB24GB左右RTX 4090、L40S24GB以上13–14B26–28GB40–48GBA100 80GB、L40S48GB以上30–40B60–80GB80–100GBA100/H100 80GB 或双卡多卡并行70B140GB160GB以上H200 141GB 或双卡Tensor Parallel4卡以上100B200GB多卡池化多卡模型/流水并行集群注意这张表默认上下文在4K到8K。如果要把上下文开到32K甚至128KKV Cache会把显存需求往上顶一个甚至两个档位尤其是大模型。我的建议是先用上一节的KV Cache公式预估再按预估结果选卡。4.2 软件栈才是真正的战场CUDA、ROCm与推理引擎硬件只决定上限软件栈决定你能拿到百分之多少。这句话在这个领域混得越久体会越深。同样一张H100用最原始的Hugging Face Pipeline跑和在TensorRT-LLM/vLLM上跑吞吐能差出三四倍还不止。所以选硬件本质上也是在选它背后的软件生态。NVIDIA阵营的推理栈最成熟TensorRT-LLM负责极致优化vLLM负责高并发服务SGLang在复杂推理场景表现不错llama.cpp则适合本地单机轻量部署。这些工具链的共同点是发展极快基本跟着新硬件的节奏走。AMD阵营这几年ROCm和vLLM的配合已经能打但遇到冷门算子时你可能会被迫自己写Triton内核。昇腾的CANN和MindIE也在快速补齐不过从PyTorch迁移过来依然需要一段阵痛期。我的实操建议是先把模型跑在一个通用引擎上比如vLLM确认功能正确再用更重的优化引擎如TensorRT-LLM去压吞吐。上来就奔着Triton手写算子除非你就是吃这碗饭的否则大概率把所有时间花在调优一个本来就用不上的极点上。4.3 实测中踩过的性能坑与调优记录这个板块写点真东西。这几年我从几张卡到十几张卡都折腾过LLM推理的坑基本分四类容量不够、带宽浪费、通信瓶颈、散热降频。逐个说说。坑一只核显存容量、不核带宽。有次给客户选推理卡对方看中一张算力很高的国产加速卡结果一测7B模型只有每秒十几个Token因为HBM带宽只有可怜的几百GB/s。好卡坏卡跑一次就现形。坑二上下文长度把显存顶爆。部署时只按权重大小算显存上线后用户一直在长文档问答KV Cache瞬间吃光显存服务直接OOM重启。后来我把KV Cache估算写进了部署脚本每加一个模型版本都先做长上下文压测再没出过这事。坑三推理引擎版本不匹配。有次升级cuBLAS和框架版本后某模型性能倒退30%查了半天发现是TensorRT-LLM版本和CUDA小版本不兼容回退才恢复正常。生产环境的版本锁定必须做得很死。坑四Tensor Parallel在跨机场景反而变慢。多卡并行做AllReduce卡间如果是NVLink那么速度飞快一旦跨机器走以太网通信开销就能把计算收益吞掉。实测下来8卡以内的单机Tensor Parallel收益明显跨机就老老实实做流水并行或者干脆每机独立服务。真到了需要跨机池化大模型的程度建议认真评估InfiniBand或RoCE方案的预算。坑五不开Continuous Batching吞吐上不去。在线推理服务不是一个个请求排队处理而是把多个请求混在一个Batch里动态调度的。vLLM默认做了但很多自研框架没做结果GPU利用率极低。这是高吞吐和低吞吐的分水岭。坑六散热和供电导致降频。消费级卡放机房长期跑满温度一上来频率就往下掉Token速度跟着掉。有条件就选数据中心卡没条件就把机箱风道做实别让硬件在红线边缘挣扎。4.4 算力经济账自建、租赁还是混合硬件选型最后绕不开钱。我见过不少团队一上来就买卡结果利用率不到20%电费和折旧白烧也见过反过来的长跑服务用按需实例月底账单吓人。核心判断标准是利用率。先说租赁。按云厂商常见价格一块H100按小时大概在两三美元量级4090云主机几毛钱一小时。短期验证、突发实验租赁绝对划算因为你随时可以释放。最省钱的玩法是先租卡把模型和推理引擎全跑通压测出这个模型到底需要多少张卡、什么配置再进入下一步。再说自建。自建的成本不只是卡钱还有服务器整机、机房机位、电力、散热、运维人力。一张H100的功耗高达700W一台8卡机器满载就是近6千瓦一年电费算下来很可观。按三年折旧综合持有成本通常比云上同配置高出一截。除非你的业务7x24小时满负荷跑且对数据主权有硬性要求否则自建很难算得过账。我现在的做法是混合跑通和生产验证用云上按需稳定后有长期负载的机器转为包年包月或者预留实例。自建只考虑一种情况——业务规模大到云成本已经超过一块自建集群摊销且运维团队能接得住。5. 我眼中的下一步硬件加速器的演化方向5.1 内存墙问题的三种解法大模型越做越大带宽和容量的缺口只会更紧。现在行业里解内存墙的路子大致有三条。第一条是把HBM继续做大做强单卡容量往200GB以上走带宽往5TB/s以上走这是最直接但成本最高的路。第二条是存内计算把部分计算塞进内存直接跳开HBM搬运理论收益极高但工程成熟度不足。第三条是从模型侧倒逼MoE稀疏激活让每个Token只加载部分专家权重量化把权重字节数压到四分之一甚至八分之一蒸馏和缓存进一步减少重复计算。我的判断是三条路会同时走硬件的进步和算法的瘦身会互为条件。5.2 多卡互联与异构调度的趋势单卡的容量和带宽总有尽头多卡互联正在成为硬件加速器体系的一部分。你买的不再是一张卡而是一整套互联拓扑。NVIDIA的NVLink加上NVSwitch让几十张卡像一台大卡一样协同AMD联合几家公司推UALink意图打破封闭生态CXL内存池化则让远端内存也能参与进来解决单机内存墙问题。在调度层面异构的趋势也很明显一个集群里可能有GPU、推理ASIC、CPU一起干活。MoE模型可以把热门专家放在高算力卡上冷门专家放在普通实例上投机解码可以用小模型加速器生成草稿再由大模型验证。硬件加速器之间的协同会比单卡性能更值得关注。5.3 算法-硬件协同设计从适配走向共生最后聊个趋势接下来的加速器设计会更早地把模型算法考虑进去而不是等模型摆在那再被硬件适配。MoE路由可以做成硬件机制低比特训练需要芯片原生支持投机解码甚至要求大小两种模型能高效跑在同一块芯片的不同区域。这才是真正的针对LLM的AI硬件加速器——不是通用计算芯片跑Transformer而是围绕Transformer的特点重新设计芯片。这几年手里经手的加速卡从GPU到ASIC都有我最大的体会是硬件参数只是一个起点真正决定项目死活的是你懂不懂带宽、显存、软件栈和成本账这四本账。如果只让我留一条建议那就是选型前先把权重体积除以带宽和KV Cache预估这两个数算清楚再谈别的。算力是弹药但决定你能跑多远的往往是那根叫内存带宽的缰绳。