端侧大模型部署终极横评：Jetson Orin 8GB 上把 13 个推理框架全摸了一遍，谁才是最优解？

小饕

365人浏览 · 2026-08-14 08:43:11

小饕 · 2026-08-14 08:43:11 发布

从 TensorRT-Edge-LLM 五次 OOM 血泪史，到 13 个方案逐个体检，这份踩坑报告帮你少走三个月弯路

适用场景：Jetson Orin 8GB / 边缘设备部署 Qwen2.5 系列 LLM

写在前面

大家好，最近我在 Jetson Orin 8GB 上折腾大模型部署，目标很朴素：把 Qwen2.5 系列跑起来，而且要跑得快、跑得稳，最后还要接 ROS2 做机器人推理。

过程有多惨烈呢？光一个 TensorRT-Edge-LLM 的 1.5B 模型构建，我就 连续 OOM 了五次——容器、宿主机、无桌面环境、最干净的窗口，五个环境全死在同一处 445MB 的 embedding 表分配上。期间还误装过版本（装了面向 Thor 的 v0.9.x，跟我的 JetPack 6.2 完全不兼容），一度怀疑人生。

冷静下来之后，我把市面上能跑 LLM 的推理框架全部调研了一遍：从 NVIDIA 官方的 TensorRT-Edge-LLM，到编译路线的 MLC-LLM，再到解释型的 llama.cpp、服务器级的 vLLM、移动端的 MNN、学术界的 PowerInfer……一共 13 个方案，逐个分析原理、优缺点、开源协议和 Jetson 适配度。

这篇文章就是调研的完整沉淀。结论先放这儿：

Jetson Orin 8GB 上部署 1.5B/3B，MLC-LLM 是综合最优解；0.5B 用已跑通的 TRT-Edge-LLM 守阵地；其余工具按"服务器向 / 移动端向 / 学术向"分类各有定位，不适合作为主引擎。

下面展开讲，全文无废话，所有数据都标了来源。

一、先分清两类：编译型 vs 解释型

13 个工具看着眼花，其实按一条轴就能分清楚：

类别	原理	代表	特点
编译型	把模型编译成目标硬件专属代码（.so / engine），运行时直接执行	MLC-LLM、TRT-Edge-LLM、LMDeploy、ExLlamaV2	性能上限高，但需编译步骤、构建期吃内存
解释型	运行时逐算子解释执行（读 ONNX / GGUF 图）	llama.cpp、ONNX Runtime、MNN	免编译即跑，性能取决于算子优化深度

再补一条轴：服务器级 vs 边缘级。

服务器级（vLLM、SGLang、ExLlamaV2）：为数据中心 GPU 设计，高并发、大模型、多卡。内存开销大，8GB 边缘设备基本劝退。
边缘级（MLC-LLM、TRT-Edge-LLM、llama.cpp、MNN、mllm）：单机低功耗、内存受限，拼的就是 tok/s 和峰值内存。

为什么这两条轴重要？ 因为"好不好用"从来不是绝对的——vLLM 是服务器吞吐王，但拿到 8GB Jetson 上就是灾难；MNN 是手机 CPU 王者，但拿到 Jetson CUDA 上就水土不服。选型的第一步是认清自己的战场。

二、第一梯队：值得投入的 4 个方案

1. MLC-LLM（TVM 编译路线）—— 1.5B/3B 首选 ⭐

一句话原理：它不是"运行时解释 ONNX"，而是 “编译器把你的模型变成一段专属的 CUDA 程序”。TVM 在编译期完成模型导入 → 静态量化（q4f16）→ TensorIR 优化 → CUDA 代码生成，Jetson 上只剩一个轻量 runtime 直接执行。

为什么它专治 8GB 的痛：

构建和运行彻底解耦。TRT-Edge-LLM 的引擎是"设备指纹"，必须在 Jetson 本机构建，构建期峰值内存是推理期的 2~3 倍——这就是我 1.5B 五次 OOM 的根因。而 MLC 的编译产物是普通 CUDA 库（.so）+ 参数文件，在 PC 上交叉编译（--host aarch64-unknown-linux-gnu + sm_87）后 scp 拷入即跑，构建内存压力根本不出现在设备上。
量化是编译期的事。q4f16 格式把权重静态压成 int4，1.5B 权重从 3.0GB 压到 ~1.2GB（新版还能用 --quantize-embedding 连 embedding 一起压），推理峰值约 2.5-3GB，8GB 的机器留了将近一半余量。
性能有 NVIDIA 官方背书：Orin Nano Super 上 3B INT4 达 38-43 tok/s、7B 21.75 tok/s。
原生流式 + OpenAI 兼容 API（mlc_llm serve），接 ROS2 直接打 /v1/chat/completions，不用像 TRT v0.6.0 那样改源码。

