1. 为什么LLM推理需要专用硬件加速器

大模型推理这件事，表面上看是"输入一句话，等几秒，出一段话"，但真正跑过推理服务的人都知道，这几秒背后是一场和内存带宽、算力利用率、功耗墙的贴身肉搏。我最早在一台单卡工作站上部署7B模型时，第一反应是"GPU利用率怎么才30%"，后来才明白，LLM推理的瓶颈根本不在算力峰值，而在显存带宽和KV Cache的读写效率。

1.1 从Transformer的计算特征说起

LLM的核心是Transformer结构，推理过程分两个阶段：Prefill（预填充）和Decode（解码）。Prefill阶段把整段prompt一次性送进去，矩阵乘法的规模大、并行度高，属于计算密集型；Decode阶段每次只生成一个token，每生成一个token都要把之前所有token的KV Cache读一遍，属于典型的访存密集型。

这两个阶段的硬件需求完全不同。Prefill吃的是算力（FLOPS），Decode吃的是带宽（Bytes/s）。一块标称算力很高的卡，如果显存带宽跟不上，Decode阶段的token生成速度（tokens/s）会惨不忍睹。这就是为什么很多加速器厂商在宣传时，除了标FLOPS，还要重点标内存带宽和能效比（tokens/Joule）。

用一个生活化的类比：Prefill像是往一个大水池里注水，水管越粗越快；Decode像是每次只舀一瓢水，但每次舀之前都要把整个水池的水搅动一遍，搅动的速度取决于水池的循环系统，而不是注水管。

1.2 通用GPU的三个"不划算"

通用GPU（比如常见的数据中心卡）跑LLM推理，有三个地方不划算：

• 功耗不划算：一颗高端数据中心GPU功耗动辄几百瓦，但Decode阶段算力利用率可能只有个位数百分比，大量晶体管在空转。
• 成本不划算：通用GPU要兼顾训练和推理、要支持各种精度和算子，芯片面积和封装成本高，推理场景用不到那么多通用性。
• 延迟不划算：通用GPU的调度和内存层级是为通用计算设计的，KV Cache的访问模式在通用架构上不是最优路径。

专用AI硬件加速器的思路，就是针对LLM推理的访存模式做定制：把KV Cache放在离计算单元更近的地方，用更宽的片上互联，砍掉推理用不到的通用逻辑，把能效比拉上去。

1.3 加速器的几种技术路线

目前针对LLM的AI硬件加速器，大致分几条路线，每条路线的取舍逻辑不一样：

选哪条路线，取决于你要服务的场景：是云端高吞吐批推理，还是端侧低延迟单路推理，还是边缘设备上的离线推理。场景不同，加速器的架构取舍完全不同。

2. 加速器核心架构拆解与关键参数

理解了为什么需要专用加速器，接下来拆解一台LLM加速器内部到底由哪些部分组成，以及每个部分的参数怎么影响实际推理表现。

2.1 计算阵列：MAC单元怎么排布

加速器的计算核心是MAC阵列（乘累加单元阵列）。LLM推理里绝大部分计算是矩阵乘法，矩阵乘法可以拆成大量的乘累加操作。MAC阵列的排布方式决定了算力密度和灵活性。

常见的排布有脉动阵列（Systolic Array）和二维网格两种。脉动阵列的特点是数据像心跳一样在阵列里流动，每个MAC单元只和邻居通信，布线简单、能效高，但灵活性差，适合固定尺寸的矩阵乘。二维网格灵活，但布线和调度复杂。

对于LLM推理，因为模型层数多、每层矩阵尺寸相对固定，脉动阵列是比较常见的选择。关键参数是阵列规模（比如128x128、256x256）和支持的精度（FP16、BF16、INT8、INT4）。

实操心得：阵列规模不是越大越好。阵列越大，单个矩阵乘的并行度越高，但小batch推理时利用率会下降。如果你的服务以单路低延迟为主，中等规模阵列加高主频往往比超大阵列更实用。

2.2 片上缓存：KV Cache放哪里

KV Cache是LLM推理的"记忆"，每生成一个token，都要把历史token的Key和Value读出来参与注意力计算。KV Cache的大小随序列长度线性增长，一个13B模型在2048序列长度下，KV Cache可能占到几个GB。

