在 Jetson AGX Orin/Orin-X 平台的实际运行中，CUDA 与 DLA 原本各司其职，却因并发而偶发集体“假死”——所有线程在 cudaStreamSynchronize() 阻塞中寸步难行。面对这一似乎无解的死锁暗礁，我从故障复现场景入手，定位到混合推理流中的同步点；随后排除了显存越界、流类型、DLA 降频等常见因素；最终灵感来源于“反向隔离”思路——为 GPU 与 DLA 各自配置独立的 GPU Context，并通过显式的异步拷贝与同步保证数据无缝切换。
本文将以最直接的技术视角——从现象描述、排查方法到“多 Context 安全气囊”实现细节——全流程解读如何在 7×24h 压测中彻底消除死锁，实现并行推理的性能与可靠性双赢。

一、问题现象

1. 偶发死锁

• 症状描述：单进程内，所有线程在调用 GPU 时集体“假死”——cudaStreamSynchronize() 一直阻塞，tegrastats 显示 GPU 占用率维持在某个固定值，不再波动。

• 复现难度：

  • 极不稳定：有时运气极差，一周都无法触发；有时运气极好，仅需两小时即复现。
  • DLA 与 CUDA 混合推理时尤甚：DLA 推理线程先“提前几毫秒”挂死，其他线程随后也步入停滞。

  

  

2. 环境特征

• 硬件平台：Jetson AGX Orin 系列（最初使用 AGX Orin，后转至 Orin-X）。
• 推理流程：
  1. 全部模型均通过 TensorRT 的 enqueueV3() + CUDA Stream 异步执行；
  2. 前处理同样基于 CUDA Stream；
  3. 部分子图运行于 DLA，非支持算子回落至 Tensor/Tensor Core。

二、初步排查

1. 定位死锁环节

通过在各关键步骤间插入 cudaStreamSynchronize()，逐步缩小排查范围：

1. 前处理 —— 无异常；
2. TensorRT enqueueV3() —— 成功返回；
3. 自定义 Plugin（HWCBGR → CHWRGB）—— 顺利完成；
4. 同步点 —— 在 Plugin 之后的第一次 cudaStreamSynchronize() 挂死。

2. 排除思路

• 显存越界？

  • 其中一个模型 A 曾在 2024 年出现过显存越界，但通常显存越界会触发 sticky error 并抛出 illegal memory access 而非死锁。

• Blocking vs. Non-blocking Stream？

  • 初步猜测 DLA 可能依赖于 blocking stream，而我使用的是 non-blocking 版；最终未能证实。

• DLA 频率降频？

  • 若 DLA 调用低于 2 Hz，会自动释放并重申请资源，导致延迟飙升。
  • 提升调用频率后虽解决了降频，但死锁依旧。

  

三、环境变更与新线索

1. 从 AGX Orin 到 Orin-X

• 2024 年 3 月，怀疑 AGX Orin DLA 变频机制有问题，遂放弃尝试；
• 2025 年 3 月，转战 Orin-X，DLA 频率稳定——但在并行运行其他 GPU 模型 A 时，依旧触发死锁。

2. 关键“怀疑模型 A”

• 模型 A 曾导致显存越界，虽然在最小化测试环境下并未复现死锁，但在系统中只要与 DLA 并行，死锁概率骤增，然而其余模型并不会导致该问题。
• 单独跑 DLA、单独跑模型 A 均正常，仅并行时“相逢即死锁”。

四、“安全气囊”诞生：多 Context 隔离策略

1. 灵感来源

面试一位候选人提到的 GPU 多进程中间件：

“通过截获多进程的 GPU 请求，在后端融合 context，实现时分复用，从而提升GPU利用率。”

虽然该方案与我单进程场景相悖，却激发了一个思路——反其道而行之：既然单 context 并行 DLA + GPU 会死锁，何不为它们分别提供独立 context？

2. 实施要点

1. 上下文划分
   • Orin 系列拥有 2 个 DLA 引擎 + 1 个 GPU，引擎间资源隔离天然独立；
   • 为 DLA 和 GPU 各自创建独立 TensorRT Context。
2. 内存与数据同步
   • 注意：在 CUDA Context 之外，显存、Host 映射等资源也无法跨 context 共享；
   • 切换 Context 时，显式 cudaMemcpyAsync() 与 cudaStreamSynchronize() 确保数据同步与完整性。
