AI推理服务的性能瓶颈往往不在模型本身，而在承载它的GPU实例是否选对了。同样是部署一个7B参数的大语言模型，不同的GPU实例在首token延迟、吞吐量和并发能力上可能相差数倍，而费用差距同样明显。这次我们拿到几款常用的阿里云ECS GPU实例，跑了一轮完整的AI推理压测，把真实数据整理出来，供正在做选型的同学参考。
测试环境与实例规格说明
这次测试选取了三款在AI推理场景中使用频率较高的GPU实例：ecs.gn7i-c16g1.4xlarge（单卡A10，24GB显存）、ecs.gn6e-c12g1.3xlarge（单卡V100，32GB显存）以及ecs.gn7e-c16g1.8xlarge（单卡A100，80GB显存）。操作系统统一使用Ubuntu 22.04，驱动版本535，CUDA 12.2，推理框架选择TensorRT-LLM 0.8和vLLM 0.4，测试模型为Qwen-7B-Chat和ResNet50。
为了保证数据可比性，所有实例都部署在同一可用区，测试客户端与实例之间走内网通信，避免公网延迟干扰。每组测试重复五次取平均值，并且在每次测试前清理GPU缓存，排除残留显存占用带来的抖动。压测工具使用vLLM自带的benchmark_serving脚本，以及locust做并发请求模拟。
文本生成场景实测结果
大语言模型推理是当前最典型的GPU负载，我们重点测了首token延迟（TTFT）和每秒输出token数（TPOT）这两个指标。输入长度统一为512 token，输出256 token，并发数从1逐步拉到64。
在Qwen-7B-Chat模型上，A10实例单并发时的TTFT约为180ms，属于可接受范围；但当并发提升到32时，TTFT飙升到超过2秒，显存带宽成为明显瓶颈。A100实例在同样条件下，32并发TTFT仍然稳定在400ms以内，TPOT保持在每秒55 token左右，整体吞吐是A10的3.5倍以上。V100的表现介于两者之间，但由于缺乏对BF16的良好支持，在半精度推理下精度和速度都有一定折损。
vLLM的PagedAttention机制对显存利用率提升非常明显。开启后A10实例的最大可服务序列数从8提升到24，这说明同样的硬件条件下，推理框架的调度策略能显著改变实例的可用容量上限。
图像推理与性价比分析
传统CV模型推理对显存要求不高，但对计算核心频率敏感。ResNet50在A10上配合TensorRT FP16引擎，单张图片推理耗时约1.8ms，每秒可处理超过550张；A100虽然单卡算力更强，但在小模型上利用率不足，每秒约620张，提升只有13%，性价比明显不如A10。
按包年包月价格粗略折算，A100的小时单价约为A10的4倍，但在7B级大模型推理中吞吐优势超过3.5倍，加上80GB显存可以同时加载多个模型或使用更大的batch，对中大规模线上服务来说综合成本反而更低。小规模业务或者CV类轻量模型，A10是更经济的选择。V100由于架构较老，除非有存量资源，否则不建议新采购用于大模型推理。
选型建议与优化技巧
结合实测数据，给出几条实用建议。第一，并发低于20、模型在13B以内的对话类应用，A10够用，配合vLLM的continuous batching可以把单卡QPS做到15以上。第二，需要跑70B级模型或多模型混部的场景，直接上A100 80GB，显存余量决定了你能开多大的batch，而batch大小直接决定吞吐上限。第三，务必开启FP16或INT8量化，我们实测A10在INT8下吞吐提升约60%，精度损失在1%以内。
另外提醒一点，阿里云GPU实例支持抢占式实例，价格能降到按量付费的三分之一左右。推理服务如果能容忍偶尔的实例回收，配合自动扩缩容和模型快速加载（预热模型权重到本地盘），用抢占式实例跑推理可以大幅压缩成本，实测整体费用节省接近55%。
总结一下，GPU实例选型的核心是让显存容量匹配模型规模、让显存带宽匹配并发需求，再叠加框架层的调度优化，三者叠加才能把推理服务的性能和成本都压到最优区间。