AI 推理平台选型与验证步骤

AI部署的选型不能只比较“模型能否启动”，而要在同一模型、请求形态、硬件和软件边界下核对吞吐、延迟、资源占用、运维与成本。先按官方文档跑通一个最小服务，再用固定请求和相同边界复测候选平台；最终只保留能够复现并保留完整记录的方案。平台是否入选，应由功能匹配、性能、运维和成本证据共同决定。

AI部署前先固定选型和指标边界

你先记录模型与量化方式、输入和输出长度、是否流式、请求到达方式、GPU、CPU、内存、磁盘、驱动及软件版本。按 MLPerf Inference 规则，被测系统是接受性能测量的软硬件资源集合；所有提交必须使用 LoadGen 生成场景查询、跟踪延迟、校验准确率并计算最终指标。对 LLM，它还收集首 token 时间（TTFT）和每个输出 token 的平均间隔（TPOT），并区分以下场景：

场景	请求方式	约束与结果
Server	按 Poisson 分布发送查询	使用基准特定的延迟约束，报告可支持的最大 Poisson 吞吐
Offline	开始时用一个查询发送全部样本	无延迟约束，测量吞吐量
Single stream	上一个请求完成后立即发送下一个	报告第 90 百分位 early-stopping 延迟估计

选平台时，你还要把模型格式、流式接口、监控字段、启停方式、版本记录和计费页面列入核对表。缺少当前文档或可复现结果的项目应标为“未验证”，不要用同类平台的能力代填。

用 vLLM 建立最小可复现基线

vLLM 的快速入门文档列出的前提是 Linux 与 Python 3.10–3.13；文档建议使用全新环境，由 uv 创建 Python 3.12 虚拟环境，并让 --torch-backend=auto 根据已安装的 CUDA 驱动选择 PyTorch 索引。服务通过 vllm serve 启动，默认地址为 http://localhost:8000，模型列表位于 /v1/models，且一个服务进程一次只托管一个模型。

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

vllm serve Qwen/Qwen2.5-1.5B-Instruct

服务启动后执行：

curl http://localhost:8000/v1/models

返回模型列表只能证明该端点可访问，不能证明吞吐、延迟或稳定性。`vLLM 的 GPU 安装文档还说明，它不原生支持 Windows，文档给出的 Windows 路径是使用兼容的 WSL；NVIDIA GPU 需要 compute capability 7.5 或更高。遇到不同 CUDA 版本或已有 PyTorch 安装时，需要从源码构建，这类环境应单独记录，不能与预编译环境混报。

用 Triton 核对多框架服务边界

需要多框架服务时，可对照Triton 官方说明：它列出 TensorRT、PyTorch、ONNX、OpenVINO、Python、RAPIDS FIL 等框架，支持 NVIDIA GPU、x86 与 ARM CPU 以及 AWS Inferentia，并推荐使用 Docker 镜像；其 HTTP/REST 和 GRPC 推理协议基于 KServe。

在 /models 已按当前文档挂载后，官方给出的启动命令为：

tritonserver --model-repository=/models --model-control-mode explicit --load-model densenet_onnx

验证时保留模型仓库、已加载模型和容器配置，把它们纳入被测系统边界。只有当这些框架、设备和协议确实对应你的工作负载时，才能记为能力匹配。

验证吞吐、延迟和输出

做新的性能测试时，先注意 NVIDIA 的 GenAI-Perf README已说明该工具不再积极开发新功能，并将新的性能测试需求转向 AIPerf。该页仍将 TTFT 定义为发送请求到收到首个响应的时间，将 Request Latency 定义为发送请求到收到最终响应的时间；Output Token Throughput 是输出 token 总数除以测试时长，Request Throughput 是最终响应数除以测试时长。

以下仅是已有的 GenAI-Perf 工作流命令，不是 AIPerf 命令：

genai-perf profile \
  -m gpt2 \
  --backend tensorrtllm \
  --streaming

运行前应让模型、backend 和 streaming 条件与被测服务一致。每次报告保留工具版本、测试时长、稳定性设置、请求样本和原始结果，不把不同定义的延迟或不同分母的吞吐量互相替代。

资源、成本与碳排要单独核对

跨平台统一的资源监控命令取决于候选平台当前文档。你需要确认可取得的 GPU 显存、CPU、内存、磁盘、功耗及采样或导出方式，并让资源观测与性能测试使用同一运行标识和起止窗口；无法取得的数据应标为未知，不能用吞吐反推。

计算费用时，到候选平台自己的定价或账单页面，逐项抄录其实际列出的加速器类型、地区、计费单位、运行时长、存储、出网流量、启动或空闲费用及其他项目，再从报价单或账单填入：

GPU_RATE = YOUR_VALUE
GPU_HOURS = YOUR_VALUE
GPU_COST = GPU_RATE * GPU_HOURS
OTHER_LISTED_COST = YOUR_VALUE
TOTAL_COST = GPU_COST + OTHER_LISTED_COST

OTHER_LISTED_COST 只汇总页面实际列出的其他费用，未列出的项目不要自行添加。若排放也属于选型条件，可参考 GHG Protocol 的 Scope 2 指南：location-based 方法使用消费地点电网的平均排放强度，market-based 方法使用合同工具的排放因子；存在合同工具的市场需要分别报告并标明方法。不同口径的碳排数字不能直接放入性能比较，这里也只是通用口径说明，不构成法律或合规意见。

验收清单与常见误区

验收前逐项确认：

• 功能：端点、模型身份和流式行为符合目标。
• 性能：被测系统、请求形态、测试窗口和指标定义保持一致。
• 可复现性：保存软件版本、启动命令、请求样本、原始结果和错误日志。
• 运维：从干净环境重复安装与启动，并记录配置变更和停止过程。
• 成本：公式中的项目均来自自己的报价单或账单。

最常见的错误是跨硬件或软件边界比较、混用不同测试场景、把不同定义的指标互换，以及把“服务能响应”当作“性能已经通过”。阈值、被测系统清单、原始输出或成本依据任一缺失，都应把结果标为验证不完整，而不是直接宣布胜出。

这些步骤按正文所链接的官方文档整理，使用前应对照当前版本复核。

资料来源

• MLPerf Inference Rules
• vLLM Quickstart
• vLLM GPU Installation
• Triton Inference Server README
• GenAI-Perf README
• GHG Protocol Scope 2 Guidance