LLaMA-2-7B部署实战：TensorRT加速全流程与性能对比

LLaMA-2-7B 部署这件事，圈子里从来不缺方案：vLLM 一条命令就能把服务跑起来，llama.cpp 轻量到在迷你主机上都能转，HuggingFace 原生 pipeline 更是零门槛。但当你真要把模型压到生产环境、被显存卡住脖子、或者面对高并发请求发愁的时候，TensorRT 的优势就实打实摆在那了。这篇文章是我自己从零到一做的完整实操记录：环境版本怎么匹配、TensorRT 怎么装最省心、LLaMA-2-7B 从 HuggingFace 权重到可部署 TensorRT 引擎的全过程，以及 Python 和 C++ 两个端各自如何把推理代码跑通。顺带把我在 RTX 5070 上做 YOLO12 ONNX 转 TensorRT 时踩过的坑和沉淀下来的 C++ 调用模板一起整合进来，一次说透。这篇内容适合正在给 LLM 选型部署方案的工程师，也适合已经被 TensorRT 版本兼容问题折磨过几轮的老哥。

1. 项目整体设计与方案选型

1.1 先摸清 LLaMA-2-7B 的脾气

动手之前必须把模型的基本盘捋清楚。LLaMA-2-7B 是稠密自回归架构，32 层 Transformer 解码器，隐藏维度 4096，前馈网络用 SwiGLU 激活函数，注意力部分采用 GQA（分组查询注意力），32 个 Q head 共享 8 个 KV head，词表大小 32000，原版训练上下文长度 4096 tokens。这些参数直接决定了部署策略。

先说显存这笔账。7B 参数在 FP16 精度下，光权重就要占约 14GB 显存，再加上激活值、CUDA context 和 KV Cache，一块 24GB 的卡跑 FP16 才算宽裕。我这次主力测试卡选了 RTX 4090 24GB，同时拿 RTX 5070 12GB 做了 INT8 量化后的可行性验证，两个卡位的数据都有。为什么最终选择 TensorRT？如果只看推理速度，PyTorch eager 模式在解码阶段连 40% 的硬件理论算力都吃不满，而 TensorRT 通过算子融合、kernel 自动调优、低精度推理，能把 decode 吞吐拉到接近显存带宽上限的程度。我实测下来，LLaMA-2-7B 在 FP16 下 TensorRT 引擎的解码速度比 PyTorch 原生快 40% 到 80%，这个差距在显存带宽更紧张的小卡上还会被放大。

1.2 部署方案横向对比：别急着选型

做选型的时候我把主流路线都跑过一遍，各自的优劣列个表：

我这次走的是经典路线：HuggingFace 权重 → ONNX → TensorRT engine → 推理。这条路子和 YOLO 系列转 TensorRT 的流程几乎一致，之前积累的工具链和踩坑经验能无缝复用，代价是 ONNX 导出这个环节对带 KV Cache 的 LLM 稍微繁琐，这个后面专门展开。

可能有朋友会问：既然搞 LLM 部署，为什么不直接用 TensorRT-LLM？我的判断是，TensorRT-LLM 更适合从零搭建一个标准 LLM 服务，但我这次的需求是把 LLaMA-2-7B 塞进现有的 TensorRT 推理框架里，这个框架本来就是给 YOLO 等视觉模型写的，C++ 推理模块都现成，直接把 LLM 的 ONNX/Engine 接进去复用率最高。而且 TensorRT-LLM 对自定义模型、自定义算子的支持往往要打补丁，调试成本不一定低于自己掌握一套通用 TensorRT 流程。通用 TensorRT 这条路跑通一次，视觉模型和 LLM 两大类部署能力就都拿到手了，ROI 很划算。

1.3 版本基线：版本不对，后面全白费

说句实在话，TensorRT 项目八成以上的报错都出在版本兼容上。我这次最终锁定的组合如下，可以直接抄作业：

• 操作系统：Ubuntu 22.04 LTS
• GPU：RTX 4090 24GB（主力）、RTX 5070 12GB（INT8 验证）
• 显卡驱动：550.54.14
• CUDA Toolkit：12.4
• cuDNN：9.1.0
• TensorRT：10.3.0
• Python：3.10
• PyTorch：2.3.0，transformers：4.42.4

