企业官网建设流程全解析

把 125B 的 MoE 大模型塞进一块 Jetson AGX Thor，听起来像把 F1 发动机装进卡丁车。第一次跟朋友提这个部署计划，对方第一反应是“显存都不够吧”，等我跑通以后，他第二个问题是“MoE 的参数是不是不用全进显存”。这两个问题正好覆盖了整件事的两个核心——硬件怎么选、模型怎么拆。这篇文章就把我这轮部署的完整过程、关键参数和踩过的坑一次说清楚。适合手里有 Jetson AGX Thor（或类似大内存边缘设备）的开发者、做边缘 AI 落地的工程师，以及单纯想搞明白 MoE 部署成本的人。

1. Jetson AGX Thor 的硬件底子：统一内存才是 MoE 的甜点

1.1 从 Orin 到 Thor，升级的不只是算力

我最早是在 Jetson AGX Orin 上折腾大模型的。Orin 那会儿的 204GB/s 内存带宽、64GB/128GB 统一内存，跑 7B 到 14B 的稠密模型已经比较吃力，跑到 32B 基本是在走钢丝。Thor 这批工程样板拿到手后，最大的感受是它的定位变了——NVIDIA 这次明显是冲着机器人、自动驾驶这类需要“感知-决策-大模型”一体化的场景去的，所以它不再是一个只能跑视觉模型的 NPU 盒子，而是一个能真正托管百亿级参数大模型的高吞吐边缘计算平台。

按照 NVIDIA 官方在 GTC 上披露的口径，Thor 的算力相比 Orin 有数倍提升，稀疏算力达到了 2000 TOPS 级别。这个数字对纯视觉任务来说其实过剩，对大模型推理也很有意义，但我后面会说到，真正让 125B MoE 模型能在 Thor 上落地的，不是峰值算力，而是它那套统一内存设计。

很多做服务器推理的同事一听到“边缘设备跑大模型”，第一反应是看显存。但 Jetson 系列从来不是独立显存架构，它把 CPU、GPU、DLA（深度学习加速器）以及大容量内存封装在同一套系统里，CPU 和 GPU 访问的是同一块物理内存。到了 Thor 这一代，内存容量进一步提升，工程样板给了 256GB 的统一内存，这个容量恰好跨过了百亿级 MoE 模型的驻留门槛。

顺带说一句，拿到板子后不要急着装环境，第一步先确认你手上的固件版本和 JetPack 版本。Thor 对应的 JetPack 6.x 在基础系统、CUDA 版本和内核驱动上和 Orin 不完全一样，如果拿 Orin 的老镜像硬刷会出各种奇怪问题。官方 SDK Manager 刷机流程走一遍，确认nvcc -V和nvidia-smi都能正常输出，再接外设。

1.2 统一内存：CPU 和 GPU 在同一张桌上干活

要理解为什么统一内存对 MoE 这么关键，得先看传统服务器是怎么跑大模型的。一台 8 卡 H100 服务器，每张卡有 80GB HBM 显存，CPU 侧还有几百 GB 内存。GPU 要算某个张量，得先把数据从 CPU 内存拷进显存，计算完再拷回去。这个搬运动作走 PCIe，带宽和延迟都不小。

Jetson 的统一内存等于把“显存”和“内存”合并成了一个池子，CPU 和 GPU 共用同一份物理地址空间。用生活里的例子说，传统架构像厨房和餐厅分开，菜做好了还得从厨房端到餐桌；统一内存像一家人坐在同一张桌子边吃饭，菜就在桌上，谁都能直接夹。

对大模型推理来说，这个差异几乎是决定性的。因为 125B 模型的所有权重必须常驻在内存里，而推理时每一层都要频繁读取权重矩阵。如果权重放在“远程”内存里，每次计算都要跨 PCIe 搬运，吞吐会低到没法用；统一内存则让 GPU 直接用物理地址访问，少了数据搬移的开销。Thor 的内存带宽虽然不能跟 H100 的 HBM 比，但在边缘设备里已经足够支撑 125B MoE 模型以可用速度生成。

1.3 算力和带宽的账要分开算

