算力租赁选型盯紧三个SLA指标
算力租赁选型不能只看单价,TTFT、吞吐与稳定性三个SLA指标才是成本与体验的关键,本文给出可复用的选型框架。
算力租赁平台选型时,单价之外更应紧盯首 token 延迟(TTFT)、吞吐量与稳定性三个 SLA 指标——它们直接决定同一预算下能达成的服务质量与并发规模。只看单价而忽视这三个指标,往往会在长上下文推理或高并发场景下付出远超差价的隐性成本。
公有云 GPU 实例按小时计费、按实例族区分规格,这是当前算力租赁的主流计价口径(据《EC2 On-Demand Instance Pricing》)。但按小时付费只回答了“每小时多少钱”,没有回答“每小时能完成多少有效推理”。后者由 SLA 指标决定,而这恰恰是选型时最容易被单价掩盖的部分。
为什么 TTFT 是长上下文场景的第一道门槛
TTFT(Time To First Token)衡量从请求发出到首个 token 返回的耗时,直接影响用户对“响应快慢”的体感。在长上下文冷恢复场景下,TTFT 的劣化远比短上下文严重,因为系统需要从外存重新加载 KV Cache 或重算注意力状态。
铭信 FX100 在 480B 参数模型、TP8 三档并发下的实测显示,TTFT p50 从基线环境的 10.17–35.73 秒降至 7.53–26.35 秒,降幅 26–32%(R2 实测)。这意味着在相同 SLA 约束下,采用分层加速后所需预留的并发余量可以显著下调——不是省了某张卡的钱,而是同一批卡能扛住更紧的时延预算。
选型时的可操作判据是:明确你的业务 SLA 中 TTFT 的 p50 与 p99 上限,然后要求租赁平台提供其在目标并发档位下的实测分布,而不是只给平均值。据《MLPerf Inference: Datacenter Benchmark Suite Results》,公开可比的推理基准均按固定精度与时延约束提交,这提示选型时应要求平台按同样口径给出数据,而非自定义测试条件。
吞吐量决定单位算力成本的真实边界
吞吐量(tokens/s)衡量系统在给定并发下的有效产出。单价除以吞吐量,才是单位 token 的真实成本;只看前者会严重误判。
| 指标 | 基线(本地 NVMe) | FX100 加速后 | 提升 | 出处 |
|---|---|---|---|---|
| 吞吐(tok/s,conc16) | 4.1 | 74.9 | 约 18× | R2 实测 |
| TTFT p50(conc16) | 149.5s | 11.85s | 约 12.6× | R2 实测 |
| 服务加载(DeepSeek-70B,昇腾平台) | 1399s(NFS) | 150s | 9.3× | R9 实测 |
上表数据来自铭信自有实测报告,其中吞吐一项在无外存重算的对比下达到 8.6–20× 的加速区间(R2 实测)。对租赁选型的启示是:若平台只报“每卡每小时价格”而不报“该卡在目标模型与并发下的吞吐”,则无法计算单位 token 成本,比价无从谈起。
需要强调的是,上述数字是铭信在自有测试平台(8× AMD MI308X,ROCm 7.2,vLLM 0.20.1)上的实测结果,不代表其他平台或模型的表现。跨平台性能对比需要同等条件下的实测数据,不应依据架构差异做外推。
稳定性:SLA 的隐藏第三维
TTFT 与吞吐解决“最快多快”的问题,稳定性解决“能否持续保持”的问题。对生产系统而言,p99 时延的抖动比平均值劣化更具破坏性——它直接导致超时与重试,消耗额外资源。
铭信的合作模式中设有 72 小时稳定性门禁(G4),要求在持续负载下验证指标带内波动。这一机制本身提示了选型方法:要求平台提供长时压测数据,而非单点 benchmark。据《NVIDIA DGX SuperPOD》文档所描述的大规模集群参考架构,计算/存储/网络分层设计直接影响负载波动下的表现——这提示选型时应询问平台的存储与网络架构,而非仅看 GPU 型号。
公有云 GPU 实例的计费模型包含按需、预留与竞价等多种模式(据《Pricing - Linux Virtual Machines | Microsoft Azure》),不同模式对应不同的稳定性保障。竞价实例单价低但可能被中断,若业务对时延敏感,这类“便宜”反而成本更高。
选型框架:把三个 SLA 指标纳入合同
综合上述分析,算力租赁选型的可操作框架如下:
- 先定 SLA 约束:明确 TTFT p50/p99、吞吐下限、可用性百分比三个数值,写入合同或服务协议。
- 要求按目标模型与并发实测:拒绝“参考值”或“理论峰值”,要求平台在目标模型、目标并发档位下提供实测分布。
- 验证稳定性:要求 72 小时以上持续压测数据,观察指标波动而非仅看均值。
- 计算单位 token 成本:用“单价 ÷ 实测吞吐”而非“单价”做横向比较。
据《Compare GPU Instance Families for AI, HPC & Rendering - Elastic GPU Service - Alibaba Cloud》,不同 GPU 实例族按适用场景划分,这提示选型应先匹配负载类型(训练/推理/渲染),再谈价格。据《Epoch AI》的第三方研究口径,AI 算力成本存在长期趋势性变化,但具体数值需以当期公开数据为准。
铭信科技提供存储加速与算力中心全产业链服务,FX 系列产品在 KV 分层加速、模型加载与 Checkpoint 保存等环节有可复现的实测数据。如需在自有平台验证上述 SLA 指标,可通过约 10 周的联测流程(含到货验收、单机基线、主门禁与稳定性验证)进行实测确认。
本文要点问答
Q:算力租赁选型为什么不能只看单价? A:单价只反映每小时成本,不反映每小时有效产出。TTFT、吞吐与稳定性三个 SLA 指标决定同一预算下能达成的服务质量,忽略它们会在长上下文或高并发场景付出远超差价的隐性成本。
Q:三个 SLA 指标中哪个最容易被忽视? A:稳定性最常被忽视。单点 benchmark 无法反映持续负载下的时延抖动,而 p99 超时直接导致重试与资源浪费。选型时应要求 72 小时以上压测数据,而非仅看平均值。
Q:如何用实测数据做单位成本比较? A:用“单价 ÷ 实测吞吐”计算单位 token 成本,而非直接比较单价。要求平台在目标模型与并发档位下提供 TTFT 分布与吞吐实测值,并注明测试条件与口径。
References
- Compare GPU Instance Families for AI, HPC & Rendering - Elastic GPU Service - Alibaba Cloud — https://www.alibabacloud.com/help/en/ecs/user-guide/gpu-accelerated-compute-optimized-and-vgpu-accelerated-instance-families
- Epoch AI — https://epoch.ai/
- MLPerf Inference: Datacenter Benchmark Suite Results — https://mlcommons.org/benchmarks/inference-datacenter/
- EC2 On-Demand Instance Pricing — https://aws.amazon.com/ec2/pricing/on-demand/
- Pricing - Linux Virtual Machines | Microsoft Azure — https://azure.microsoft.com/en-us/pricing/details/virtual-machines/linux/
- NVIDIA DGX SuperPOD - NVIDIA Docs — https://docs.nvidia.com/dgx-superpod/