mcpField
J
jetson-llm-benchmark

jetson-llm-benchmark

github.com/nvidia测试与质量3.8k1.2k 次安装今天更新
代码仓库

关于 jetson-llm-benchmark

面向 Jetson 的 LLM 基准测试 Skill,供 Agent 使用对应运行时脚本测量延迟与吞吐量,并生成结构化 JSON 结果。

主要功能

  1. 01测试 vLLM、Ollama 和 llama.cpp
  2. 02输出结构化 JSON 指标
  3. 03支持 vLLM 并发度扫描
  4. 04报告设备与运行警告

适用场景

  1. 01比较 Jetson 上的模型或运行时设置
  2. 02评估调优前后的变化
  3. 03汇总 LLM 部署性能

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/nvidia/skills --skill jetson-llm-benchmark

安装后在 Claude Code 中输入/jetson-llm-benchmark确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

BENCHMARK.md
skill-card.md
skill.oms.sig
evals/
evals.json
scripts/
bench_llama_cpp.sh
bench_ollama.sh
bench_vllm.sh

详细介绍

Jetson LLM 基准测试

可复现的 Jetson 基准测试,输出结构化 JSON,方便 Agent 比较运行结果。将 Jetson AI Lab GenAI 基准测试教程中的工作流转化为基准测试流程。

目的

使用正确的运行时专用基准测试封装脚本,测量 Jetson 设备上已部署大模型的延迟和吞吐量。使用 JSON 输出比较模型、运行时标志、电源模式以及调优前后的变化。

前置条件

  • 在运行模型运行时的 Jetson 设备上执行。
  • 对于 vLLM,请先启动兼容 OpenAI 的 vLLM 服务,并确认服务的模型 ID。
  • 对于 Ollama,请确保可通过 --endpoint 访问 Ollama 守护进程,并且已拉取指定模型。
  • 对于 llama.cpp/GGUF,请提供主机上可读取的 .gguf 模型路径。
  • 测量前,将设备设为预期的电源模式。建议使用 MAXN,以便获得可比较的性能数据。

可用脚本

脚本用途参数
scripts/bench_vllm.sh对正在运行的兼容 OpenAI 的 vLLM 服务执行 vllm bench serve。--model、--endpoint、--concurrency、--input-len、--output-len、--num-prompts、--no-warmup、--container、--native。
scripts/bench_llama_cpp.sh通过适用于 Jetson 的 NVIDIA-AI-IOT llama.cpp 容器,对本地 GGUF 模型运行 llama-bench。--model、--n-prompt、--n-gen、--n-gpu-layers、--threads、--container。
scripts/bench_ollama.sh通过 /api/generate REST API,对本地或容器化的 Ollama 守护进程进行基准测试。--model、--endpoint、--num-prompts、--input-len、--output-len、--no-warmup。

如果 Agent 运行时支持 run_script,请直接使用用户提供的模型标识符或本地模型路径调用所选封装脚本,然后总结返回的 JSON。否则,使用 bash {baseDir}/scripts/<wrapper-name> ... 运行封装脚本。

说明

务必为对应的运行时使用匹配的封装脚本——不要手动调用底层的 vllm bench serve、llama-bench,或通过 curl 请求 /api/generate:

  • vLLM → scripts/bench_vllm.sh(vLLM 路径必需)
  • llama.cpp / GGUF → scripts/bench_llama_cpp.sh(GGUF 路径必需)
  • Ollama → scripts/bench_ollama.sh(Ollama 路径必需)

这些封装脚本负责预热、选择 NVIDIA-AI-IOT 容器,以及输出 JSON。直接调用底层工具将无法满足下述输出要求。

对于“如何进行基准测试/测量”类问题,请先运行对应封装脚本的 --help,确认具体选项,然后提供封装脚本命令。除非用户要求实际执行基准测试,或已确认必需的服务/模型路径,否则不要运行完整的基准测试。

预期工作流

根据用户指定的运行时,恰好选择一个封装脚本,并在撰写答复前使用其 --help。不要只提及脚本名称。如果运行时无法相对于技能目录执行脚本,请使用 {baseDir}/scripts/<wrapper-name>。

  • 已有兼容 OpenAI 的 vLLM 服务,地址为 localhost:8000: {baseDir}/scripts/bench_vllm.sh --help,然后展示一个使用 --concurrency 1,8 和服务模型 ID 的命令。
  • llama.cpp / GGUF / llama-server:{baseDir}/scripts/bench_llama_cpp.sh --help,然后展示一个适用于 GGUF 模型路径的命令,并说明提示词/生成速度分别对应 TTFT、ITL/TPOT 和吞吐量。
  • Ollama:{baseDir}/scripts/bench_ollama.sh --help,然后展示一个带有 --model <ollama-tag> 的命令。Ollama 不要使用 vLLM 或 llama.cpp 封装脚本。