版本匹配的核心原则是：驱动版本必须大于等于 CUDA 要求的最低驱动，CUDA 大版本要对上 TensorRT 的依赖要求，cuDNN 再跟着 CUDA 走。TensorRT 10.x 对 CUDA 12.x 的适配最成熟，这也是我选 10.3 的原因之一。这套组合我在两台机器上分别装过，没遇到不可解的冲突，可以放心用。如果你用的是更新的 50 系显卡，驱动版本建议直接上最新稳定版，别的组件版本参照这个表对齐。

2. 环境搭建与 TensorRT 安装实战

2.1 两种安装方式，我的选择是 tar 包

TensorRT 官方提供 deb、rpm、tar 包三种安装方式。Linux 上我强烈推荐 tar 包，原因很实际：解压即用，不需要 root 权限，换版本删目录走人，干净利落。deb 包虽然会自动把库文件拷贝到系统路径，看起来省事，但 TensorRT 版本迭代太快，装多了系统路径里散落一堆历史版本，后面排查问题眼花缭乱。

tar 包安装流程：

# 1. 从 NVIDIA 官网下载 TensorRT 10.3.0 的 tar 包 # 文件名类似 TensorRT-10.3.0.Linux.x86_64-gnu.cuda-12.4.tar.gz # 2. 解压到指定目录 mkdir -p ~/opt && tar -xzf TensorRT-10.3.0.Linux.x86_64-gnu.cuda-12.4.tar.gz -C ~/opt # 3. 把环境变量写进 ~/.bashrc export TRT_ROOT=~/opt/TensorRT-10.3.0 export LD_LIBRARY_PATH=$TRT_ROOT/lib:$LD_LIBRARY_PATH export PATH=$TRT_ROOT/bin:$PATH export PYTHONPATH=$TRT_ROOT/python/python3.10/site-packages:$PYTHONPATH # 4. 验证是否可用 trtexec --version

看到版本号输出就说明 trtexec 就能用了。trtexec 是 TensorRT 自带的命令行工具，既能构建引擎也能跑性能基准，后面我们会频繁用到它。这里有个细节：PYTHONPATH里的路径要和你实际 Python 版本对应，我用的是 Python 3.10，所以路径里出现python3.10。如果换了版本，记得把这里一起改掉，这是很多人装了 TensorRT 却 import 失败的常见原因。

2.2 依赖组件：CUDA 和 cuDNN 的版本陷阱

TensorRT 本身不强制要求装完整 CUDA Toolkit，因为驱动里已经带了 runtime 库，但我们的整个流程要跑 PyTorch 训练脚本、要导出 ONNX、要在 C++ 里做前处理，这些都需要完整 CUDA 环境。所以我仍然装了 CUDA 12.4 Toolkit，并用nvcc --version确认版本一致。

最容易踩的坑是 cuDNN 版本不匹配。TensorRT 10.3 对应 cuDNN 9.x，如果系统里残留的是 cuDNN 8.x，构建引擎时经常报CUDNN_STATUS_NOT_INITIALIZED或者直接静默失败。解决方法是把新版本的 libcudnn.so 路径放到LD_LIBRARY_PATH最前面，同时用ldd确认程序实际加载了哪个库：

ldd ~/opt/TensorRT-10.3.0/bin/trtexec | grep cudnn

我在 RTX 5070 上折腾 YOLO12 ONNX 转 TensorRT 时就踩过这个坑——新机器只装了驱动，没显式装 cuDNN，一跑就报版本不对。后来统一用 conda 环境管理依赖才把这类问题压住。我的建议是每个项目用独立的 conda 环境，CUDA 相关路径别往全局塞，不然新老项目互相污染，排查起来想哭。

2.3 装好之后先别浪，跑一遍官方自检

装完 TensorRT，我强烈建议先跑两个验证，确认链路干净：

# 1. 跑一个内置的 MNIST 样例，验证 Python 绑定和推理链路 cd ~/opt/TensorRT-10.3.0/data/mnist python ~/opt/TensorRT-10.3.0/samples/python/network_api_pytorch_mnist/sample.py # 2. 用 trtexec 构建并跑一个简单 ONNX trtexec --onnx=~/opt/TensorRT-10.3.0/samples/python/network_api_pytorch_mnist/mnist.onnx \ --fp16 --saveEngine=mnist.engine

这两个能跑通，说明 TensorRT 核心、Python 绑定、cuDNN 全部正常。这一步值得花十分钟做，因为后面 LLaMA-2-7B 一旦报错，你会庆幸基础环境是干净的。我最怕的那种情况就是：模型代码没问题、环境一塌糊涂，来回排查两小时发现是 cuDNN 版本残留，白白浪费生命。

