Jetson 部署大模型:从刷机到跑通推理的完整步骤
在 Jetson 上部署大模型,核心思路是先用 JetPack 把系统环境准备好,再编译支持 GPU 加速的推理框架,最后加载量化后的模型文件进行验证。
整个过程对零基础用户来说并不复杂,但需要留意内存限制和依赖版本匹配。
下面按实际操作顺序展开。
先确认设备型号与系统版本
不同型号的 Jetson 内存大小和算力差异很大,直接决定能跑多大的模型。
开始前先登录设备终端,执行以下命令确认硬件信息:
cat /etc/nv_tegra_release
free -h
第一条命令查看 L4T 版本,第二条查看可用内存。
一般来说,8GB 内存的设备建议运行 7B 以下的量化模型,16GB 及以上可以尝试 13B 级别。
如果系统版本过旧,建议先用 NVIDIA SDK Manager 刷入较新的 JetPack,刷机前备份好个人数据。
刷机完成后,确保设备能正常联网,并执行一次系统更新:
sudo apt update && sudo apt upgrade -y
配置 Python 与编译工具链
Jetson 自带的 Python 版本可能较旧,建议安装 Python 3.8 以上版本,并配置虚拟环境隔离依赖。
以 Ubuntu 系统为例:
sudo apt install -y python3-pip python3-venv git cmake build-essential
python3 -m venv ~/llm-env
source ~/llm-env/bin/activate
pip install --upgrade pip
虚拟环境激活后,后续所有操作都在该环境中进行。
如果 pip 安装速度慢,可以临时更换国内镜像源,但不要随意修改系统全局配置。
编译支持 GPU 的推理框架
在 Jetson 上常用 llama.cpp 作为推理后端,它对 ARM 架构和 CUDA 的支持较好。
克隆源码并编译:
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
mkdir build && cd build
cmake .. -DLLAMA_CUBLAS=ON
make -j4
编译参数 -DLLAMA_CUBLAS=ON 用于启用 CUDA 加速。
如果编译过程中提示找不到 CUDA,先确认 JetPack 中的 CUDA 工具链已安装,并检查 nvcc --version 是否正常输出。
编译完成后,build/bin 目录下会生成 main 等可执行文件。
准备模型文件并执行推理
大模型原始权重通常较大,需要先转换为 gguf 格式并量化。
可以在性能更强的电脑上完成转换,再把量化后的文件拷贝到 Jetson。
以 4-bit 量化为例,转换命令参考:
python convert.py /path/to/model --outtype f16 --outfile model-f16.gguf
./quantize model-f16.gguf model-q4_0.gguf q4_0
将生成的 model-q4_0.gguf 拷贝到 Jetson 后,运行推理测试:
./build/bin/main -m /home/user/models/model-q4_0.gguf -p "你好,请介绍一下你自己" -n 128 --gpu-layers 20
--gpu-layers 表示卸载到 GPU 的层数,数值越大显存占用越高。
如果出现内存不足,适当调低该值。
首次运行会加载模型,耐心等待输出结果。
常见报错与避坑提醒
部署过程中容易遇到几类问题,提前了解可以减少反复折腾:
- 编译报错缺少 CUDA 头文件:检查 JetPack 版本与 CUDA 路径是否匹配,必要时设置
export PATH=/usr/local/cuda/bin:$PATH。 - 推理时提示 out of memory:降低
--gpu-layers数值,或换用更小的量化模型,同时关闭其他占用内存的进程。 - 模型加载失败:确认 gguf 文件完整,转换时没有中断,文件权限允许当前用户读取。
- 运行速度慢:检查是否真正启用了 GPU 加速,编译时是否遗漏
LLAMA_CUBLAS参数。
验证部署是否成功
完成推理测试后,可以从三个方面确认部署效果:
- 观察终端是否正常输出文本,且没有报错中断。
- 执行
nvidia-smi或tegrastats查看 GPU 占用情况,推理时应有明显波动。 - 记录单次推理耗时,作为后续优化或更换模型的参考基线。
如果以上步骤都能顺利通过,说明大模型已经在 Jetson 上跑通。
后续可以根据实际场景调整量化等级和 GPU 层数,在速度与效果之间取得平衡。
遇到新问题时,优先回看编译参数和内存占用这两个最容易出错的环节。