Model-Optimizer：大模型推理效能工程方法论

1. 项目概述：Model-Optimizer不是工具，而是一套可落地的模型推理效能工程方法论

“Model-Optimizer”这个名称听起来像某个开源工具或GUI软件，但实际在工业级AI部署现场，它根本不是一个现成的下载包，而是一整套贯穿模型选型、格式转换、硬件适配、调度调优到服务封装的闭环工程实践。我过去三年带团队落地过27个大模型推理项目，从Qwen系列、DeepSeek-MoE到GLM-5、Qwen3-Embedding，所有上线服务背后都跑着同一套Model-Optimizer流程——它不依赖某一家厂商的黑盒方案，而是把TensorRT、vLLM、CUDA、Docker这些技术模块像乐高一样拧在一起，让模型真正“跑得动、跑得稳、跑得省”。核心关键词Model-Optimizer、TensorRT、vLLM、NVIDIA，在真实产线里从来不是孤立存在的：比如你用vLLM部署Qwen3-Embedding-0.6B，如果跳过TensorRT加速层，GPU显存占用会飙升42%，吞吐直接掉一半；而如果你在Rocky Linux 10上装NVIDIA驱动时没屏蔽ECC报错，后续TensorRT编译会卡在PTX生成阶段，连engine文件都出不来。这不是理论推演，是我上周刚帮客户踩过的坑——他们用docker vllm/vllm-openai:v0.27.1镜像加载Qwen3-Embedding，结果发现镜像里压根没预置模型权重，还得自己挂载volume，而挂载路径权限一设错，vLLM scheduler直接拒绝启动。所谓Model-Optimizer，本质就是把这类“看似能跑、实则崩在细节”的陷阱，提前拆解成可检查、可验证、可回滚的操作项。它适合三类人：正在用vLLM部署大模型却卡在吞吐瓶颈的后端工程师；需要把PyTorch .pt文件转成TensorRT engine做边缘部署的算法同学；还有在Ubuntu/Win10/Rocky多系统混搭环境下反复折腾NVIDIA驱动和CUDA版本的运维同事。你不需要记住所有命令，但必须理解每个环节的“为什么必须这么做”——比如为什么vLLM Docker镜像中不带模型？因为模型权重动辄几GB，镜像体积爆炸会导致CI/CD流水线超时，且不同客户要的模型版本、量化精度完全不同，硬编码进镜像等于自废扩展性。

2. Model-Optimizer整体设计思路：拒绝“一键式幻觉”，构建四层可验证流水线

2.1 为什么不能只用vLLM或只用TensorRT？——硬件抽象层与计算图优化层的天然割裂

很多团队一上来就冲着vLLM去，觉得它开箱即用、API兼容OpenAI，部署快。但实测下来，vLLM在A100/H100千卡集群上确实香，可一旦落到RTX 4060 Laptop GPU这种消费级卡上，问题就来了：显存只有8GB，而Qwen3-Embedding-0.6B的FP16权重+KV Cache就占5.2GB，剩下不到3GB要塞下vLLM的PagedAttention管理结构、CUDA stream调度器、以及用户请求队列——内存碎片化直接导致OOM。这时候单纯调vLLM的--max-num-seqs参数没用，因为底层计算图没变，显存峰值还是那个峰值。反过来，有人迷信TensorRT，把.pt文件转成.engine后推理速度翻倍，但TensorRT是静态图引擎，不支持vLLM那种动态批处理（dynamic batching）和连续提示（continuous prompting），遇到ChatBox这类交互式场景，每次新token生成都要重新走一遍CUDA kernel launch流程，延迟飙到800ms以上。Model-Optimizer的底层逻辑，就是把这两层强行“焊接”起来：用TensorRT做模型主体推理（Kernel级优化），用vLLM做请求调度与内存管理（Runtime级优化）。具体怎么焊？不是简单拼接，而是分四层构建：

• 第一层：硬件感知层——自动识别GPU型号、显存容量、CUDA Compute Capability（比如RTX 4060 Laptop GPU是SM_86，H100是SM_90），决定是否启用FP8量化、是否开启TensorRT的BuilderConfig中的fasterTransformer插件；
• 第二层：模型切片层——对Qwen3-Embedding这类小模型，直接TensorRT全图优化；对DeepSeek-MoE这种稀疏模型，则用vLLM的MoE专家路由+TensorRT的专家子图分别编译，再通过CUDA Graph串联；
• 第三层：服务封装层——用FastAPI暴露HTTP接口，但关键是在vLLM backend里注入TensorRT engine句柄，让generate()调用最终落到TRT引擎而非PyTorch eager mode；
• 第四层：可观测层——不只是nvidia-smi看GPU利用率，而是用NVIDIA Nsight Systems抓取每个kernel的latency、memory bandwidth占用，用vLLM自带的metrics exporter输出scheduler queue time、prefill time、decode time三段耗时。

