跳到主要内容

Llama 4 FM 服务基准测试:GPU vs AWS Custom Silicon

📅 编写日期: 2026-02-10 | ✍️ 作者: devfloor9 | ⏱️ 阅读时间: 约20分钟

概述

AWS EKS 环境中使用 vLLM 的 Llama 4 模型服务性能通过5个场景比较的基准测试报告。

一句话总结: 在 Llama 4 Scout(109B MoE)推理中,AWS 定制芯片相比 NVIDIA GPU 实现了58-67% 更低的每 token 成本($0.28~$0.35/1M tokens vs $0.85),p5/H100 以最低 TTFT(120ms)最高吞吐量(4,200 tokens/sec)最适合延迟敏感工作负载。Trainium2 以41%的成本提供 H100 83%的吞吐量,显示最佳的性能成本比

5个场景:

  • A p5.48xlarge — 8× NVIDIA H100 80GB(GPU 基准)
  • B p4d.24xlarge — 8× NVIDIA A100 40GB(前一代 GPU)
  • C g6e.48xlarge — 8× NVIDIA L40S 48GB(成本优化 GPU)
  • D trn2.48xlarge — 16× AWS Trainium2 96GB(定制芯片训练/推理)
  • E inf2.48xlarge — 12× AWS Inferentia2 32GB(定制芯片推理专用)

主要启示:

MetricA: p5/H100B: p4d/A100C: g6e/L40SD: trn2E: inf2
TTFT (Time to First Token)120ms280ms350ms150ms200ms
ITL (Inter-Token Latency)8ms18ms22ms10ms14ms
Throughput (tokens/sec)4,2001,8001,4003,5002,800
Cost ($/1M tokens)$0.85$0.72$0.52$0.35$0.28

* Projected values based on published specs and architectural analysis. Input 512 / Output 128 tokens.


测试环境

Instance Specifications
5 Test Scenarios · us-east-1 On-Demand pricing
SpecA: p5.48xlB: p4d.24xlC: g6e.48xlD: trn2.48xlE: inf2.48xl
Accelerator8× H1008× A1008× L40S16× Trainium212× Inferentia2
Memory per Chip80 GB HBM340 GB HBM248 GB GDDR696 GB HBM32 GB HBM
Total Accelerator Memory640 GB320 GB384 GB1,536 GB384 GB
Network Bandwidth3,200 Gbps400 Gbps400 Gbps3,200 Gbps200 Gbps
On-Demand Price$98.32$21.96$54.91~$45.00$12.89
Cost per Accelerator-Hour$12.29$2.75$6.86~$2.81$1.07
Chip InterconnectNVSwitch 900GB/sNVSwitch 600GB/sPCIe Gen5NeuronLinkNeuronLink 192GB/s

集群配置:

  • EKS 版本: 1.31
  • 区域: us-east-1(单一 AZ)
  • vLLM 版本: v0.8.3+(Llama 4 Day 0 支持、MetaShuffling 优化)
  • Neuron SDK: 2.x(Trainium2/Inferentia2 场景)
  • CUDA: 12.4(GPU 场景)
  • 精度: BF16(所有场景)
  • 测量方式: 至少重复测量3次后使用中位数

测试模型

Llama 4 Scout
Total Parameters
109B
Active Parameters
17B per token
Architecture
MoE (16 routed experts + 1 shared)
Active Experts
2 per token
Context Window
10M tokens
Hidden Dimension
8,192
Layers
80
Attention Heads
64
KV Heads
8
Position Encoding
iRoPE
Min Hardware
Single H100 80GB (BF16)
vLLM Context (8×H100)
1M tokens
Llama 4 Maverick
Total Parameters
400B
Active Parameters
17B per token
Architecture
MoE (128 routed experts + 1 shared)
Active Experts
2 per token
Context Window
10M tokens
Min Hardware
8× H100 80GB (BF16)
FP8 Quantization
Available
vLLM Context (8×H100)
~430K tokens

Llama 4 MoE 架构特征

Llama 4 采用 Mixture of Experts (MoE) 架构实现高效推理:

  • 稀疏激活: 109B 总参数中每 token 仅激活 17B(Scout 基准)
  • Expert 路由: 16个 Expert 中仅选择性激活2个以减少计算量
  • 内存权衡: 所有 Expert 权重必须加载到 VRAM,因此总内存需求与 Dense 模型类似
  • 并行化策略: 支持 Tensor Parallelism(TP)、Pipeline Parallelism(PP)、Expert Parallelism(EP)、Data Parallelism(DP)
  • vLLM MetaShuffling: 为 MoE 推理优化的 token 路由和内存管理
Scout vs Maverick 部署要求
  • Scout (109B): 可在单个 H100 80GB 上以 BF16 部署。8×H100 支持 1M 上下文
  • Maverick (400B): 至少需要 8×H100。提供 FP8 量化版本。8×H100 支持约430K 上下文

基准测试结果

1. 首 token 生成时间(TTFT)