代价：编译链路学习成本高（TVM 生态，不是 pip install 即用）；Jetson 支持是社区驱动，无 NVIDIA 官方分发；性能是区间而非保证，实际值得自己跑。

开源情况：Apache-2.0（mlc-ai/mlc-llm，活跃维护）。HF 官方 mlc-ai 组织有 Qwen2.5 全系列预转换模型（1.5B 约 940MB），还有社区预构建容器 dustynv/mlc:0.20.0-r36.4.0 对应 JP6.2。

Jetson 8GB 适配度：★★★★★

2. TRT-Edge-LLM（NVIDIA 官方）—— 0.5B 已跑通，守阵地 ✅

一句话原理：与服务器版 TensorRT-LLM 同源，但针对 Jetson 的 CUDA + TensorRT 深度定制。全流程是 checkpoint 导出（ONNX）→ TensorRT 引擎构建 → C++ runtime 推理。

我的实测数据（0.5B）：TTFT 1.9s，生成 21.9-30.5 tok/s，峰值内存 4.23GB，功耗 15.2W。

优点：NVIDIA 官方维护，文档/教程齐全；性能有保障；版本与 JetPack 绑定规范（v0.6.x 对应 JP6.2/Orin）；v0.7.1 已支持 Qwen3.5 MTP 推测解码。

致命缺点：

构建必须在 Jetson 本机，构建期内存是推理期的 2-3 倍。我的判断红线：embedding 表（vocab × hidden × 2B fp16）超过 445MB 即死（8GB 上限）——0.5B 的 embedding 是 260MB，1.5B 是 445MB，刚好卡死在红线上，五次 OOM 就是这么来的。
v0.6.0 高层 API 无原生流式（要改源码重编译或 FastAPI 子进程包装）。
升级换代迁移成本高（版本强绑定 JetPack）。

开源情况：Apache-2.0（NVIDIA/TensorRT-Edge-LLM，2025 年开源）。

Jetson 8GB 适配度：★★★★☆（0.5B 全链路已跑通；1.5B 需 16GB 构建拷回或放弃）

3. llama.cpp —— 万能基线，绕不开的参考系 📏

一句话原理：纯 C/C++ 实现，GGUF 模型格式 + 多档量化（Q4_K_M 等）。底层 ggml 张量库，MMQ/MulMat 量化内核针对各 CPU 指令集手写优化。

优点：跨平台最广（Linux/Windows/macOS/Android/iOS/Jetson 全覆盖）；免编译安装，GGUF 模型直接拉即跑；社区最大、更新最快（新模型发布数小时内支持）；server 模式原生流式 + OpenAI 兼容；还有推测解码 fork（如 cortexist/llama.cpp MTP）可提速 30-40%。

缺点：性能上限低于编译型方案（无定制 kernel 融合）；无 paged KV cache；单模型单进程，并发弱。

Jetson 8GB 适配度：★★★★☆（1.5B Q4_K_M 约 1GB，~25 tok/s，作为基线够用）

我的定位：所有新方案的性能数字，我都会先拿 llama.cpp 做基准比一比——它是最公平的"参考系"。

4. LMDeploy（TurboMind 引擎）—— 免编译的中间项 🚀

一句话原理：上海 AI Lab / InternLM 团队出品，核心是 TurboMind C++ 推理引擎，预置了高度优化的 INT4 GEMM kernel（基于 FlashInfer），模型加载后直接跑——没有"导出→构建引擎"那一步。官方基准（RTX 4090，Llama-2-7B）TurboMind 206 tok/s，比 MLC 的 159 tok/s 还快约 30%。

优点：pip install 即用，无编译步骤，性能接近编译型；原生流式 + OpenAI 兼容 API；官方文档把 Jetson Orin 列为目标平台；对 Qwen 系列优化好（同源模型）。

缺点：社区以中文为主，国际生态弱；Jetson 8GB 实测数据少；aarch64 适配依赖编译（无官方预编译 wheel）。

Jetson 8GB 适配度：★★★☆☆（理论可用，30-50 tok/s 是估计值，需自测）