这套设计拒绝“一键式幻觉”，因为每个层都有明确的输入输出契约。比如硬件感知层输出必须包含sm_version、total_memory_mb、ecc_enabled三个字段，否则下游切片层直接abort。这比网上那些“三行命令部署vLLM”的教程靠谱得多——那些教程在RTX 4060 Laptop GPU上跑Qwen3-Embedding，十次有八次在warmup阶段就OOM，因为没做显存预留计算。

2.2 为什么选择TensorRT-LLM而非原生TensorRT？——LLM专用算子库解决长上下文瓶颈

TensorRT本身是通用推理引擎，但处理LLM时有个致命短板：原生TensorRT对RoPE旋转位置编码、ALiBi偏置、FlashAttention等LLM专属算子支持弱。比如Qwen3-Embedding用的是Qwen2的RoPE实现，其theta基底是10000，而TensorRT 10.2默认只认100000，不改源码直接编译会报“invalid rotary base”错误。TensorRT-LLM就是为填这个坑生的——它把LLM常用算子全部重写为CUDA kernel，并做了深度融合。实测对比：同样编译Qwen3-Embedding-0.6B的FP16 engine，用原生TensorRT耗时23分钟，生成engine大小1.8GB；用TensorRT-LLM耗时8分钟，engine仅1.1GB，且支持context length从2048扩展到8192而不崩溃。关键差异在BuilderConfig配置：

# TensorRT-LLM特有配置项（原生TensorRT没有） builder_config = BuilderConfig( name="qwen3_embedding", precision="fp16", # 或"bf16"、"int8" quantization=QuantizationConfig( # 支持AWQ/GPTQ/FP8 quant_algo=QuantAlgo.W8A16, # 权重8bit，激活16bit kv_cache_quant_algo=QuantAlgo.INT8_KV_CACHE # KV Cache单独量化 ), max_batch_size=128, max_input_len=8192, # 原生TensorRT这里只能设2048 max_output_len=1024, plugin_config=PluginConfig( # LLM专用插件开关 use_gpt_attention_plugin=True, # 启用自研FlashAttention use_rope_plugin=True, # RoPE算子硬件加速 use_context_fmha=True # Context FMHA优化 ) )

这个配置里，use_rope_plugin=True直接决定了能否正确处理Qwen3的theta=10000设定；use_context_fmha=True则让长文本prefill阶段的显存占用降低37%。而原生TensorRT用户得自己手写RoPE CUDA kernel，还要跟PyTorch的rope_emb函数对齐——这已经超出普通工程师能力范围。所以Model-Optimizer流程里，TensorRT-LLM不是可选项，是必选项。至于网上搜到的“pt文件转换tensorrt”教程，90%用的还是老版TensorRT，根本跑不通Qwen3系列，纯属误导。

2.3 为什么vLLM必须配合Docker？——环境隔离是避免“在我机器上能跑”陷阱的唯一解

vLLM官方文档说“pip install vllm”就能跑，但现实是：你在Ubuntu 22.04上装vLLM 0.27.1，依赖的CUDA Toolkit是12.1，而客户生产环境用的是Rocky Linux 10 + CUDA 12.4，直接pip install会因cudnn版本不匹配core dump；更糟的是，Win10用户装NVIDIA驱动后常发现“nvidia控制面板找不到了”，其实是Windows Update自动覆盖了驱动，导致vLLM找不到GPU。Model-Optimizer强制要求Docker，不是为了时髦，而是解决三个刚性问题：

1. CUDA版本锁死：Docker镜像里固化CUDA Runtime（如nvidia/cuda:12.4.0-devel-ubuntu22.04），vLLM编译时链接的cudnn.so版本完全可控，避免运行时符号解析失败；
2. 驱动兼容兜底：NVIDIA Container Toolkit让容器内看到的nvidia-smi输出与宿主机一致，即使宿主机驱动是535.104.02（常见于RTX 4060 Laptop GPU），容器内也能正确调用GPU，不用管Win10里“nvidia profile inspector”显示的奇怪状态；
3. 模型热加载安全：vLLM docker镜像中不带模型（这是正确设计！），而是通过-v /path/to/models:/models挂载。这样客户换模型只需改挂载路径，不用重建镜像——而重建镜像时若用错base image（比如该用nvidia/cuda:12.4.0-devel-ubuntu22.04却用了12.1），整个CI流水线就废了。

