
名称	jetson-llm-benchmark
描述	使用结构化JSON输出，在vLLM、llama.cpp和Ollama上对Jetson LLM/VLM服务性能进行基准测试。
版本	0.0.2
开源协议	“Apache-2.0” metadata:
作者	“Jetson Team” tags: [jetson, llm, benchmark] languages: [bash] data-classification: public

Jetson LLM 基准测试

可复现的Jetson基准测试，具有结构化JSON输出，使代理可以比较运行结果。本技能编码了Jetson AI Lab GenAI基准测试教程中的工作流程。

目的

使用正确的运行时特定基准测试包装器，测量Jetson目标上已部署LLM的延迟和吞吐量。使用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`。

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

说明

始终使用与运行时匹配的包装器脚本 — 请不要手动调用底层vllm bench serve、llama-bench或针对/api/generate的curl：

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>。

现有vLLM兼容OpenAI的服务器位于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>的命令。请勿将vLLM或llama.cpp包装器用于Ollama。

何时使用

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

三条路径 — 按运行时选择

A. vLLM（推荐，便于与部署方式保持一致）

服务器必须已经在运行（使用jetson-llm-serve）。运行 bench_vllm.sh：

scripts/bench_vllm.sh \
  --model <正在服务的HF仓库ID> \
  --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（请勿自行编写针对/api/generate的curl）：

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

按顺序执行单流请求（concurrency=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图缓存未命中 — 请重新预热并重新测量。
Thor NVFP4数字与Orin W4A16数字不可比；在没有quant列的情况下，切勿将它们放在同一张表中。

限制

vLLM测量需要已经运行的兼容OpenAI的vLLM服务器。本技能对服务器进行基准测试；它不启动或调优服务器。
Ollama结果在设计上是单流的，不能直接与vLLM并发扫描比较。
llama.cpp/GGUF基准测试默认运行NVIDIA-AI-IOT容器。在运行之前请告知用户，因为如果镜像不存在，Docker将拉取并执行外部镜像。
除非调用者通过--container传递了摘要固定的镜像，否则容器镜像标签可能是可变的。对于发布或合规性测量，建议使用摘要固定的镜像并在结果中记录。默认vLLM基准测试客户端镜像是通过vllm/vllm-openai:latest的上游vLLM 0.20+（用于Thor和Orin JetPack 7.2 / L4T r39+），以及用于较旧Orin的NVIDIA-AI-IOT ghcr.io/nvidia-ai-iot/vllm:latest-jetson-orin。
只有在模型、量化、提示长度、输出长度、电源模式、时钟和热状态都受控时，结果才具有可比性。

错误处理

退出码2：无效参数、缺少--model，或所需模型文件不可读。使用--help重新运行包装器并更正路径或模型ID。
退出码3：运行时预检失败，例如Ollama无法访问、无法为vLLM容器选择识别Jetson代际，或缺少Ollama模型。启动服务、拉取模型或传递显式--container。
Docker错误通常意味着容器运行时不可用、无法拉取镜像，或模型目录挂载不可读。报告准确的stderr，不要捏造基准测试数字。
空或格式错误的JSON表示基准测试未成功完成。保留原始错误，修复运行时问题，然后重新运行。

移交给

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

来源

Jetson AI Lab — GenAI基准测试和NVIDIA-AI-IOT GHCR包。