部署大模型先别急着挑GPU：运维责任才是选型起点

大模型推理平台的选型经常从GPU规格和单卡价格开始，但真正决定方案能否长期运行的，往往是业务SLO、流量波动以及团队可以承担的运维边界。只有先明确延迟、吞吐、可用性和故障责任，才能判断托管服务与Kubernetes自管集群分别适合什么场景。

大模型推理选型常从“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下最慢用户的体验。只看平均延迟，容易掩盖高峰时的排队。

flowchart TD
    A[定义业务SLO] --> B{需要节点与框架级控制?}
    B -- 否 --> C[托管端点]
    B -- 是 --> D[HyperPod/Kubernetes]
    C --> E[基准模型与实例组合]
    D --> E
    E --> F[测TTFT/ITL/吞吐/P99]
    F --> G{容量是否稳定?}
    G -- 否 --> H[实例池与降级配置]
    G -- 是 --> I[路由/缓存/批处理优化]
    H --> I
    I --> J[压测、故障演练、成本复盘]

AWS称，推理推荐会先按模型结构、尺寸和显存缩小实例空间，再应用推测解码、内核调优和张量并行，最后在真实GPU上基准测试。其示例中，GPT-OSS-20B经过吞吐优化后，在相同请求延迟下Token每秒翻倍。这个结果只能说明特定配置存在收益，不能证明所有模型都翻倍。

两条路线怎么选

假设你做一个内部文档助手，白天有明显峰值、模型更新不频繁、平台团队只有两人。托管端点通常更合理：运维边界清楚，能用兼容API和自动扩缩容快速接入。若你运营多个大模型、已有GPU集群、需要自定义调度和预填充/解码分离，HyperPod的控制权才可能抵消Kubernetes复杂度。

容量感知实例池值得单独看。团队可按优先级配置最多五种实例，首选资源不足时自动回退。它提高可用性，却也引入异构结果：不同GPU对应的量化、张量并行和推测解码配置可能不同。若不做数值一致性与性能回归，所谓回退可能把故障换成质量下降或成本飙升。

缓存同样要按负载判断。大量请求共享长系统提示时，前缀感知路由能把相似请求送到保有相同缓存的副本，减少重复预填充；会话短、提示差异大时，维护路由和缓存元数据可能收益有限。预填充与解码分离则适合两阶段资源特征差异明显的长上下文服务，不是默认必选项。

我的判断

推理平台的核心产品不是GPU，而是可预测的任务完成成本。 最便宜的单卡不一定带来最低成本；如果冷启动、低利用率和尾延迟导致重试，与体验都会恶化。反过来，最强控制权也不是免费午餐，它需要调度、坚控、升级和事故响应能力。

我建议把“谁负责凌晨三点的容量故障”写进选型表。若答案是应用团队且他们并不懂GPU调度，就应优先托管；若已有平台团队并且优化一成利用率就能覆盖数名工程师成本，再考虑自管集群。

边界与风险

AWS文章是产品方总结，13项能力的可用区域、配额、实例支持和具体价格可能不同，上线前须以当前控制台与文档为准。前缀缓存、KV Cache分层和预填充/解码分离对长上下文或重复前缀更有价值，对短请求未必划算。OpenAI兼容API也不代表全部字段与行为完全一致。

可立即执行的选型表

先记录一周真实请求的输入输出长度、并发和高峰；定义TTFT、ITL、P99与错误率目标；选三种代表性实例；用同一模型、精度和请求集压测；加入冷启动、容量不足和节点故障；计算每千次成功任务而非每小时实例成本；最后再比较托管与自管所需的人力值班。没有真实负载时，任何“最佳实例”都只是猜测。

成本表里要单列闲置、重试、数据传输、坚控和工程人力。把月度总成本除以满足质量与延迟门槛的成功任务数，才能比较不同路线；失败或超时的请求即使消耗了GPU，也不应被当作有效吞吐。

你的推理服务当前最贵的约束，是GPU、延迟还是运维人力？