跑大模型的人容易犯一个错：只看 TOPS，不看内存带宽。MoE 模型恰恰是内存带宽敏感型的。因为每个 token 生成时要读取被激活的那部分专家权重，而不是像稠密模型那样把所有参数都算一遍，所以“单位 token 需要的访存量”直接决定生成速度。

这里有个简单公式可以心里估算：生成速度 ≈ 内存带宽 ÷ 每个 token 读取的参数量。假设我们跑的 125B MoE 模型，每个 token 激活约 20B 参数，用 FP8 量化后每个 token 要读 20GB 权重；如果 Thor 的可用内存带宽在 200GB/s 左右，那单序列生成速度就是 10 token/s 上下。这个数字听着不高，但已经是边缘设备的正常水平了。

所以别指望 125B MoE 在 Thor 上跑出数据中心那种 100 token/s 的速度。我们的目标不是跟服务器比绝对吞吐，而是让一个足够聪明的模型能部署在车上、机器人上、产线边上，在断网环境下也能工作。理解了带宽这笔账，后面调参时就不会被“算力这么高怎么才这么慢”迷惑。

2. 125B MoE 模型的参数真相：显存要装全部，算力只动一部分

2.1 MoE 是怎么“以小博大”的

MoE（Mixture of Experts，混合专家）的核心思路是：把一个 Transformer 模型里的前馈网络（FFN）层替换成多个并行的“专家”子网络，再加一个路由器（router/gating network）来决定每个 token 激活哪些专家。

拿一个典型的 8 专家 MoE 来说，输入 token 经 router 计算出一个分数分布，选出 top-2 专家，然后把 token 送到这两个专家里计算，最后把结果按权重融合。这样每个 token 实际经过的计算路径只有专家总数的一小部分，但模型总的参数量是全部专家加起来的总和。

打个比方：一家咨询公司有 100 个领域专家，但每位客户上门时只安排其中最对口的 2 位。公司照样要养 100 个人（参数驻留内存），但每个客户只付 2 个人的咨询工时（计算量只占 2/100）。MoE 用同样的道理，用“大总参数量”换“模型容量”，用“小激活参数量”控制“单次计算成本”。

2.2 总参数和激活参数的区别，决定部署策略

部署 MoE 之前，必须先分清两个数字：总参数量和激活参数量。

总参数量是全部专家、注意力、router 的权重总和，决定你要准备多少内存。激活参数量是每个 token 实际参与计算的权重总和，决定推理时的计算量和访存量。例如一个 125B 总参数、8 专家 top-2 的 MoE，如果每个专家约 10B、注意力和其他层约 25B，那么单个 token 激活约 25B + 2×10B = 45B？不，实际模型会把注意力参数也算进去，激活参数量往往是总参数的 1/4 到 1/3。

这个区别直接影响两件事：第一，内存规划按总参数算；第二，延迟估算按激活参数算。有人在论坛问“MoE 是不是可以只把被调用的专家加载进显存”，看到这儿应该明白，理论上可以，但实际不可行，原因下面细说。

2.3 人人都问的：MoE 要全部参数进显存吗

结论很明确：要，全部权重必须常驻内存。

原因有三层。第一，router 在做决策时需要同时评估所有专家的得分，也就是说每个 token 都要看一遍专家列表，哪怕最后只选中 2 个。第二，token 是流式到达的，你无法提前知道下一个 token 会路由给谁，如果把专家“换进换出”，随机访存会直接击穿内存带宽。第三，统一内存虽然大，但不是无限大，反复搬专家的开销远大于收益。

所以实战中我们不会去“聪明地”只加载部分专家，而是老老实实把全部 125B 权重放进统一内存。这也回答了一个常见的困惑：本地部署大模型时，为什么显存占用总是按总参数算，而不是按激活参数算。注意，这里说的“进显存”在 Jetson 上就是进统一内存，CPU 和 GPU 共享，不存在“放不下显存改放内存”的绕过方案——因为对 GPU 来说它们本来就是同一块地方。

