本文将介绍如何在 Jetson Thor 平台上编译、部署和测试 llama.cpp 项目中的 GGUF 格式的大模型。
克隆 llama.cpp
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
CUDA GPU Compute Capability（计算能力）
计算能力（CC）定义了每种 NVIDIA GPU 架构的硬件特性和支持的指令。在下表中查找您的GPU的计算能力。
编译
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES="110"
cmake --build build --config Release -j $(nproc)
模型部署
运行 llama-server
NVIDIA Jetson Thor 采用了 Blackwell 架构的 GPU。
性能基准测试分析
部署模型
vllm serve /models/Qwen/Qwen3-8B --served-model-name qwen3
运行性能基准测试
vllm bench serve \
--base-url http://localhost:8000 \
--model qwen3 \
--tokenizer /models/Qwen/Qwen3-8B \
--dataset-name random \
--random-input-len 2048 \
--random-output-len 128 \
--num-prompts 100 \
--max-concurrency 8
该文章是对 NVIDIA Jetson Thor 平台进行大语言模型部署、系统优化和深度性能基准测试的权威指南。
平台配置与环境准备： 文章首先详细介绍了在 Jetson AGX Thor 开发套件上进行 BSP（Jetson Linux）安装流程。这包括下载 ISO 映像、使用 Balena Etcher 创建可启动 USB 棒，以及通过首次启动完成 UEFI 固件更新和 Ubuntu 初始设置。软件环境基于 JetPack 7，它提供了对前沿机器人和生成式 AI 的全面支持。部署环境采用云原生技术，通过 Docker 容器运行 vLLM 或 TritonServer 等推理服务。
系统性能调优：
为了释放硬件全部潜力，文章强调了系统级的性能调优步骤：必须通过 sudo nvpmodel -m 0 将功耗模式设置为最高性能模式 (MAXN)（130W），并使用 sudo jetson_clocks 锁定 CPU、GPU 和内存的核心频率，禁用 DVFS 机制。测试结果显示，MAXN + jetson_clocks 组合能显著提升性能，在高负载下，FP8 模型的吞吐量提升约 18.5%，在低负载下，每 Token 平均延迟（TPOT）减少约 43%。
量化模型基准测试结果： 文章对 Qwen3-8B 模型的多种量化精度（包括 BF16、FP8、FP4、Int4 等）进行了详尽的性能分析。
安装 FastChat & vLLM
安装 FastChat
FlashAttention-2 currently supports:
Turing GPU T4 不支持，需要使用 FlashAttention 1.x，否则会报错 ❌：
可以比较两个连续模型推理的准确性和性能指标，这些推理在两个不同的受支持的英特尔设备上执行或以不同的精度执行。交叉检查工具可以比较每层或整个模型的指标。
查看帮助信息 $ python cross_check_tool.py -h usage: -------------------------------------------------------------- For cross precision check provide two IRs (mapping files may be needed) run: python3 cross_check_tool.py \ --input path/to/file/describing/input \ --model path/to/model/.xml \ --device device_for_model \ --reference_model path/to/reference_model/.
服务器 CPU 40核，内存 256G，操作系统 Ubuntu 20.04，Python3.9
RESTAPI 基于 FastAPI 实现的文件上传和下载 router = APIRouter(prefix='/file_benchmarking', tags=['Files']) @router.post('/upload/binary/chunk/async_func/async_r_sync_w', tags=['Upload', 'binary']) async def upload_binary_chunk_async_func_async_r_sync_w(request: Request): file_path = get_random_filename() with open(file_path, "wb") as file: async for chunk in request.stream(): file.write(chunk) return {'file_path': file_path} @router.
CPU
概念
平均负载
单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和 CPU 使用率并没有直接关系。
当平均负载高于 CPU 数量 70% 的时候，你就应该分析排查负载高的问题了。一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能。 70% 这个数字并不是绝对的，最推荐的方法，还是把系统的平均负载监控起来，然后根据更多的历史数据，判断负载的变化趋势。当发现负载有明显升高趋势时，比如说负载翻倍了，你再去做分析和调查。
工具
查看 cpu核数
nproc
lscpu
grep 'model name' /proc/cpuinfo | wc -l
显示平均负载 uptime
uptime、top，显示的顺序是最近1分钟、5分钟、15分钟，从此可以看出平均负载的趋势
$ uptime
12:51:13 up 754 days, 2:02, 3 users, load average: 0.41, 0.65, 2.63
持续自动运行命令 watch
watch -d uptime: -d会高亮显示变化的区域
系统压力测试工具 stress
安装
yum install stress -y
strees: --cpu cpu压测选项，-i io压测选项，-c 进程数压测选项，--timeout 执行时间
使用 FastAPI 实现了文件的上传和下载，部署服务使用了 uvicorn 和 gunicorn+uvicorn 两种方法。
基准测试工具使用的是 wrk
服务器 CPU 40核，内存 256G，操作系统 Ubuntu 20.04，Python3.9
测试流程
使用的测试图片 health.jpg (256kb)
生成测试数据
生成通过 HTTP POST 发送二进制数据的文件。
python make_http_postdata.py make health.jpg postdata
file: /home/wjj/test/postdata
boundary: gouchicao0123456789
创建用于 wrk 的 lua 脚本：postfile.lua
wrk.method = "POST"
local f = io.open("postdata", "rb")
wrk.body = f:read("*all")
wrk.headers["Content-Type"] = "multipart/form-data; boundary=gouchicao0123456789"
部署 FastAPI 应用 uvicorn uvicorn app.
健康码识别服务使用了 FastAPI 进行开发的，本周主要工作是为了对健康码识别的服务进行性能调优。接口函数使用了 async 关键字，但是内部的实现并没有使用 await。由于改写成异步代码需要时间，这里并没有改写代码，只是删除了 async 关键字。部署服务使用了 uvicorn 和 gunicorn+uvicorn 两种方法。
基准测试工具使用的是 ab
测试流程
生成测试数据
准备测试图片 health.jpg
echo -n '{"base64": "' > health.json
base64 -w0 health.jpg >> health.json
echo -n '"}' >> health.json
部署服务
uvicorn
docker run --runtime=nvidia --rm -it -e NVIDIA_VISIBLE_DEVICES=2 -p 20001:8000 \
-v $(pwd):/health_code_service --name=health-uvicorn health-code-service \
uvicorn controller:app --host 0.0.0.0 --workers 1