SageMaker AI 2026 推理更新拆解：从容量调度到分层 KV Cache 与 PD 分离

2026-09-19 33 预计阅读时间: 1 分钟
来源: aws.amazon.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：12 分钟

2026 年上半年，Amazon SageMaker AI 围绕推理交付了 13 项更新，覆盖两条部署路径：全托管推理端点与 Amazon SageMaker HyperPod Inference。把这些发布放在一起看，主线并不是简单增加实例类型或配置项，而是同时优化模型选择、容量供给、缓存层次和大模型推理流水线。

对于正在运行生成式 AI 服务的团队，这些变化对应四个直接问题：模型该部署到什么硬件上、突发容量从哪里来、KV Cache 如何避免挤爆昂贵显存，以及 prefill 与 decode 是否还应该绑定在同一组计算资源中。

两条部署路径解决的是不同层级的问题

全托管端点与 HyperPod Inference 都能承载在线推理，但它们面向的控制粒度不同。

路径 更适合的场景 团队主要关注点
SageMaker 全托管端点 希望减少集群运维、快速上线稳定 API 实例选择、自动扩缩、版本发布、单请求延迟
SageMaker HyperPod Inference 大规模模型、复杂并行策略或需要更强基础设施控制 跨节点调度、容量池、吞吐、缓存与计算拓扑

选择时不要只比较单卡价格。真正影响成本的通常是有效吞吐、扩容等待时间、缓存命中率以及尾延迟。一个单价较低但频繁发生排队或缓存重建的部署，可能比更昂贵但利用率稳定的部署成本更高。

四类更新背后的架构信号

1. 推理推荐从“选实例”走向“用负载做决策”

推理推荐的价值不只是给出某个实例型号，而是缩短模型、硬件和运行参数之间的试错过程。生产评估至少应同时记录：

  • 每秒请求数与每秒生成 token 数；
  • 首 token 延迟与完整请求延迟；
  • P50、P95 和 P99，而不只是平均值；
  • 不同输入长度、输出长度和并发度下的表现；
  • 单位请求或百万 token 的估算成本。

尤其对大语言模型来说，短问答、长文档摘要和多轮对话不是同一种负载。只用一个固定提示词跑基准，很容易得到无法指导生产选型的结论。

2. 容量感知实例池把容量变成调度输入

容量感知实例池反映出一个现实：推理调度不能假设某一种加速器永远有充足库存。更实用的策略是准备一组经过验证的候选容量，让调度系统根据可用性和策略选择落点。

这也意味着模型制品需要具备一定的硬件可移植性。团队应提前验证候选实例上的容器镜像、量化格式、张量并行配置和显存占用，而不是在容量紧张时临时迁移。

容量池并不等于可以随意混用硬件。不同加速器可能产生吞吐、数值精度和启动时间差异，切换之前仍需设置兼容性门槛与性能下限。

3. 分层 KV Cache 开始处理“显存不是无限的”

自回归生成过程中，KV Cache 可以避免每一步都重新计算历史 token，但它会随上下文长度、批大小和并发会话增长。把全部缓存长期保留在高成本加速器内存中，往往不可持续。

分层 KV Cache 的思路是根据访问频率和延迟要求，将数据放在不同层级：热数据留在最快的内存层，较冷数据下沉到容量更大但访问更慢的层级。它带来的不只是容量扩展，也引入了新的工程取舍：

  • 下沉与回迁是否会拉高首 token 或逐 token 延迟；
  • 会话路由是否稳定，能否避免缓存频繁跨节点移动；
  • 缓存命中率是否足以覆盖数据搬运成本；
  • 多租户环境中如何隔离缓存和清理敏感上下文。

因此，缓存层次必须与会话亲和性、批处理策略和可观测性一起设计。

4. Prefill/Decode 分离让两种计算阶段独立扩缩

大模型推理包含特征明显不同的两个阶段：prefill 处理整个输入上下文，通常计算密集；decode 逐 token 生成结果，更容易受内存带宽、缓存访问和调度抖动影响。

如果两个阶段始终绑定在相同实例上，长提示词可能占满计算资源，使正在生成的请求发生抖动。将 prefill 与 decode 解耦后，可以分别选择硬件、并行方式和扩缩指标。例如，prefill 池按待处理输入 token 扩容，decode 池按活跃序列数或生成 token 速率扩容。

代价是系统多了一次阶段间状态传输。只有当资源利用率提升超过 KV 状态传输、网络和调度开销时，分离才真正划算。短上下文、低并发服务未必需要这套复杂度。

可复制的端点基准测试