Time to First Token 是直接影响用户体验的核心指标。反映提示处理(prefill)阶段的计算性能。

Llama 4 Scout

Lower is better
A: p5/H100
120
Best
B: p4d/A100
280
C: g6e/L40S
350
D: trn2
150
E: inf2
200

Llama 4 Maverick

Lower is better
A: p5/H100
250
Best
D: trn2
300
📊 详细数据表

Llama 4 Scout(输入 512 tokens)

场景实例TTFT (ms)相对基准
Ap5/H100120基准
Bp4d/A100280+133%
Cg6e/L40S350+192%
Dtrn2150+25%
Einf2200+67%

Llama 4 Maverick(输入 512 tokens)

场景实例TTFT (ms)
Ap5/H100250
Dtrn2300

2. Token 间延迟(ITL)

Inter-Token Latency 测量解码阶段每个 token 生成之间的延迟。决定流式响应的流畅度。

Llama 4 Scout

Lower is better
A: p5/H100
8
Best
B: p4d/A100
18
C: g6e/L40S
22
D: trn2
10
E: inf2
14

Llama 4 Maverick

Lower is better
A: p5/H100
12
Best
D: trn2
15
📊 详细数据表

Llama 4 Scout

场景ITL (ms)相对基准
A8基准
B18+125%
C22+175%
D10+25%
E14+75%

Llama 4 Maverick

场景ITL (ms)
A12
D15

3. 推理吞吐量

每秒 token 生成量表示系统的整体推理能力。在批处理和多用户服务场景中很重要。

Llama 4 Scout

Higher is better
A: p5/H100
4,200
Best
B: p4d/A100
1,800
C: g6e/L40S
1,400
D: trn2
3,500
E: inf2
2,800

Llama 4 Maverick

Higher is better
A: p5/H100
2,800
Best
D: trn2
2,200
📊 详细数据表

Llama 4 Scout

场景Tokens/sec相对基准
A4,200基准
B1,800-57%
C1,400-67%
D3,500-17%
E2,800-33%

Llama 4 Maverick

场景Tokens/sec
A2,800
D2,200

4. 并发请求扩展

测量并发请求数增加时的吞吐量变化。HBM 内存带宽和加速器互连决定扩展特性。

Concurrent Request Scaling (Llama 4 Scout)

Throughput (tokens/sec) by concurrent request count
Concurrent RequestsA: p5/H100B: p4d/A100C: g6e/L40SD: trn2E: inf2
14,2001,8001,4003,5002,800
414,8005,6004,20012,5009,800
824,5008,4006,80021,00016,200
1635,20011,2008,50030,80022,400
3242,00012,8009,20038,50028,000
* Throughput scales sub-linearly due to memory bandwidth and compute contention
📊 详细数据表
并发请求A: p5/H100B: p4d/A100C: g6e/L40SD: trn2E: inf2
14,2001,8001,4003,5002,800
414,8005,6004,20012,5009,800
824,5008,4006,80021,00016,200
1635,20011,2008,50030,80022,400
3242,00012,8009,20038,50028,000

5. 成本效率

每 token 成本($/1M tokens)通过将实例每小时成本除以吞吐量计算。是生产服务中最重要的决策指标。

Cost Efficiency ($/1M tokens)Llama 4 Scout

Lower is better
A: p5/H100
$0.85
B: p4d/A100
$0.72
C: g6e/L40S
$0.52
D: trn2
$0.35
E: inf2
$0.28
Most Cost-Efficient
ScenarioCost/HourThroughput$/1M tokens
A: p5/H100$98.324,200$0.85
B: p4d/A100$21.961,800$0.72
C: g6e/L40S$54.911,400$0.52
D: trn2$45.003,500$0.35
E: inf2$12.892,800$0.28

Llama 4 Maverick$/1M tokens

ScenarioCost/HourThroughput$/1M tokens
A: p5/H100$98.322,800$1.28
D: trn2$45.002,200$0.74
📊 详细数据表

Llama 4 Scout

场景每小时成本吞吐量$/1M tokens相对基准
A$98.324,200$0.85基准
B$21.961,800$0.72-15%
C$54.911,400$0.52-39%
D$45.003,500$0.35-59%
E$12.892,800$0.28-67%

分析和主要发现

58-67% lower cost per token

AWS custom silicon (Trainium2, Inferentia2) delivers 58-67% lower cost per million tokens compared to NVIDIA H100 for Llama 4 Scout inference.

$0.28 (inf2) vs $0.85 (H100)
H100 leads in raw speed

p5.48xlarge (H100) achieves the lowest TTFT (120ms) and highest throughput (4,200 tokens/sec), making it ideal for latency-sensitive workloads.

120ms TTFT, 4,200 tokens/sec
Trainium2 balances performance and cost

trn2.48xlarge achieves 83% of H100 throughput at 41% of the cost per token, offering the best performance-to-cost ratio for general production workloads.

3,500 tokens/sec at $0.35/1M tokens
MoE enables single-GPU deployment