我们线上用的镜像标签是vllm/vllm-openai:v0.27.1，但它只是runtime环境，真正的模型加载逻辑写在entrypoint.sh里：

#!/bin/bash # entrypoint.sh if [ ! -f "/models/qwen3-embedding-0.6b/model.safetensors" ]; then echo "ERROR: Model not found at /models/qwen3-embedding-0.6b" exit 1 fi # 关键：指定tensorrt_llm_engine_dir，让vLLM优先加载TRT engine vllm serve \ --model /models/qwen3-embedding-0.6b \ --tensorrt-llm-engine-dir /models/qwen3-embedding-0.6b/trt_engine \ --dtype half \ --gpu-memory-utilization 0.85 \ --max-model-len 8192

这个脚本里--tensorrt-llm-engine-dir参数，就是Model-Optimizer把TensorRT-LLM和vLLM焊死的关键接口。没有它，vLLM永远只会走PyTorch路径。

3. 核心细节解析：从NVIDIA驱动安装到TRT engine生成的12个生死关卡

3.1 NVIDIA驱动安装：Rocky Linux 10与Ubuntu的差异化处理

Rocky Linux 10和Ubuntu 22.04虽然都是Linux，但驱动安装策略天差地别。Ubuntu用apt-get装驱动最省事，但Rocky Linux 10必须用RPM Fusion仓库，否则kernel module签名验证过不去。实操步骤：

Rocky Linux 10（重点防ECC报错）：

# 1. 启用RPM Fusion sudo dnf install epel-release -y sudo dnf config-manager --set-enabled powertools sudo dnf install https://mirrors.rpmfusion.org/free/el/rpmfusion-free-release-$(rpm -E %rhel).noarch.rpm -y sudo dnf install https://mirrors.rpmfusion.org/nonfree/el/rpmfusion-nonfree-release-$(rpm -E %rhel).noarch.rpm -y # 2. 安装驱动（必须指定--no-opengl-files，否则ECC报错） sudo dnf install akmod-nvidia xorg-x11-drv-nvidia-cuda -y sudo akmods --force sudo dracut --force # 3. 屏蔽ECC报错（关键！否则TensorRT编译失败） echo 'options nvidia NVreg_EnableGpuFirmware=0' | sudo tee /etc/modprobe.d/nvidia.conf sudo update-initramfs -u # Ubuntu用此命令，Rocky用dracut --force sudo reboot

提示：NVreg_EnableGpuFirmware=0这行配置是绕过NVIDIA固件ECC校验的唯一合法方式。网上流传的“修改bios关闭ECC”在笔记本GPU上根本不可行，RTX 4060 Laptop GPU的ECC是硬件强制开启的。

Ubuntu 22.04（重点防nvidia-smi通信失败）：

# 1. 卸载所有残留驱动 sudo apt-get purge *nvidia* -y sudo apt-get autoremove -y sudo reboot # 2. 安装官方驱动（不用ubuntu-drivers autoinstall，太傻） wget https://us.download.nvidia.com/tesla/535.104.02/NVIDIA-Linux-x86_64-535.104.02.run chmod +x NVIDIA-Linux-x86_64-535.104.02.run sudo ./NVIDIA-Linux-x86_64-535.104.02.run --no-opengl-files --no-x-check --no-nouveau-check # 3. 验证（必须看到compute capability） nvidia-smi -q | grep "Product Name\|CUDA Version\|ECC Enabled" # 输出应含：Product Name : NVIDIA RTX 4060 Laptop GPU, CUDA Version : 12.2, ECC Enabled : Enabled

注意：--no-x-check防止X server冲突，--no-nouveau-check禁用nouveau驱动抢占GPU。如果漏掉这两项，nvidia-smi会报“Failed to initialize NVML: Driver/library version mismatch”。

3.2 TensorRT安装：避开/usr/lib/x86_64-linux-gnu/libnvrtc.so.12.2陷阱

TensorRT 10.2.0.6要求CUDA 12.2，但Ubuntu 22.04默认CUDA是12.4，直接装会因libnvrtc.so版本不匹配崩溃。正确做法是降级CUDA toolkit：

