Jetson Orin 8GB 部署 TensorRT-Edge-LLM：Qwen2.5 从安装到 OpenAI 兼容服务全流程（11 个坑血泪实录，保姆级实战）

小饕

2026-08-14 0 阅读17分钟

本文基于 Jetson Orin Nano Super DevKit 8GB + JetPack 6.2 实测，全程手把手，附带全部踩坑记录。想要快速照抄命令的直接翻到文末【附录：完整命令速查】。

前言：为什么折腾这个？

手头有一块 Jetson Orin Nano Super 8GB，之前使用TensorRT 部署Imagenet 模型获得了极大的性能提升（7 ～ 30倍），现在想在板子上跑本地大模型看看使用TensorRT engine部署大模型有没有性能提升。于是把目光投向 NVIDIA 官方的 TensorRT-Edge-LLM——毕竟是官方针对 Jetson 深度优化的推理框架，FP16 引擎 + 融合 Attention 插件，性能潜力大得多。

理想很丰满，现实很骨感：从安装到真正跑通，前后踩了 11 个坑，无一例外都是「版本匹配 / 环境配置 / 内存碎片」这类工程问题，没有一个跟模型本身有关。这篇文章把我的完整路径和所有坑都记录下来，希望你不用再走一遍弯路。

最终成果：Qwen2.5-0.5B-Instruct 引擎构建成功 → 推理验证通过 → 部署成 OpenAI 兼容 HTTP 服务，生成速率 ~26 tok/s，功耗仅 ~15W。

一、先说结论（只想看重点的看这节）

完整链路一句话：容器内导出 ONNX（plugin 模式）→ docker cp 拷到宿主机 → 宿主机无桌面模式窗口下构建引擎 → llm_inference 推理验证 → FastAPI 网关做成 OpenAI 兼容服务。

三个最重要的认知（提前打预防针）：

1. ⚠️ 安装分两部分，缺一不可：① Python 静态工具链（tensorrt-edgellm-export-llm 等 11 个 CLI 工具，pip 安装，负责导出 ONNX 与量化）；② C++ Runtime 工具（llm_build / llm_inference / llm_bench，源码编译，负责构建与推理）。两者必须同源同版本（v0.6.0）。
2. 🔴 8GB Orin 的构建能力红线：最多构建 0.5B 模型。1.5B 实测五次全败（下面第五节有完整血泪史）。16GB 上限 3B；7B 需要 64GB AGX 构建后拷回。
3. 📊 0.5B 引擎性能实测：生成 22~30 tok/s（平均 ~26.5）、TTFT ~1.9s、峰值内存 ~4.23GB（55.7%）、功耗 ~15.2W、GPU 利用率 99%。

二、环境与版本锚点（决定生死的第一步）

2.1 硬件环境

| 项 | 值 | 说明 | | --- | --- | --- | | 硬件 | Jetson Orin Nano Super DevKit 8GB | 统一内存架构（CPU/GPU 共享物理内存），sm_87 | | 系统 | Ubuntu 22.04.5 LTS / glibc 2.35 | 宿主机与容器一致 | | JetPack | 6.2（L4T 36.x） | meta 包 nvidia-tensorrt 6.2.3 | | TensorRT | 10.3.0.30（CUDA 12.5/12.6） | 决定导出模式选择的硬约束 | | 模型 | Qwen2.5-1.5B-Instruct（失败）→ Qwen2.5-0.5B-Instruct（成功） | vocab=151936 |

2.2 版本锚点：第一个坑就埋在这里（P0）

TensorRT-Edge-LLM 的版本与 JetPack 强绑定，而官方 README 没有版本对照矩阵。 我最开始直接 git clone 按默认分支装了最新的 v0.9.0，结果后面编译、构建各种不兼容，排查半天才意识到版本装错了——JP6.2（TRT 10.3.x）必须用 v0.6.0。

| 版本线 | 面向平台 | EMBEDDED_TARGET | 锚点 | | --- | --- | --- | --- | | v0.9.x（默认分支） | Thor | jetson-thor | JetPack 7.1 / CUDA 13.x / TRT 10.15+ | | v0.6.x（本方案） | Orin | jetson-orin | JetPack 6.2 / CUDA 12.6 / TRT 10.3.x |

判断某个 tag 能不能用在自己的设备上：看它的 cmake/aarch64_linux_toolchain.cmake 文件里有没有 jetson-orin 目标——含 Orin 的版本线（v0.6.x）才可用于 JP6.2。