加速器设计里，KV Cache的存放位置直接决定Decode速度：

• 放HBM：容量大，但带宽受限，每次读KV Cache都要走片外，延迟高。
• 放SRAM：带宽极高、延迟低，但容量小，通常只有几十MB，放不下长序列的完整KV Cache。
• 分层放：近期token的KV放SRAM，远期token的KV放HBM，按需换入换出。

分层方案是目前比较务实的做法。关键参数是SRAM容量和HBM带宽的配比。我的经验是，SRAM至少要能放下最近512到1024个token的KV，才能让Decode阶段的访存大部分命中片上。

2.3 互联带宽：片间怎么连

单芯片放不下大模型的全部权重，多芯片互联是必然。互联带宽决定了多芯片协同推理时的效率。

互联分两个层面：片内互联（计算单元到缓存的通路）和片间互联（芯片到芯片的通路）。片内互联用NoC（片上网络），片间互联用高速SerDes或者光互联。

关键参数是互联带宽与计算带宽的比值。如果互联带宽远小于计算带宽，多芯片协同时会因为等数据而空转。一般来说，片间互联带宽至少要达到单芯片内存带宽的1/2以上，多芯片扩展的效率才不会掉得太厉害。

2.4 精度支持：INT4到底能不能用

LLM推理的精度选择是个权衡：精度越低，算力和带宽需求越小，但模型质量可能下降。

• FP16/BF16：质量最稳，但算力和带宽需求最高。
• INT8：质量损失很小，算力和带宽需求减半，是目前主流的推理精度。
• INT4：算力和带宽需求再减半，但质量损失因模型而异，需要配合量化感知训练或者GPTQ/AWQ这类后训练量化方法。

加速器如果原生支持INT4，等效算力可以做到FP16的4倍。但要注意，INT4的反量化开销不能忽略，如果反量化在通用核上做，反而会成为瓶颈。好的设计会把反量化逻辑做进计算阵列旁边。

注意：不是所有模型都适合INT4。小模型（7B以下）对量化更敏感，INT4后质量下降明显；大模型（30B以上）冗余度高，INT4往往能保持不错的质量。上线前一定要在自己的评测集上跑一遍，别只看公开榜单。

3. 从零搭建LLM推理加速环境的实操过程

理论讲完，进入实操。这一节我按"环境准备→模型转换→推理服务→性能调优"的顺序，把一台LLM加速器从开箱到跑通推理的完整流程走一遍。以下步骤基于常见的加速器SDK和推理框架实践，具体命令因厂商而异，但思路通用。

3.1 环境准备与驱动安装

拿到加速器后，第一步是装驱动和运行时。大多数加速器厂商会提供一套类似CUDA的软件栈，包括驱动、运行时库、算子库和推理框架插件。

# 以常见的加速器软件栈为例，检查设备是否被识别 lspci | grep -i accelerator # 安装驱动（具体包名因厂商而异） sudo dpkg -i accelerator-driver-*.deb sudo reboot # 安装运行时和算子库 pip install accelerator-runtime accelerator-ops # 验证设备可见性 accelerator-smi

accelerator-smi能列出设备、显存占用、温度、功耗，说明驱动装好了。如果这一步报错，先检查内核版本和驱动是否匹配，这是最常见的坑。

实操心得：驱动和固件的版本一定要对齐。我踩过一次坑，驱动是新的、固件是旧的，结果推理时随机出现结果不一致，排查了两天才发现是固件版本问题。装完驱动后，务必用厂商提供的自检工具跑一遍。

3.2 模型转换与量化

加速器通常不直接吃HuggingFace格式的权重，需要转换成厂商的中间格式，顺便做量化。

# 以常见的转换流程为例 from accelerator_tools import ModelConverter converter = ModelConverter( model_path="meta-llama/Llama-2-13b-hf", output_path="./llama2-13b-accel", precision="int8", # 量化精度 calib_dataset="./calib.jsonl", # 量化校准集 max_seq_len=4096, ) converter.convert() converter.verify() # 验证转换后精度损失

