部署大模型别先选GPU，先回答你愿意承担多少运维
内容提要
大模型推理选型应先明确服务目标、流量与运维责任，而非先选GPU。AWS提供托管端点与HyperPod两条路线：前者省运维、易上线，后者控制强但需平台能力。选型应基于真实负载压测，关注TTFT、尾延迟和每千次成功任务成本，并明确故障责任归属。
延伸解读
选型起点：运维责任而非硬件型号
文章指出，大模型推理选型常从“选哪款GPU”开始，但顺序反了。应先明确服务级目标、流量形态、模型更新频率和团队能承担的故障责任。AWS复盘将托管端点与HyperPod的分界定为控制权与值班压力的分配，而非性能高低。这意味着选型第一步是回答“谁负责凌晨三点的容量故障”，而非比较卡型。
指标翻译：从业务问题到推理指标
文章强调将业务问题翻译成推理指标：TTFT决定用户多久看到响应，ITL影响流式输出顺滑度，吞吐决定资源服务能力，尾延迟看P90/P99最慢用户体验。只看平均延迟会掩盖高峰排队。AWS示例中GPT-OSS-20B经吞吐优化后Token每秒翻倍，但文章提醒这仅说明特定配置存在收益，不能证明所有模型都翻倍。
两条路线的适用场景与隐藏成本
托管端点适合快速上线、运维边界清楚的团队；HyperPod适合已有平台工程能力、需要训练到服务一体化或混合云部署的团队。容量感知实例池可提高可用性，但引入异构结果，不同GPU的量化、张量并行配置可能不同，若不做数值一致性与性能回归，回退可能带来质量下降或成本飙升。缓存与预填充/解码分离也需按负载判断，并非默认必选。
成本视角：每千次成功任务而非单卡价格
文章认为推理平台的核心产品是可预测的任务完成成本。最便宜的单卡不一定带来最低成本，冷启动、低利用率和尾延迟导致重试会恶化账单与体验。建议计算每千次成功任务成本，而非每小时实例成本，并将闲置、重试、数据传输、监控和工程人力单列。失败或超时请求即使消耗GPU，也不应算作有效吞吐。
Q&A
部署大模型推理时，为什么不应该先选GPU？
因为选型顺序反了。应先明确服务级目标、流量形态、模型更新频率和团队能承担的故障责任，而不是先纠结用H100还是新一代卡。真正的分界不是性能高低，而是你愿意把多少控制权和值班压力留在自己手里。
AWS提供的托管端点和HyperPod两条路线分别适合什么团队？
托管端点负责GPU供应、扩缩容和运维，适合希望快速上线、平台团队较小的团队；HyperPod提供Kubernetes、节点和框架层控制，适合已有平台工程能力、需要训练到服务一体化或混合云部署的团队。
评估大模型推理服务时应该关注哪些关键指标？
至少关注四类指标：首Token时间（TTFT）决定用户多久看到响应；Token间延迟（ITL）影响流式输出是否顺滑；吞吐决定同一资源能服务多少请求；尾延迟看P90、P99下最慢用户的体验。只看平均延迟容易掩盖高峰排队。
容量感知实例池有什么潜在风险？
它允许按优先级配置最多五种实例，首选资源不足时自动回退，提高可用性，但会引入异构结果：不同GPU对应的量化、张量并行和推测解码配置可能不同。若不做数值一致性与性能回归，回退可能导致质量下降或成本飙升。
如何判断该选托管端点还是自管集群？
把“谁负责凌晨三点的容量故障”写进选型表。若答案是应用团队且他们不懂GPU调度，应优先托管；若已有平台团队，并且优化一成利用率就能覆盖数名工程师成本，再考虑自管集群。
做推理选型时，可立即执行的步骤有哪些？
先记录一周真实请求的输入输出长度、并发和高峰；定义TTFT、ITL、P99与错误率目标；选三种代表性实例；用同一模型、精度和请求集压测；加入冷启动、容量不足和节点故障；计算每千次成功任务成本；最后比较托管与自管所需的人力值班。