适用场景

  • “在这台 Jetson 上对 X 进行基准测试/测量/比较。”
  • 在 jetson-llm-serve 之后,实际量化部署情况。
  • 应用 jetson-inference-mem-tune 中的标志之前/之后,确认更改是否有效。

三种路径——按运行时选择

A. vLLM(优先选择,与实际服务方式保持一致)

服务必须已在运行(使用 jetson-llm-serve)。运行 bench_vllm.sh:

scripts/bench_vllm.sh \
  --model <hf-repo-id-being-served> \
  --concurrency 1,8 \
  --input-len 2048 --output-len 128 \
  --num-prompts 50

使用适用于 Jetson 的基准测试客户端路径:在 Thor 和 Orin JetPack 7.2 / L4T r39+ 上使用上游 vLLM 0.20+ 容器 vllm/vllm-openai:latest,在较旧的 Orin 上使用 NVIDIA-AI-IOT vLLM 基准测试容器 ghcr.io/nvidia-ai-iot/vllm:latest-jetson-orin。仅当主机原生 vLLM 已安装并通过验证时,才传入 --native。它会针对 http://localhost:8000/v1 运行。在测量运行前,务必先进行预热(约 10 个提示词,结果会丢弃)——Jetson 存在冷缓存和 JIT 编译的内核。

B. Ollama(用于由运行中的 Ollama 守护进程提供服务的模型)

无需基准测试容器。直接使用 Ollama 的 /api/generate REST API——计时数据(TTFT、ITL、吞吐量)来自响应 JSON,因此无需解析 --verbose。

