Serverless GPU 选型：显存、区域与冷启动检查
梳理 Serverless GPU 的显存、区域与冷启动检查方法：以 NVIDIA L4 的 24 GB VRAM 为例，结合服务支持边界和按秒计费规则，形成可复核的平台比较清单。
Serverless GPU 选型要同时核对：服务是否明确提供 GPU、显存能否覆盖模型与并发开销、区域是否符合用户和数据边界，以及冷启动和计费如何发生。做 GPU服务器租用时，先排除不支持 GPU 的服务，再用统一字段比较候选平台，不要只看 GPU 型号。验证时把提交、就绪和返回分开计时，避免把不同口径的数字直接横比。
选型前准备：先做服务边界筛选
候选记录不要从产品名称反推能力，而要填写服务支持状态、GPU 型号、每种 GPU 的 VRAM、部署区域、模型与结果存放区域、冷启动控制方式及计费范围。文档没有明确说明的字段保留“待确认”，不要用其他平台的数据代填。
根据 SageMaker Serverless Inference 端点文档，该服务目前不支持 GPU；同一页面列出 1024 MB 至 6144 MB 的端点 RAM，这不是 GPU 显存。因此，它应移出 GPU 候选，而不是拿系统内存与模型权重比较。
显存：用模型需求卡住候选
先从所用模型与推理框架的当前文档填写初筛表：
MODEL_WEIGHT = YOUR_VALUE
KV_CACHE = YOUR_VALUE
WORKING_SET = YOUR_VALUE
HEADROOM = YOUR_VALUE
TOTAL_VRAM_REQUIRED = MODEL_WEIGHT + KV_CACHE + WORKING_SET + HEADROOM
精度或量化方式、上下文长度、并发请求和推理框架都会改变显存占用，不能拿另一个模型或旧版本的数字直接套用。候选 GPU 的 VRAM 应覆盖初筛结果；标称显存更大，也不代表模型在目标上下文与并发下必然适配。
按 Cloud Run 的 GPU 支持说明，页面列出的 NVIDIA L4 具有 24 GB VRAM，NVIDIA RTX PRO 6000 Blackwell 具有 96 GB VRAM，并明确 GPU 显存与实例内存分开。只把这些信息当作 Cloud Run 已记录的候选配置，不能据此推断其他平台也提供同款 GPU。
GPU服务器租用：按用户、数据和容量选区域
先记录主要调用用户所在地、服务端点区域、模型或缓存区域、结果存储区域。AWS 的 区域与可用区说明 明确说明，各 Region 相互隔离，资源不会自动跨 Region 复制；其建议也包括靠近客户或满足法律及其他要求。因此，多区域部署要另行设计复制与故障切换，数据驻留需由合规负责人确认。这里只提供一般信息，不构成法律意见。
若架构包含 EC2 资源，应按 EC2 启动问题排查 区分错误：InsufficientInstanceCapacity 表示当前按需容量不足，InstanceLimitExceeded 表示达到 Region 中可启动实例的配额。前者可按文档建议稍后重试、去掉指定 Availability Zone 或减少实例数量；后者应核对配额，不能都按容量不足处理。
其他候选平台的当前可用 Region、模型存放位置和容量状态，应从其控制台或文档填写。GPU 型号本身不能证明某个区域可部署，也不能代替数据边界检查。
冷启动：拆开启动、执行与空闲等待
根据 RunPod Serverless 计费说明，从 worker 启动到完全停止按秒计费，并向上取整；启动时间包括容器初始化和把模型加载到 GPU 内存，执行完成后还可能包含 idle-timeout，文档列出的默认值为 5 秒。费用核对可使用：
RAW_WORKER_SECONDS = START_SECONDS + EXECUTION_SECONDS + IDLE_TIMEOUT_SECONDS
TOTAL_BILLABLE_SECONDS = CEILING(RAW_WORKER_SECONDS)
TOTAL_COST = TOTAL_BILLABLE_SECONDS × YOUR_VALUE
YOUR_VALUE 应从自己的当前报价或账单填入适用单位费率；存在多种适用费率时，应按 worker 组合拆行记录，不能沿用旧报价，也不能只计算请求执行时间。
RunPod worker 文档 说明，Active workers 持续运行并消除冷启动；Flex workers 可缩容到零，但扩容时会产生冷启动，未使用时费用为零。两者不是速度排名，而应结合流量是否持续、能否接受重新启动及空闲成本核对。
验证时，应分别记录业务提交、资源可用、模型就绪、首次输出和请求完成时间。只记录其中一个时间点，无法判断延迟来自排队、容器启动、模型加载、推理还是返回链路。
用统一记录完成验收
每个候选使用下列模板：
SERVICE = YOUR_VALUE
GPU_AND_VRAM = YOUR_VALUE
REGION_AND_DATA_BOUNDARY = YOUR_VALUE
COLD_START_CONTROL = YOUR_VALUE
BILLING_SCOPE = YOUR_VALUE
PASS_OR_FAIL = YOUR_VALUE
提交业务含义一致的代表性请求，并保持模型、参数、请求格式和事先约定的空闲状态一致。不同平台的 API 即使不同，也应把时间统一换算到业务提交、模型就绪和完整返回这些相同边界。
验收时重点排查：
- 是否把系统内存或端点 RAM 当成 GPU VRAM。
- 是否仅凭最大显存判断模型能否在目标上下文和并发下运行。
- 是否把靠近用户等同于满足数据要求或保证容量。
- 是否遗漏 worker 启动、模型加载和空闲等待等计费范围。
- 是否用不同计时起点比较冷启动结果。
任何仍为“待确认”的字段都不应标记为通过。
本文仅按正文所链接的官方文档整理，未运行或测量；使用前应按当前版本复核。