在采用任何新调度或缓存能力前，先为现有 SageMaker 实时端点建立基线。下面的 Python 脚本会并发调用一个已经部署好的端点，并输出成功率、吞吐以及 P50、P95、P99 延迟。

运行前需要：

  1. 已配置可调用端点的 AWS 凭证；
  2. 将 ENDPOINT_NAME 改为实际端点名；
  3. 根据模型容器协议修改 PAYLOAD。示例假设端点接受包含 inputs 字段的 JSON。
python -m pip install boto3
export ENDPOINT_NAME='my-sagemaker-endpoint'
export AWS_REGION='us-east-1'
export CONCURRENCY='8'
export REQUESTS='50'
export PAYLOAD='{"inputs":"Explain why tiered KV caching matters in one paragraph."}'
python benchmark_endpoint.py

将以下内容保存为 benchmark_endpoint.py：

import json
import os
import statistics
import time
from concurrent.futures import ThreadPoolExecutor, as_completed

import boto3

endpoint_name = os.environ["ENDPOINT_NAME"]
region = os.getenv("AWS_REGION", "us-east-1")
concurrency = int(os.getenv("CONCURRENCY", "8"))
request_count = int(os.getenv("REQUESTS", "50"))
payload = os.getenv(
    "PAYLOAD",
    '{"inputs":"Explain SageMaker inference in one sentence."}',
).encode("utf-8")

client = boto3.client("sagemaker-runtime", region_name=region)


def invoke_once():
    started = time.perf_counter()
    response = client.invoke_endpoint(
        EndpointName=endpoint_name,
        ContentType="application/json",
        Accept="application/json",
        Body=payload,
    )
    response["Body"].read()
    return time.perf_counter() - started


def percentile(values, p):
    ordered = sorted(values)
    index = round((len(ordered) - 1) * p)
    return ordered[index]


latencies = []
errors = []
wall_started = time.perf_counter()

with ThreadPoolExecutor(max_workers=concurrency) as pool:
    futures = [pool.submit(invoke_once) for _ in range(request_count)]
    for future in as_completed(futures):
        try:
            latencies.append(future.result())
        except Exception as exc:
            errors.append(str(exc))

wall_time = time.perf_counter() - wall_started
result = {
    "endpoint": endpoint_name,
    "requests": request_count,
    "successful": len(latencies),
    "failed": len(errors),
    "throughput_requests_per_second": round(len(latencies) / wall_time, 2),
}

if latencies:
    result.update(
        {
            "mean_ms": round(statistics.mean(latencies) * 1000, 2),
            "p50_ms": round(percentile(latencies, 0.50) * 1000, 2),
            "p95_ms": round(percentile(latencies, 0.95) * 1000, 2),
            "p99_ms": round(percentile(latencies, 0.99) * 1000, 2),
        }
    )

if errors:
    result["sample_error"] = errors[0]

print(json.dumps(result, indent=2))

这段脚本适合做快速回归，不等同于完整压测。正式测试还应加入预热、固定测试时长、输入长度分布、输出 token 统计和限流控制。对流式响应，还要分别记录 time to first token 与 inter-token latency；仅测完整响应时间会掩盖 decode 阶段的问题。

如何决定先采用哪一项能力

可以按瓶颈而不是按功能发布时间安排升级顺序：

  • 实例选型反复试错：先建立代表性数据集，再使用推理推荐与基准结果筛选配置。
  • 扩容失败或等待时间不可控：验证多个候选实例，设计容量感知的实例池与降级策略。
  • 长上下文导致显存压力：观察 KV Cache 占用、命中率和会话迁移，再评估分层缓存。
  • 长提示词拖慢正在生成的请求：分别测量 prefill 和 decode，确认是否值得拆分资源池。
  • 低并发且模型较小：继续使用简单的全托管端点可能更经济，不必为了架构先进而引入集群复杂度。

上线前还应检查故障回退、跨硬件结果一致性、缓存中的数据隔离、配额、区域容量，以及部署变化对 P99 延迟的影响。

结语

SageMaker AI 在 2026 年上半年的 13 项推理发布，可以看作一组相互关联的能力：推荐系统帮助做部署前决策，容量感知实例池处理供给不确定性，分层 KV Cache 扩展有效内存，而 prefill/decode 分离进一步重塑计算流水线。

采用这些能力时，最稳妥的路径不是一次性重构，而是先记录端点基线，再定位成本或延迟瓶颈，每次只改变一个关键变量。对于多数团队，清晰的负载模型和可信的 P95/P99 数据，往往比选择最新架构更重要。

# AI # AWS # 云平台 # 机器学习

相关推荐