git clone --depth 1 --branch v0.6.0 https://github.com/NVIDIA/TensorRT-Edge-LLM.git
git describe --tags      # 验证：应显示 v0.6.0

官方文档 System Requirements 只写了 Thor/JP7.1，没有提示 Orin 用户需切到 v0.6.x——这个坑文档里完全没有，是踩了才发现的。

三、安装分两半：Python 工具链 + C++ Runtime

3.1 安装 Python 静态工具链（pip 分层安装）

# ① 克隆源码（--depth 1 --branch 直接锁定 v0.6.0，天然规避默认分支坑）
git clone --depth 1 --branch v0.6.0 https://github.com/NVIDIA/TensorRT-Edge-LLM.git
cd TensorRT-Edge-LLM

# ② 安装主包（必须 --no-deps！原因见 3.2）
pip install . --no-deps

# ③ 安装量化工具 nvidia-modelopt（同样 --no-deps + 手动补运行时依赖）
pip install nvidia-modelopt==0.39.0 --no-deps
pip install omegaconf pulp pydantic nvidia-ml-py ninja

# ④ 安装模型/数据集等核心依赖（分批装，避免超时）
pip install transformers==4.57.6 datasets==4.4.2 peft==0.18.1 \
            pillow==12.1.1 backoff==2.2.1 soundfile==0.13.1 \
            librosa==0.11.0 einops==0.8.2

# ⑤ 隐式依赖（"import 报错 → 缺啥装啥"，见 3.3）
pip install scipy --only-binary :all:
pip install torchprofile
pip install onnx-graphsurgeon

3.2 为什么必须 --no-deps？（版本冲突坑）

容器环境已有 aarch64 平台优化过的 torch 2.11.0 / onnx 1.22.0，而项目声明要求 torch~=2.10.0 / onnx==1.19.0——直接 pip install . 会因 onnx==1.19.0 无匹配发行版直接失败：

ERROR: No matching distribution found for onnx==1.19.0

关键原则：Jetson 容器里的包是平台优化过的，运行时兼容性 > 版本号精确匹配。 用 --no-deps 跳过依赖解析、保持环境现有版本，实测完全兼容。

3.3 隐式依赖：装一个报下一个

--no-deps 的代价是依赖要手动补齐，而且有些依赖连声明里都没写，只能靠迭代发现：import tensorrt_edgellm 报错 → 装缺的包 → 再试，循环到通过。本环境共发现 3 个：

| 隐式依赖 | 用途 | 安装注意 | | --- | --- | --- | | scipy | modelopt NAS 模块 | ⚠️必须 --only-binary :all:——aarch64 源码编译要 30+ 分钟，预编译轮子秒装 | | torchprofile | modelopt 模型性能分析 | 普通安装 | | onnx-graphsurgeon | ONNX 图操作（INT4 量化必需） | 普通安装 |

环境注意：不要新建 Python 虚拟环境——容器 /opt/venv 已配置 aarch64 优化的 PyPI 源，新建 venv 会丢失平台预编译包。

验证：

python -c "import tensorrt_edgellm; print(tensorrt_edgellm.__version__)"   # 期望 0.6.0
tensorrt-edgellm-export-llm --help                                          # 有 usage 输出即可用

装完一共得到 11 个 tensorrt-edgellm-* 命令行工具，本方案核心用到 export-llm。

3.4 编译 C++ Runtime（4 个关键参数，一个都不能少）

git checkout v0.6.0          # 版本锚点，必须与导出端一致

rm -rf build && mkdir -p build && cd build
cmake .. \
  -DCMAKE_BUILD_TYPE=Release \
  -DTRT_PACKAGE_DIR=/usr \
  -DCMAKE_TOOLCHAIN_FILE=cmake/aarch64_linux_toolchain.cmake \
  -DEMBEDDED_TARGET=jetson-orin \
  -DNV_ONNX_PARSER_LIB=/usr/local/cuda/targets/aarch64-linux/lib/libnvonnxparser.so
make -j4

正确配置的判据（configure 输出必须同时满足）：

1. CUDA_CTK_VERSION set to 12.6
2. FMHA 日志的排除列表不再含 87
3. 无 NOTFOUND
4. Build files written

编译产物（后面全靠它们）：