3. LLaMA-2-7B 模型转换：从 HuggingFace 权重到 TensorRT 引擎

3.1 ONNX 导出前的模型结构梳理

TensorRT 吃的是 ONNX 图，所以第一步得把 HuggingFace 的 PyTorch 权重导出成 ONNX。LLaMA-2 这类自回归模型的导出有个特殊之处：KV Cache 怎么处理。

自回归生成是逐 token 进行的，每生成一个新 token，都要把之前算好的 Key/Value 缓存拼进注意力计算。ONNX 导出有两种策略：

• 不带 KV Cache 导出：只导出单次前向，推理时自己在业务代码里管理 K/V，每次把完整的历史序列喂进去。这种方式实现最简单，但 decode 阶段反复计算历史部分，浪费严重，越往后越慢。
• 带 KV Cache 导出：把 past_key_values 作为模型的额外输入，每个 decode step 只做增量计算。这是生产部署的必然选择，但导出脚本复杂度高一个台阶。

我这次选了带 KV Cache 的导出方案。如果你按官方例子导出后发现 ONNX 图里没有past_key_values相关的输入输出，十有八九是导出时把模型的use_cache关掉了，这是最常见的坑。

3.2 自定义导出脚本：让 KV Cache 正确上桌

transformers里自带的transformers.onnx.export对 LLaMA-2 的支持并不完整，最后我用自定义脚本完成的导出。核心思路：把模型的 past_key_values 输出作为输入喂回去，用 dynamic_axes 声明所有可变维度：

import torch from transformers import LlamaForCausalLM, LlamaTokenizer model_id = "meta-llama/Llama-2-7b-hf" tokenizer = LlamaTokenizer.from_pretrained(model_id) model = LlamaForCausalLM.from_pretrained(model_id, torch_dtype=torch.float16) model.config.use_cache = True # 构造带 KV Cache 的 forward 包装 def forward_with_past(input_ids, attention_mask, position_ids, past_key_values): outputs = model( input_ids=input_ids, attention_mask=attention_mask, position_ids=position_ids, past_key_values=past_key_values, use_cache=True, ) return outputs.logits, outputs.past_key_values dummy_input_ids = torch.randint(0, 32000, (1, 64), dtype=torch.long) dummy_attention_mask = torch.ones(1, 64, dtype=torch.long) dummy_position_ids = torch.arange(64, dtype=torch.long).unsqueeze(0) _, past = forward_with_past( dummy_input_ids, dummy_attention_mask, dummy_position_ids, None ) torch.onnx.export( model, (dummy_input_ids, dummy_attention_mask, dummy_position_ids, past), "llama2_7b.onnx", input_names=["input_ids", "attention_mask", "position_ids", "past_key_values"], output_names=["logits", "present_key_values"], dynamic_axes={ "input_ids": {0: "batch", 1: "seq"}, "attention_mask": {0: "batch", 1: "seq"}, "position_ids": {0: "batch", 1: "seq"}, "past_key_values": {0: "batch", 2: "past_seq"}, "logits": {0: "batch", 1: "seq"}, "present_key_values": {0: "batch", 2: "present_seq"}, }, opset_version=17, )

这段代码看着不复杂，实际调试的坑全在past_key_values的结构上。它是一组 tuple，每个元素对应一层的(key, value)，LLaMA-2-7B 有 32 层，所以 past 是 32 个 tuple。torch.onnx.export对这种嵌套结构支持很差，我在真实导出时是把 past 拍平成一组一维 tensor 再作为输入的，这样 ONNX 图才能正确表达形状关系。上面代码我为了可读性做了简化，实际工程里你需要解包每一层的 K/V 再重新组装。

提示：导出完成后，用netron打开 ONNX 文件检查一下输入输出节点，重点确认past_key_values和present_key_values的形状标注是否带上了 batch/seq 动态维度。这一步能提前发现 80% 的 shape 问题，别省。

如果你不想手写这些细节，也可以直接用llm-export这类开源项目，或者 TensorRT-LLM 自带的转换脚本，它们对 LLaMA 系列已经支持得很成熟，只是定制灵活性没那么高。

3.3 使用 trtexec 构建 TensorRT 引擎