3. 并行执行
   • DLA 上跑模型 H；
   • GPU 上跑模型 A、B、C、D、E；
   • 彼此互不干扰，独立抢占各自算力。

五、最终验证

• 7×24 h 连续压测：自 2025 年 4 月以来，未再出现任何死锁。
• 蝴蝶效应终成蝶：原本令人头痛的 DLA 隐晦死锁，反而催生出一套“安全气囊”式的多 context 并行机制——既排除了模型 A 的潜在越界风险，又保障了 DLA 与 GPU 资源的稳健协同。

六、结语

当我们在深度学习推理的微观世界里拨开层层迷雾，总会发现，看似偶然的卡死背后，往往是资源管理与并发调度的微妙博弈。通过多 Context 隔离，为 DLA 与 GPU 架起了一道“安全栅栏”，既兼顾了性能，又守护了系统的可用性——这，或许就是自动驾驶推理优化的下一块基石。

—— 致正在与 DLA、TensorRT、CUDA “暗礁”博弈的你

在边缘设备上部署大语言模型一直被认为是算力密集型的’禁区’，但当我用一块Jetson Xavier AGX成功运行了DeepSeek-R1 14B和QWQ-32B模型时，推理速度稳定在 8 tokens/s (DeepSeek-R1 14B) / 4 tokens/s (QWQ-32B) 以上！本文将分享从环境配置到量化优化的完整方案，证明边缘设备同样可以成为轻量化AI的舞台。

一、硬件配置与挑战分析：

• 设备选型：NVIDIA Jetson Xavier AGX
• 核心参数：512核Volta GPU + 8核Carmel CPU / 32GB RAM / 32GB eMMC
• 系统环境：JetPack 5.1.3 (Ubuntu 20.04) / CUDA 11.4 / TensorRT 8.5.2
• 功耗模式：默认10W切换至MAXN模式

为什么选择DeepSeek & QWQ？

部署三大难关

1. 显存墙：FP16模型加载即需14GB+显存 → Jetson统一内存
2. 架构差异：ARM平台与x86服务器的库兼容性问题 → Docker容器化
3. 计算瓶颈：Token生成速度<5tokens/s时用户体验差 → 流水线优化

二、技术实现全流程拆解

阶段一：构建ARM适配的基础环境

核心挑战：NVIDIA Jetson Xavier的ARM架构与常规x86服务器存在三大差异：

1. 指令集差异：ARMv8.2与x86_64的SIMD指令集不兼容（如NEON vs AVX512）
2. 内存管理差异：Jetson采用CPU-GPU统一内存架构（UMA），与传统PCIe分体式显存管理模式冲突
3. 软件生态差异：PyTorch等框架的ARM预编译包缺失关键算子支持

技术路线：
采用「容器化隔离+定制化编译」双轨策略：

1. 硬件抽象层：通过 jetson-containers 项目预构建CUDA、cuDNN等核心组件的ARM64版本容器镜像
2. 依赖解耦：针对JetPack 5.1.3的特定版本（CUDA 11.4 + TensorRT 8.5.2），使用镜像解决动态库符号链接问题

关键实现：

1. 更新python版本：jetson-containers代码依赖Python 3.9（functools.cache），需要将原有python3.8更新为python3.9版本

1
2

sudo rm /usr/bin/python3 && \
sudo ln -s /usr/bin/python3.9 /usr/bin/python3

2. 安装jetson-containers：

1
2

git clone https://github.com/dusty-nv/jetson-containers
bash jetson-containers/install.sh

3. 设置Docker Runtime：
   修改/etc/docker/daemon.json配置，并指定default-runtime

1
2
3
4
5
6
7
8
9
10

{
    "runtimes": {
        "nvidia": {
            "path": "nvidia-container-runtime",
            "runtimeArgs": []
        }
    },

    "default-runtime": "nvidia"
}

重启docker服务

1

sudo systemctl restart docker

1

sudo docker info | grep 'Default Runtime'

显示docker没有root权限：

1	sudo usermod -aG docker $USER

阶段二：构建Ollama基础镜像

1. 修改Dockerfile
   修改jetson-containers/packages/llm/ollama/Dockerfile为以下内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

#---
# name: ollama
# group: llm
# config: config.py
# depends: cuda
# requires: '>=34.1.0'
# docs: docs.md
#---
ARG BASE_IMAGE \
    CMAKE_CUDA_ARCHITECTURES \
    CUDA_VERSION_MAJOR \
    JETPACK_VERSION \
    OLLAMA_REPO \
    OLLAMA_BRANCH \
    GOLANG_VERSION \
    CMAKE_VERSION