build/libNvInfer_edgellm_plugin.so.1.0   (37MB, 运行时插件库, 必须)
build/examples/llm/llm_build             (引擎构建工具)
build/examples/llm/llm_inference         (推理工具)
build/examples/llm/llm_bench             (性能测试工具)

四、导出 ONNX（记住：别加 --trt_native_ops！）

4.1 下载模型 + 导出

# 容器内
huggingface-cli download Qwen/Qwen2.5-0.5B-Instruct \
  --local-dir qwen25_0.5b_trt/Qwen2.5-0.5B-Instruct

tensorrt-edgellm-export-llm \
  --model_dir  /workspace/qwen25_0.5b_trt/Qwen2.5-0.5B-Instruct \
  --output_dir /workspace/qwen25_0.5b_trt/onnx_new \
  --device cuda

4.2 导出模式抉择（P5：最深的坑）

v0.6.0 导出有两种模式，选错直接构建失败：

| 模式 | 导出算子 | domain | 要求 | JP6.2 (TRT 10.3.x) | | --- | --- | --- | --- | --- | | 默认 plugin 模式 | AttentionPlugin | trt | 依赖插件库 | ✅必须用这个 | | --trt_native_ops | Attention 等 | 空 | TRT ≥ 10.15（JP7.x） | ❌ |

JP6.2 必须用默认 plugin 模式，不要加 --trt_native_ops——Native 模式要求 TRT ≥ 10.15，JP6.2 只有 10.3，导出后构建阶段必然 Cannot find plugin。

4.3 构建前的必做检查（验证导出模式）

python3 -c "
import onnx
from collections import Counter
m = onnx.load('.../onnx_new/model.onnx')
print('total:', len(m.graph.node))
print(Counter(n.domain for n in m.graph.node))
"

期望结果（Qwen2.5-0.5B，28 层）：

domain 分布: {'': 基础算子, 'trt': 28}     ← 28 个 AttentionPlugin，插件模式 ✅

如果看到 ('Attention','') 或 ('RotaryEmbedding','')（空 domain）= 错用了 TRT Native 模式，必须重导。

五、构建引擎（最惨烈的一章：OOM 血泪史）

5.1 标准构建命令

# ① 拷贝产物（容器 → 宿主机）+ 停容器释放内存
mkdir -p /home/zy/Desktop/workplace/engineMake_0_5b
docker cp jupyter-tensorrt:/workspace/qwen25_0.5b_trt/onnx_new /home/zy/Desktop/workplace/engineMake_0_5b/
docker stop jupyter-tensorrt

# ② 切无桌面模式 + MAXN（关键！释放 GPU 内存）
sudo systemctl isolate multi-user.target
sudo nvpmodel -m 0
tegrastats --interval 1000 --stop 3   # 确认 lfb ≥ 65x4MB

# ③ 构建（0.5B，512/2048 参数）
cd /home/zy/Desktop/workplace/engineMake_0_5b
export EDGELLM_PLUGIN_PATH=/home/zy/Desktop/workplace/engineMake/trt_build/libNvInfer_edgellm_plugin.so
/home/zy/Desktop/workplace/engineMake/trt_build/examples/llm/llm_build \
  --onnxDir onnx_new --engineDir engine_new \
  --maxBatchSize 1 --maxInputLen 512 --maxKVCacheCapacity 2048

成功判据：日志出现 LLM engine built successfully，且 engine_new/ 下有三件套：llm.engine + config.json + tokenizer.json。

5.2 新手必看：lfb 是什么？

Jetson 是统一内存架构（CPU/GPU 共享物理内存），tegrastats 输出里 (lfb Nx4MB) 表示当前最大连续空闲块：

RAM 928/7607MB (lfb 177x4MB)   ← lfb = 177 × 4MB = 708MB

读法：lfb Nx4MB → 实际大小 = N × 4MB。这是比 free -h 总量更关键的指标——总量够没用，要的是连续大块。

• 0.5B 需要 ≥ 65×4MB（260MB）
• 1.5B 需要 ≥ 112×4MB（445MB）

5.3 为什么 1.5B 死了 5 次（P7-P9 全记录）

第一次失败：差 13MB 的惨案。 构建进入 autotuner 阶段后 OOM：

NvMapMemAllocInternalTagged: error 12
CUDA error 2 for 466747648-byte allocation

