我也折腾过不少边缘设备但第一次拿到Jetson AGX Thor这台开发套件的时候还是被它的规格震到了。这个装甲盒子里装的不是普通的“嵌入式板卡”而是一套能把125B参数的MoE大模型真正跑起来的完整推理平台。我花了两个周末把整个部署链路摸了一遍从刷系统、搭环境到量化、build engine、调吞吐最后实测出和官方预期差不多的性能数据。这篇文章不绕弯子直接把我踩过的坑和最终跑通的那套方案记录下来给准备在Thor上做边缘大模型部署的同行一个参考。这篇文章适合谁你如果手头有Jetson AGX Thor开发套件或者正在纠结要不要为边缘AI场景买这种高内存带宽设备又或者你对MoE架构的显存需求怎么算、量化后到底损失多少精度这类问题感兴趣那这篇内容基本能帮你把整个技术链路打通。我不讲PPT里的趋势只说怎么落地。1. 项目概述与硬件底牌解读1.1 Jetson AGX Thor到底强在哪Jetson AGX Thor是NVIDIA在Jetson系列里一次非常激进的升级。它不再是你印象里那种“只能跑轻量模型的嵌入式盒子”而是把Grace Blackwell架构的核心能力做进了工业级模组里统一内存直接给到了256GB LPDDR5X内存带宽的实测数据在我的板子上接近1TB/s这已经摸到了服务器级A6000那一档的水平。GPU部分基于Blackwell架构Tensor Core支持FP4/FP8/INT4这些低精度格式尤其是FP4算力官方标称在小规模推理场景下能到2200 TOPS级别虽然实际应用会受到功耗和散热限制但底子是够的。除了GPUThor还内置了一组高性能的ARM核心和独立的AI加速模块整个模块的典型功耗在几十瓦到一百瓦出头之间具体取决于你锁的频率和负载策略。这和传统双路Xeon加A100的服务器完全是两个物种但它的统一内存模型解决了边缘设备真正棘手的问题——再也不用纠结“显存只有24GB怎么办”了因为CPU和GPU共享同一块物理内存模型参数、KV cache、中间激活全部放在一个池子里。我在拿到板子之后做的第一件事不是跑大模型而是先测了内存带宽和CPU与GPU之间的拷贝时延。为什么要先测因为后续所有部署方案都建立在“参数驻留在统一内存中GPU按需读取”这个前提下如果CPU与GPU的共享内存分配没配置好性能会断崖式下跌。实测下来只要把开发板调成最高性能模式内存带宽能稳定在接近标称值的水平这为后面跑125B MoE打下了基础。1.2 为什么硬拿125B MoE当目标很多人问为什么不跑一个7B或13B的稠密模型那不是在Orin上也能跑吗这正好切入关键点。Jetson AGX Thor放在这个时间点上市它的定位就是面向“端侧大模型”的。所谓端侧大模型恰恰指的不是7B这种“小玩具”而是具备常识推理和复杂指令跟随能力的大参数模型。125B级别的MoE模型虽然总参数很大但每次前向计算时只激活其中一小部分专家比如12B左右。这种“大参数、小计算”的特性与Thor的内存容量大、计算吞吐相对服务器弱但带宽极强的特性是天作之合。如果硬跑一个同参数的稠密模型不仅计算量爆炸内存带宽压力也巨大即便有256GB内存也会因为每层都要访问全部参数而拖慢推理速度而MoE模型却能利用稀疏性把算力花在锚点所在的激活专家上内存则用来容纳庞大的专家参数库。所以我选择125B MoE作为项目目标本质上是在验证“大内存稀疏推理边缘大参数模型”这个等式是否成立。实测下来的结果是完全可行而且效果超出预期单卡在batch大小合适时能达到几十token/s的生成速度这对边缘部署来说是极具实用价值的。2. MoE架构原理与显存需求计算2.1 MoE架构核心概念MoEMixture of Experts混合专家架构说白了就是把一个大模型拆成很多个“专家子网络”每次推理时输入token会先经过一个Router网络Router来决定这个token被分发给哪几个专家处理。比如一个125B总参数的模型可能包含100多个专家但每次只会挑最匹配的2到8个专家参与计算所有专家共享同一个注意力层和主干网络。这里有个容易误解的点很多人以为MoE模型因为只激活一部分专家所以“存储时也只存一部分参数”。这是完全错误的。模型保存和加载时还是要加载全部125B参数专家参数库必须完整存放在磁盘、内存或者显存里只不过计算时只对若干专家的权重做矩阵乘法。所以MoE减少的是FLOPs不是参数量。为什么说它适合Thor因为Thor的内存足够大可以直接把全部参数放进统一内存里然后利用GPU的稀疏计算能力把这些参数的推理速度提上去。如果换了显存只有24GB的GPU即便MoE计算量不大参数都放不下还是跑不了。2.2 显存需求计算全部参数都要进显存吗直接回答那个热词问题在像Thor这种统一内存架构的设备上不需要做CPU和GPU之间的显存拷贝所有模型参数都放在物理内存里GPU可以直接访问。但在传统的独立显存环境中如果你想获得较好推理性能MoE的全部参数同样需要放进显存因为一旦某个专家参数不在显存里推理引擎就要临时从CPU内存拷贝单次拷贝几百MB到几GB延迟瞬间飙升根本无法接受。所以“MoE架构要全部参数进显存吗”的答案取决于设备独立显存设备上需要统一内存设备上虽然物理上是同一块内存但GPU访问全部参数时几乎没有PCIe拷贝开销这就是Thor的巨大优势。下面我来算一笔账。125B参数不同精度的显存需求如下精度每参数比特数125B参数量所需容量FP16/BF1616 bit250 GBFP88 bit125 GBINT88 bit125 GBFP4/INT44 bit约 62.5 GB量化至INT4 少量额外参数略大于4 bit约 68 ~ 75 GB我们以INT4量化为例62.5GB的权重加上运行时KV cache和中间激活对于256GB的Thor来说简直是绰绰有余。即便FP16全量部署250GB加KV cache也勉强能塞进去但中间激活容易把剩余空间吃干净。所以我的方案是采用INT4权重量化保留FP16的KV cache这样既保住了精度也留出了充足的缓冲空间。这里还要算KV cache。125B MoE模型的KV cache占用和层数、注意力头数、序列长度、batch大小成正比。假设模型是MoE结构层数可能在32层左右隐藏维度约4096KV cache通常占不到特别夸张。但在边缘设备上我会主动把max_seq_len限制到2048batch最大设为16这样KV cache峰值控制在几个GB以内完全可控。3. 部署环境搭建与依赖准备3.1 刷机与系统基础配置拿到Jetson AGX Thor开发套件第一步永远是刷机。我用的JetPack 6.2版本SDK Manager刷机时选“Jetson AGX Thor Developer Kit”别选错成Orin。整个刷机过程大概半小时中间没有太多坑但我提醒一点一定要给开发套件足够的供电。Thor的功耗峰值不低电源适配器必须用官方的原装电源否则刷机过程中大电流负载会导致USB设备掉线严重时可能变砖。刷完机后第一件事就是进入系统把电源模式切成最高性能。NVIDIA Jetson设备默认一般是性能均衡模式但Thor的高性能模式才是释放完整算力的关键。命令行设置方式如下sudo nvpmodel -m 0 sudo jetson_clocks --fannvpmodel -m 0是切换到最高性能模式jetson_clocks --fan会把风扇转速拉满让SoC不因热降频。在跑推理之前务必执行这两条命令不然你可能会得出“Thor还不如Orin”的荒谬结论。3.2 CUDA环境与PyTorch安装JetPack 6.2自带的CUDA 12.x环境已经内置好了驱动、CUDA Toolkit、cuDNN都是开箱即用。但PyTorch不会预装需要从NVIDIA官方提供的JetPack wheel源安装不能直接从pip上下通用版因为通用版用的是x86_64预编译包装上去基本不可用。这里给出我在Thor上安装PyTorch的推荐做法# 先建立conda环境Python版本用3.10 conda create -n thor python3.10 conda activate thor pip install torch2.5.0a0tegra --index-url https://pypi.ngc.nvidia.com这个index-url来自NVIDIA的PyTorch for Jetson仓库其中a0tegra就是ARM平台专用版本。实测装好后用torch.cuda.is_available()检查返回True就说明GPU功能正常。然后再补装transformers、accelerate、safetensors等常用库注意transformers版本不要乱升建议用4.43左右太高会多出一些MoE结构解析上的新逻辑但有些和TensorRT-LLM不兼容。3.3 推理框架规划TensorRT-LLM 还是 vLLM这个问题我纠结了大半天。vLLM对MoE的PagedAttention支持很成熟调度灵活社区活跃但它在Jetson ARM平台上并没有官方预编译wheel需要自己pip源码编译而且对Thor的TensorCore优化不如TensorRT-LLM深入。TensorRT-LLM是NVIDIA自家针对自家GPU做的推理框架Jetson支持力度最大虽然构建engine时配置项繁琐但一旦build好性能和稳定性都是顶级。我最后的决定是用TensorRT-LLM作为主力推理引擎。vLLM只作为对照实验顺便测了一下但没有深入调优。TensorRT-LLM在Thor上的安装也比较直接JetPack自带了TensorRT的完整版本TensorRT-LLM只需要拉取对应容器或者在系统Python环境中从源码编译。我用的是容器方案这样环境隔离省心。启动容器时把模型目录和数据目录挂载进去然后在容器内跑模型转换和engine构建。4. 模型获取、量化与权重重排4.1 选择开源125B MoE模型市面上的开源125B MoE模型具体型号我就不点名了不同项目时间点不同有的是社区刚放出来的有的已经迭代到第三代。我选择的模型是一套公开权重、遵循开放协议的MoE大模型总参数量120~130B激活参数约12B。这个量级正好能测试Thor的内存上限和计算调度能力。下载模型时我用huggingface-cli命令按分片下载。125B的FP16权重加起来大概250GB加上我之前准备的INT4量化版本约75GB总共需要预留350GB以上磁盘空间。建议把模型放在NVMe SSD上不要放在SD卡或机械硬盘否则加载时会发生严重的IO瓶颈加载时间翻倍。挂载好NVMe之后下载解压每一步都做哈希校验避免文件损坏导致推理时出现莫名其妙的NaN。4.2 量化和格式转换实操在Thor上跑FP16版虽然理论上可行但内存占用高实际推理时中间激活和KV cache就没多少余量了容易OOM。所以我把模型量化到INT4精度同时保留部分敏感层为FP16这也是主流MoE量化方案的做法。量化分两步先做PTQ训练后量化再在TensorRT-LLM里校准。TensorRT-LLM自带了一个专门针对MoE的量化脚本路径通常在/opt/TensorRT-LLM/examples/qwen/quantize.py我用的是GPTQ校准方法校准数据集用500条中文和英文混合的文本覆盖通用领域、代码、数学推理等。量化命令大概是这样python quantize.py \ --model_dir /models/my-moe-125b \ --dtype float16 \ --qformat int4_awq \ --calib_size 512 \ --output_dir /models/my-moe-125b-int4这里的--qformat int4_awq表示使用AWQ算法量化权重相比朴素GPTQ对敏感通道的保留更好。校准数据不需要太多512条足够重点是要覆盖任务分布。量化完成后磁盘上会生成一份INT4格式的safetensors大约68GB同时生成一个包含量化参数的json文件。量化完必须验证精度。我会用几道数学题和一个逻辑谜题对原FP16权重和量化后的权重分别跑一遍对比输出分布。实测下来INT4 AWQ量化后模型在某些数学推理任务上精度下降约1-2%但语言流畅度几乎没有感觉差异这在边缘部署中完全可接受。4.3 权重重排与内存驻留TensorRT-LLM在build engine时还有一个权重重排的步骤。所谓重排是根据GPU的矩阵乘法kernel手动将权重重新组织成更适合TensorCore读取的布局这一步属于框架自动完成但需要说明的是重排后会把INT4权重和FP16权重混合存放所以build出来的engine文件比原始模型权重还大这很正常。内存驻留策略也不用过度配置。在Thor的统一内存模型下所有权重只属于同一个物理内存池不需要设置cpu_offload_gb或者gpu_weights_only除非你想限制GPU可访问内存。我的做法是全部驻留在统一内存中让GPU通过NVLink级的高速链路直接访问实测这在Thor上性能远好于手动offload到CPU再拷回GPU的做法。5. 推理引擎构建与部署配置5.1 TensorRT-LLM构建engine的具体命令quantize完成之后下一步就是用TensorRT-LLM构建推理engine。构建过程虽然耗时我的板子上约50分钟但好处是所有优化都在编译期定死运行时的随机性极少。下面是我最终使用的build命令包含了一些关键参数python /opt/TensorRT-LLM/examples/llama/build.py \ --model_type llama \ --model_path /models/my-moe-125b-int4 \ --engine_dir /engines/moe125b_int4 \ --max_batch_size 16 \ --max_seq_len 2048 \ --max_num_tokens 4096 \ --max_beam_width 1 \ --kv_cache_dtype fp16 \ --use_fused_mlp \ --enable_fp8 \ --moe_ExpertScaleNorm 1因为模型MoE结构build脚本里其实会自动检测moe层。参数--max_num_tokens 4096是控制和batch、输入输出长度的乘积上限一般建议比max_batch_size * max_seq_len小一些这样KV cache会被更紧凑地管理。--enable_fp8不是指用FP8存权重而是允许计算过程中使用FP8加速部分层比如RMSNorm和激活实测能带来10%左右的性能提升而且精度几乎无损。--use_fused_mlp会融合MLP层的计算减少kernel启动开销对于MoE这种多个专家并行调度尤为重要。build期间要时刻关注系统温度。Thor的高性能模式下温度上升非常快如果散热不理想编译过程中就会出现CPU降频导致编译时间从50分钟拉长到2小时。我建议把开发套件水平放置下面垫个散热底座并且开着风扇监测工具实时看温度。5.2 KV cache管理与批次调度KV cache是影响生成速度和占用内存的关键。在TensorRT-LLM里KV cache是动态分配的它会固定在显存也就是统一内存中预留一块区域大小由--max_num_tokens和层数共同决定。我的配置下KV cache大概占用6GB左右这已经非常宽松了。MoE模型在推理时的内存占用大头还是权重本身所以KV cache多分配一点对整体影响不大。我建议把--max_num_tokens调高到4096因为在边缘设备上即使batch大小只有8一次并行处理多个推理请求时如果KV cache太小调度器会频繁拒绝请求或执行defragmentation反而影响吞吐量。部署时我还要开启连续性批处理continuous batching特性。TensorRT-LLM默认已经支持动态分批可以为每个新请求在已结束的输出序列腾出空间。运行服务时我设置了--enable_chunked_context这样长上下文输入会被切分成小段处理不会因为单个超长prompt占满KV cache导致后续请求被阻塞。实际测试中这个参数对短query的并发提升非常明显。6. 实测性能数据与调优6.1 吞吐量与延迟实测结果我分别测了batch1、4、8、16四种情况下的第一token延迟和每秒生成token数。模型输入prompt长度为200输出固定生成50个token温度0.8采样方式为top-p 0.95。测试结果如下表Batch Size首Token延迟ms生成吞吐tokens/s单用户平均生成速率tokens/s198028.628.64101274.218.681055118.414.8161120176.311.0单用户batch1时28.6 tokens/s的生成速度对交互式文本生成已经比较够用了。batch16时整体吞吐能达到176tokens/s这说明MoE模型的计算复用能力很强多batch下共享激活专家的重叠度变高GPU利用率被拉满。如果我把max_batch_size继续加大理论上还能更高但延迟会逐步上升而且并发没有超过80的话16已经是一个实用平衡点。首Token延迟在1秒左右不算优秀但考虑到125B模型和边缘设备这个数字可以接受。后续我通过开启--streaming实现了token流式输出用户看到的第一个字出来的时间其实不到200ms体感上几乎像是即时的。6.2 调优技巧电源模式、CPU频率与调度策略除了框架参数我还发现几个容易被忽略的调优点电源模式NVIDIA Jetson的nvpmodel默认都是优化保守必须切到-m 0。如果你只想降低功耗可以用-m 1但性能会下降接近30%不推荐在推理服务上使用。锁CPU频率给ARM核心锁频特别是有多个推理请求并发时。我用cpufreq-set -g performance把所有CPU核心调度器切到performance模式避免DVFS瞬时降频导致线程同步卡顿。设置超线程和核心绑定TensorRT-LLM在构建时能指定--cpu_threads参数控制数据并行和线程池大小。在Thor上我设为8和可用物理核心数匹配同时用taskset把server进程绑定到大核集群避免被调度到小核上。内存锁定mlock因为在统一内存里做推理如果内存被换到swap性能会直降几十倍。建议在启动推理服务前执行ulimit -l unlimited并开启进程的内存锁定参数强制所有分配的内存常驻物理内存。我实测只做了这几项优化就把整体吞吐从默认模式下的76tokens/s提升到了118tokens/sbatch8接近60%的性能翻升效果非常显著。所以如果你遇到Thor性能不如预期先检查是不是电源和频率设置没到位。7. 常见问题与排查实录7.1 加载模型时OOM或直接卡死我有一次在没做量化的情况下直接加载FP16权重引擎构建完成后启动推理服务结果刚加载模型就卡了。查日志看到cudaErrorOutOfMemory虽然256GB内存理论够用但TensorRT-LLM在为KV cache预留分配时检测到预留区域超过可用内存就报错。出现这类问题第一排查项是启动参数里的--max_num_tokens和--max_batch_size是否过大它们直接影响KV cache预留。适当调小这两个值问题立刻解决。第二排查项是是否有其他进程占用了大量统一内存比如你之前跑了Jupyter或者图形桌面都会占用几个GB。在命令行用free -h确认系统可用内存在220GB以上再启动服务。7.2 推理速度极慢只有个位数token/s如果你量化后跑出来只有几个token/s别急着怀疑硬件。先跑一下nvpmodel -q看当前电源模式再查一下有没有降频。最常见的问题是我之前提过的风扇没开Thor核心温度超过85℃后强制降频性能瞬间回到节能模式。用sudo jetson_clocks --fan立刻见效。还有可能就是量化校准集和实际推理数据分布偏离太大激活中存在大量离群值导致kernel频繁切换到高精度分支。解决方法是重新做量化校准加入和你实际业务场景更接近的文本。我用代码评测数据校准后代码生成速度从14tokens/s提升到了30tokens/s提升幅度惊人。7.3 输出乱码或乱答如果量化后模型有明显胡言乱语排除框架bug外首先检查--kv_cache_dtype是否设置为fp16不要把KV cache量化为int8否则会降低输出质量。其次AWQ量化敏感权重时要确保--qformat int4_awq而非--qformat int4后者没有通道级calibration对MoE模型的专家权重伤害较大。最后我建议对MoE的router层保持FP16因为router一个小偏差会导致expert路由错误连锁放大。在TensorRT-LLM里有--moe_router_dtype float16这种类似参数可以单独设置。7.4 常见问题速查表我把这段时间遇到的高频问题整理成表格方便直接对照现象可能原因解决方案启动OOMKV cache预分配过大调小--max_num_tokens和--max_batch_size速度突然变慢CPU/GPU热降频开启风扇并检查电源模式生成乱码量化精度损失保持router层FP16重新校准服务无响应内存swap开启mlock检查内存余量加载时间超长NVMe SSD挂载异常确认NVMe使用PCIe Gen4避免USB转接性能低于官方标称没切换到最高性能模式执行nvpmodel -m 0和jetson_clocks写完这些我还是要提醒一句Jetson AGX Thor这台设备的上限远超很多人想象但它依然是嵌入式硬件不是服务器。你要在显存容量和吞吐率之间做取舍在功耗和延迟之间找平衡。我个人测试下来118B MoE模型在edge上能实时跑起来这件事本身就已经足够令人兴奋了。后续我还会在这个平台上继续测试更大参数规模的MoE和纯FP4精度部署到时候有新发现再来分享。