# 1. 卸载现有CUDA sudo apt-get purge cuda-* -y sudo apt-get autoremove -y # 2. 安装CUDA 12.2（TensorRT 10.2唯一兼容版本） wget https://developer.download.nvidia.com/compute/cuda/12.2.2/local_installers/cuda_12.2.2_535.104.05_linux.run sudo sh cuda_12.2.2_535.104.05_linux.run --silent --override --no-opengl-libs # 3. 安装TensorRT（必须用tar包，deb包会污染系统库） wget https://developer.download.nvidia.com/compute/machine-learning/tensorrt/10.2.0/local_repos/nv-tensorrt-local-repo-ubuntu2204-10.2.0.6_1.0-1_amd64.deb sudo dpkg -i nv-tensorrt-local-repo-ubuntu2204-10.2.0.6_1.0-1_amd64.deb sudo apt-get update sudo apt-get install tensorrt -y # 4. 验证（关键看libnvrtc.so.12.2是否存在） ls -la /usr/lib/x86_64-linux-gnu/libnvrtc.so* # 必须有 libnvrtc.so.12.2 -> libnvrtc.so.12.2.122

警告：如果看到libnvrtc.so.12.4，说明CUDA没降级成功，TensorRT编译时会报“nvrtc: error: failed to open libnvrtc.so.12.2”。这个错误在网上搜不到解决方案，因为大家默认CUDA版本越高越好，但TensorRT偏偏反着来。

3.3 PT文件转TensorRT engine：Qwen3-Embedding的6个定制化参数

Qwen3-Embedding-0.6B的.pt文件不能直接喂给trtexec，必须先用TensorRT-LLM的convert.py转成中间格式，再用build.py生成engine。核心参数如下：

完整转换命令：

# 1. 转ONNX（TensorRT-LLM内部步骤，不用手动） python3 /opt/tensorrt_llm/examples/qwen/convert_checkpoint.py \ --model_dir /models/qwen3-embedding-0.6b \ --dtype float16 \ --output_dir /models/qwen3-embedding-0.6b/tllm_engine # 2. 构建engine（这才是关键） trtllm-build \ --checkpoint_dir /models/qwen3-embedding-0.6b/tllm_engine \ --output_dir /models/qwen3-embedding-0.6b/trt_engine \ --gpt_attention_plugin float16 \ --gemm_plugin float16 \ --max_input_len 8192 \ --max_output_len 1 \ --logits_dtype float32 \ --use_custom_all_reduce disable \ --world_size 1

实操心得：--world_size 1必须显式指定，否则TensorRT-LLM默认按多卡构建，生成的engine在单卡上load会报“rank mismatch”。这个坑我在三个客户现场都遇到过，没人文档里提。

3.4 vLLM部署Qwen3-Embedding：绕过scheduler逻辑的3个隐藏开关

vLLM的scheduler默认为文本生成设计，但Qwen3-Embedding是无状态批量计算，必须关掉prefill/decode分离逻辑。关键配置：

vllm serve \ --model /models/qwen3-embedding-0.6b \ --tensorrt-llm-engine-dir /models/qwen3-embedding-0.6b/trt_engine \ --dtype half \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --enforce-eager \ # 关键！禁用CUDA Graph，否则TRT engine无法接入 --disable-log-stats \ # Embedding无需统计token生成率 --max-num-batched-tokens 4096 # 批处理大小，根据显存动态调

注意：--enforce-eager是生死开关。vLLM默认启用CUDA Graph优化，但TensorRT-LLM engine不兼容Graph capture，不加此参数会报“TRT engine execution failed: invalid argument”。网上所有“vllm部署大模型”教程都漏了这点，导致TRT加速失效。

4. 实操全流程：从零开始部署Qwen3-Embedding-0.6B的完整记录

4.1 环境准备：Rocky Linux 10 + NVIDIA驱动 + Docker Toolkit

客户环境是Rocky Linux 10，GPU为RTX 4060 Laptop GPU（Compute Capability SM_86），要求支持8192上下文。第一步不是装vLLM，而是确保硬件层可信：

# 1. 检查GPU识别 lspci | grep -i nvidia # 输出应含：01:00.0 VGA compatible controller: NVIDIA Corporation GA107M [GeForce RTX 4060 Laptop GPU] (rev a1) # 2. 验证驱动安装（重点看ECC状态） nvidia-smi -q | grep -A 5 "ECC" # 正确输出：ECC Enabled : Enabled （不是Disabled！） # 3. 安装NVIDIA Container Toolkit（Rocky专用） distribution=$(. /etc/os-release;echo $ID$VERSION_ID) \ && curl -fsSL https://nvidia.github.io/libnvidia-container/$distribution/nvidia-container-toolkit.repo | sudo tee /etc/yum.repos.d/nvidia-container-toolkit.repo sudo yum install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker # 4. 验证容器GPU访问 docker run --rm --gpus all nvidia/cuda:12.2.2-devel-ubuntu22.04 nvidia-smi # 必须输出与宿主机一致的nvidia-smi结果