量化校准集很关键。校准集要覆盖你实际业务里的输入分布，否则量化后的模型在你的场景上可能掉点严重。我一般会从线上日志里采样500到1000条真实请求做校准。

转换完成后，verify()会对比原模型和转换后模型在若干样本上的输出差异。如果差异过大，要么换校准集，要么退回INT8甚至FP16。

3.3 推理服务部署

转换好的模型通过推理框架加载。大多数加速器会提供自己的推理引擎，或者适配主流框架（如TensorRT-LLM、vLLM的加速器后端）。

# 以常见的推理引擎为例 from accelerator_inference import LLMEngine engine = LLMEngine( model_path="./llama2-13b-accel", max_batch_size=32, max_seq_len=4096, kv_cache_dtype="int8", # KV Cache量化 tensor_parallel=2, # 张量并行度，对应芯片数 ) engine.start() response = engine.generate( prompt="解释一下什么是注意力机制", max_new_tokens=256, temperature=0.7, ) print(response)

tensor_parallel要和实际芯片数匹配。2路张量并行意味着模型权重被切到2块芯片上，每块芯片算一部分，最后做all-reduce。如果芯片数不够，这个参数设大了会直接报错。

3.4 性能基准测试

服务跑起来后，第一件事是测基准，搞清楚当前配置下的吞吐和延迟。

# 用推理引擎自带的benchmark工具 accelerator-bench \ --model ./llama2-13b-accel \ --batch-size 1,4,8,16,32 \ --input-len 128,512,2048 \ --output-len 128 \ --num-runs 10

重点看三个指标：

• TTFT（Time To First Token）：首token延迟，反映Prefill速度。
• TPOT（Time Per Output Token）：每token生成时间，反映Decode速度。
• 吞吐（tokens/s）：整体吞吐，反映批处理效率。

我实测下来，batch size从1加到8，吞吐能涨3到4倍，但TTFT也会涨。如果业务对首token延迟敏感，batch不能开太大。

3.5 参数调优与显存规划

显存规划是部署时最容易翻车的地方。KV Cache、模型权重、激活值都要占显存，算错了就OOM。

KV Cache的显存占用公式：

KV Cache大小 = 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × batch_size × 精度字节数

以13B模型为例，40层、40头、头维度128、序列长度4096、batch 8、INT8精度：

2 × 40 × 40 × 128 × 4096 × 8 × 1 byte ≈ 13.4 GB

这还没算模型权重（13B INT8约13GB）和激活值。所以13B模型在INT8下，单卡至少需要32GB显存才能跑batch 8、序列4096。显存不够时，要么降batch，要么降序列长度，要么开KV Cache量化。

提示：KV Cache量化到INT8能省一半显存，但要注意，KV Cache量化对长序列任务的质量影响比权重量化更明显。如果业务是长文档问答，KV Cache量化要谨慎。

4. 常见问题排查与性能瓶颈定位

加速器部署过程中遇到的问题，大多集中在精度、性能、稳定性三类。这一节把典型问题和排查思路整理成速查表，再补充几个我踩过的坑。

4.1 精度问题速查

精度问题的排查原则是逐层回退：先关KV Cache量化，再关权重量化，最后回退到FP16。哪一步质量恢复了，问题就定位在哪一层。

4.2 性能瓶颈定位

性能上不去，先分清是Prefill慢还是Decode慢。

• TTFT高、TPOT正常：Prefill瓶颈，通常是算力不够或者batch太大。降batch、升主频、检查是否有算子没走加速器。
• TTFT正常、TPOT高：Decode瓶颈，通常是访存瓶颈。检查KV Cache是否命中片上缓存，检查HBM带宽利用率。
• 两者都高：可能是互联瓶颈或者调度问题。检查多芯片通信是否成为瓶颈。

# 查看加速器利用率和带宽 accelerator-smi --query-utilization --query-memory-bandwidth # 查看推理引擎的profiling accelerator-prof --model ./llama2-13b-accel --profile-level 2

profiling工具能告诉你每个算子的耗时占比。如果发现某个算子耗时异常，大概率是没走加速器，回退到了通用核。

4.3 稳定性问题

稳定性问题最烦人，因为往往不是必现。常见的稳定性坑：