诊断三连：容器内存限制 max（无限制 ✅）→ free -h 显示 free 5.2GB（总量充足 ✅）→ tegrastats 显示 lfb 108x4MB = 432MB（❌ 最大连续空闲块不够）。autotuner 要 445MB 连续块，只有 432MB——差 13MB → ENOMEM。free 的 5.2GB 全是碎片，拼不出连续大块。

关键认知 1：报错里的 ForeignNode[/Unsqueeze.../Cast] 根本不是节点问题，是 autotuner 没内存跑 tactic 的连带报错，别傻乎乎去改 ONNX。

关键认知 2：swap、drop_caches、compact_memory 全都没用——碎片在 NvMap heap 层（Jetson 统一内存 carveout），Linux buddy 的内存规整碰不到它，只有整机重启能清零。

降参也没用：445MB 是 embedding 权重表。 把参数从 1024/4096 降到 512/2048 重跑，分配数字 466747392B 与上次 466747648B 只差 256B（对齐误差）——同一笔固定分配。数学解码：

466,747,392 B = 151,936 (vocab_size) × 1,536 (hidden_size) × 2 (fp16 字节)
              = Qwen2.5-1.5B 的 embedding 权重表 ≈ 445 MB

embedding 表大小只由模型结构决定，与 maxInputLen / maxKVCacheCapacity / maxBatchSize 毫无关系。 通用公式：embedding 表 = vocab_size × hidden_size × dtype_bytes。1.5B = 445MB，0.5B = 151936 × 896 × 2 ≈ 260MB。

重启后还是失败：8GB 硬性天花板。 重启后 lfb 恢复 684MB → 容器内重试失败 → docker cp 到宿主机直跑仍失败 → 最干净窗口（重启 + 无桌面 + 无容器 + lfb 708MB + RAM 仅 928MB）仍失败。五个环境全部死在同一个 445MB 分配上。 构建中段的真实内存账：

builder Init kernel library   ≈ 986MB   ← 固定吃，与模型无关
autotuner workspace           ≈ 数百MB  ← 交错分配
embedding 表（1.5B）           445MB

空闲 lfb 708MB ≠ 构建中段状态——这些分配交错进行、反复试探，8GB 设备的 NvMap 峰值连续块必然不足。结论：1.5B 在 8GB Orin 上构建不可行，不是碎片、不是容器、不是环境，是硬性峰值天花板。

为什么量化救不了？ SQ/AWQ 量化的都是 Linear 层（矩阵乘）， embedding 是查表操作默认保持 fp16——445MB 原样还在；而且校准本身要先加载全量 fp16 模型跑推理，先 OOM 在校准阶段。量化是"构建成功后的优化手段"，不是解决构建 OOM 的钥匙。

5.4 最终成功组合拳（P10）

1. 无桌面模式：sudo systemctl isolate multi-user.target——桌面环境（Xorg/compositor）占 1GB+ GPU 内存，切掉后释放
2. MAXN 功耗模式：sudo nvpmodel -m 0——内存分配最充足
3. 趁重启窗口：整机重启后 NvMap heap 清零，立即构建（别开桌面、别启容器，每多一分钟 lfb 都在掉）
4. 模型换 0.5B：embedding 260MB，在 lfb 708MB 下余量充足

llm_build 与插件库是模型无关的通用工具：同一份 trt_build/ 可以构建任意模型。引擎绑定的是 sm_87 架构 + TRT 版本 + 插件版本，不绑定具体模型。

六、推理验证 + 部署

6.1 推理验证（llm_inference）

cat > input.json << 'EOF'
{
  "batch_size": 1,
  "temperature": 0.7,
  "top_p": 0.9,
  "top_k": 50,
  "max_generate_length": 128,
  "requests": [
    {"messages": [
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "用一句话介绍你自己"}
    ]}
  ]
}
EOF

export EDGELLM_PLUGIN_PATH=/home/zy/Desktop/workplace/engineMake/trt_build/libNvInfer_edgellm_plugin.so
/home/zy/Desktop/workplace/engineMake/trt_build/examples/llm/llm_inference \
  --engineDir engine_new --inputFile input.json --outputFile output.json
cat output.json

实测输出（验证通过 🎉）：

"output_text": "我是来自阿里云的大规模语言模型，我叫通义千问。"

formatted_complete_request 含完整的 <|im_start|>system/user/assistant chat template 三段，说明模板拼装正确。

6.2 部署为 OpenAI 兼容服务