三、第二梯队：了解即可的 3 个方案

5. ONNX Runtime（CUDA EP）—— 快速备选

一句话原理：微软的跨平台推理引擎，EP（Execution Provider）插件架构，CUDA EP 调用 cuDNN/cuBLAS 执行。图优化器做算子融合，但没有 fused attention——这是它性能瓶颈的关键：Attention 拆成多个 kernel 逐个执行，带宽浪费严重。

优/缺点：标准 ONNX 生态、pip 即装、跨平台，这是优点；无 fused attention → 1.5B 只有 10-20 tok/s（对比 MLC 的 38-43），而且 ORT 的 TensorRT EP 会重演 TRT 构建 OOM（绕回原路），这是硬伤。

Jetson 8GB 适配度：★★★☆☆（1.5B 标准 ONNX 峰值 ~5GB 可跑，性能是代价）

6. mllm（UbiquitousLearning）—— 小众探索

注意！ 这个项目叫 mllm（北邮/上交团队），不是阿里的 MNN-LLM，俩名字太像了，调研时差点搞混。

一句话原理：多模态轻量推理引擎，纯 C/C++ 无依赖，复用 ggml 的 ARM 底层 kernel + 自研 NPU 路径（ASPLOS 2025 论文）。2026-03 起实验性支持 Jetson Orin/Thor 的 CUDA（Qwen3-VL-2B W8A8 在 AGX Orin 32GB 上 3.12x prefill 加速）。

Jetson 8GB 适配度：★★★☆☆（小众探索选项，CUDA 标注"实验特性"，不急于投入）。MIT 协议。

7. PowerInfer —— 原理值得了解，Qwen 场景不适用

一句话原理：上海交大 IPADS 实验室，利用 LLM 的激活稀疏性——每次推理只有部分神经元被激活。离线 profiling 出"热神经元"（驻留 GPU）和"冷神经元"（放 CPU），GPU 不够的部分 CPU 补。统一内存架构（如 Jetson）上天然适配，无需 CPU-GPU 拷贝。

为什么 Qwen 用不了：Qwen2.5 用 SwiGLU 激活（较密），稀疏性红利大幅缩水；预转换模型仅 ReluLLaMA 等少数几个，Qwen 不在支持列表。要做 ReLU 化改造才能发挥优势，学术项目生产成熟度低。

Jetson 8GB 适配度：★★☆☆☆（原理有启发，别在 Qwen 上浪费时间）

四、第三梯队：不建议投入的 6 个方案（含原因）

方案	类型	不推荐原因
vLLM	服务器级	aarch64 pip wheel 不存在、编译失败；假设完整服务器环境，8GB 单进程太重；NVIDIA CES demo 是在 Jetson Thor（128GB）上跑的，不是 Orin 8GB
SGLang	服务器级	与 vLLM 同级，同样 aarch64 编译 + 内存开销；8GB 跑不起来。但它的 RadixAttention 前缀缓存思路，做 ROS2 Agent 多轮工具调用时可借鉴
ExLlamaV2	桌面 GPU 专用	EXL2 混合精度量化很牛（70B 压进 24GB），但 CUDA kernel 假设桌面 GPU 架构，社区明确报告 Jetson “Generally unsupported”
ExecuTorch	移动端/NPU 向	Meta 官方 PyTorch 端侧 runtime，支持 Jetson 但不是 CUDA 主场；以后部署手机/NPU 再考虑
Ollama	llama.cpp 封装	上手最易，但 Orin 上内存常驻 5.8GB、启动 18s，比直接 llama.cpp 多 10-15% 开销——8GB 设备内存预算太紧张，原型可以，生产别用
MNN-LLM	编译优化（CPU 向）	见下方单独说明

特别说明：MNN-LLM —— 手机 CPU 的王者，不是 Jetson CUDA 的选手

MNN-LLM（阿里）确实有 CUDA 后端，sm_87 在支持范围内（SM60-SM120），理论上能编译后在 Orin 8GB 上跑 Qwen2.5。但它的全部核心优势都在 CPU 侧：

论文宣称的"8.6x prefill / 2.3x decode vs llama.cpp"，是在**手机 CPU（ARM NEON sdot/i8mm 指令）**上测的。ARM 汇编重排、big.LITTLE 多核均衡、DRAM-Flash 混合存储——这些优化在 Jetson CUDA 上全部用不上。
CUDA 后端没有任何公开的 LLM 性能基准，kernel 优化深度完全未知（黑盒）。
独立仓库已停更（2025-01），Jetson 零文档零测试。

