> ## Documentation Index
> Fetch the complete documentation index at: https://dragonwingdocs.qualcomm.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 为 LLM、VLM、音频和 VLA 工作负载选择 Qualcomm 运行时（第 5 部分，共 7 部分）
> 为 LLM、VLM、音频和 VLA 工作负载选择 Qualcomm 运行时路径，并衡量每种产品真正重要的指标。
经典的视觉迁移主要围绕张量、预处理、量化和摄像头流水线。
GenAI 迁移则增加了另一层：
```text theme={null}
模型权重
运行时格式
提示模板
tokenizer
上下文长度
prefill 速度
decode 速度
内存占用
serving API
多模态输入
```
这就是为什么我们对 LLM、VLM、音频和 VLA 工作负载的最佳实践是在移植你自己的应用之前，先从一个受支持的参考路径开始。
对于大多数团队，这意味着**先用 GenieX**。
GenieX 为你提供本地 LLM/VLM 推理的 Qualcomm 面向路径，带有 CLI、Python SDK、Linux ARM64 上的 Docker 以及与 OpenAI 兼容的本地服务器。它还暴露了两条有用的运行时通道：
| 运行时通道 | 模型格式 | 最适合 |
| -------------------- | -------------------- | -------------------------- |
| GenieX + `llama_cpp` | GGUF | 广泛的 Hugging Face 模型覆盖和快速实验 |
| GenieX + `qairt` | Qualcomm AI Hub 预编译包 | 受支持模型的 NPU 聚焦路径 |
当你需要底层调试或直接的 GGUF 实验时，原始 `llama.cpp` 仍然有用。对于迁移故事，GenieX 是更干净的首要推荐。
本文是一份决策指南，而不是每种模态的完整食谱。在贯穿的案例研究中，它涵盖了可选的本地 LLM/VLM sidecar，它可以放在迁移后的摄像头流水线旁边。
在开始之前：
```text theme={null}
[ ] 已知目标开发板和可用内存
[ ] 已选择或缩窄运行时通道：GenieX qairt、GenieX llama_cpp、原始 llama.cpp 或应用运行时
[ ] 已提供模型格式：AI Hub 包、GGUF、ONNX 或框架检查点
[ ] 已记录 tokenizer、提示模板和上下文长度
[ ] 已定义工作负载特定指标：TTFT、decode tok/s、WER、首个音频延迟或动作延迟
```
***
## 从运行时开始，而不是从模型名称开始
在 Jetson 上，GenAI 原型可能围绕 vLLM、TensorRT-LLM、llama.cpp、Python Transformers 或自定义服务构建。第一个 Qualcomm 决定不是"具体哪个框架替换它？"而是：
```text theme={null}
我需要广泛的 GGUF 覆盖，还是一个预编译的 Qualcomm NPU 工件？
```
这给你一棵小的决策树：
```text theme={null}
需要最快的第 0 天演示或广泛的模型选择？
-> GenieX + llama_cpp 运行时
需要来自 AI Hub 的受支持 NPU 优化工件？
-> GenieX + qairt 运行时
需要与现有本地 LLM 服务的应用兼容？
-> GenieX 本地服务器 / 与 OpenAI 兼容的 API
需要尚未覆盖的自定义模型架构？
-> 把它当成一个模型移植项目，而不是命令行切换
```
这与视觉文章相同的主题：当有现成工件时使用它，只有在模型需要时才构建转换路径。
对于运行中的智能摄像头案例研究，最小的有用动作是：保留现有的 sidecar API，在 Dragonwing 上证明一个 GenieX 本地服务器，然后只交换服务 URL 或后端。除非音频和 VLA 是真实的产品需求，否则跳过它们。
***
## LLM：分别测量 prefill 和 decode
单一的"每秒 token 数"隐藏了太多。
对于面向用户的 LLM 工作负载，至少追踪：
| 指标 | 它告诉你什么 |
| ------------------ | ------------------ |
| TTFT | 用户等待第一个 token 需要多久 |
| Prefill tokens/sec | 提示/上下文被处理的速度 |
| Decode tokens/sec | 新 token 生成的速度 |
| 上下文长度 | 真实提示是否装得下 |
| 内存变化 | 应用是否能在长会话中存活 |
| 持续功耗 | 产品是否能持续运行 |
一个模型可以有很好的 decode 速度，但如果 TTFT 高，它仍然感觉慢。一个模型可以运行短演示，但在生产上下文长度翻倍时仍然失败。
使用 GenieX 基准测试或运行时日志跨模型和 OS 镜像捕获相同的测量。`geniex-bench` 是一个独立的二进制文件，与 `geniex` CLI 分开。从 GenieX 基准测试教程安装它，把 `BENCH` 设置到解压后的二进制文件，然后运行像这样的示例：
```bash theme={null}
curl -fsSL \
https://qaihub-public-assets.s3.us-west-2.amazonaws.com/qai-hub-geniex/geniex-bench-linux-arm64.tar.gz \
| tar xz
BENCH_DIR=$(ls -d geniex-bench-linux-arm64-*)
export LD_LIBRARY_PATH="$BENCH_DIR/lib:$BENCH_DIR/lib/llama_cpp${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
export GENIEX_PLUGIN_PATH="$BENCH_DIR/lib"
BENCH="$BENCH_DIR/bin/geniex-bench"
"$BENCH" \
--plugin llama_cpp \
--device npu \
-m unsloth/Qwen3.5-0.8B-GGUF:Q4_0 \
-p 512 \
-n 128
"$BENCH" \
--plugin qairt \
--device npu \
-m ai-hub-models/Qwen3-4B \
-p 512 \
-n 128
```
对于 GGUF/`llama_cpp`，上下文长度可以在模型和内存限制内于运行时调整。对于 `qairt` 包，上下文长度由编译后的包固定；如果产品提示需要，请使用更长上下文的包。
对于简单的首次运行，使用当前 GenieX 文档中的一个示例：
```bash theme={null}
geniex infer ai-hub-models/Qwen3-4B
```
对于广泛的 GGUF 实验，使用当前 GenieX 文档中的一个示例：
```bash theme={null}
geniex infer unsloth/Qwen3.5-0.8B-GGUF:Q4_0
```
对于 GGUF 模型，`Q4_0` 是通常用于 Hexagon NPU 支持的第 0 天选择。
***
## 选择与开发板匹配的模型
模型支持变化很快，所以以 AI Hub 和 GenieX 文档为准。当前已验证的模型族包括示例如：
| 系列 | 示例 | 备注 |
| ------- | ----------------------------------------- | ----------------------- |
| 小型 LLM | Qwen3 0.6B/1.7B、Llama 3.2 1B/3B | 首次本地助手测试的好选择 |
| 较大 LLM | Qwen3 4B/8B、Llama 3.1 8B、Gemma、Phi-4 Mini | 关注内存、上下文和 TTFT |
| VLM | Qwen2.5-VL、Qwen3-VL、SmolVLM、Florence-2 | 验证图像路径和 projector/运行时支持 |
| 音频 | Whisper Tiny/Base/Small、MeloTTS、PiperTTS | 测量流式延迟，而不仅是最终输出 |
| 机器人/VLA | ACT、Pi0.5 | 验证完整的闭环延迟和安全行为 |
在设备上可靠运行的较小模型通常比只能在实验室提示中工作的较大模型更有用。
***
## VLM：把文本路径与视觉路径分开
视觉-语言模型容易被过度简化。它们不是加了一个图像参数的 LLM。
一个 VLM 至少有两条性能路径：
```text theme={null}
image encode / projector 路径
text prefill 路径
text decode 路径
```
这些路径可以有不同的内存占用和运行时行为。分别验证它们：
```text theme={null}
[ ] 纯文本提示工作
[ ] 单图像提示工作
[ ] 预期图像分辨率工作
[ ] 重复的图像提示保持内存稳定
[ ] TTFT 在真实图像负载下可接受
[ ] 在产品图像上答案质量可接受
```
对于 Jetson 迁移，主要的应用问题通常是你的应用是否已经与一个 OpenAI 兼容端点通信。如果是，GenieX 本地服务器可以让应用侧的变更保持很小。验证你版本中确切的 AI Hub 模型 ID：
```bash theme={null}
geniex pull ai-hub-models/Qwen3-4B-Instruct-2507
geniex serve
```
然后在设备上本地测试：
```text theme={null}
http://127.0.0.1:18181/v1/chat/completions
```
对于网络上的另一台机器，要么用你 GenieX 版本文档记录的 bind/host 选项启动服务器，要么使用 SSH 隧道。这样可以让迁移边界保持干净：模型 serving 先变，然后是应用逻辑。
***
## 音频：把流式作为产品路径
音频演示常作为批处理作业通过，但作为产品失败。
对于像 Whisper 这样的 ASR 模型，测量：
```text theme={null}
片段长度
分块大小
第一个部分结果延迟
最终结果延迟
WER
音频捕获周围的 CPU 负载
反复片段上的内存增长
```
对于像 MeloTTS 或 PiperTTS 这样的 TTS 模型，测量：
```text theme={null}
首个音频延迟
实时因子
音频欠载
语音质量
播放周围的 CPU 负载
```
如果 Jetson 版本使用 Python 服务，一开始保留那个边界。交换推理后端、保留请求/响应契约，然后再优化捕获/播放路径。
最小的有用音频迁移计划是：
```text theme={null}
Qualcomm 上的已知良好模型
-> 与 Jetson 相同的测试片段
-> 相同的评分脚本
-> 相同的服务 API
-> 然后优化流式
```
在称音频迁移完成之前的最低可交付物：一个可重复的脚本，在 Jetson 和 Dragonwing 上运行相同片段，打印 WER 或实时因子，并记录首个结果延迟。
***
## VLA 和机器人：延迟是安全输入
视觉-语言-动作模型和机器人策略有不同的成功条件。好听的答案不够。动作循环必须稳定。
对于 ACT、Pi0.5 或类似工作负载，测量完整循环：
```text theme={null}
摄像头帧到达
预处理
模型推理
动作解码
控制输出
机器人执行
下一帧反馈
```
有用的关口：
| 关口 | 原因 |
| ------- | ----------------- |
| 端到端动作延迟 | 决定控制稳定性 |
| 抖动 | 尖峰可能比平均延迟更糟 |
| 内存增长 | 长时间 rollout 暴露泄漏 |
| 热行为 | 机器人持续运行 |
| 安全回退 | 当推理错过截止时间时需要 |
| 确定性日志记录 | 需要用于调试糟糕的 rollout |
模型运行时只是一部分。产品是闭环。
在称 VLA 迁移完成之前的最低可交付物：一个记录了输入时间戳、推理时间戳、动作时间戳、错过的截止时间和安全回退行为的日志回放或闭环运行。
***
## 来自 Jetson 的迁移模式
| Jetson 模式 | Qualcomm 起点 |
| ------------------------ | ------------------------------------ |
| 本地 `llama.cpp` 服务器 | GenieX 本地服务器或 GenieX `llama_cpp` 运行时 |
| TensorRT-LLM / vLLM 原型 | 如果模型受支持则 GenieX `qairt` |
| Python Transformers 脚本 | GenieX Python SDK 或 CLI 包装器 |
| 自定义 REST 服务 | 保留 REST 契约，改变其背后的运行时 |
| DeepStream + LLM sidecar | 保留 sidecar 边界，单独迁移视觉流水线 |
| 调用模型服务的 ROS 节点 | 保留 ROS 消息契约，先移动推理服务 |
实际的迁移不是重写。它是保留已经工作的服务边界。
***
## 公平地做基准测试
在比较 Jetson 和 Qualcomm 数字之前，记录设置：
```text theme={null}
模型名称和确切修订版
运行时
精度
上下文长度
批次/并发
提示长度
输出 token 数
图像/音频分辨率
OS 镜像
SDK/运行时版本
功耗模式 / 热状态
```
然后报告与工作负载匹配的指标：
| 工作负载 | 主要指标 |
| ---- | ------------------------------------- |
| LLM | TTFT、prefill tok/s、decode tok/s、内存、功耗 |
| VLM | 图像 TTFT、decode tok/s、图像尺寸、内存、功耗 |
| ASR | WER、第一个部分延迟、最终延迟、实时因子 |
| TTS | 首个音频延迟、实时因子、欠载 |
| VLA | 端到端动作延迟、抖动、持续热行为 |
一个在可接受延迟下使用较少功耗的 Qualcomm 结果，可能是更好的产品结果，即使 Jetson GPU 在狭义的合成基准中胜出。
***
## 结论
对于 GenAI 和机器人工作负载，模型文件只是迁移的一部分。运行时选择、serving API、tokenizer 行为、上下文长度、内存和持续功耗都很重要。
从 GenieX 开始。对广泛的 GGUF 覆盖和快速实验使用 `llama_cpp` 通道。当 AI Hub 提供受支持的 NPU 优化包时使用 `qairt` 通道。尽可能保留现有的服务边界，分别测量 TTFT 和 decode，并在称迁移完成之前验证完整的产品循环。