事实：v0.6.0 没有内置 HTTP server（官方 OpenAI 兼容 server 是后续版本 + Thor 平台功能）。用 FastAPI 网关包装 llm_inference（输入输出本身就是 OpenAI 兼容 JSON 格式）：

pip install fastapi uvicorn
python3 llm_server.py \
  --engine-dir    engineMake_0_5b/engine_new \
  --llm-inference engineMake/trt_build/examples/llm/llm_inference \
  --plugin        engineMake/trt_build/libNvInfer_edgellm_plugin.so \
  --port 8000

测试：

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen2.5-0.5b","messages":[{"role":"user","content":"你好"}]}'

任意 OpenAI SDK 对接（手机/电脑/任何设备）：

from openai import OpenAI
client = OpenAI(base_url="http://:8000/v1", api_key="not-needed")

systemd 开机自启（可选）：见文末附录完整命令。

推理阶段内存需求远小于构建（实测系统峰值 ~4.23GB / 55.7%），不需要无桌面模式，桌面可正常使用。

七、性能实测（真数据，不掺水）

用 llm_bench 对 Qwen2.5-0.5B-Instruct 引擎做了 4 次实测：

| 测试 | Prompt | TTFT (ms) | 生成速率 (tok/s) | 峰值内存 (MB) | 峰值功耗 (mW) | GPU 利用率 | GPU 温度 | | --- | --- | --- | --- | --- | --- | --- | --- | | test_1 | 你好，请介绍一下自己 | 1595.52 | 21.85 | 4229（55.6%） | 15050 | 99.0% | 57.1°C | | test_2 | 写一首关于人工智能的诗 | 1981.66 | 25.16 | 4237（55.7%） | 15246 | 99.0% | 58.1°C | | test_3 | 解释量子计算的基本原理 | 1974.50 | 30.46 | 4236（55.7%） | 15246 | 99.0% | 58.4°C | | test_4 | 如何优化 TensorRT 模型性能？ | 1979.08 | 28.44 | 4236（55.7%） | 15246 | 99.0% | 58.6°C |

性能画像（4 次平均）：

| 指标 | 实测值 | 说明 | | --- | --- | --- | | TTFT（首 token 延迟） | ~1.9s | 含引擎加载开销（每次运行重新加载 ~1-2s） | | 生成速率 | 21.9 ~ 30.5 tok/s（平均 ~26.5） | 随生成内容/长度波动 | | Prefill 速率 | ~3.6-4.1 tok/s | 短 prompt 下占比小 | | 峰值内存 | ~4.23GB（55.7%） | 0.5B fp16 权重 + KV + 激活 + runtime | | 峰值功耗 | ~15.2W | 边缘设备可长时间稳定运行 | | GPU 利用率 | 99% | 计算已打满 | | GPU 温度 | ~58°C | 低于降频线（90°C），热余量充足 |

四点结论：

1. GPU 是当前瓶颈，但热/功耗余量充足：利用率 99% + 温度 ~58°C + 功耗 ~15.2W → 算力已打满，距离散热（90°C 降频线）与功耗上限仍有相当余量
2. TTFT 的主因是引擎加载：每次运行重新加载引擎（~1-2s）占 TTFT 1.9s 的大头——生产环境若写 C++ 常驻进程（引擎只加载一次），TTFT 可降到几百 ms 量级
3. 实用定位：~26 tok/s + 15.2W 功耗，非常适合语音交互、轻量问答等边缘实时场景
4. 对比 llama.cpp：同样 0.5B 模型，TRT 引擎的生成速度明显更优——这就是折腾 TensorRT-Edge-LLM 的价值

八、11 个坑全记录（精简速查表）