• 长时间运行后性能下降：可能是散热问题，加速器降频了。检查温度和功耗墙。
• 并发请求下偶发超时：可能是调度队列满了，或者KV Cache换入换出抖动。检查队列深度和KV Cache命中率。
• 多芯片推理结果不一致：可能是all-reduce的同步问题，检查通信库版本和拓扑配置。

实操心得：稳定性问题一定要开日志，而且要开详细日志。我遇到过一次偶发超时，最后发现是KV Cache换出时的一个边界条件，只在序列长度刚好跨过某个阈值时触发。没有详细日志根本定位不到。

4.4 几个容易忽略的坑

坑一：忽略预热。加速器首次加载模型和首次推理会慢很多，因为要编译算子、填充缓存。上线前一定要做预热，否则第一批请求的延迟会很难看。

坑二：batch size设成固定值。实际业务请求长度不一，固定batch会导致短请求等长请求。用连续批处理（continuous batching）能显著提升吞吐。

坑三：只看平均延迟，不看P99。平均延迟好看不代表体验好，P99延迟才是用户感知的。调优时要盯P99。

坑四：忽略模型本身的优化。加速器再快，也救不了一个没做任何优化的模型。GQA（分组查询注意力）、FlashAttention、RoPE外推这些模型侧优化，配合加速器能叠加收益。

5. 加速器选型与场景匹配的实战建议

最后聊聊选型。市面上的LLM加速器越来越多，怎么选是个实际问题。我的建议是先定场景，再定指标，最后定产品。

5.1 按场景定需求

• 云端高吞吐批推理：优先看吞吐（tokens/s/卡）和能效比（tokens/Joule），batch能力要强，KV Cache容量要大。
• 云端低延迟单路推理：优先看TTFT和TPOT，batch可以小，但单路延迟要低。
• 端侧/边缘离线推理：优先看功耗和体积，算力可以低，但能效比要高，最好支持INT4。
• 长上下文场景：优先看KV Cache容量和长序列下的带宽保持能力，序列越长越吃带宽。

5.2 按指标做对比

选型时不要只看峰值算力，要看实际场景下的有效算力。有效算力 = 峰值算力 × 利用率。利用率取决于模型结构、batch大小、序列长度。

我一般会要求厂商提供在目标模型和目标场景下的实测数据，而不是跑分数据。跑分数据（比如MLPerf）有参考价值，但和你的实际场景可能差很远。

5.3 生态与迁移成本

加速器的软件生态成熟度，直接决定迁移成本。要重点看：

• 算子覆盖度：主流模型（Llama、Qwen、ChatGLM等）的算子是否都支持。
• 框架适配：是否适配vLLM、TensorRT-LLM、HuggingFace等主流框架。
• 量化工具链：是否提供完整的量化、校准、验证工具。
• 社区活跃度：遇到问题能不能找到资料和同行。

生态不成熟的加速器，迁移成本可能比硬件差价还高。这一点在选型时容易被忽略。

5.4 一个实际的选型决策流程

我自己的决策流程是这样的：

1. 明确场景：吞吐优先还是延迟优先，云端还是端侧，序列多长。
2. 列出硬指标：显存容量、带宽、算力、功耗、互联带宽。
3. 筛选候选：按硬指标筛掉明显不满足的。
4. 实测验证：在候选产品上跑自己的模型和业务数据，看实测吞吐、延迟、质量。
5. 算总账：硬件成本 + 迁移成本 + 运维成本 + 功耗成本，算三年TCO。
6. 小规模试点：先上一小批，跑一段时间再决定是否扩大。

这套流程走下来，基本能避开大部分选型坑。最怕的是被峰值算力忽悠，买回来发现实际场景利用率只有20%，那就亏大了。

LLM推理加速这件事，硬件只是一半，另一半是软件和模型侧的配合。加速器选对了，模型优化没跟上，收益也出不来。反过来，模型优化到位了，通用硬件也能跑得不错。真正的最优解，永远是硬件、软件、模型三者的协同。我在实际项目里最大的体会是：不要指望一块加速器解决所有问题，先把自己的推理链路摸清楚，知道瓶颈在哪，再去找对应的硬件，这样才不会花冤枉钱。