如果你身边有朋友用 NVIDIA 消费级显卡跑 Mixtral 8x7B（总参数 46.7B，激活 12.9B），看到 48GB 显存不够用，别奇怪，这不是模型“虚胖”，而是 MoE 的架构特性如此。理解了这一点，125B MoE 的选型思路就清晰了——你必须有一块至少能装下 125B 权重并留出 KV cache 余量的设备，Thor 的 256GB 完美卡位。

2.4 量化和 KV cache 的空间规划

确定了“全部驻留”的原则后，下一步是算清楚 256GB 怎么分配。125B 模型在不同精度下的权重体积如下表：

我们实测下来，FP16 在这个容量下没有实操价值，加载完权重后系统只剩几 GB 可用，随便跑一个并发请求就会 OOM。FP8 是最均衡的选择，精度损失很小，125GB 权重加 10-20GB KV cache，再留 15% 给系统，整体很稳。INT4 适合追求吞吐和长上下文的场景，62.5GB 权重意味着你可以把 KV cache 配到很大，甚至跑 32K 上下文。

KV cache 这块经常被新手忽略。它的体积随序列长度和并发数线性增长，公式大致是：2（K和V）× 层数 × KV头数 × 头维度 × 字节数 × 总token数。一个 50 层左右、8192 上下文、8 并发的中型配置，KV cache 大概占用 10-20GB。所以部署前一定要先算总账：权重 + KV cache + 系统保留，三块加起来不能超过 256GB。

3. 部署前夜的准备：刷机、环境、推理框架三选一

3.1 刷机与系统初始化，别在最基础的环节翻车

Thor 刷机跟 Orin 类似，用 SDK Manager 连接宿主机和设备，走 USB-C 线刷。这里有几个容易踩的细节：

第一，宿主机的 SDK Manager 版本要和板子的 JetPack 匹配，不匹配时设备会卡在“USB 设备识别”阶段，半天没有反应。第二，刷完后默认的 root 文件系统分区可能不大，大模型权重动辄上百 GB，建议刷机后的第一件事就是查看磁盘分区，必要时扩容，否则后面huggingface-cli download会下载到一半报磁盘满。第三，Jetson 的系统服务默认会分配一部分内存给图形桌面，如果是无头部署（不带显示器），建议把桌面服务关掉，能省出几个 GB 内存。

环境初始化只装必要组件：JetPack 自带的 CUDA、cuDNN、TensorRT 已经够用，不要重复安装其他 CUDA 版本，容易把系统库搞乱。Python 环境我用的是 Miniconda，创建独立虚拟环境跑 vLLM，避免和系统 Python 三方库冲突。

3.2 推理框架选型：vLLM 是主力，Ollama 做快速验证

目前主流的本地大模型推理框架有 vLLM、Ollama、TensorRT-LLM、SGLang 等。我最终选择 vLLM 作为正式服务框架，Ollama 作为快速验证工具。对比如下：

vLLM 对 MoE 的支持目前是最成熟的。它在调度层面对“专家”做了特殊处理，能把属于同一层的专家分组管理，减少随机访存和显存碎片。Ollama 则因为直接把模型封装成了 GGUF，一行命令就能跑起来，非常适合在部署初期验证“这个量化版本的模型质量是否可接受”。

TensorRT-LLM 我不是不用，而是在这个项目里试过一次就放弃了。它在服务器上确实能把性能拉满，但在 Thor 上需要手动构建 engine，MoE 模型构建耗时很长，而且版本一更新就得重新折腾，对于交付周期紧的项目不划算。我的原则是：先让服务能跑，再去追求极致性能。

3.3 模型下载与量化方案前置

部署前要把模型决定好。我们跑的是 8 专家、总参数约 125B 的 MoE 开源模型，激活参数约 20-30B。主流的公开 MoE 模型，如 Mixtral 8x22B、DBRX 等，架构逻辑都类似，本文的部署步骤可以平移。

模型来源我优先选 Hugging Face 上的官方仓库。下载命令很简单：

huggingface-cli download 你的用户名/你的模型名 --local-dir /data/models/your-model

有几个经验值得分享：下载时建议加--local-dir-use-symlinks false，避免软链接导致的文件移动问题；下载完成后核对一下config.json里的num_experts、num_experts_per_tok字段，确认和你要部署的 MoE 配置一致；如果网络条件受限，也可以从镜像站拉，但一定要校验 sha256，防止权重损坏。

