SageMaker AI年内上线 13 项推理能力，覆盖托管端点与HyperPod两条路径
AWS官方博客梳理 2026 年迄今SageMaker AI的 13 项推理更新：7 项面向全托管端点，6 项面向Kubernetes原生的HyperPod Inference，涵盖实例推荐、容量感知实例池、OpenAI兼容API、容器缓存、分层KV缓存与分离式预填充/解码。
AI解读：这条新闻本质上是一份产品清单：SageMaker AI在 2026 年目前为止发了 13 项推理功能，7 项给全托管端点，6 项给HyperPod Inference。前者主打少运维，后者给要自己管GPU集群、又想要AWS托底可靠性的团队。
值得普通读者注意的不是“13”这个数字，而是几项直接改成本结构的功能：实例推荐免去 2 到 3 周人工压测，还免费给出优化建议；容器缓存在Qwen3-8B上把启动时间从 525 秒压到 258 秒；异步推理的请求负载现在可以直接塞进请求体，不必先上传S3。
真正被影响的是已经在SageMaker上跑生成式AI推理的团队：容量不足不再直接让端点创建失败，而是按最多 5 个实例类型的优先级回退；基于OpenAI SDK、LangChain或Strands Agents的应用迁移只需改端点URL。对只做实验、还没上生产的用户，这些更新暂时用不到。
限制同样写得很具体：OpenAI兼容API只在 14 个AWS区域可用，异步内联负载限 128,000 字节、覆盖 31 个区域，前缀感知路由的路由开销为每请求 1.3 到 1.9 毫秒，分离式预填充/解码目前验证在Llama 3.3 70B的混合流量上。这些条件决定了哪些工作负载能直接受益。
AWS在官方博客中盘点Amazon SageMaker AI 2026年迄今的推理更新：共 13 项新能力，分布在两条部署路径上——全托管端点（7 项）和Amazon SageMaker HyperPod Inference（6 项）。博客作者为Kareem Syed-Mohammed，内容基于该博客发布时公开的功能说明与基准数据。
两条路径的定位由博客给出的对照表界定：端点由AWS全托管、用控制台/SDK/CLI部署、由CloudWatch托管自动扩缩；HyperPod是托管Kubernetes栈，用kubectl、Terraform、控制台、CLI、SDK部署，支持Karpenter、KEDA、CloudWatch扩缩，提供节点级访问、自定义框架和AMI，适合基于Kubernetes的训练到推理、多云/混合云场景。
托管端点的 7 项更新：实例推荐、容量回退与OpenAI兼容API
Inference recommendations与基准测试（2026 年 4 月）：博客称选对实例类型、服务容器和优化设置通常需要 2 到 3 周人工压测 1000 多种组合；该功能让客户指定模型和性能目标（成本、延迟或吞吐），SageMaker走三步流程——按模型架构、大小和内存需求筛选实例类型；应用目标对齐的优化（吞吐用EAGLE 3.0推测解码，延迟用内核调优，按模型大小用张量并行）；在真实GPU上运行NVIDIA AIPerf并给出多次运行的置信度报告。输出是带部署就绪配置和验证指标的SageMaker Model Package，包括首token时间（TTFT）、token间延迟（ITL）、P50/P90/P99延迟、吞吐和成本预测。博客给出的示例中，GPT-OSS-20B的吞吐优化在相同请求延迟下达到 2 倍token/秒。生成推荐不额外收费，有ML Reservations的客户可在预留容量上免费基准测试。
容量感知实例池（2026 年 5 月）：此前端点只能绑定单一实例类型，容量不足会导致端点在服务任何请求前失败。现在客户可定义最多 5 个实例类型的优先级列表，SageMaker在端点创建、扩容和缩容时自动按列表尝试：创建时首选类型无容量立即回退；扩容时优先级列表中下一个可用类型承接需求；缩容时先移除回退实例，使集群在容量释放后回归首选硬件。每个实例类型有独立CloudWatch指标维度，可按异构集群做加权扩缩策略；每个池条目可引用各自的优化模型配置（高内存实例用张量并行、中端用推测解码、小回退实例用量化），实例推荐可自动生成这些按硬件的配置。该功能支持单模型、推理组件和异步端点，覆盖所有商业AWS区域。
OpenAI兼容API（2026 年 5 月）：此前基于OpenAI SDK、LangChain或Strands Agents的应用要用SageMaker托管模型，必须写自定义客户端适配器和重写鉴权。现在SageMaker端点暴露 /openai/v1路径，支持带流式的Chat Completions，迁移只需改端点URL，SDK调用、流式逻辑和提示格式不变。鉴权使用由现有AWS凭据生成、最长 12 小时有效的bearer token，去掉了SigV4签名复杂度。多模型端点可在同一OpenAI SDK下调用多个模型，各自独立分配资源。博客称该功能在 14 个AWS区域可用，支持vLLM和SGLang的AWS Deep Learning Containers以及自定义容器实现 /v1/chat/completions路径。
容器缓存（2026 年 6 月）：自动扩缩时新实例此前要从Amazon ECR拉完整容器镜像才能服务请求，超过 10 GB的大型服务容器光拉取就增加数分钟空转。容器缓存自动预拉镜像，新实例启动时本地已有容器，零配置、无需改代码或容器，在受支持的加速器实例类型上自动启用。博客给出的数据：Qwen3-8B在ml.g6.2xlarge上用LMI容器（17.7 GB压缩），端到端启动延迟从 525 秒降到 258 秒，减少 51%；模型下载时间从 168 秒降到 77 秒，因为镜像不再争抢网络带宽。早期访问客户观察到 38% 到 65% 的改善。
异步推理内联负载（2026 年 6 月）：此前异步推理要把每个输入负载先传到Amazon S3再调用端点，哪怕只是几百字节的JSON提示。现在InvokeEndpointAsync API的Body参数可直接接收最大 128,000 字节的负载，省去S3预暂存。博客列出的好处：每请求少一次网络往返；无需配置输入桶或授予IAM s3:PutObject权限；立即做大小和参数校验；避免每次调用的S3 PUT费用。该功能完全向后兼容，原有InputLocation工作流不变，在 31 个AWS区域可用。
前缀感知路由：一种新路由策略，把共享提示前缀的请求导向同一实例，从而最大化KV缓存复用。博客说明多数LLM应用中系统指令、检索文档和对话历史在请求间大量重复，通常每个实例都要从头重算这些共享token。该功能以请求开头作为指纹做一致路由，内置过载保护和扩缩期间的稳定行为。在 7 个实例上对Llama 3.1 70B的基准显示：长上下文工作负载（8,000 token前缀）P90 TTFT下降 33% 到 37%，P50 TTFT下降 71% 到 77%，KV缓存命中率从约 25% 升到 82%；短上下文P90 TTFT下降 24% 到 37%。路由开销为每请求 1.3 到 1.9 毫秒。SageMaker现有三种路由策略：RANDOM（默认）、LEAST_OUTSTANDING_REQUESTS和新的PREFIX_AWARE，启用只需在端点配置中设置RoutingStrategy、PrefixLength和ConcurrencyThreshold，无需改模型容器或服务框架，支持多租户前缀隔离、推理组件和动态LoRA适配器，已在实时推理端点可用。
HyperPod Inference的 6 项更新：EKS算子简化与分离式预填充/解码
EKS上的简化Inference Operator（2026 年 4 月）：博客称在Kubernetes上部署LLM通常要为每个模型编写和维护Deployment、Service、ConfigMap、HorizontalPodAutoscaler和健康检查接线，管理数十个模型时这类手写基础设施本身就成了工程负担。简化版Inference Operator是原生EKS附加组件，通过AWS控制台、CLI、SDK、kubectl或Terraform一步安装；安装后提交单个自定义资源定义即可部署模型。主要能力包括：多实例类型回退（按优先级列表依次尝试，模型无需人工干预即达服务状态）；内置自动扩缩（与CloudWatch、Amazon Managed Service for Prometheus和KEDA原生集成做事件驱动扩缩）；EKS附加组件生命周期（AWS在集群生命周期内管理版本升级、兼容性检查和健康监控）；JumpStart集成（通过同一算子界面直接部署SageMaker JumpStart的流行基础模型）。
托管分层KV缓存与智能路由：HyperPod Inference管理两级KV缓存——L1层在各节点的CPU内存中做低延迟本地复用，L2层用Redis做跨节点共享，使一个模型pod算出的缓存前缀可被集群内其他pod复用。智能路由提供三种模式：前缀感知路由（把带共享系统提示或文档前缀的请求导向最可能命中缓存的实例）、KV感知路由（用实时缓存状态把请求导向缓存占用率最高的实例）、轮询（标准负载分发，适合不看重缓存复用的工作负载）。博客称分层缓存加智能路由在长上下文和多轮工作负载上，相比无缓存基线最多降低 40% 延迟。
数据捕获（2026 年 5 月）：受监管企业需要可防篡改的推理活动日志用于合规、漂移监控和离线评估数据集构建。HyperPod Inference的数据捕获通过自定义资源定义（CRD）启用三个捕获点——SageMaker端点（应用边界的完整请求和响应）、ALB（负载均衡器流量，用于路由可见性和延迟测量）、模型pod（容器边界的请求和响应，用于模型级调试）。捕获数据流入Amazon S3，无需自定义sidecar容器或应用埋点；团队可在三个点中选择性启用，使存储成本与实际需求成比例。
分离式预填充和解码（2026 年 7 月）：预填充和解码共用同一GPU池时，复杂提示的长预填充会阻塞队列中所有并发用户的token生成，混合流量下每token延迟随请求复杂度变得不可预测。该功能在Inference Operator v3.2中发布，把两个阶段分到不同GPU池：预填充GPU处理提示；请求的KV缓存就绪后通过EFA上的GPU-Direct RDMA传到解码池，绕过CPU的直接内存传输；解码GPU生成输出token，不受新进预填充工作干扰。两个池可独立扩缩。博客称在混合流量下用Llama 3.3 70B验证，DPD的TTFT和ITL分布比同址预填充/解码更一致。运维人员在CRD中为预填充和解码节点指定独立实例池，Inference Operator自动管理EFA配置和KV缓存传输。
性能特性（2026 年 7 月）：博客提到HyperPod引入Hugging Face、NVMe和Route 53集成以增强部署灵活性、性能和安全性，其中Hugging Face Hub集成可直接部署模型而无需先把权重预暂存到S3，并支持门控模型、版本固定和token（来源摘要在此处截断，未给出该集成的完整说明与基准数据）。