拿到 ONNX 之后，下一步就是用 trtexec 构建引擎。LLaMA-2-7B 的 ONNX 文件在 FP16 权重下大约 14GB，构建过程对显存要求不低，建议在空闲机器上构建，或者用--workspace限定临时显存上限：

trtexec \ --onnx=llama2_7b.onnx \ --saveEngine=llama2_7b_fp16.engine \ --fp16 \ --minShapes=input_ids:1x1,attention_mask:1x1,position_ids:1x1,past_key_values:1x64x8x1x128 \ --optShapes=input_ids:1x64,attention_mask:1x64,position_ids:1x64,past_key_values:1x64x8x64x128 \ --maxShapes=input_ids:1x1024,attention_mask:1x1024,position_ids:1x1024,past_key_values:1x64x8x4096x128 \ --workspace=16384 \ --verbose

几个关键参数逐个说明：

• --fp16：开启 FP16 精度，权重和激活全部转半精度，显存占用直接砍半，也是构建 LLaMA-2-7B 引擎的默认选项。
• --minShapes/optShapes/maxShapes：定义动态 shape 的三个 profile 边界，对应最小、最优、最大输入形状。KV Cache 的维度要仔细算：(batch, num_kv_heads, past_seq, head_dim)。LLaMA-2-7B 的 GQA 是 8 个 KV head，head_dim 128，所以中间那个维度写成 8。
• --workspace：构建时的临时内存池上限，单位 MB。7B 模型构建期间峰值可能跑到 20GB 以上，显存小的机器建议调低。
• --verbose：打印详细日志，报错信息都在里面，排查问题离不开它。

构建时间在 4090 上约 15 到 25 分钟，取决于机器负载。构建完成后生成llama2_7b_fp16.engine，体积约 13.5GB。可以用trtexec --loadEngine=llama2_7b_fp16.engine加载并跑一次基准测试验证引擎可用。

3.4 用 Python API 构建引擎：更精细的控制

trtexec 适合标准流程，但要自定义优化策略（比如特定层保留 FP32）、管理多 profile 切换、做 INT8 量化，就得用 Python API。核心模板：

import tensorrt as trt TRT_LOGGER = trt.Logger(trt.Logger.ERROR) builder = trt.Builder(TRT_LOGGER) network = builder.create_network( 1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH) ) parser = trt.OnnxParser(network, TRT_LOGGER) with open("llama2_7b.onnx", "rb") as f: parser.parse(f.read()) config = builder.create_builder_config() config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 16 << 30) config.set_flag(trt.BuilderFlag.FP16) profile = builder.create_optimization_profile() profile.set_shape("input_ids", (1, 1), (1, 64), (1, 1024)) # 其他输入按同样方式设置，略 config.add_optimization_profile(profile) serialized_engine = builder.build_serialized_network(network, config) with open("llama2_7b_fp16.engine", "wb") as f: f.write(serialized_engine)

两个坑提醒一下：第一，EXPLICIT_BATCH标志是 TensorRT 8 以后的硬性要求，OnnxParser 解析带动态轴的模型必须开，忘了开直接报错；第二，set_memory_pool_limit设置构建期临时显存上限，调太小会构建失败报CUDA error: out of memory，调太大又和别的任务抢显存，我一般按机器总显存的一半来设，具体数值看你环境。

3.5 聊聊 INT8 量化：小显存卡的最后出路

如果你的目标卡只有 12GB 显存，FP16 引擎 13.5GB 根本塞不下，只能用 INT8。TensorRT 的 INT8 量化分 PTQ（训练后量化）和 QAT（量化感知训练），部署场景首选 PTQ。流程是准备一批校准数据，统计激活值分布，生成量化 scale：

trtexec \ --onnx=llama2_7b.onnx \ --saveEngine=llama2_7b_int8.engine \ --int8 \ --calib=calibration.cache \ --workspace=12288

INT8 引擎体积约 7GB，放进 RTX 5070 的 12GB 显存没有压力。精度上，我用困惑度评估从原始 FP16 的 5.2 涨到 5.4 左右，下游任务差距基本可接受。但要特别留意：LLM 对激活值量化比 CNN 敏感得多，某些敏感层建议用--precisionConstraints单独保留 FP16。量化后如果输出明显劣化，优先怀疑校准数据分布太单一，扩大校准集、混合各种风格的 prompt 再试一次，往往就好了。

4. 推理代码实现与性能实测

