在 AWS 上临时申请 GPU 实例时，一个很常见的问题是：我知道自己需要某种 GPU，但不知道现在到底哪个 Region 更容易拿到机器。如果直接打开 EC2 Console 一个区域一个区域尝试，会遇到两个问题：第一，很多区域虽然支持该实例类型，但当前未必有容量，大白话讲就是没货了；第二，GPU 实例通常受到 Region-specific Service Quota 限制，如果 quota 为 0，即使该区域有机器也无法启动。

因此，一个更合理的流程应该是：

先明确算力需求 → 确定可以接受的实例类型 → 用实时 capacity signal 筛选 Region/AZ → 再检查并申请对应 Region 的 quota → quota 到位后立即启动。

 

需要特别区分三个概念：

Instance offered in Region
        ≠
Currently enough capacity
        ≠
My AWS account is allowed to launch it

 这三个问题分别对应 Instance Type Offering、Spot Placement Score 和 Service Quota。

 

1. 先明确自己到底需要什么机器

根据个人项目需求来选择，我的场景主要是深度学习模型计算，希望使用 NVIDIA L40S，显存大约需要40-50G。根据跟AI讨论的结果，它推荐我申请g6e类型的机器，部分规格如下：

Instance	vCPU	RAM	GPU	GPU memory
g6e.xlarge	4	32 GiB	1 × NVIDIA L40S	44 GiB
g6e.2xlarge	8	64 GiB	1 × NVIDIA L40S	44 GiB
g6e.4xlarge	16	128 GiB	1 × NVIDIA L40S	44 GiB

根据我自己的需求，我不需要RAM，只对显存有要求，那这里我可以选择最便宜的g6e.xlarge。但是，待会下面要说的Spot Placement Score最适合输入至少 3 个自己真正能够接受的实例类型。如果需求写得过死，例如“只能是 g6e.4xlarge”，寻找可用容量的空间会明显缩小。因此我们会把这3个满足条件的都纳入候选机器。

那么我们的需求就可以定义为：

GPU: NVIDIA L40S
GPU memory: ≥ 44 GiB
GPU count: 1
Instance candidates:
    g6e.xlarge
    g6e.2xlarge
    g6e.4xlarge
Target capacity: 1 instance

 

2. Linux 安装并登录 AWS CLI

AWS CLI v2 可以直接在 Linux 本地使用。当前 AWS 官方推荐的用户级安装方式为：

curl -fsSL https://awscli.amazonaws.com/v2/install.sh | bash
export PATH="$HOME/.local/bin:$PATH"
aws --version

默认安装到：

~/.local/share/aws-cli

并在：

~/.local/bin

创建命令链接。AWS CLI 官方同时支持 x86-64 和 ARM Linux。如果希望以后每次打开 shell 都能直接使用：

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

如果平时 AWS Console 是通过 root user 邮箱登录，并不需要专门创建长期 Access Key。AWS CLI v2.32.0 以后支持浏览器登录：

aws login

第一次会要求输入一个 Region，例如：

eu-north-1

随后浏览器打开 AWS 登录页面，使用原来的 root user 邮箱、密码和 MFA 登录即可。aws login 支持 root user、IAM user 和 federated identity；root user 不需要额外赋予登录权限。

登录完成后验证：

aws sts get-caller-identity

如果能正常返回 Account 和 ARN，说明 CLI 已经可以调用 AWS API。需要注意，AWS 官方仍然不建议日常长期使用 root user；这里主要是为了临时查询和管理当前账号资源。

 

3. 真正寻找“当前哪里比较有机器”：Spot Placement Score

AWS 对普通 On-Demand EC2 没有提供一个公开 API，让用户直接查询目前有多少机器available。所以目前最有价值的实时容量信号是Spot Placement Score。它根据当前 Spot capacity、使用趋势、请求规模和实例组合等信息，对 Region 或 AZ 打 1–10 分。10 表示当前请求成功的可能性很高，1 表示成功可能性很低。这个分数是 point-in-time signal，会随时间变化。

对于前面定义的需求，可以直接查询：

aws ec2 get-spot-placement-scores \
  --instance-types g6e.xlarge g6e.2xlarge g6e.4xlarge \
  --target-capacity 1 \
  --target-capacity-unit-type units \
  --output table

这里：