| # | 阶段 | 现象 | 根因 | 解法 | | --- | --- | --- | --- | --- | | P0 | 安装 | 默认分支装成 v0.9.0，编译不兼容 | 版本与 JetPack 强绑定，官方无版本矩阵 | git checkout v0.6.0 | | P0补充 | 安装 | pip install . 失败 onnx==1.19.0 无匹配 | 项目声明与容器平台优化版本冲突 | --no-deps 分层安装 + 迭代补隐式依赖 | | P1 | 编译 | FMHA 日志EXCLUDE_SM_87 | 漏传 toolchain / EMBEDDED_TARGET | 补全 4 参数 cmake 配置 | | P2 | 编译 | NV_ONNX_PARSER_LIB NOTFOUND | 命令漏\ + v0.6.0 源码硬编码 x86_64 路径 | 显式指定 aarch64 路径 | | P3 | 编译 | math.h: No such file or directory | 容器缺 libc6-dev | apt-get install -y libc6-dev | | P4 | 编译 | 装完仍找不到 math.h | 平铺头文件布局（非标准 multiarch） | ln -sf 软链补齐 | | P5 | 导出 | Cannot find plugin | 错用--trt_native_ops（需 TRT≥10.15） | 去掉该参数，plugin 模式重导 | | P6 | 构建 | Cannot open plugin library | 插件库相对路径按 cwd 解析 | export EDGELLM_PLUGIN_PATH 绝对路径 | | P7 | 构建 | autotuner OOM，差 13MB | NvMap heap 碎片，lfb 432MB < 445MB | 重启整机（碎片只有重启能清零） | | P8 | 构建 | 降参仍 OOM | 445MB 是 embedding 表，与参数无关 | 换模型（0.5B 的 embedding 仅 260MB） | | P9 | 构建 | 重启后仍失败 | 8GB 设备硬性内存天花板 | 0.5B 是唯一出路 | | P10 | 构建 | — | — | 无桌面 + MAXN + 重启窗口 + 0.5B 组合拳 |

三个最深的坑再强调一遍：

• P0 版本：先查 toolchain 里有没有 jetson-orin，再动手装
• P5 导出模式：JP6.2 永远别加 --trt_native_ops
• P7-P9 内存：lfb 比 free 重要，embedding 表 = vocab × hidden × 2，先算好红线再选模型

九、总结与展望：还能跑多大？

构建期内存 ≫ 推理期内存——你现在的困境是"构建不动"，不是"跑不动"。8GB 跑不了大模型 TRT 引擎，但"8GB 上不了大模型"是错的：

| 设备 | 可构建上限 | 推理上限 | | --- | --- | --- | | 8GB Orin（本方案） | 0.5B | 7B Q4（llama.cpp） | | Orin NX / Nano Super 16GB | 3B（int8 稳） | 7B~14B 量化 | | Orin AGX 64GB | 7B+ | 14B~32B 量化 |

7B 怎么上？ 两条路：

1. 64GB AGX 构建 int8 引擎 → 拷回（sm_87 同架构，引擎可直接迁移，x86 云端代不了工——引擎绑定架构）
2. 16GB 上构建 3B int8 作为租机实际目标（7B 在 16GB 上连量化校准都会 OOM）

引擎可跨 Orin 机型迁移：同 sm_87 + 同 TRT 版本 + 同插件，16GB 构建的引擎直接拷回 8GB 推理，无需重建。

附录：完整命令速查（从零到可用）

# ═══ 阶段零：安装 Python 静态工具链（容器内）═══
git clone --depth 1 --branch v0.6.0 https://github.com/NVIDIA/TensorRT-Edge-LLM.git && cd TensorRT-Edge-LLM
pip install . --no-deps                              # 主包（--no-deps 避开 onnx==1.19.0 冲突）
pip install nvidia-modelopt==0.39.0 --no-deps        # 量化工具
pip install omegaconf pulp pydantic nvidia-ml-py ninja   # modelopt 运行时依赖
pip install transformers==4.57.6 datasets==4.4.2 peft==0.18.1 \
            pillow==12.1.1 backoff==2.2.1 soundfile==0.13.1 \
            librosa==0.11.0 einops==0.8.2
pip install scipy --only-binary :all:                # 隐式依赖（aarch64 必须预编译轮子！）
pip install torchprofile && pip install onnx-graphsurgeon   # 隐式依赖
tensorrt-edgellm-export-llm --help                   # 验证：11 个 CLI 工具可用

# ═══ 阶段一：编译 C++ Runtime（容器内）═══
apt-get update && apt-get install -y libc6-dev
rm -rf build && mkdir -p build && cd build
cmake .. \
  -DCMAKE_BUILD_TYPE=Release \
  -DTRT_PACKAGE_DIR=/usr \
  -DCMAKE_TOOLCHAIN_FILE=cmake/aarch64_linux_toolchain.cmake \
  -DEMBEDDED_TARGET=jetson-orin \
  -DNV_ONNX_PARSER_LIB=/usr/local/cuda/targets/aarch64-linux/lib/libnvonnxparser.so