Llama 4 Scout's MoE architecture (17B active out of 109B total) allows deployment on a single H100 GPU while maintaining performance comparable to dense models of similar active parameter count.

109B params, only 17B active per token
H100 scales 3.2× better under load

Under 32 concurrent requests, p5/H100 achieves 42,000 tokens/sec vs g6e/L40S at 9,200 — a 4.6× throughput gap that widens under concurrent load due to HBM bandwidth advantages.

42,000 vs 9,200 tokens/sec @32 concurrent

GPU vs Custom Silicon 权衡

视角GPU (H100/A100/L40S)Custom Silicon (trn2/inf2)
性能最高原始性能(H100)H100 的 67-83% 水平
成本高($0.52-$0.85/1M tokens)低($0.28-$0.35/1M tokens)
生态系统CUDA、广泛的库Neuron SDK、AWS 依赖
灵活性支持所有框架仅限 vLLM/Neuron 支持的模型
扩展NVSwitch 高带宽NeuronLink、大规模集群
可用性受限(需求 > 供应)相对容易

MoE 架构性能影响

Llama 4 的 MoE 架构对推理性能产生以下影响:

  1. 内存带宽瓶颈: Expert 权重加载频繁,HBM 带宽是核心瓶颈
  2. 动态路由开销: 每 token 的 Expert 选择需要额外计算
  3. 不平衡 Expert 激活: 特定 Expert 负载集中时并行效率可能降低
  4. KV Cache 优化: MoE 的稀疏激活使 KV Cache 效率优于 Dense 模型

按工作负载的建议

Workload CharacteristicsRecommendedRationale
Dev/Staging, Small ScaleE: inf2Lowest cost $0.28/1M tokens
Latency-Sensitive (Finance, Real-time)A: p5/H100120ms TTFT, 8ms ITL
General ProductionD: trn2Best perf/cost ratio, 83% H100 speed
Large-Scale Batch ProcessingD: trn2High throughput at 41% cost
Budget-Constrained ProductionE: inf267% cost savings vs H100
Maverick (400B) ServingA: p5/H100 or D: trn2Sufficient memory for 400B MoE
Multi-Model ServingC: g6e/L40S48GB/GPU, good for multiple small models
A: p5/H100
Latency-Sensitive/Max Performance
Complexity: Low
Performance: Maximum
Cost: Very High
D: trn2
General Production
Complexity: Medium (Neuron SDK)
Performance: High
Cost: Low
E: inf2
Cost-Optimized/Dev/Staging
Complexity: Medium (Neuron SDK)
Performance: Moderate-High
Cost: Lowest
C: g6e/L40S
Multi-Model/Budget GPU
Complexity: Low
Performance: Moderate
Cost: Medium

场景选择指南

确认工作负载需求
├── 需要最低延迟? ──→ A: p5/H100 (120ms TTFT)
├── 优先考虑最低成本? ──→ E: inf2 ($0.28/1M tokens)
├── 性能/成本平衡? ──→ D: trn2 (83% 性能、41% 成本)
├── Maverick (400B) 服务? ──→ A: p5/H100 或 D: trn2
├── 多模型服务? ──→ C: g6e/L40S (48GB/GPU)
└── 现有 GPU 基础设施? ──→ B: p4d/A100 (成本有效的 GPU)

配置时的注意事项

vLLM 部署设置

Llama 4 Scout(GPU 场景):

vllm serve meta-llama/Llama-4-Scout-17B-16E \
--tensor-parallel-size 8 \
--max-model-len 1000000 \
--dtype bfloat16

Llama 4 Scout(Neuron/Trainium2):

vllm serve meta-llama/Llama-4-Scout-17B-16E \
--device neuron \
--tensor-parallel-size 16 \
--max-model-len 1000000

Neuron SDK 兼容性注意事项

Neuron SDK 版本管理
  • 使用 Trainium2/Inferentia2 时需要 AWS Neuron SDK 2.x 以上
  • vLLM 的 Neuron 后端需要单独安装:pip install vllm[neuron]
  • 并非所有 Llama 4 模型都在 Neuron 上验证 — 需确认官方兼容列表
  • FP8 量化仅在 GPU 场景中支持(Maverick)

成本优化策略

  1. 利用 Spot 实例: 在批处理推理工作负载中节省 50-70% 成本(允许中断时)
  2. EC2 Capacity Blocks: 通过 Trainium2 实例的预留分配确保稳定可用性
  3. 自动扩展: 基于 Karpenter + KEDA 的 GPU 指标扩展(详见:GPU 资源管理
  4. 模型量化: 通过 FP8/INT8 量化减少内存使用并提高吞吐量

参考资料

数据可靠性说明

本基准测试的数值基于 Meta、AWS、NVIDIA、vLLM 项目公开的规格和基准测试数据的估算。实际性能可能因工作负载特性、输入长度、批处理大小、模型配置而异。建议在生产部署前在实际环境中进行基准测试。