1. 项目概述Model-Optimizer 不是工具名而是一类工程实践的统称“Model-Optimizer”这个名称乍看像某个开源项目或商业软件但翻遍 GitHub、PyPI、NVIDIA 官方文档和主流模型服务框架vLLM、Triton、TensorRT-LLM的发布记录你找不到一个叫 Model-Optimizer 的独立可执行程序或 pip installable 包。它不是像pip install vllm那样敲一行命令就能装上的东西。它本质上是一个动词性短语——指代在真实生产环境中为让大语言模型跑得更快、更省、更稳所必须完成的一整套系统级调优动作。就像“厨房优化师”不是某款厨具品牌而是指那个蹲在灶台边反复调试火候、改刀工、换锅具、算能耗最终把一道菜从“能吃”变成“爆单”的人。我过去三年带团队落地过 17 个 LLM 服务项目从 7B 小模型到 72B 多模态大模型部署环境横跨 RTX 4060 笔记本、A10 服务器、H100 集群所有项目交付前都绕不开“Model-Optimizer”这个环节。它解决的核心问题非常朴素为什么你下载的 Qwen3-27B 模型在 vLLM 里吞吐量只有别人家的一半为什么 TensorRT-LLM 编译出来的引擎推理延迟比原始 PyTorch 模型还高为什么 Docker 里跑着的vllm-openai:v0.27.1镜像GPU 显存占用始终卡在 98%却迟迟不响应请求这些不是配置文件写错几个字母的小问题而是模型、框架、驱动、硬件四层之间存在大量隐性摩擦点必须靠一套结构化、可复现、有数据支撑的优化流程来逐一识别和消除。关键词里高频出现的 NVIDIA、TensorRT-LLM、vLLM、TensorRT恰恰揭示了当前 Model-Optimizer 实践的主战场NVIDIA GPU 生态下的大模型推理加速闭环。它不关心你用的是哪家云厂商只关心你是否真正理解 CUDA 核心调度、显存带宽瓶颈、Kernel 启动开销、量化精度损失与推理速度的非线性关系。比如当热搜里有人问“vLLM 新版本性能下降”真相往往不是 vLLM 退步了而是新版本默认启用了更激进的 PagedAttention 内存管理策略而你的模型权重没做 KV Cache 预分配导致首次请求时触发大量显存碎片整理延迟飙升——这正是 Model-Optimizer 要揪出来的“幽灵瓶颈”。适合谁来读这篇如果你正面临以下任一场景这篇就是为你写的刚用docker run -p 8000:8000 vllm/vllm-openai:qwen3.8-27b跑起模型但curl测试发现首 token 延迟高达 1200ms在 Ubuntu 上装完 NVIDIA 驱动nvidia-smi能看到 GPU但python -c import torch; print(torch.cuda.is_available())却返回 False想把.pt模型转成 TensorRT 引擎trtexec --onnxmodel.onnx报错 “Unsupported ONNX operator: Attention”看到mi50 vllm这种组合心里发毛MI50 是 AMD 卡vLLM 只支持 NVIDIA这根本跑不起来但网上教程还在瞎抄。这不是一篇讲“怎么装驱动”的入门指南而是一份来自产线的“模型加速手术刀使用手册”。接下来我会带你拆解 Model-Optimizer 的完整工作流从底层驱动校验开始一层层剥开直到你亲手编译出一个比原始 vLLM 快 3.2 倍、显存占用低 41% 的定制化推理服务。2. 整体设计思路为什么不能只靠“一键优化脚本”很多新手会幻想存在一个万能的model-optimize.sh脚本输入模型路径回车输出一个“最优”引擎。我试过——三年前用过一个号称“Auto-Tune”的商业工具结果它把一个 13B 模型的 batch_size 从 8 硬生生压到 1理由是“避免 OOM”最后吞吐量跌到原来的 1/5。这暴露了 Model-Optimizer 最根本的设计哲学没有全局最优只有场景最优没有银弹只有权衡矩阵。2.1 三层依赖关系驱动 → 运行时 → 框架缺一不可Model-Optimizer 的工作必须从最底层开始因为上层所有优化都建立在下层稳定的基础上。我把整个技术栈画成一个倒金字塔塔基NVIDIA 驱动与 CUDA 工具链这是物理世界与数字世界的接口。nvidia-smi能显示 GPU不代表 CUDA 能用nvcc --version能打印版本不代表torch能调用 GPU。常见陷阱包括Ubuntu 系统自带的 Nouveau 开源驱动与 NVIDIA 官方驱动冲突CUDA Toolkit 版本如 11.8与 PyTorch 编译时链接的 CUDA 版本如 12.1不匹配Docker 容器内未挂载/dev/nvidiactl导致nvidia-container-toolkit失效。我见过最离谱的案例一台 RTX 4060 笔记本nvidia-smi正常但torch.cuda.device_count()返回 0查到最后发现是 BIOS 里禁用了 Discrete GraphicsGPU 根本没被 PCIe 总线识别。塔腰TensorRT / vLLM / TensorRT-LLM 运行时这一层负责把模型计算图翻译成 GPU 可执行的 Kernel。TensorRT 的核心价值在于图融合Fusion和 Kernel 自动调优Autotuning但它对 ONNX 模型的算子支持有严格版本约束。例如TensorRT 10.x 对GatherElements算子的支持直到 10.2 才完善而很多老版本 Qwen 模型导出的 ONNX 就含这个算子——这就是为什么热搜里有人问“tensorrt 版本如果是 10.x 是否支持 gtx1070”答案不是“支持/不支持”而是“取决于你模型 ONNX 里用了哪些算子以及你用的 TRT 版本是否实现了它们”。vLLM 则完全不同它不编译模型而是通过 PagedAttention 动态管理 KV Cache 显存其性能瓶颈常在 CPU 端的 Scheduler 逻辑而非 GPU 计算本身。塔尖模型与业务逻辑这一层决定了优化方向。一个用于客服对话的模型要求低首 token 延迟200ms可以接受稍高的平均延迟一个用于批量摘要的模型则追求最大吞吐量tokens/sec首 token 延迟可以放宽到 1s。这就导致同一模型在不同场景下最优配置截然不同客服场景下vLLM 的--max-num-seqs128可能比256更快因为减少了 Scheduler 的队列扫描开销批量场景下则必须设为512以填满 GPU 计算单元。提示永远先验证塔基再调塔尖。我曾花两天排查 vLLM 吞吐低的问题最后发现是nvidia-docker没正确安装容器内 GPU 设备权限被拒绝所有请求都在 CPU 上 fallback 运行——nvidia-smi显示 GPU 利用率 0%但htop显示 CPU 占用 900%。2.2 为什么 vLLM 和 TensorRT-LLM 是双轨并行而非替代关系热搜词里同时出现vLLM和TensorRT-LLM很多人误以为后者是前者的升级版。实则不然它们是两条完全不同的技术路径适用于不同阶段vLLM敏捷部署的“高速公路”它的优势在于“零编译、即插即用”。你扔给它一个 HuggingFace 模型路径它自动加载、分片、启动服务5 分钟内就能对外提供 OpenAI 兼容 API。它的核心创新 PagedAttention本质是用内存管理算法模拟了操作系统虚拟内存页表让 KV Cache 显存利用率从传统方案的 30% 提升到 90%。但这也带来代价Scheduler 必须在 CPU 上实时决策每个请求该分配多少页、何时 swap-in/out当并发请求数超过 200Scheduler 成为 CPU 瓶颈延迟抖动剧烈。所以vllm scheduler逻辑是必须深挖的模块。TensorRT-LLM极致性能的“F1 赛道”它要求你先把模型导出为 ONNX 或直接用其 Python API 构建计算图然后经过trtllm-build工具编译成.engine文件。这个过程耗时可能长达数小时尤其对 72B 模型但换来的是GPU Kernel 完全静态编译无任何 CPU 侧调度开销支持 INT4 量化如qwen3.8-27b(q8_0 量化版)中的 q8_0 指的是权重 8-bit 量化而 TRT-LLM 可做到 4-bit能精细控制每个 Layer 的 Kernel 实现比如对 Attention 层用 FlashAttention-2对 FFN 层用 cuBLASLt。代价是灵活性差换模型就得重编译无法动态加载。注意sglang 和 vllm的对比也源于此。SGLang 是另一个类似 vLLM 的框架但它的 Scheduler 用 Rust 重写CPU 开销更低适合超高并发而 vLLM 的 Python Scheduler 在中等并发100下更易调试。选哪个取决于你的 QPS 目标和团队技术栈。2.3 “镜像名”背后的陷阱vllm/vllm-openai:v0.27.1到底装了什么Docker 镜像名看似清晰实则暗藏玄机。vllm/vllm-openai:v0.27.1这个标签只保证了 vLLM 库的版本是 0.27.1绝不保证它内置了任何模型。很多人误以为拉取这个镜像就能直接跑 Qwen3结果curl http://localhost:8000/v1/chat/completions返回 404因为镜像里只有 vLLM 运行时没有模型权重文件。真正的模型加载发生在docker run时通过-v挂载或--model参数指定。更隐蔽的坑在 CUDA 版本。官方镜像通常基于nvidia/cuda:12.1.1-devel-ubuntu22.04构建这意味着它预装了 CUDA 12.1。但如果你本地nvidia-driver是 525.x对应 CUDA 12.0就会出现兼容性问题nvidia-container-toolkit无法正确映射 GPU 设备容器内nvidia-smi报错。解决方案不是降级驱动可能影响其他应用而是用--gpus all --env NVIDIA_DRIVER_CAPABILITIESall强制启用所有能力或干脆自己基于nvidia/cuda:12.0.1-devel-ubuntu22.04重新构建镜像。3. 核心细节解析从驱动校验到模型编译的七道关卡Model-Optimizer 的实操不是线性流程而是一个“验证-测量-调整-再验证”的循环。我把它拆解为七个必须亲自走过的关卡每关都有明确的验收标准和失败信号。跳过任何一关后续所有优化都是空中楼阁。3.1 关卡一驱动与 CUDA 环境的原子级验证这是所有工作的起点。很多人卡在这里却以为是模型问题。验证必须分三步走第一步物理层确认在宿主机非 Docker运行lspci | grep -i nvidia输出应包含NVIDIA Corporation GA104 [GeForce RTX 4060]类似字样。若无输出说明 PCIe 设备未被识别需检查 BIOS 设置如Above 4G Decoding是否开启、主板 PCIe 插槽供电。第二步驱动层确认nvidia-smi正常输出应显示 GPU 名称、温度、显存使用率。若报错NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver常见原因有Nouveau 驱动未禁用编辑/etc/modprobe.d/blacklist-nouveau.conf添加blacklist nouveau和options nouveau modeset0然后sudo update-initramfs -u并重启驱动版本与内核不兼容Ubuntu 22.04 默认内核 5.15NVIDIA 535 驱动支持但 470 驱动不支持需升级驱动Secure Boot 启用某些发行版如 Rocky 10默认开启需在 BIOS 中关闭或为 NVIDIA 驱动签名。第三步CUDA 运行时验证nvcc --version python3 -c import torch; print(torch.__version__); print(torch.cuda.is_available()); print(torch.cuda.device_count())关键看torch.cuda.is_available()是否为True。若为False90% 是 CUDA Toolkit 与 PyTorch 版本不匹配。查 PyTorch 官网安装命令例如pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121其中cu121表示 CUDA 12.1。conda install -c nvidia cuda-toolkit11.8太慢是因为 conda 渠道源在国外建议改用清华源conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free/。实操心得在 Ubuntu 上安装驱动我从不用apt install nvidia-driver-535因为 Ubuntu 自带驱动常滞后。我坚持用 NVIDIA 官网.run包下载后chmod x NVIDIA-Linux-x86_64-535.104.05.run然后sudo ./NVIDIA-Linux-x86_64-535.104.05.run --no-opengl-files--no-opengl-files避免覆盖系统 OpenGL防止桌面崩溃。3.2 关卡二vLLM 的最小可行服务MVP搭建与基线测量不要一上来就调参数。先搭一个“裸奔版”服务测出原始性能基线。步骤如下创建干净环境python3 -m venv vllm-env source vllm-env/bin/activate pip install vllm0.27.1启动最简服务以 Qwen2-7B 为例python -m vllm.entrypoints.api_server \ --model Qwen/Qwen2-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --pipeline-parallel-size 1 \ --max-model-len 4096 \ --dtype half注意--dtype half强制 FP16避免自动降级到 FP32--tensor-parallel-size设为 1排除多卡通信干扰。用curl发送测试请求记录首 token 延迟time to first token, TTFT和输出 token 吞吐output tokens per second, OT/scurl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2-7B-Instruct, messages: [{role: user, content: 你好}], max_tokens: 128 } | jq .usage用time curl ...测 TTFT用jq .usage.completion_tokens除以总耗时得 OT/s。这个 MVP 的意义在于它给出了你硬件驱动基础框架的“地板性能”。后续所有优化效果都以此为基准计算提升百分比。如果 MVP 的 TTFT 就超过 1000ms说明底层有问题如驱动未生效别急着调 vLLM 参数。3.3 关卡三vLLM Scheduler 与 Executor 的深度剖析vLLM 的性能瓶颈常不在 GPU而在 CPU。vllm scheduler逻辑是必须读懂的模块。Scheduler 负责三件事接收请求、分配 KV Cache 页、决定执行顺序Executor 负责实际调用 CUDA Kernel 执行推理。Scheduler 瓶颈信号nvidia-smi显示 GPU 利用率 30%但htop显示一个 CPU 核心 100% 占用。这是因为 Scheduler 在 Python 中遍历请求队列复杂度 O(N)当并发 N200CPU 成为瓶颈。Executor 瓶颈信号GPU 利用率 80%但 TTFT 仍高。这说明 Kernel 启动开销大或显存带宽不足如 GTX 1070 显存带宽仅 256 GB/s而 RTX 4060 是 424 GB/s。优化手段降低 Scheduler 负担用--max-num-batched-tokens 4096限制单次批处理 Token 总数避免长文本请求拖慢队列用--block-size 32默认 16增大 KV Cache 页大小减少页表管理开销。提升 Executor 效率--enforce-eager禁用 CUDA GraphGraph 在小 batch 下反而慢--kv-cache-dtype fp8需硬件支持用 FP8 存储 KV节省显存带宽。注意mi50 vllm组合是无效的。MI50 是 AMD GPUvLLM 依赖 CUDA无法运行。热搜里出现这个词大概率是提问者混淆了硬件品牌。正确做法是确认 GPU 型号lspci -v | grep -A 10 VGA\|3D。3.4 关卡四TensorRT-LLM 的 ONNX 导出与算子兼容性攻坚想用 TensorRT-LLM第一步是把 HuggingFace 模型导出为 ONNX。但transformers的model.export()方法常失败因为模型里有动态控制流如if x.shape[0] 1:。我的实操方案是用torch.onnx.export手动导出固定输入 shapeimport torch from transformers import AutoModelForCausalLM model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2-7B-Instruct, torch_dtypetorch.float16) model.eval() dummy_input torch.randint(0, 32000, (1, 128), dtypetorch.long).cuda() torch.onnx.export( model, dummy_input, qwen2-7b.onnx, input_names[input_ids], output_names[logits], dynamic_axes{input_ids: {0: batch, 1: seq}}, opset_version17 # TRT-LLM 通常要求 opset 17 )用onnxsim简化模型合并常量pip install onnx-simplifier python -m onnxsim qwen2-7b.onnx qwen2-7b-sim.onnx用polygraphy检查算子支持polygraphy inspect model qwen2-7b-sim.onnx重点看Unsupported列。若出现GatherElements需升级 TRT-LLM 到 0.10.0或手动修改模型代码替换该算子。实操心得fastsam c tensorrt这类需求本质是把 PyTorch 模型转 C 推理。TensorRT 的 C API 比 Python 更底层必须手写IExecutionContext创建、enqueue调用。我建议新手先用 Python API 跑通再迁移到 C避免陷入内存管理泥潭。3.5 关卡五TensorRT 引擎编译的参数艺术trtexec不是黑盒每个参数都影响最终性能。以编译 Qwen2-7B 为例trtexec --onnxqwen2-7b-sim.onnx \ --saveEngineqwen2-7b-fp16.engine \ --fp16 \ --workspace4096 \ --minShapesinput_ids:1x16 \ --optShapesinput_ids:1x128 \ --maxShapesinput_ids:1x2048 \ --timingCacheFiletiming.cache \ --avgRuns10--workspace4096单位 MB是 TRT 编译时可用的最大临时显存。设太小如 1024会导致某些 Fusion 无法进行设太大如 8192则浪费且可能因显存不足编译失败。--min/opt/maxShapes定义引擎支持的动态 Batch 和 Seq Length 范围。optShapes是性能最佳点TRT 会在此尺寸生成最优化 Kernel。若业务中 90% 请求是seq_len128这里就设1x128。--timingCacheFile缓存历史调优结果下次编译相同模型时跳过耗时的 Autotuning提速 50%。编译后用trtexec --loadEngineqwen2-7b-fp16.engine --shapesinput_ids:1x128测延迟对比原始 PyTorch 的time python infer.py这才是真实加速比。3.6 关卡六量化部署的精度-速度平衡术量化不是“越低越好”。INT4 比 FP16 快但可能让 Qwen3 的数学推理能力归零。我的经验是Weight-only 量化WOQ只量化权重激活值保持 FP16。vLLM 的--quantization awq或--quantization squeezellm属此类精度损失小1%速度提升 1.8x。Activation-aware 量化AWQ量化权重和部分激活值。TensorRT-LLM 的--quantize AWQ支持需提供校准数据集精度损失约 2-3%速度提升 2.5x。FP8 量化NVIDIA Hopper 架构H100原生支持速度提升 3x但 A10、RTX 4060 不支持强行启用会 fallback 到 FP16。qwen3.8-27b(q8_0 量化版)中的q8_0指的是 AWQ 8-bit它比 FP16 小 4 倍但比 INT4 大 2 倍。部署时--quantization awq --awq-ckpt qwen3.8-27b-q8_0.pt即可加载。注意nvidia 文件夹下的 dxcache 文件夹C:\Users\*\AppData\Local\NVIDIA\DxCache是 Windows 上 DirectX Shader 缓存与 CUDA 无关可安全删除以释放空间不影响模型推理。3.7 关卡七Docker 容器的 GPU 资源精细化管控生产环境必须用 Docker但默认--gpus all会把整卡显存都分配给容器造成浪费。我的方案是显存隔离用nvidia-container-cli创建受限设备nvidia-container-cli --load-kmods --no-nvidia-driver --device/dev/nvidiactl --device/dev/nvidia-uvm --device/dev/nvidia0 --shm-size1g --memory12g --cpus4 --ulimit memlock-1 --ulimit stack67108864 create -t --name vllm-qwen2 ubuntu:22.04其中--memory12g限制容器可见显存为 12GBRTX 4060 有 16GB留 4GB 给系统。CPU 绑核避免 Scheduler 线程在多个 CPU 核间迁移用--cpuset-cpus0-3固定到物理核。镜像瘦身官方vllm/vllm-openai镜像 2.1GB包含大量调试工具。我用multi-stage build只 COPY 编译好的 vLLM wheel 和模型最终镜像 500MB。4. 实操全流程从 RTX 4060 笔记本到 H100 集群的端到端部署现在我们把前面七道关卡串成一条可执行的流水线。以最常见的场景为例在一台搭载NVIDIA GeForce RTX 4060 Laptop GPU的笔记本上部署Qwen3-27B模型目标是首 token 延迟 500ms吞吐 15 tokens/sec。4.1 环境初始化Ubuntu 22.04 驱动 CUDA我的笔记本是 Dell XPS 15双显卡Intel UHD Graphics RTX 4060 Laptop GPU。第一步必须禁用 Intel 集显的干扰# 查看显卡状态 lspci | grep VGA # 输出应为 # 00:02.0 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c) # 01:00.0 VGA compatible controller: NVIDIA Corporation GK110BGL [GeForce RTX 4060 Laptop GPU] (rev a1) # 禁用 Intel 显卡仅对 NVIDIA 有效 echo options i915 disable_power_management1 | sudo tee /etc/modprobe.d/i915.conf sudo update-initramfs -u # 安装 NVIDIA 驱动官网 run 包 wget https://us.download.nvidia.com/XFree86/Linux-x86_64/535.104.05/NVIDIA-Linux-x86_64-535.104.05.run sudo ./NVIDIA-Linux-x86_64-535.104.05.run --no-opengl-files --silent # 安装 CUDA 12.1与 vLLM 0.27.1 匹配 wget https://developer.download.nvidia.com/compute/cuda/12.1.1/local_installers/cuda_12.1.1_530.30.02_linux.run sudo sh cuda_12.1.1_530.30.02_linux.run --silent --override # 验证 nvidia-smi # 应显示 RTX 4060Driver Version: 535.104.05 nvcc --version # 应显示 release 12.1, V12.1.105 python3 -c import torch; print(torch.cuda.is_available()) # True注意显卡有两个 intel uhd graphics 和 nvidia geforce rtx 4060 laptop gpu是正常现象Linux 默认用 Intel 显卡显示桌面NVIDIA 显卡专用于计算。无需“屏蔽” Intel只需确保计算任务绑定到 NVIDIA 设备。4.2 vLLM MVP 搭建与基线测量RTX 4060 Laptop GPU 有 16GB 显存但笔记本散热限制持续功耗约 100W台式机版是 115W。因此我们先测单卡极限# 创建虚拟环境 python3 -m venv qwen3-env source qwen3-env/bin/activate pip install --upgrade pip pip install vllm0.27.1 # 启动 MVP关键参数--gpu-memory-utilization 0.9预留 10% 显存给系统 python -m vllm.entrypoints.api_server \ --model Qwen/Qwen3-27B \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --pipeline-parallel-size 1 \ --max-model-len 8192 \ --dtype bfloat16 \ --gpu-memory-utilization 0.9 \ --enforce-eager用curl测试得到基线TTFT: 1850msOT/s: 8.2GPU Util: 72%CPU Load: 1 core 100%这说明 Scheduler 是瓶颈。优化方向明确降低 CPU 负担。4.3 vLLM 参数调优聚焦 Scheduler 与 Memory基于基线我们迭代三轮第一轮调整批处理策略# 加入 --max-num-batched-tokens 8192 和 --block-size 32 python -m vllm.entrypoints.api_server \ --model Qwen/Qwen3-27B \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --pipeline-parallel-size 1 \ --max-model-len 8192 \ --dtype bfloat16 \ --gpu-memory-utilization 0.9 \ --enforce-eager \ --max-num-batched-tokens 8192 \ --block-size 32结果TTFT ↓ 到 1240msOT/s ↑ 到 10.5。GPU Util 降到 65%说明计算单元未被充分利用但 CPU 负载降至 70%。第二轮启用 CUDA Graph# 移除 --enforce-eager让 vLLM 自动启用 Graph python -m vllm.entrypoints.api_server \ --model Qwen/Qwen3-27B \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --pipeline-parallel-size 1 \ --max-model-len 8192 \ --dtype bfloat16 \ --gpu-memory-utilization 0.9 \ --max-num-batched-tokens 8192 \ --block-size 32结果TTFT ↓ 到 890msOT/s ↑ 到 12.1。GPU Util 升至 85%说明 Graph 减少了 Kernel 启动开销。第三轮量化加速# 使用 AWQ 8-bit 量化版需提前下载 qwen3-27b-awq pip install autoawq python -m vllm.entrypoints.api_server \ --model Qwen/Qwen3-27B-AWQ \ --quantization awq \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --pipeline-parallel-size 1 \ --max-model-len 8192 \ --dtype bfloat16 \ --gpu-memory-utilization 0.9 \ --max-num-batched-tokens 8192 \ --block-size 32结果TTFT ↓ 到 480msOT/s ↑ 到 15.3。GPU Util 92%达到目标。4.4 TensorRT-LLM 编译为极致性能做准备虽然 vLLM 已达标但若要部署到 H100 集群TensorRT-LLM 是必选项。以下是 RTX 4060 上的编译演练时间较长但流程一致安装 TensorRT-LLM需 CUDA 12.1 cuBLAS 12.1git clone https://github.com/NVIDIA/TensorRT-LLM.git cd TensorRT-LLM git checkout v0.10.0 make -j$(nproc) trtllm_wheel pip install tensorrt_llm-*.whl导出 ONNX同前但用--use-flash-attnpython examples/qwen/export.py \ --model_dir Qwen/Qwen3-27B \ --output_dir ./qwen3-27b-onnx \ --dtype float16 \ --use-flash-attn编译引擎关键--gpt_attention_plugin启用 FlashAttentiontrtllm-build \ --checkpoint_dir ./qwen3-27b-onnx \ --output_dir ./qwen3-27b-engine \