make -j4
# 编译失败缺 math.h 时（平铺头布局容器）：
ln -sf /usr/include/math.h /usr/include/aarch64-linux-gnu/math.h

# ═══ 阶段二：导出 ONNX（容器内，别加 --trt_native_ops！）═══
huggingface-cli download Qwen/Qwen2.5-0.5B-Instruct --local-dir qwen25_0.5b_trt/Qwen2.5-0.5B-Instruct
tensorrt-edgellm-export-llm \
  --model_dir qwen25_0.5b_trt/Qwen2.5-0.5B-Instruct \
  --output_dir qwen25_0.5b_trt/onnx_new --device cuda
# 验证导出模式（期望 {'':基础, 'trt':28}）：
python3 -c "import onnx;from collections import Counter;m=onnx.load('qwen25_0.5b_trt/onnx_new/model.onnx');print(Counter(n.domain for n in m.graph.node))"

# ═══ 阶段三：构建引擎（宿主机无桌面）═══
docker cp jupyter-tensorrt:/workspace/qwen25_0.5b_trt/onnx_new /home/zy/Desktop/workplace/engineMake_0_5b/
docker stop jupyter-tensorrt
sudo systemctl isolate multi-user.target && sudo nvpmodel -m 0
tegrastats --interval 1000 --stop 3        # 确认 lfb ≥ 65x4MB
cd /home/zy/Desktop/workplace/engineMake_0_5b
export EDGELLM_PLUGIN_PATH=/home/zy/Desktop/workplace/engineMake/trt_build/libNvInfer_edgellm_plugin.so
/home/zy/Desktop/workplace/engineMake/trt_build/examples/llm/llm_build \
  --onnxDir onnx_new --engineDir engine_new \
  --maxBatchSize 1 --maxInputLen 512 --maxKVCacheCapacity 2048
# 构建完恢复桌面：
sudo systemctl set-default graphical.target && sudo systemctl isolate graphical.target

# ═══ 阶段四：推理验证 ═══
# 写 input.json（OpenAI 兼容格式，见正文 6.1）
/home/zy/Desktop/workplace/engineMake/trt_build/examples/llm/llm_inference \
  --engineDir engine_new --inputFile input.json --outputFile output.json
cat output.json

# ═══ 阶段四补充：性能测试（可选）═══
/home/zy/Desktop/workplace/engineMake/trt_build/examples/llm/llm_bench \
  --engineDir engine_new --mode prefill --inputLen 128 --outputLen 64
# 搭配 tegrastats 采样系统资源：tegrastats --interval 1000

# ═══ 阶段五：部署（systemd 开机自启）═══
sudo tee /etc/systemd/system/edgellm-server.service > /dev/null << 'EOF'
[Unit]
Description=TensorRT-Edge-LLM OpenAI Server
After=network.target
[Service]
User=zy
WorkingDirectory=/home/zy/Desktop/workplace
ExecStart=/usr/bin/python3 /home/zy/Desktop/workplace/llm_server.py \
  --engine-dir engineMake_0_5b/engine_new \
  --llm-inference engineMake/trt_build/examples/llm/llm_inference \
  --plugin engineMake/trt_build/libNvInfer_edgellm_plugin.so
Restart=always
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload && sudo systemctl enable --now edgellm-server

OOM 诊断三步法（遇到构建失败先走一遍）：

① 容器限制？    cat /sys/fs/cgroup/memory.max          （max = 无限制）
② 总量够吗？    free -h                                  （够但失败 → 碎片问题）
③ 连续块够吗？  tegrastats  看 (lfb Nx4MB)               （关键指标！）
    └─ lfb ≥ embedding 表大小 → 碎片不是主因，查构建峰值公式（权重×2.5+1GB）
    └─ lfb < embedding 表大小 → NvMap 碎片，重启整机，开机立即构建

参考资料：TensorRT-Edge-LLM v0.6.0 官方 Installation Guide / Quick Start / Engine Builder Developer Guide；v0.6.0 源码（toolchain、FMHA 逻辑、plugin 注册名、trtUtils.h）；jetson-ai-lab 教程。

如果本文对你有帮助，欢迎点赞收藏；有问题评论区见，知无不言。

本文为实战记录，环境为 Jetson Orin Nano Super DevKit 8GB / JetPack 6.2 / TRT 10.3.0.30，不同环境结果可能不同，请以你的实际硬件为准。