结论：用 CUDA 后端跑 MNN 等于"放弃了它全部的 CPU 优化，只剩一个没验证过的 CUDA kernel"，和 MLC-LLM（TVM 为 sm_87 定制编译的 CUDA kernel）竞争时毫无优势。

开源情况：Apache-2.0（alibaba/MNN，阿里官方开源）。Jetson 8GB 适配度：★★☆☆☆

五、性能速查表（Jetson Orin 8GB 场景）

方案	模型/量化	预期 tok/s	推理峰值内存	构建/安装成本
TRT-Edge-LLM	0.5B fp16（实测）	21.9-30.5	4.23GB	高（本机构建）
MLC-LLM	1.5B q4f16	20-40（社区）	~2.5-3GB	中（PC 交叉编译）
MLC-LLM	3B q4f16	38-43（NVIDIA 基准）	~3.5GB	中
llama.cpp	1.5B Q4_K_M	~25	~1.5GB	低（免编译）
LMDeploy	1.5B INT4	30-50（估计）	~2GB	低（pip 装）
ORT CUDA EP	1.5B fp16/int8	10-20	~5GB	低（pip 装）
MNN-LLM	1.5B INT4	无 CUDA 数据	未知	中（源码编译）

注：tok/s 均为社区报告范围，实际值受功耗模式（15W/25W/MAXN）、上下文长度影响。顺带说一句，我实测 TRT 0.5B 在 15W 模式是 21.9-30.5 tok/s——低功耗模式对性能的影响，比很多教程说的要大。

六、我的选型结论 + 组合拳建议

按需求选型

需求	推荐	理由
1.5B/3B 追求速度	MLC-LLM	PC 交叉编译绕开构建 OOM，q4f16 量化，原生流式 + OpenAI API
0.5B 已跑通继续用	TRT-Edge-LLM	别浪费已构建的引擎，守阵地
快速看 1.5B 效果	llama.cpp / LMDeploy	免编译，当天可跑
1.5B 不想编译	ORT CUDA EP	标准 ONNX 直跑，代价是 10-20 tok/s
ROS2 集成	MLC serve / llama.cpp server	原生流式 + OpenAI 兼容
生产化服务	自研 FastAPI 网关 + 任一引擎	网关统一调度，引擎随便换

三梯队结论

第一梯队（值得投入）：MLC-LLM（主力）、TRT-Edge-LLM（已跑通）、llama.cpp（基线）、LMDeploy（免编译中间项）
第二梯队（了解即可）：ORT（备选）、mllm（小众探索）、PowerInfer（原理参考）
第三梯队（不适用）：vLLM/SGLang（服务器向）、ExLlamaV2（桌面 GPU 专用）、ExecuTorch（手机 NPU 向）、Ollama（原型玩具）、MNN-LLM（CUDA 无验证）

最关键的认知：真正提速的是"组合拳"，不是换引擎

把 13 个方案都摸完之后，我最深的体会是——端侧 LLM 提速的杠杆排序是：量化 > 推测解码 > 引擎选型。

量化（q4f16 / Q4_K_M / INT4）：内存减半到四分之一，这是 8GB 上能不能跑 1.5B/3B 的前提；
推测解码（EAGLE / Medusa / MTP）：小模型先猜、大模型验证，端侧算力闲置严重（memory-bound），正好把闲置算力利用起来，实测可提速 30-40% 甚至翻倍；
引擎选型：决定了上限和开发成本，但没有量化和推测解码，光换引擎是挤不出多少油的。

所以我的落地路线是：MLC-LLM（q4f16）为主引擎跑 1.5B/3B，TRT-Edge-LLM 守 0.5B 阵地，llama.cpp 做性能基线，后续在 MLC 上叠加 EAGLE 推测解码冲更高 tok/s。

七、附录：开源协议速查（13 个全部可免费商用）

协议	工具	商用限制
Apache-2.0	MLC-LLM、TRT-Edge-LLM、LMDeploy、vLLM、SGLang、MNN、PowerInfer	无（需保留版权声明，修改需标注）
MIT	llama.cpp、ONNX Runtime、ExLlamaV2、mllm、Ollama	无（最宽松）
BSD-3-Clause	ExecuTorch	无（需保留版权声明）