大模型推理选型常从"H100还是新一代卡"开始，其实顺序反了。先要明确的是服务级目标、流量形态、模型更新频率和团队能承担的故障责任。AWS最新复盘列出托管端点与Kubernetes原生HyperPod两条路线，真正的分界不是性能高低，而是你要把多少控制权和多少值班压力留在自己手里。
发生了什么
AWS在9月18日汇总了SageMaker AI 2026年至今的13项推理能力。托管端点方向包括推理推荐、容量感知实例池、OpenAI兼容API、容器缓存、可观测性、异步载荷和前缀感知路由；HyperPod方向包括简化Operator、分层KV Cache、数据捕获、性能优化、预填充与解码分离、模型缓存。
官方把两条路径定位得很清楚：托管端点负责GPU供应、扩缩容和运维，适合希望快速上线的团队；HyperPod提供Kubernetes、节点和框架层控制，适合已有平台工程能力、需要训练到服务一体化或混合云部署的团队。计费共同特点是按实例资源而非按Token消费，但实际成本仍取决于利用率与保留资源。
一手来源：AWS技术复盘。文中性能样例由AWS提供，跨模型与跨硬件的独立复现仍需自行完成。
先把业务问题翻译成推理指标
生成式AI服务至少有四类指标：首Token时间（TTFT，Time to First Token）决定用户多久看到响应；Token间延迟（ITL，Inter-Token Latency）影响流式输出是否顺滑；吞吐决定同一资源能服务多少请求；尾延迟则看P90、P99下最慢用户的体验。只看平均延迟，容易掩盖高峰时的排队。
AWS称，推理推荐会先按模型结构、尺寸和显存缩小实例空间，再应用推测解码、内核调优和张量并行，最后在真实GPU上基准测试。其示例中，GPT-OSS-20B经过吞吐优化后，在相同请求延迟下Token每秒翻倍。这个结果只能说明特定配置存在收益，不能证明所有模型都翻倍。
两条路线怎么选
假设你做一个内部文档助手，白天有明显峰值、模型更新不频繁、平台团队只有两人。托管端点通常更合理：运维边界清楚，能用兼容API和自动扩缩容快速接入。若你运营多个大模型、已有GPU集群、需要自定义调度和预填充/解码分离，HyperPod的控制权才可能抵消Kubernetes复杂度。
容量感知实例池值得单独看。团队可按优先级配置最多五种实例，首选资源不足时自动回退。它提高可用性，却也引入异构结果：不同GPU对应的量化、张量并行和推测解码配置可能不同。若不做数值一致性与性能回归，所谓回退可能把故障换成质量下降或成本飙升。
缓存同样要按负载判断。大量请求共享长系统提示时，前缀感知路由能把相似请求送到保有相同缓存的副本，减少重复预填充；会话短、提示差异大时，维护路由和缓存元数据可能收益有限。预填充与解码分离则适合两阶段资源特征差异明显的长上下文服务，不是默认必选项。
我的判断
推理平台的核心产品不是GPU，而是可预测的任务完成成本。 最便宜的单卡不一定带来最低成本；如果冷启动、低利用率和尾延迟导致重试，账单与体验都会恶化。反过来，最强控制权也不是免费午餐，它需要调度、监控、升级和事故响应能力。
我建议把"谁负责凌晨三点的容量故障"写进选型表。若答案是应用团队且他们并不懂GPU调度，就应优先托管；若已有平台团队并且优化一成利用率就能覆盖数名工程师成本，再考虑自管集群。
边界与风险
AWS文章是产品方总结，13项能力的可用区域、配额、实例支持和具体价格可能不同，上线前须以当前控制台与文档为准。前缀缓存、KV Cache分层和预填充/解码分离对长上下文或重复前缀更有价值，对短请求未必划算。OpenAI兼容API也不代表全部字段与行为完全一致。
可立即执行的选型表
先记录一周真实请求的输入输出长度、并发和高峰；定义TTFT、ITL、P99与错误率目标；选三种代表性实例；用同一模型、精度和请求集压测；加入冷启动、容量不足和节点故障；计算每千次成功任务而非每小时实例成本；最后再比较托管与自管所需的人力值班。没有真实负载时，任何"最佳实例"都只是猜测。
成本表里要单列闲置、重试、数据传输、监控和工程人力。把月度总成本除以满足质量与延迟门槛的成功任务数，才能比较不同路线；失败或超时的请求即使消耗了GPU，也不应被当作有效吞吐。
你的推理服务当前最贵的约束，是GPU、延迟还是运维人力？
关注「蜗牛聊AI」，一起看懂技术变化背后的真正机会。
本文首发于 java4u.cn，转载请注明出处。