--target-capacity 1

表示需要 1 个 capacity unit，而：

--target-capacity-unit-type units

表示这里的单位按实例数量理解。

AWS 要求在通过 instance type 查询 Spot Placement Score 时最好提供至少 3 种不同 instance types；少于 3 种时 AWS 会返回较低的 score。因此，这三个类型不应该随便凑数，而应该都是真正可以接受的机器。

一次实际查询得到：

Region            Score
ap-south-1          2
eu-central-1        2
ap-northeast-3      1
ap-northeast-2      9
us-east-2           1
us-east-1           9
ap-south-2          4
eu-south-2          1
ap-northeast-1      9
us-west-2           1

这个结果说明，在查询发生的那个时间点，下面三个区域对于这组 G6e 请求表现出了明显更好的 Spot capacity signal：

ap-northeast-2   Seoul          9
us-east-1        N. Virginia    9
ap-northeast-1   Tokyo          9

因此，这表明如果现在以这组 instance types 和 target capacity 请求 Spot，这三个 Region 相对更可能成功。但不代表100%，AWS 明确说明 Spot Placement Score 只是 recommendation，并不保证最终请求一定成功。

当然这里还有一点，Region score 高并不意味着这个 Region 内每一个 AZ 都有很好的容量。因此，对于高分区域进一步执行：

aws ec2 get-spot-placement-scores \
  --instance-types g6e.xlarge g6e.2xlarge g6e.4xlarge \
  --target-capacity 1 \
  --target-capacity-unit-type units \
  --single-availability-zone \
  --region-names ap-northeast-2 us-east-1 ap-northeast-1 \
  --output table

实际结果：

AvailabilityZoneId   Region           Score
apne2-az1            ap-northeast-2     1
apne1-az4            ap-northeast-1     9
use1-az6             us-east-1          1
apne2-az2            ap-northeast-2     9
apne1-az1            ap-northeast-1     9
use1-az4             us-east-1          3
use1-az2             us-east-1          2
use1-az1             us-east-1          1

这个结果比前面的 Region score 更有价值。

虽然 us-east-1 在 Region level 得到了 9，但具体 AZ 最高只有 3；相反：

Tokyo:
    apne1-az4 = 9
    apne1-az1 = 9

Seoul:
    apne2-az2 = 9

因此，如果最终要把任务落到单个 AZ，东京和首尔明显比 N. Virginia 更值得优先考虑。

之所以会出现“Region=9，但单个 AZ 很低”，是因为 Region-level score 默认假设请求可以在整个 Region 的多个 AZ 之间灵活选择，并使用 capacity-optimized strategy；而 --single-availability-zone 查询的则是单个 AZ 本身的容量情况。

所以总结一下筛选顺序：

Global Region score
        ↓
挑选高分 Region
        ↓
AZ-level score
        ↓
找真正高分的 AZ

 

4. Capacity 找到了以后，再检查 quota

通过 Spot Placement Score 找到高分 Region 和 AZ 之后，还需要检查当前 AWS 账号在这些区域是否具有足够的 EC2 GPU quota。EC2 GPU quota 具有明显的 Region-specific 特征，同一账号在不同 Region 中的额度彼此独立，同时 Spot 和 On-Demand 也分别采用不同的 quota。因此，一个 Region 的 Spot Placement Score 很高，只能说明当前容量信号较好，无法说明当前账号已经具备启动实例的权限。

对于 G6、G6e 等 G family 实例，AWS 使用 G/VT quota 管理可运行规模，并按照 vCPU 数量计算额度。例如，g6e.xlarge 配置 4 vCPU、1 张 NVIDIA L40S 和 44 GiB GPU memory，因此启动一台 g6e.xlarge 至少需要 4 个 G/VT vCPU quota；g6e.2xlarge 需要 8，g6e.4xlarge 需要 16。这里的 quota 数值代表 vCPU 数量，与 GPU 数量并不直接对应。AWS 官方文档也将 EC2 instance quota 定义为基于 vCPU 的区域级限制。

Spot G/VT quota 可以通过以下命令查询：

for r in ap-northeast-1 ap-northeast-2 us-east-1; do
  echo "===== $r ====="
  aws service-quotas get-service-quota \
    --service-code ec2 \
    --quota-code L-3819A6DF \
    --region "$r" \
    --query "Quota.Value" \
    --output text