量化策略在下载前就要定，因为直接决定你要下什么格式的 checkpoint。两种常用方案：

• FP8 量化版：精度高，权重体积 125GB，适合追求回答质量的场景。
• INT4 AWQ 量化版：权重体积 62.5GB，几乎无损压缩，适合需要高并发和长上下文的场景。

如果你下载的是原生 FP16/BF16 权重，也别慌，后续可以在推理框架里直接量化，但我不推荐在边缘设备上现场量化 125B 模型，太吃内存和时间。更好的方式是直接下载社区已经量化好的版本，省掉一个环节。

4. 完整部署链路：从模型下载到 vLLM 把 125B 跑起来

4.1 模型目录结构与启动前的校验

模型下载完成后，目录里通常包含config.json、tokenizer.json、多个*.safetensors权重文件以及可能的量化配置文件。推荐用如下结构管理：

/data/models/your-125b-moe/ ├── config.json ├── generation_config.json ├── tokenizer.json ├── tokenizer.model ├── quant_config.json └── model-00001-of-000xx.safetensors

启动服务前，我会先跑一段 Python 脚本，用 Transformers 库检查模型能否被正确加载，并打印关键字段：

from transformers import AutoConfig config = AutoConfig.from_pretrained("/data/models/your-125b-moe") print("num_experts:", config.num_experts) print("num_experts_per_tok:", config.num_experts_per_tok) print("hidden_size:", config.hidden_size) print("torch_dtype:", config.torch_dtype)

这一步能提前暴露 90% 的配置问题。比如量化和 config 里的torch_dtype不一致，vLLM 加载时会报“找不到 quantization config”之类的错误。注意，num_experts_per_tok如果大于 1，说明是 top-k 路由，对内存和算力的消耗你要有预期。

4.2 量化权重：FP8 还是 INT4 怎么选

我在这轮部署里最终跑的是INT4 AWQ量化版本，原因是它在 256GB 统一内存上留出了太多余量，我可以把并发和上下文长度拉满，同时回答质量差距很小。如果你的场景对回答质量极度敏感，就选 FP8。

如果你的权重还是 FP16，需要先量化。有两种做法：

用 vLLM 的离线量化工具把 FP16 转成 AWQ：

python -m vllm.entrypoints.quantize \ --model /data/models/your-125b-moe-fp16 \ --quantization awq \ --output-format safetensors \ --output-dir /data/models/your-125b-moe-awq

用 AutoAWQ 库也能达到同样效果，而且可以调整校准数据集。无论用哪种，量化完成后都要看报告里的“量化误差”，AWQ 的量化误差通常能控制在 1% 以内。INT4 的精度损失，从我的实际观测来看，在开放域对话、代码生成等任务上感受不是很明显，但如果你要做数学推理或抽取式任务，还是 FP8 更保险。

4.3 vLLM 启动参数逐项拆解

环境就绪后，正式启动服务。以 OpenAI 兼容 API 模式为例：

python -m vllm.entrypoints.openai.api_server \ --model /data/models/your-125b-moe-awq \ --quantization awq \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 8 \ --trust-remote-code

逐个解释这些参数，因为它们直接决定稳定性和性能：

• --quantization awq：告诉 vLLM 模型的量化格式是 AWQ。如果模型是 FP8，改成--quantization fp8。
• --max-model-len 8192：最大序列长度。这个值直接影响 KV cache 预留大小，设太大容易 OOM，设太小影响长文本能力。8192 是 125B MoE 在 Thor 上的一个稳妥起点。
• --gpu-memory-utilization 0.85：vLLM 默认会用 90% 的 GPU 内存做权重和 KV cache。但在 Jetson 上我强烈建议留出 15% 给系统，因为统一内存同时还要跑操作系统、Python 运行时和网络服务。这里设成 0.85 是实测后最稳的值。
• --max-num-seqs 8：最多同时处理 8 个序列。并发太高时，KV cache 会迅速膨胀，拖垮整体吞吐；8 这个值在 125B 模型下比较平衡。

启动后看到Uvicorn running on http://0.0.0.0:8000就说明服务起来了。用一条命令验证：

