在 Jetson Orin 8GB 上成功部署 Qwen2.5-VL-3B 多模态大模型，图文识别速度 23.0 tok/s

最近世界机器人运动会正在如火如荼地进行，世界机器人大会也在北京举行，看到王兴兴的演讲后突然对当前的机器人大模型技术有了兴趣。经过几天的研究发现，目前机器人和自动驾驶领域的大模型应用技术，最前沿的是 WAM（World-Action Model，世界-动作模型）。由于数据太少这个模型还没有真正的工程化应用，目前工程化应用的技术大多为 VLA 模型。VLA（Vision-Language-Action 视觉-语言-动作模型）= VLM（视觉语言模型）+ 动作输出。VLM 输出文本回答，VLA 则能够直接输出机器人可执行控制动作。代表模型有：RT-2（Google）、OpenVLA（斯坦福）、π0、GR00T；适合机械臂、人形机器人具身控制。还有很多的机器人公司基于的硬件平台算力有限，或者主打低成本，使用的是 VLM 模型，输出文本然后根据文本再用自己的平台技术生成 Action 动作。
于是我就想试试这些模型的性能，经过研究然后我就发现，我手头的 Jetson Orin Nano Super 8GB 内存无论如何也不够部署现有的 VLA 模型，除非进行量化、裁剪和蒸馏改造，工程量太大。
我就先在这个只有 8GB 内存的 Jetson Orin 上跑一个能看图的 VLM 大模型，看看性能如何，做几个应用试试。经过一番折腾，Qwen2.5-VL-3B 愉快地跑了起来，速度不慢，完全满足我的要求，今天就来跟大家分享一下这个实战经验。

🎯 为什么要做这个实验？

说实话，现在的 AI 圈子真是卷得不行。GPT-4V、Gemini 这些大模型是多模态，但都是云端服务。对于边缘设备部署，我们想要的是：

• 🚀 本地运行：数据不上传，隐私有保障
• 💰 成本控制：不用付费 API，一次部署终身使用
• ⚡ 响应快速：本地推理，网络延迟为 0
• 🔧 灵活定制：可以根据具体需求微调和优化

手头的 Jetson Orin 8GB 作为测试平台，这个设备算是边缘 AI 的"黄金配置"——不算太贵，性能也够用。关键是只有 8GB 内存，这能真正考验模型的实用性。能识别图片又能给文字指令的话，我能发挥的地方就多了，比如我可以让它监视我家的傻狗有没有拆家、拆家报警。可以监视儿童的睡眠和苏醒，盯着孩子写作业，监控疲劳驾驶。这些都是比较有实际应用价值的工作，设备低功耗时只有 15W，超频 25W，还不如你家头顶照明灯的功率大，电费超级省，部署 VLM 后不用担心像频繁使用网络模型那样超支。总之我相信算力越便宜，用的人越多。

🛠️ 环境准备：硬软件配置

硬件配置

• 设备：NVIDIA Jetson Orin 8GB RAM
• 架构：ARM64, sm_87（Orin 专用架构）
• CUDA：12.6 (JetPack 6.2)

说实话，一开始我还担心 8GB 内存不够用。但经过测试，只要合理配置，完全够用！

软件环境

• 操作系统：Linux (Ubuntu based)
• 编译工具：build-essential, cmake, git, curl
• 模型格式：GGUF (Quantized 4-bit)

🔥 第一步：编译 llama.cpp（踩坑记录）

1.1 系统依赖安装

sudo apt update
sudo apt install -y build-essential cmake git curl

1.2 llama.cpp 源码获取与编译

这里我要重点说一下！一开始我直接 git clone 然后编译，结果发现没有启用 CUDA 加速，速度慢得要命。后来才发现需要加上 -DGGML_CUDA=ON 参数：

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
# 注意这个参数很重要！
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j $(nproc)

💡 编译要点：

• 一定要启用 CUDA backend：不然就只能用 CPU 跑，速度会慢很多
• 多线程编译：-j $(nproc) 能大大加快编译速度
• Release 优化：这样编译出来的版本运行效率更高

