企业官网建设流程全解析

两三个月前，有个做私有化部署的朋友来问我：一张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_bytes=2): 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 TFLOPS，HBM带宽只有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）和算力同等重要。单卡训练大模型不现实，训练集群的瓶颈经常不在算力，而在通信。

推理是"带宽优先"的。刚才算过，低并发时算术强度只有1，HBM带宽直接决定Token速度。高并发时算力才逐步成为约束。对推理来说，延迟和吞吐是两笔账：单流请求看每个Token的延迟，高并发看整体吞吐量。

微调排在中间。以LoRA为例，你需要同时存下权重、梯度、优化器状态和KV Cache，虽然计算量比全量训练小，但对显存容量的要求一点不含糊。7B模型LoRA微调，FP16下光权重加优化器状态就要30GB以上，一张24GB的4090只能开很小的Batch，实际体验很憋屈。

三者的硬件优先级我给你整理成一张表，后面选型会反复用到：

2. 主流加速器家族盘点——GPU、TPU、NPU、FPGA各打什么牌

2.1 GPU：生态护城河最深的大众选择

提到AI硬件加速器，大多数人第一个想到的就是NVIDIA GPU，这并不奇怪。A100、H100、H200到最新的B200，每一代都把Tensor Core、FP8/BF16支持和HBM带宽往前推了一大截。H100的FP8算力接近2000 TFLOPS，H200把显存提到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更漂亮。最新的Trillium（TPU 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路线的不少，国际上也有创业公司在做。这个方向还处在"愿景很性感、落地要看良率"的阶段。

主流的四类加速器我放在一张表里，方便对比：

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只有几十MB，HBM有几十到上百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大约要512KB，32K上下文就要吃掉约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、激活值和推理引擎的开销。我按自己实际部署过的经验整理了一张表，括号里的数据是量化和长上下文的参考调整值：

注意，这张表默认上下文在4K到8K。如果要把上下文开到32K甚至128K，KV 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预估"这两个数算清楚，再谈别的。算力是弹药，但决定你能跑多远的，往往是那根叫内存带宽的缰绳。