实测记录：客户第一次执行nvidia-ctk runtime configure时报错“failed to connect to containerd”，原因是Rocky 10默认用podman而非docker。解决方案是sudo yum install docker-ce并禁用podman：sudo systemctl disable podman.socket。这个细节官网文档没写，但Rocky 10用户必踩。

4.2 模型准备：Qwen3-Embedding-0.6B的目录结构与权限修复

Qwen3-Embedding-0.6B从HuggingFace下载后，目录结构必须严格符合TensorRT-LLM要求：

/models/qwen3-embedding-0.6b/ ├── config.json ├── model.safetensors ├── tokenizer.json ├── tokenizer_config.json └── trt_engine/ # 编译后存放engine的目录

但客户给的模型包里tokenizer.json权限是600（只读），导致vLLM启动时报“Permission denied: tokenizer.json”。修复命令：

chmod 644 /models/qwen3-embedding-0.6b/tokenizer.json chmod 644 /models/qwen3-embedding-0.6b/config.json # 关键：trt_engine目录必须存在且可写 mkdir -p /models/qwen3-embedding-0.6b/trt_engine chmod 755 /models/qwen3-embedding-0.6b/trt_engine

注意：chmod 755不是777！TensorRT-LLM build过程会生成大量临时文件，777权限在企业环境被安全策略拦截。755足够，且符合SOC2审计要求。

4.3 TensorRT-LLM编译：在Docker中完成engine生成

不用在宿主机装TensorRT-LLM，直接用官方镜像编译：

# 启动编译容器（挂载模型目录） docker run -it --gpus all \ -v /models:/models \ -w /workspace \ --rm \ tensorrtllm/tensorrtllm:main \ bash -c " cd /workspace/examples/qwen && python convert_checkpoint.py \ --model_dir /models/qwen3-embedding-0.6b \ --dtype float16 \ --output_dir /models/qwen3-embedding-0.6b/tllm_engine && trtllm-build \ --checkpoint_dir /models/qwen3-embedding-0.6b/tllm_engine \ --output_dir /models/qwen3-embedding-0.6b/trt_engine \ --gpt_attention_plugin float16 \ --gemm_plugin float16 \ --max_input_len 8192 \ --max_output_len 1 \ --logits_dtype float32 \ --world_size 1 "

编译耗时实测：RTX 4060 Laptop GPU上约18分钟。生成的engine文件/models/qwen3-embedding-0.6b/trt_engine/rank0.engine大小为1.12GB，比原.pt文件（1.35GB）小17%，且支持FP16精度。

4.4 vLLM服务启动：带健康检查的production-ready命令

最终启动命令必须包含健康检查端点，供K8s liveness probe使用：

# 创建health_check.py（vLLM不自带，需自定义） cat > /models/qwen3-embedding-0.6b/health_check.py << 'EOF' from fastapi import FastAPI import uvicorn app = FastAPI() @app.get("/health") def health(): return {"status": "ok", "model": "qwen3-embedding-0.6b"} if __name__ == "__main__": uvicorn.run(app, host="0.0.0.0:8000", port=8000) EOF # 启动vLLM服务（后台运行） docker run -d \ --name qwen3-embedding \ --gpus all \ -p 8000:8000 \ -v /models:/models \ -w /workspace \ --restart unless-stopped \ vllm/vllm-openai:v0.27.1 \ bash -c " python3 /models/qwen3-embedding-0.6b/health_check.py & vllm serve \ --model /models/qwen3-embedding-0.6b \ --tensorrt-llm-engine-dir /models/qwen3-embedding-0.6b/trt_engine \ --dtype half \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --enforce-eager \ --max-num-batched-tokens 4096 \ --host 0.0.0.0 \ --port 8000 "

验证：curl http://localhost:8000/health返回{"status":"ok","model":"qwen3-embedding-0.6b"}；curl http://localhost:8000/v1/embeddings -X POST -H "Content-Type: application/json" -d '{"input":"hello world","model":"qwen3-embedding-0.6b"}'返回200且embedding维度为1024。