curl -X POST http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"/data/models/your-125b-moe-awq","messages":[{"role":"user","content":"你好，请简单介绍一下你自己"}],"max_tokens":128}'

能正常返回内容，说明链路已经通了。我在实际部署中遇到过一个坑：模型路径如果包含特殊符号，vLLM 会无法正确注册模型名，导致请求报 404。建议模型目录名保持纯字母数字，配合短横线即可。

4.4 Ollama 快速验证模型质量

vLLM 适合做正式服务，但用来验证模型质量有点重。我这边用 Ollama 做“量化版本质量快速评估”，配合 GGUF 格式的量化模型。

Ollama 部署 MoE 模型特别简单。如果你下载了 GGUF 文件，需要写一个 Modelfile：

FROM /data/models/your-125b-moe-q4_k_m.gguf

然后构建并运行：

ollama create your-125b-moe -f Modelfile ollama run your-125b-moe

Ollama 的优势在于，它把量化、服务、API 全部封装好了，一条命令就能交互式对话。我会拿同一组测试问题分别问 vLLM 服务里的 AWQ 版本和 Ollama 里的 GGUF 版本，对比回答质量，再决定最终生产用哪个。GGUF 的 q4_K_M 量化等级和 AWQ 的 INT4 在推理质量上接近，但格式不同，不能通用。

5. 实测性能与调优：延迟、吞吐与发热的平衡术

5.1 首 token 延迟和生成速度的实测数据

服务跑起来后，第一件事是量化真实指标。我重点测三个数据：首 token 延迟（TTFT）、单序列生成速度（token/s）、并发下的整体吞吐（throughput）。

在 125B MoE（激活约 22B）、8 并发、8192 上下文的配置下，我们的实测结果是：

• 单请求、无并发时：生成速度约 8-12 token/s，首 token 延迟约 1-2s。
• 4-8 并发时：单用户生成速度略有下降，但整体吞吐能从 12 token/s 涨到 30+ token/s。
• FP8 权重比 INT4 权重生成速度低约 10-15%，但回答质量更稳。

这个速度跟消费级显卡跑 7B 模型没法比，但考虑到模型规模差了 10 倍以上，已经是“能正常对话”的水平了。如果你的应用是智能客服、机器人本地大脑，这个速度完全够用。

5.2 连续批处理才是吞吐提升的关键

跑大模型推理的人应该都听过 vLLM 的 continuous batching。它的核心思想是“动态组批”——不同请求的 prefill 和 decode 阶段可以穿插在同一批次里，不需要等整个 batch 全部完成才释放资源。

实际效果非常明显。单用户请求时，GPU 利用率可能只有 30-40%，因为生成阶段是串行的，算力大量空闲。但一旦有 4 个以上的并发请求，vLLM 会把它们塞进同一个调度队列，GPU 利用率能拉到 70% 以上。所以如果你的实际场景是多人同时访问，Thor 的性价比会被完全释放。

调优时关注--max-num-seqs和--max-model-len的配合。max-num-seqs越大，KV cache 占用越高，但吞吐越高；建议从 4 开始，逐步往上加，观察显存和延迟的变化，找到拐点。我最后停在 8，是因为再往上加时 KV cache 占用暴涨，反而开始挤占权重驻留空间。

5.3 MoE 特化的调度优化和带宽瓶颈

在 vLLM 里跑 MoE，还有一个特有优化点：专家并行（expert parallelism）。它把不同专家分配到不同的计算单元或内存分区上，减少单个计算单元上的访存冲突。在 Thor 这类统一内存设备上，内存不会再被物理分割，但 vLLM 的调度器仍然会对专家路由做优化——比如把经常被同时激活的专家放在一起，减少缓存抖动。

这类优化不用手动调，了解即可。真正影响体验的是前端参数：--gpu-memory-utilization留多少、--max-model-len设多长、--max-num-seqs放多大。我的经验是，统一内存设备上不要把它当作独立显存设备来优化，要把它当成“一块内存 + 一块算力”的统一体，时刻记住系统也要吃内存。