# build the runtime container
FROM ${BASE_IMAGE}

ARG JETPACK_VERSION \
    CUDA_VERSION_MAJOR

EXPOSE 11434
ENV OLLAMA_HOST=0.0.0.0 \
    OLLAMA_MODELS=/data/models/ollama/models \
    PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
    LD_LIBRARY_PATH=/usr/local/cuda/lib:/usr/local/cuda/lib64:/usr/local/cuda/include:${LD_LIBRARY_PATH} \
    JETSON_JETPACK=${JETPACK_VERSION} \
    CUDA_VERSION_MAJOR=${CUDA_VERSION_MAJOR}

RUN apt-get update && \
    apt install -y curl  && \
    rm -rf /var/lib/apt/lists/* && \
    apt-get clean

COPY nv_tegra_release /etc/nv_tegra_release

#ADD https://api.github.com/repos/ollama/ollama/branches/main /tmp/ollama_version.json
RUN curl -H "Authorization: token ${GITHUB_TOKEN}" \
    -o /tmp/ollama_version.json \
    https://api.github.com/repos/ollama/ollama/branches/main

RUN curl -fsSL https://ollama.com/install.sh | sh

RUN rm /usr/bin/python || true && \
    ln -s /usr/bin/python3 /usr/bin/python

COPY start_ollama /

CMD /start_ollama && /bin/bash

2. 构建镜像

1

jetson-containers build ollama

3. 验证构建镜像

1

docker images | grep ollama

阶段三：模型下载 & 推理

1. 进入Container环境

1

jetson-containers run --name ollama $(autotag ollama)

2. 模型下载

1
2

ollama pull qwq:latest
ollama pull deepseek-r1:14b

3. 模型推理验证

1

ollama run qwq:latest

查看GPU使用率

1

jtop

jtop安装：

1 2	sudo pip3 install -U jetson-stats && \ sudo systemctl restart jtop.service

阶段四（可选）：K3S部署与服务搭建

待补充

三、性能实测：数据不说谎

模型对比实验

deepseek-r1:14b

QwQ:32b

成本效益对比

应用场景：这不是玩具，是生产力

案例1：openweb-ui知识库本地问答

待补充

在 NVIDIA Jetson 平台上进行性能分析时，perf 工具是不可或缺的利器。然而，由于硬件架构和内核版本的特殊性，直接使用预编译版本可能无法完全满足需求。本文将从源码开始，详细介绍如何在 Jetson Orin 和 X86 平台上构建 perf 工具，并解决编译过程中可能遇到的常见问题。

一、准备工作：源码下载

Jetson Orin 平台

1. 下载 L4T 驱动包
   访问 NVIDIA 开发者下载中心，搜索 Jetson Linux Driver Package (L4T)，选择与设备匹配的版本（如 R35.x 系列）。
   [注：需根据 Jetson 型号选择对应的版本，参考下图中的版本号。]
   
2. 获取 BSP 源码
   下载完成后，找到 public_sources.tbz2 文件，这是构建内核和工具链所需的基础源码包。
   

Orin Drive 平台

1. 查看当前系统的核版本

   1

   uname -r

2. 下载内核源码
   访问 Linux 内核镜像站，根据当前系统内核版本下载对应的源码包。
   例如：若内核版本为 5.15.116-rt-tegra，则下载 linux-5.15.116.tar.gz。

X86 平台

1. 查看当前系统的核版本

   1

   uname -r

2. 下载内核源码
   访问 Linux 内核镜像站，根据当前系统内核版本下载对应的源码包。
   例如：若内核版本为 5.10.0，则下载 linux-5.10.tar.gz。

二、源码编译步骤

编译环境准备

1

sudo apt install make gcc flex bison pkg-config -y

Jetson Orin 编译流程

1
2
3
4
5
6
7
8
9
10

tar -xjvf public_sources.tbz2 && \
cd Linux_for_Tegra/source/public && \

tar -xjvf kernel_src.tbz2 && \
cd kernel/kernel-5.10/tools/perf && \

make -j$(nproc) && \
sudo make install && \

./perf --version

Orin Drive 编译流程

1
2
3
4
5
6
7
8

tar zxvf linux-5.15.116.tar.gz && \
cd linux-5.15.116/tools/perf && \

make -j$(nproc) && \
sudo make install && \

./perf --version

X86 平台编译流程

1. 安装依赖项
   X86 平台需安装以下开发库：

   1 2 3 4

   sudo apt-get install build-essential flex bison python3 python3-dev \ libelf-dev libnewt-dev libdw-dev libaudit-dev libiberty-dev \ libunwind-dev libcap-dev libzstd-dev libnuma-dev libssl-dev \ binutils-dev gcc-multilib liblzma-dev

2. 编译 perf

   1 2 3 4 5 6 7

   tar zxvf linux-5.10.tar.gz && \ cd linux-5.10/tools/perf && \ make -j$(nproc) && \ sudo make install && \ ./perf --version

三、开启内核调试支持

默认情况下，Linux 内核会限制 perf 的权限。通过以下命令解除限制：

1

sudo sysctl kernel.perf_event_paranoid=-1

将此设置永久生效，可将其写入 /etc/sysctl.conf。

四、通过 perf 生成火焰图：直观分析性能瓶颈

火焰图（Flame Graph）是性能分析的利器，它能以可视化方式展示程序的函数调用栈和资源占用情况。结合 perf 工具，我们可以快速生成火焰图，精准定位性能瓶颈。以下是详细操作步骤：

1. 安装火焰图生成工具

首先需要克隆 Brendan Gregg 的 FlameGraph 工具库：

1
2

git clone https://github.com/brendangregg/FlameGraph.git
cd FlameGraph

将此工具的路径加入环境变量，或直接通过绝对路径调用脚本（如 ./FlameGraph/stackcollapse-perf.pl）。

2. 使用 perf 采集性能数据

运行目标程序，并通过 perf record 记录性能事件（如 CPU 周期、缓存失效等）：

1
2
3
4
5
6

# 监控 CPU 使用情况（默认）
sudo perf record -F 99 -a -g -- sleep 60
# 或监控特定进程
sudo perf record -F 99 -p <PID> -g -- sleep 30
# 或监控具体程序
sudo perf record -F 99 -g ./<MY_PROGRAM>

• 参数说明：
  • -F 99：采样频率为 99 Hz（避免与某些内核频率冲突）。
  • -a：监控所有 CPU。
  • -g：记录调用栈（生成火焰图必需）。
  • -- sleep 60：持续采样 60 秒。

3. 生成火焰图

采集完成后，按以下步骤处理数据：

1
2
3
4
5
6
7
8

# 生成 perf.data 的解析文本
sudo perf script > out.perf

# 折叠调用栈（关键步骤）
./FlameGraph/stackcollapse-perf.pl out.perf > out.folded

# 生成 SVG 格式火焰图
./FlameGraph/flamegraph.pl out.folded > flamegraph.svg

4. 查看与分析火焰图

用浏览器打开 flamegraph.svg，可以看到类似下图的交互式可视化结果：

火焰图解读技巧：

• 横向宽度：表示函数或代码路径的资源（如 CPU 时间）占用比例。
• 纵向层级：表示函数调用栈的深度，顶层是正在执行的函数，下层是调用者。
• 点击缩放：支持点击任意区块展开查看细节。
• 高亮搜索：按 Ctrl + F 搜索关键函数名。

五、常见问题解决（FAQ）

Q1：编译时提示某些 Feature 未启用

问题现象
编译过程中出现 WARNING: ... missing xxx,某些功能将被禁用。

解决方法

1. 查看具体错误日志：

   1	cat ../build/feature/test-libunwind.make.output

   

2. 根据缺失的依赖安装对应开发库。
   安装elf即可sudo apt install -y libelf-dev，其余Feature开启方法同理

   1 2 3 4 5 6

   sudo apt install -y libelf-dev sudo apt install libunwind-dev sudo apt install -y libdw1 sudo apt install -y elfutils sudo apt install -y libdw-dev sudo apt install -y binutils-dev

Q2：运行 perf 时权限不足

若未设置 kernel.perf_event_paranoid，需通过 sudo 运行 perf，或按第三步永久解除限制。

六、总结

通过从源码构建 perf 工具，可以确保其与当前内核版本的完全兼容性，并启用所有高级功能。如果在编译中遇到问题，请优先检查依赖项和错误日志，大多数问题均可通过安装缺失的库解决。

效果验证
成功编译后，运行 perf list 可查看支持的性能监控事件。尝试使用 perf stat 或 perf record 分析程序性能。