5. 常见问题与排查技巧实录：27个真实故障的根因分析

5.1 NVIDIA驱动相关问题速查表

独家技巧：RTX 4060 Laptop GPU在Linux下常报NVRM: Xid (PCI:0000:01:00): 79, PID=0, GPU has fallen off the bus，这是PCIe电源管理bug。永久修复：echo 'pci=noaer' >> /etc/default/grub，然后sudo grub2-mkconfig -o /boot/grub2/grub.cfg。

5.2 TensorRT编译失败高频原因

实测数据：在RTX 4060 Laptop GPU上，--max_input_len 8192编译需6.2GB显存；设为4096后降至3.1GB，编译成功率从45%升至100%。

5.3 vLLM服务启动失败诊断树

当docker logs qwen3-embedding显示空白或Segmentation fault时，按此顺序排查：

1. 检查TRT engine路径：docker exec -it qwen3-embedding ls -la /models/qwen3-embedding-0.6b/trt_engine/，确认rank0.engine存在且大小>1GB；
2. 验证engine兼容性：docker exec -it qwen3-embedding python3 -c "import tensorrt_llm; print(tensorrt_llm.__version__)，必须输出0.10.0（TensorRT-LLM 0.10.0才支持Qwen3）；
3. 检查CUDA Graph冲突：日志中搜cuda graph，若出现CUDA graph capture failed，立即加--enforce-eager参数；
4. 显存溢出定位：docker exec -it qwen3-embedding nvidia-smi -q -d MEMORY \| grep "Used"，若启动瞬间显存飙升至95%，说明--gpu-memory-utilization设太高，降至0.7。

终极技巧：vLLM日志默认级别太低，加--log-level DEBUG启动，关键错误会出现在[INFO|engine.py:xxx]行，而不是被淹没在INFO流里。

5.4 模型推理性能不达标根因分析

客户抱怨“Qwen3-Embedding吞吐只有23 req/s，比预期低40%”，排查发现：

• 错误配置：--max-num-batched-tokens 1024（太小），导致batch size平均只有8；
• 正确配置：--max-num-batched-tokens 4096，batch size提升至32，吞吐达38 req/s；
• 硬件限制：RTX 4060 Laptop GPU的PCIe带宽只有16GB/s，当batch size>64时，显存带宽成为瓶颈，吞吐不再增长。

性能公式：实际吞吐 ≈ min(理论吞吐, PCIe带宽 / 单请求数据量)。Qwen3-Embedding单请求输出1024*4=4KB，PCIe带宽16GB/s可支撑4M req/s，但GPU计算单元只能跑38 req/s，所以瓶颈在GPU而非PCIe。

6. 进阶扩展：Model-Optimizer如何支撑H100千卡集群与边缘C++部署

6.1 H100千卡集群部署：从单卡TRT engine到分布式推理

H100集群不是简单增加--tensorrt-llm-engine-dir路径，而是要用TensorRT-LLM的--world_size参数构建多卡engine。以8卡H100为例：

# 1. 在每张卡上生成rank-specific engine trtllm-build \ --checkpoint_dir /models/qwen3-embedding-0.6b/tllm_engine \ --output_dir /models/qwen3-embedding-0.6b/trt_engine \ --gpt_attention_plugin float16 \ --gemm_plugin float16 \ --max_input_len 8192 \ --max_output_len 1 \ --logits_dtype float32 \ --world_size 8 # 生成rank0.engine ~ rank7.engine

vLLM启动时自动识别多卡engine，但必须加--tensor-parallel-size 8：

vllm serve \ --model /models/qwen3-embedding-0.6b \ --tensorrt-llm-engine-dir /models/qwen3-embedding-0.6b/trt_engine \ --tensor-parallel-size 8 \ --dtype half \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --enforce-eager

关键指标：8卡H100吞吐达312 req/s（单卡38 req/s × 8.2倍线性加速），得益于TensorRT-LLM的NCCL AllReduce优化。而纯vLLM方案在8卡上仅达210 req/s，因PagedAttention跨卡同步开销大。

6.2 FastSAM C++ TensorRT部署：Model-Optimizer的跨框架复用

FastSAM是视觉模型，但Model-Optimizer方法论同样适用。其C++部署要点：

• 模型转换：用torch.onnx.export()导出ONNX，再用trtexec --onnx=fastsam.onnx --saveEngine=fastsam.trt生成engine；
• C++加载：不用TensorRT C++ API从头写，而用[Tensor