done

其中，L-3819A6DF 对应 All G and VT Spot Instance Requests。如果同时考虑 On-Demand，可以查询 Running On-Demand G and VT instances：

for r in ap-northeast-1 ap-northeast-2 us-east-1; do
  echo "===== $r ====="
  aws service-quotas get-service-quota \
    --service-code ec2 \
    --quota-code L-DB2E81BA \
    --region "$r" \
    --query "Quota.Value" \
    --output text
done

在一次实际测试中，东京、首尔和 N. Virginia 都获得了较高的 Spot Placement Score，但这些区域的 G/VT Spot quota 均为 0。这一结果需要拆成两个维度理解：Spot Placement Score 描述当前容量信号，Service Quota 描述当前账号能够申请的资源上限。前者由 AWS 当前基础设施容量和需求状况决定，后者属于账号级限制。只有两个条件同时满足，实例才具备实际启动的可能性。

这里还有一个容易产生误解的现象。如果扫描所有 Region 后发现某些区域已经具有非零 quota，例如 eu-central-1 = 8、eu-north-1 = 4、eu-west-1 = 16，这些数值本身不能作为当前 GPU availability 的依据。若这些额度来自此前提交的 quota increase request，那么它们记录的只是账号过去在哪些 Region 获得过额度。当前实例容量仍然需要通过 Placement Score、实际 Spot 请求或最终启动结果判断。因此，在整个流程中可以把两个指标理解为两个独立筛选条件：Placement Score 用于寻找当前值得尝试的区域，Service Quota 用于确认账号是否已经具备进入这些区域申请资源的资格。

 

5. 对高分 Region 并行申请 Quota

当候选 Region 已经通过 Spot Placement Score 筛选出来后，quota 申请应围绕这些区域展开。如果任务具有较强的时间限制，可以同时向多个高分 Region 提交 quota increase request，从而避免整个流程依赖单一区域的审批速度。对于本文的例子，东京和首尔在 AZ-level 查询中都出现了 score=9 的 Availability Zone，因此它们具有较高的优先级；N. Virginia 的 Region-level score 同样达到 9，但具体 AZ 得分较低，可以作为额外候选区域。

如果目标是一台 g6e.xlarge，最低 G/VT quota 为 4，因此可以直接向多个候选 Region 同时申请 4 vCPU 的 Spot quota：

for r in ap-northeast-1 ap-northeast-2 us-east-1; do
  echo "===== Requesting Spot quota in $r ====="
  aws service-quotas request-service-quota-increase \
    --service-code ec2 \
    --quota-code L-3819A6DF \
    --desired-value 4 \
    --region "$r"
done

如果任务同时接受 On-Demand，也可以并行提交对应的 On-Demand G/VT quota：

for r in ap-northeast-1 ap-northeast-2 us-east-1; do
  echo "===== Requesting On-Demand quota in $r ====="
  aws service-quotas request-service-quota-increase \
    --service-code ec2 \
    --quota-code L-DB2E81BA \
    --desired-value 4 \
    --region "$r"
done

这种做法的核心目的是增加并行候选路径。例如，Tokyo Spot、Tokyo On-Demand、Seoul Spot、Seoul On-Demand 可以同时进入审批流程；只要其中任意一个满足 quota 要求，就可以立即进入实例启动阶段。这里需要注意，Spot Placement Score 与 quota approval 属于两个独立系统。Placement Score 高表示当前 Spot capacity signal 较好，并不会直接提高 Service Quota 的审批概率，因此 quota 申请范围仍然需要结合时间要求、成本限制和可接受的实例类型综合决定。

提交 quota increase request 后，可以等待 AWS 邮件通知，也可以直接通过 CLI 查询申请状态：

for r in ap-northeast-1 ap-northeast-2 us-east-1; do
  echo "===== $r ====="
  aws service-quotas list-requested-service-quota-change-history-by-quota \
    --service-code ec2 \
    --quota-code L-3819A6DF \
    --region "$r" \
    --query "RequestedQuotas[*].[DesiredValue,Status,Created]" \
    --output table
done

常见状态包括 PENDING、CASE_OPENED、APPROVED 和 DENIED。如果其中一个候选 Region 已经变为 APPROVED，就可以立即转向该区域准备启动实例。