4.1 Python 端推理：最小可运行链路

引擎构建好之后，推理逻辑其实是固定的套路：加载引擎、创建 execution context、分配输入输出 buffer、跑自回归循环。核心代码：

import numpy as np import tensorrt as trt import pycuda.driver as cuda import pycuda.autoinit TRT_LOGGER = trt.Logger(trt.Logger.WARNING) runtime = trt.Runtime(TRT_LOGGER) with open("llama2_7b_fp16.engine", "rb") as f: engine = runtime.deserialize_cuda_engine(f.read()) context = engine.create_execution_context() def allocate_buffers(engine, context): inputs, outputs, allocations = [], [], [] for i in range(engine.num_io_tensors): name = engine.get_tensor_name(i) shape = context.get_tensor_shape(name) dtype = trt.nptype(engine.get_tensor_dtype(name)) size = trt.volume(shape) host = cuda.pagelocked_empty(size, dtype) device = cuda.mem_alloc(host.nbytes) context.set_tensor_address(name, int(device)) if engine.get_tensor_mode(name) == trt.TensorIOMode.INPUT: inputs.append(host) else: outputs.append(host) allocations.append(device) return inputs, outputs, allocations

自回归循环的核心是不断把当前 token 的 logits 采样结果拼进下一轮输入，同时把新算出的 K/V 从输出 buffer 拷回输入 buffer 作为下一轮的 past_key_values。这个"输出拷回输入"在 Python 端的开销很明显，每轮生成都要做多次显存拷贝，吞吐天然上不去。所以 Python 版我基本只用来做功能验证，确认引擎没问题、采样逻辑正确之后就转到 C++ 了。

4.2 C++ 端推理：从 YOLO12 项目迁移来的调用模板

C++ 部分直接用我之前在 RTX 5070 上做 YOLO12 ONNX 转 TensorRT 时沉淀下来的调用模板改的。视觉模型和 LLM 解码的整体框架高度一致：加载引擎、创建 context、申请显存、绑定 tensor 地址、异步执行、同步等待。核心类长这样：

#include <NvInfer.h> #include <cuda_runtime_api.h> #include <fstream> #include <vector> class LlamaTensorRT { public: explicit LlamaTensorRT(const std::string& enginePath) { std::ifstream file(enginePath, std::ios::binary); std::vector<char> data((std::istreambuf_iterator<char>(file)), std::istreambuf_iterator<char>()); auto runtime = nvinfer1::createInferRuntime(logger_); engine_ = runtime->deserializeCudaEngine(data.data(), data.size()); context_ = engine_->createExecutionContext(); cudaStreamCreate(&stream_); } bool decode(const int64_t* inputIds, int seqLen, float* logits) { // 设置动态 shape context_->setInputShape("input_ids", nvinfer1::Dims2(1, seqLen)); // 绑定输入输出地址 context_->setTensorAddress("input_ids", (void*)inputIds); context_->setTensorAddress("logits", logits); // 异步执行 return context_->enqueueV3(stream_); } void sync() { cudaStreamSynchronize(stream_); } private: nvinfer1::ILogger logger_; // 需要自定义 Logger 类 nvinfer1::IExecutionContext* context_ = nullptr; nvinfer1::ICudaEngine* engine_ = nullptr; cudaStream_t stream_ = nullptr; };

细节上有个重要的差异：LLM 比 YOLO 多管一个 KV Cache。C++ 端不仅要为输入输出 tensor 分配显存，还得预先为每一层的 K/V 开辟固定大小的显存区。分配时按最大序列长度算，比如按 2048 上下文、8 个 KV head、head_dim 128 来算，单层 KV 大小是2（K 和 V）× 2048 × 8 × 128 × 2 字节 ≈ 8MB，32 层合计约 256MB。这个数字不算大，但很多人就是忘了给 KV Cache 留显存，导致长文本生成到一半直接 OOM，代码逻辑怎么查都查不出问题。

注意：enqueueV3是新版 TensorRT 的推荐接口，替代了旧版的enqueue。如果你用的是 TensorRT 8.4 之前的版本，接口名和方法签名会有差异，别硬套。

4.3 性能实测：FP16 和 INT8 的吞吐对比

我在 4090 上分别跑了 FP16 和 INT8 引擎，输入 64 token 的 prompt，生成 128 个新 token，以token/s衡量：