编译过程大概需要 10-15 分钟，大家可以趁机泡杯咖啡 ☕

📥 第二步：模型下载（关键步骤）

2.1 主模型下载

huggingface-cli download Taoufik/Qwen2.5-VL-3B-Instruct-Q4_K_M-GGUF \
  --local-dir ./qwen_vl_gguf/

2.2 视觉投影组件下载

⚠️ 重点来了！ 很多人部署多模态模型失败就是因为漏了这个步骤！

wget https://huggingface.co/Mungert/Qwen2.5-VL-3B-Instruct-GGUF/resolve/main/Qwen2.5-VL-3B-Instruct-mmproj-f16.gguf \
  -P /home/zy/Desktop/workplace/models/qwen_vl_gguf/

模型组成说明：

• 主模型：qwen2.5-vl-3b-instruct-q4_k_m.gguf (~1.8GB) - 这是语言模型部分
• 视觉投影：Qwen2.5-VL-3B-Instruct-mmproj-f16.gguf (~几百MB) - 这是处理图片的部分

两个缺一不可！我第一次测试的时候就只下载了主模型，结果报 500 错误，查了半天才发现是少了这个 mmproj 组件。

🤖 第三步：文本能力测试（先跑个简单的）

在测试视觉功能之前，我们先验证一下基本的文本生成能力是否正常。

3.1 命令行模式测试

./build/bin/llama-cli \
  -m ~/Desktop/workplace/models/qwen_vl_gguf/qwen2.5-vl-3b-instruct-q4_k_m.gguf \
  -p "解释量子计算的基本原理" \
  -n 512 \
  --ctx-size 2048

测试结果：

• 模型成功生成关于量子计算的详细解释
• 推理性能：Prompt: 151.1 tok/s | Generation: 23.2 tok/s
• 输出质量：逻辑清晰，内容准确，完全符合预期！

说实话，看到这个结果的时候我还是挺激动的。毕竟在边缘设备上能达到这样的推理速度，已经很实用了。

3.2 服务器模式测试

接下来我们启动一个 HTTP 服务，这样其他程序也能通过 API 调用：

./build/bin/llama-server \
  -m ~/Desktop/workplace/models/qwen_vl_gguf/qwen2.5-vl-3b-instruct-q4_k_m.gguf \
  --host 127.0.0.1 \
  --port 8080 \
  --ctx-size 2048

API 测试：

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-3.5-turbo",
    "messages": [
      {"role": "user", "content": "你好，请用一句话介绍一下你自己"}
    ],
    "max_tokens": 128
  }'

服务器性能数据：

• Prompt 处理：157.47 tokens/s
• 文本生成：19.37 tokens/s
• 响应时间：158.76ms (prompt), 981.08ms (generation)
• 内存占用：稳定运行在 8GB 限制内

看到这个服务器跑起来，我心里就有底了。OpenAI 兼容的 API 接口意味着集成起来会非常方便。

👁️ 第四步：视觉理解能力测试（重头戏来了！）

现在到了最关键的部分了——测试图像理解能力！

4.1 CLI 模式图像识别

./build/bin/llama-cli \
  -m ~/Desktop/workplace/models/qwen_vl_gguf/qwen2.5-vl-3b-instruct-q4_k_m.gguf \
  --mmproj ~/Desktop/workplace/models/qwen_vl_gguf/Qwen2.5-VL-3B-Instruct-mmproj-f16.gguf \
  --image ~/Desktop/workplace/tensorRT/vlm_lama_cpp_deploy/test_resized.jpg \
  -p "这张图片里有什么？" \
  -n 256 \
  --ctx-size 2048

图像识别结果：

说实话，看到这个结果的时候我真的很惊喜！模型不仅识别出了主要的物品，还注意到了一些细节。这种细致的观察能力在边缘设备上真的很有用。

4.2 服务器模式视觉测试

现在我们启动完整的多模态服务器：