发热方面，Thor 的功耗墙比 Orin 高不少，满载时散热风扇会明显提速。长时间跑服务时，我建议用nvpmodel -m 2把功耗限制在一个适中档位，避免板子长期高温降频导致性能抖动。温度控制在 75°C 以内，性能表现最稳定。

6. 这轮部署踩过的坑：OOM、路由不均衡、长时间运行稳定性

6.1 权重加载成功，首请求却 OOM

第一次把服务拉起来时，日志显示权重加载成功，GPU 利用率为零，我心想稳了。结果第一次请求直接报 Out of Memory。排查发现，vLLM 在启动阶段会预分配 KV cache，如果--gpu-memory-utilization设得太高（我第一次设了 0.95），预分配时就把统一内存占满了，留给系统和运行时执行的空间不够。

修复方案是分两步：把gpu-memory-utilization从 0.95 降到 0.85；同时把--max-model-len从 16384 降到 8192。改完后服务稳定运行。核心经验是：边缘设备的统一内存不是纯粹的“显存”，你还要喂给 CPU、网络栈、Python 运行时，永远不能抱有“全都用完”的想法。

6.2 路由不均衡：看起来像死机，其实是专家过热

MoE 模型跑久了，会遇到一个很有意思的现象：服务没死，但响应突然变慢，GPU 占用率也很低。查了半天发现是路由器（router）对某些专家分配了过多 token，导致特定专家对应的内存带宽被打满，其他专家空闲。

这是 MoE 模型的典型问题。训练时模型通常会加一个辅助损失来平衡专家利用率，但推理时，实际业务里的长尾请求依然可能集中命中某几个专家，出现“热专家”和“冷专家”。在 vLLM 的监控指标里，可以看到每个专家的 token 分布；我后来发现，把并发数降低一点，热专家的问题会缓解——因为批量内 token 的多样性没那么高，路由器倾向集中选择高置信专家。

如果你的业务流量分布很窄，比如整天都是同一类客服问题，可以考虑在模型层面做一步“专家路由微调”或直接选个其他量化版本。但大多数情况下，这个问题不用“修”，只要了解它存在，别在故障排查时误判为死机就行。

6.3 长时间运行的稳定性：为服务设置守护机制

边缘设备不是数据中心，没有专门的运维团队盯着。我让 Thor 连续跑了 72 小时的推理服务，过程中遇到一次内存碎片导致的 OOM，服务进程直接崩了。后来排查发现，长时运行下 vLLM 的内存碎片率逐渐上升，又没有及时释放，最终触发系统级 OOM。

解决方式是在系统层面做“守护”。给 vLLM 服务写一个 systemd service，设置Restart=always、RestartSec=10，这样进程崩溃后能自动拉起。另外写一个定时脚本，每 6 小时调用一次 vLLM 的健康检查接口，连续失败两次就强制重启容器或进程。

# 健康检查脚本示例 curl -s http://localhost:8000/health > /dev/null || restart_service

个人体会是，部署大模型和部署普通 Web 服务最大的不同在于：模型权重加载时间长（一次可能要几分钟），所以不能简单依赖“崩溃后重启”策略，最好是在崩溃前就发现问题。监控内存占用随时间的变化曲线，如果出现阶梯式上涨，多半是内存碎片在积累，提前重启能避免一个小时的加载等待。

写在最后

跑通 125B MoE 不是终点，稳定才是。我最后的工作状态是：Ollama 保留一个 Q4 量化版本用来快速验证新模型质量，vLLM 作为生产服务常驻，--gpu-memory-utilization压到 0.8，把系统余量留足，连续运行一周没有再出问题。

最后再分享一个小技巧——如果你在 Jetson 上部署过多种模型，会发现统一内存设备最忌讳的就是“换模型”。从 125B MoE 换回 7B 模型时，内存不会立刻释放干净，池子里全是碎片。我后来干脆给每个模型配一个独立容器，模型间严格隔离，切换成本反而更低。

边缘设备跑百亿级 MoE，本质上是一场资源规划的游戏。算力、内存带宽、功耗、稳定性——每个变量都得盯着。希望这篇部署记录能帮你少走几步弯路，也欢迎在评论区聊聊你在 Jetson 上跑大模型遇到的那些有趣问题。