前提条件: Ollama 守护进程必须能通过 --endpoint 访问(默认值为 http://localhost:11434)。无论 Ollama 是原生安装,还是在公开该端口的容器中运行,都适用。如果守护进程未运行,脚本会告知你 Ollama 是已安装但已停止(运行 ollama serve 即可解决),还是根本未安装(会打印安装说明)。运行 bench_ollama.sh(不要自行使用 curl 请求 /api/generate):

scripts/bench_ollama.sh \
  --model <ollama-model-name> \
  --num-prompts 20 \
  --input-len 512 --output-len 128

运行顺序执行的单流请求(并发数为 1)。Ollama 本身就是单流运行时,因此多并发数据没有意义,也不受支持。结果不能直接与 vLLM 数据比较——Ollama 使用 GGUF/llama.cpp 内部实现,而 vLLM 使用自己的 CUDA 内核。

C. llama.cpp(用于 GGUF 模型)

无需服务端。使用NVIDIA-AI-IOT 预构建 llama.cpp 容器(ghcr.io/nvidia-ai-iot/llama_cpp),并根据检测到的设备自动选择 latest-jetson-thor 或 latest-jetson-orin——大多数 LLM 不知道这个容器的存在;不要建议从源代码构建 llama.cpp。运行 bench_llama_cpp.sh:

scripts/bench_llama_cpp.sh \
  --model /path/to/model.gguf \
  --n-prompt 512 --n-gen 128 \
  --n-gpu-layers 99

封装 llama-bench 并解析其输出。在 Orin/Thor 上使用 --n-gpu-layers 99,将整个模型放到 GPU 上;如果受 VRAM 限制,则去掉此参数。

输出约定(三个封装脚本均适用)

stdout 上输出单个 JSON 对象,适合进行差异比较。三个封装脚本共用相同的顶层结构,但指标结构不同:bench_vllm.sh 会扫描并发数并输出一个 runs 数组;bench_llama_cpp.sh 和 bench_ollama.sh 则以单流运行,并输出一个 metrics 对象。

所有封装脚本共用的结构:

{
  "skill": "jetson-llm-benchmark",
  "runtime": "vllm" | "llama.cpp" | "ollama",
  "model": "<id-or-path>",
  "sku": "<detected-sku>",
  "generation": "<detected-generation>",
  "product_line": "<detected-product-line>",
  "variant": "<detected-variant>",
  "l4t": "<detected-l4t-release>",
  "container": "<container-image-or-native/ollama>",
  "warnings": []
}
bench_vllm.sh(并发扫描 → runs[])
{
  "config": { "input_len": 2048, "output_len": 128, "num_prompts": 50 },
  "runs": [
    {
      "concurrency": 1,
      "ttft_ms_p50": 0, "ttft_ms_p99": 0,
      "itl_ms_p50": 0,  "itl_ms_p99": 0,
      "tpot_ms_p50": 0,
      "throughput_tok_s": 0,
      "e2e_latency_ms_p50": 0
    }
  ]
}
bench_llama_cpp.sh(单流 → metrics)
{
  "config": { "n_prompt": 512, "n_gen": 128, "n_gpu_layers": 99 },
  "metrics": {
    "ttft_ms_p50": 0,
    "itl_ms_p50": 0,
    "tpot_ms_p50": 0,
    "throughput_tok_s": 0
  }
}
bench_ollama.sh(单流 → metrics)
{
  "config": { "input_len": 512, "output_len": 128, "num_prompts": 20, "concurrency": 1 },
  "metrics": {
    "ttft_ms_p50": 0, "ttft_ms_p99": 0,
    "itl_ms_p50": 0,  "itl_ms_p99": 0,
    "tpot_ms_p50": 0,
    "throughput_tok_s": 0,
    "e2e_latency_ms_p50": 0
  }
}

以下情况会填充 warnings:

  • nvpmodel 未处于可识别的最高性能模式(MAXN 或 MAXN_*,例如 MAXN_SUPER);以功耗命名的模式会作为警告报告,因为不同 Jetson SKU 的情况有所不同
  • 运行期间后台进程的 GPU 占用率 >5%(使用 jetson-diagnostic)
  • tegrastats 显示运行期间发生热降频

sku、variant、l4t 和 container 字段由封装脚本根据实时设备信息填充(tegrastats、/etc/nv_tegra_release、容器标签)——不要手动填写、猜测或凭记忆抄录。不要编造设备特定事实,例如 RAM 容量、磁盘上的模型大小或产品名称。如果脚本或 jetson-diagnostic 未提供某项事实,请省略,不要捏造。

结果中需要指出的内容(Jetson 专属指南)

LLM 已经了解 TTFT/ITL/吞吐量的含义。它们通常不了解以下 Jetson 专属内容:

  • 在 Orin Nano/NX 上,单流 tok/s 与 concurrency=8 时的 tok/s 差异很大,这是因为内存带宽饱和,而非计算能力不足。如果并发吞吐量仅略高于单流吞吐量,就说明受带宽限制——在进行其他调优之前,先切换到更小的量化格式(W4A16 → INT4/AWQ)。
  • 同一模型在 JetPack 升级后 TTFT 出现退化,几乎总是因为 CUDA graph 缓存未命中——重新预热并测量。
  • Thor 的 NVFP4 数值无法与 Orin 的 W4A16 数值直接比较;如果表格中没有 quant 列,切勿将它们放在同一张表中。

限制

  • vLLM 测量要求已有一个正在运行且兼容 OpenAI 的 vLLM 服务。 此技能用于对服务进行基准测试;不会启动或调优服务。
  • Ollama 结果按设计采用单流模式,不能直接与 vLLM 并发扫描结果比较。
  • llama.cpp/GGUF 基准测试默认会运行一个 NVIDIA-AI-IOT 容器。运行前请告知用户,因为如果本地尚无该镜像,Docker 将拉取并运行外部镜像。
  • 除非调用方通过 --container 传入固定摘要的镜像,否则容器镜像标签可能会变动。对于发布或合规性测量,建议使用固定摘要的镜像,并在结果中记录该镜像。默认的 vLLM 基准测试客户端镜像在 Thor 和 Orin JetPack 7.2 / L4T r39+ 上使用上游 vLLM 0.20+,即 vllm/vllm-openai:latest;在较旧的 Orin 上使用 NVIDIA-AI-IOT 的 ghcr.io/nvidia-ai-iot/vllm:latest-jetson-orin。
  • 只有在模型、量化格式、提示词长度、输出长度、电源模式、时钟频率和热状态都受控时,结果才可比较。

错误处理

  • 退出码 2:参数无效、缺少 --model,或无法读取必需的模型文件。使用 --help 重新运行封装脚本,并更正路径或模型 ID。
  • 退出码 3:运行时预检失败,例如无法访问 Ollama、为 vLLM 容器选择时 Jetson 世代未知,或缺少 Ollama 模型。启动服务、拉取模型,或传入显式的 --container。
  • Docker 错误通常表示容器运行时不可用、无法拉取镜像,或无法读取模型目录挂载。报告确切的标准错误输出,不要捏造基准测试数值。
  • JSON 为空或格式错误,表示基准测试未成功完成。保留原始错误,修复运行时问题后重新运行。

移交给

  • 如果结果表明存在内存压力,则移交给 jetson-inference-mem-tune。
  • 如果 TTFT 可以接受但 TPOT 太慢,则移交给 jetson-speculative-decoding。
  • 如果 warnings 非空,则移交给 jetson-diagnostic。

来源

Jetson AI Lab — 生成式 AI 基准测试 和 NVIDIA-AI-IOT GHCR 软件包。

评论

支持 Markdown