这个数据基本符合理论预期。解码阶段是典型的 memory-bound 场景，瓶颈在显存带宽而不是算力，INT8 把权重体积砍掉一半后，单位 token 需要搬运的数据量随之减半，所以速度能到 FP16 的 1.5 到 1.6 倍。这也解释了为什么小显存卡上量化几乎是必选项：RTX 5070 12GB 上 INT8 引擎能稳定跑到 52 tok/s，FP16 引擎连加载都过不了。

要提醒一点：trtexec 自带的 benchmark 数字通常比集成到业务代码里要好看，因为业务代码要加 tokenizer、前后处理、采样策略、网络传输这些开销。我上面的对比是在自己的推理框架里统一测的，引擎之间只差精度策略，数据可信度更高。如果你要把这个部署到线上，建议也按这个思路做自己的压测脚本，别直接拿 trtexec 的数值去写服务承诺。

5. 常见问题与排查技巧实录

5.1 显存不足和 OOM

LLM 部署最常见的坑就是显存不够，我的排查顺序是：先看引擎体积，ls -lh *.engine，FP16 引擎往 12GB 卡上塞必然失败；再看 KV Cache 预留量，能加载但生成到一半才崩，十有八九是 KV Cache 算少了；最后看 host 端内存，自回归循环里如果反复用std::vector拷数据，host 内存峰值也可能爆，建议用固定长度 buffer 或内存池。

提示：nvidia-smi显示的进程显存占用包含 CUDA context 和其他开销。要看 TensorRT 引擎实际分配了哪些 buffer，建议在代码里打日志输出每个 tensor 的 shape 和 dtype，一目了然。

5.2 输出乱码和 token 不一致

TensorRT 推理结果和 PyTorch 不一致，优先怀疑两个点：一是 FP16 精度引起的采样差异，温度低时影响不大；二是位置编码或 attention mask 没对齐，尤其用了 KV Cache 之后，mask 的形状和取值必须和 PyTorch 完全一致。

我踩过的一个具体坑：导出 ONNX 时 attention mask 用的是 int64，引擎输入 tensor 却绑成了 int32，结果 mask 值全变成 0、1 之外的随机数，注意力分数异常，输出直接放飞自我。排查方法很直接：把第一个 token 的 logits 打印出来和 PyTorch 对齐，如果完全一致再往下查采样循环，否则先查输入预处理。

5.3 引擎构建时的 Shape 冲突

error: convolution weight is not a constant tensor这类报错，多半是 ONNX 里有动态 shape 的地方 TensorRT 无法推断。LLaMA-2 导出最容易出问题的是 KV Cache 的 concat 操作：past_seq 和 current_seq 拼接时，如果 dynamic_axes 没声明干净，TensorRT 会认为维度是固定的，构建时直接冲突。

建议导出 ONNX 后用 netron 或 onnxruntime 检查一遍图的输入输出，确认所有需要动态的轴都标了dynamic_axes，特别是past_key_values里的past_seq维度，一个都不能漏。漏掉一个，构建阶段或者运行阶段就会以各种奇奇怪怪的姿势报错。

5.4 长序列生成到 2000 token 后变慢

如果生成越过某个 token 数之后速度明显下降，大概率是 KV Cache 到达 profile 的最大形状边界，TensorRT 在内部做了重分配或者 padding。解决办法是构建引擎时把 maxShapes 里的序列长度按实际需求设大，但代价是引擎体积和显存占用同步增长，需要权衡。

另一个经验：很多场景下 2048 上下文就够用，没必要为了"万一以后用得到"把 maxShapes 拉满到 4096。大 profile 会影响 kernel 选择，短序列推理反而变慢。我实测把 maxShapes 从 4096 降到 2048，短 prompt 的 prefill 延迟还能再降 10% 左右。

5.5 问题速查表

最后再分享一点我自己的体会。TensorRT 部署 LLM 这件事，真正的难点从来不是"怎么调 API"，而是怎么把整条链路里的变量管住——版本匹配、动态 shape、KV Cache、量化精度、内存生命周期，每一个都可能在最后一公里给你上眼药。我这次把链路跑通之后，最大的收获其实是积累了一套能复用的骨架：同一个引擎加载模板、同一套 buffer 管理代码，换个模型换几个 shape 参数就能继续用。如果你也正被 TensorRT 折磨，我的建议是：先把 trtexec 跑通、把报错日志读透、把 shape 打印出来看，一步一步来，这条路是走得通的。