./build/bin/llama-server \
-m ~/Desktop/workplace/models/qwen_vl_gguf/qwen2.5-vl-3b-instruct-q4_k_m.gguf \
  --mmproj ~/Desktop/workplace/models/qwen_vl_gguf/Qwen2.5-VL-3B-Instruct-mmproj-f16.gguf \
  -ngl 99 \
  --ctx-size 3072 \
  --host 127.0.0.1 \
  --port 8080

这里我要特别说明几个参数：

• --mmproj：这个参数非常重要！指定视觉投影组件的路径
• -ngl 99：将所有层都卸载到 GPU，充分利用硬件加速
• --ctx-size 3072：图像理解需要更大的上下文窗口

Python 自动化测试：

python test_vlm.py --url http://localhost:8080 --image ./test.jpg \
  --max-tokens 512 --resize 768 --prompt "图片里是什么内容，有没有可乐"

视觉测试结果：

• 图片处理：自动缩放至 768px 长边 (432x768)
• 内容识别：详细描述冰箱内物品布局和种类，有没有肥宅快乐水
• 性能指标：
  • 总耗时: 3.78s
  • 生成速度: 23.0 tok/s
  • Token 使用: 87 completion + 430 prompt = 517 total

这个结果真的很不错！3.78 秒的总耗时，包括图像编码、模型推理和文本生成，对于边缘设备来说已经完全实用了。

📊 性能实测数据分析

性能表现总结

任务类型	功耗	Prefill (tok/s)	TTFT (ms)	Decode (tok/s)
纯文本	15W	233.4	116	15.3
纯文本	25W	372.0	72	23.9
图片理解	15W	180.2	2525	15.2
图片理解	25W	268.6	1694	23.5

📊 性能分析

⚡ 功耗对比：

• 15W 模式：节能模式，适合长期运行的离线应用
• 25W 模式：高性能模式，推理速度提升约 40-50%

📈 任务类型对比：

• 纯文本任务：TTFT 仅 72-116ms，首字生成速度极快
• 图片理解任务：TTFT 较高（1.7-2.5s），但解码速度仍保持 15-23 tok/s

🎯 最佳实践建议：

• 实时交互场景 → 使用 25W 模式
• 长期监控场景 → 使用 15W 模式，更省电且速度仍可接受

功能验证结果

✅ 文本生成能力：完全正常，逻辑清晰，内容准确
✅ 视觉理解能力：准确识别图像内容，细节描述到位
✅ 多模态融合：成功处理图文结合的复杂任务
✅ API 兼容性：OpenAI 格式接口，易于集成

边缘设备适应性分析

✨ 优势：

• 📦 体积适中：模型量化后 ~1.8GB，适合边缘部署
• 🎯 内存可控：8GB RAM 完全够用，还有富余
• ⚡ GPU 加速：推理速度实用，不拖泥带水
• 🔧 灵活配置：支持调整上下文大小，适应不同需求

⚠️ 限制：

• 🧩 组件依赖：图片处理需要额外的 mmproj 组件
• 📷 分辨率敏感：高分辨率图片会显著增加 token 消耗
• 🐌 速度差异：视觉任务相比纯文本速度稍慢

💡 技术要点与踩坑经验

1. 模型组件理解（关键！）

• 主模型 GGUF：包含量化的语言模型参数，负责文本生成
• mmproj GGUF：视觉编码器和投影层，处理图像输入
• 两者配合：完整的多模态能力需要同时加载这两个组件

我第一次测试的时候就吃了这个亏，只下载了主模型，结果一直报 500 错误。后来查了半天日志才发现是缺少 mmproj 组件。

2. 性能优化策略

• GPU 加速：-ngl 99 将所有层卸载到 GPU，充分利用硬件性能
• 上下文管理：根据任务调整 --ctx-size，避免资源浪费
• 图片预处理：缩小图片尺寸能大幅减少 token 消耗
• 量化选择：Q4_K_M 在精度和速度间取得了很好的平衡

3. 踩坑经历与解决方案

❌ 问题 1：图片处理超出上下文限制

error: request (2716 tokens) exceeds the available context size (2048 tokens)

✅ 解决方案：

• 方案 A：调整 --ctx-size 4096，增大上下文窗口
• 方案 B：使用图片缩放，--resize 768 减少图片 token

❌ 问题 2：视觉功能报 500 错误

HTTP Error 500: Internal Server Error

✅ 解决方案：确保启动时加载 mmproj 组件

--mmproj /path/to/mmproj.gguf

❌ 问题 3：端口被占用

couldn't bind HTTP server socket, hostname: 0.0.0.0, port: 8000

✅ 解决方案：

# 查看占用端口的进程
sudo lsof -i :8000

# 杀掉进程或换端口
--port 8080

🚀 应用前景：这能用来做什么？

经过这次测试，我发现这个部署方案有很多实用场景：

🏭 智能边缘设备

• 工业检测：产品质检、缺陷识别
• 智能监控：实时场景分析、异常检测
• 机器人视觉：环境理解、物体识别

🌐 多模态应用

• 图文理解：社交媒体内容分析
• 场景识别：安防监控、智能家居
• 辅助功能：视障人士辅助、教育辅助

🔮 未来改进方向

虽然现在已经成功了，但我觉得还有提升空间：

1. ⚡ 性能优化：进一步优化内存使用和推理速度
2. 🔧 功能扩展：添加更多视觉任务支持，比如目标检测
3. 🎯 部署简化：开发一键部署脚本，降低使用门槛
4. 🌐 应用集成：构建完整的应用解决方案，而不仅仅是模型

🎯 总结：这次实战的收获

说实话，这次实验真的是收获满满：

1. ✅ 部署成功：在 Jetson Orin 8GB 上成功部署了完整的 Qwen2.5-VL-3B 多模态模型
2. ✅ 功能验证：文本生成和视觉理解功能都正常工作，效果超出预期
3. ✅ 性能可行：推理速度满足实际应用需求，16.7 tok/s 的图像理解速度很实用
4. ✅ 内存可控：总体内存占用在 8GB 限制内，还有优化空间

最重要的是，证明了在资源受限的边缘设备上，我们完全可以运行复杂的多模态大模型。这对于 IoT、机器人、工业自动化等领域来说，意义重大。

📝 关键命令速查

启动完整服务：

./build/bin/llama-server \
  -m /path/to/qwen2.5-vl-3b-instruct-q4_k_m.gguf \
  --mmproj /path/to/mmproj.gguf \
  --ctx-size 3072 \
  -ngl 99 \
  --host 0.0.0.0 \
  --port 8000

测试脚本使用：

# 纯文本测试
python test_vlm.py --prompt "解释量子计算"

# 视觉理解测试  
python test_vlm.py --image ./test.jpg --resize 768

# OCR 能力测试
python test_ocr.py --image ./document.jpg --type document

💬 写在最后

这次实验从下午开始，到晚上差不多就完成了。整个过程虽然遇到了一些坑，但解决后的成就感真的很棒。

边缘 AI 正处于爆发期，能在有限资源下运行复杂模型，这才是真正的技术挑战。希望我的这次实战经验能对大家有所帮助。

如果你也在做边缘 AI 部署，欢迎交流踩坑经验！毕竟，解决实际问题才是我们工程师的价值所在，对吧？😄

---

📅 实验时间：2024年8月23日（约4小时）
🔧 实验环境：llama.cpp + CUDA 12.6 + JetPack 6.2 + Python 3.10+

🔗 相关资源：

• llama.cpp GitHub
• Qwen2.5-VL 模型
• Jetson Orin 开发者指南

💡 下一期预告：我会分享如何将这个多模态模型集成到实际的机器人系统中，实现真正的"AI 眼睛"。敬请期待！

---

🎯 觉得有用的话，别忘了点赞关注！有问题的朋友欢迎评论区交流，我们一起成长！

#边缘AI #大模型部署 #JetsonOrin #多模态AI #技术实战