地质承载

1 3 秒看懂

“地质承载”不是关于土壤或岩石的工程术语，而是借用岩土工程中地基极限承载力的思想，衡量 AI 在线服务在高并发请求下的最大稳定吞吐容限。它关心的不是服务器标称的 QPS 天花板，而是系统在延迟非线性飙升、错误率突增之前，真正能扛住的持续压力。一旦接入真实流量的 AI 推理服务越过这个“承载界限”，就会像地基发生整体剪切破坏一样，从正常响应滑向大面积超时、雪崩式重试和级联故障，恢复代价远超提前限流或降级的成本。因此，这个概念的工程落点非常明确：在接近极限之前，通过限流、熔断、弹性伸缩和优先级调度等手段，把负载控制在安全区内，确保即使在流量尖刺或局部资源耗尽的情况下，核心业务仍然可用。

2 3 分钟产业解释

在 AI 产业链中，“地质承载”位于 chain-server 层，也就是模型训练完成后被部署为在线推理服务的基础设施层。这个问题之所以在 2023–2025 年被反复讨论，有清晰的产业背景。一方面，生成式 AI 的批量上线使推理请求的并发量和单次算力消耗都远超传统微服务，突发流量（例如社交传播带来的瞬时涌入）很容易在几秒内把服务推到过载边缘。另一方面，推理服务的运行环境远比训练更不可控：用户输入长度波动、输出 token 数不确定、批处理策略动态变化，都使得承载极限不再是固定数值，而是一个随负载模式漂移的“地质剖面”。大量企业发现自己原先为 Web 服务设计的流量治理策略（静态阈值、简单排队）在面对 LLM 推理时频繁失效，轻则 P99 延迟膨胀数倍，重则整个推理管线被“液化”式破坏。产业层面的共识是，必须重新引入类似岩土工程的安全系数、增量加载测试和塑性变形监测等理念，把承载力的识别、保护、降级和恢复机制内建到 MLOps 流程中，而不是在故障发生后再去查日志。

3 技术原理

从岩土工程的角度看，地基极限承载力是指单位面积地基所能承受的最大荷载，超过该值会发生整体剪切破坏、冲剪破坏或局部破坏，伴随剧烈的沉降和侧向变形。将这一模型迁移到 AI 在线推理服务，可以得到三个对应层次：

• 弹性阶段（拟弹性区）：随着请求并发数增加，延迟近乎线性增长，错误率保持在极低水平（如 <0.1%），所有资源（GPU、CPU、内存带宽）的利用率同步上升但未触及瓶颈。这一阶段对应地基的压密阶段和局部塑性区尚未开展。
• 塑性开展区（屈服阶段）：达到某个 QPS 阈值之后，延迟开始以超线性斜率攀升，P99 延迟可能出现数倍跳变；部分请求由于排队溢出或显存不足而失败，错误率升至 0.5%–2%。若此时停止加压，系统仍能自行恢复到弹性阶段而不需要重启。这类似于地基中出现连续的塑性区但尚未形成贯穿滑动面，属于可用但不健康的过渡状态。
• 极限破坏（整体滑动）：再增加少许负载，延迟出现“悬崖式”跌落或超时风暴，错误率急剧突破 5%，健康检查失败、实例重启、依赖的模型服务出现连锁不可用，最终整个推理面不可服务。其动力学类似地基丧失稳定性的瞬间，滑动面完全贯通，沉降不可控。要恢复往往需要人工介入、流量切除和部分实例替换。

在工程实现中，刻画这种三个阶段的关键在于连续加压并监测延迟-错误-利用率的三维响应曲面。这不同于传统的“找到最大 QPS”思维，因为不同的请求混合（例如输入长度分布、batch size、KV 缓存命中率）会形成不同的“地基剖面”。因此，真正的“地质承载”不只一个数，而是一族条件极限：在给定 SLA（如 P99 < 500 ms，错误率 < 0.5%）和典型请求模式下，系统能安全承载的最大并发量。这也是岩土工程中区分“允许承载力”与“极限承载力”的思路——前者已经内置安全系数，是工程师实际用于决策的数值。

实现这套机制依赖一系列过载保护组件的协同：

• 限流器：令牌桶、漏桶、滑动窗口计数器等在入口处根据当前承载余量丢弃过量请求。与静态阈值不同，其限流阈值必须能随底层实例数量和实测承载极限动态调整。
• 熔断器：当下游依赖（例如 embedding 服务、数据库、外部 API）的承载耗尽时，暂停向其发送请求，给其恢复时间窗，避免上游持续加压使其彻底破坏。
• 优先级队列与隔离：将不同业务请求分到独立的承载域，每个域有各自的允许承载力。当总体资源紧张时，准入控制器按优先级执行降级，例如保留对话类请求而暂时拒绝批量摘要任务。
• 弹性伸缩控制器：基于实际承载余量而非单纯的 CPU/GPU 利用率进行扩缩容决策。当系统进入塑性开展区时，提前增加实例，在进入极限破坏之前恢复安全余量。
• 渐进式降级：在超载不可避免时，关闭非核心功能（例如停止记录详细日志、关闭复杂的后处理步骤），保留最小可用产品（MVP）服务集，使系统以受控的“沉降”方式运行，而非突然崩溃。

4 关键参数

刻画 AI 推理服务地质承载状态，通常需要关注以下参数：

• 极限吞吐量 Qₗᵤₗ (rps 或 tpm)：在定义好的 SLA 约束下（例如 P99 < 300 ms，错误率 < 0.5%），系统能持续承载的最大吞吐量，单位视服务类型可为每秒请求数或每分钟生成的 token 数。这一数值必须注明测试方式、请求模版、模型版本、实例规格、并发客户端数等边界条件。
• 安全承载系数 FOS (Factor of Safety)：类比岩土工程，安全系数 = Qₗᵤₗ / 实际运行目标 Q。根据业务关键等级，FOS 通常设定在 1.5–3.0。例如，支付级 AI 风控服务可能保持 FOS≥2.5，而非核心的文案润色服务可能容忍 FOS=1.2。需要注意，FOS 会随请求分布变化而漂移，需要周期性重测。
• P99/P95 延迟拐点压力 P_critical：延迟对吞吐量的二阶导数为零（即弹性-塑性转变点）对应的吞吐量。在实际工程中，常用“P99 延迟超过基线值 2 倍”时的吞吐量作为弹性阶段的结束点。
• 过载恢复时间 T_recover：从切除超量负载（例如限流使 QPS 回到安全区）到 P99 延迟和错误率回到 SLA 范围内所需的时间。T_recover 过长通常意味着队列积压严重或连接池未及时释放，需要优化。
• 资源瓶颈信号：GPU 显存占用率（>95% 时批处理可能频繁 OOM）、CPU 排队线程数、NIC 带宽利用率、KV 缓存命中率等。这些指标结合吞吐量曲线可用于判断当前处于哪一力学阶段。
• 请求成本畸形指数：定义为 (错误请求消耗的算力 / 总消耗算力)。在近极限区域，这一指标快速上升，因为大量资源被浪费在处理最终会失败或超时的请求上。该指数的激增本身就是承载即将进入破坏阶段的预警。

所有参数必须标注测量窗口、实例拓扑与请求合成方式，否则不可比。例如，在 2024 年某云厂商发布的公开基准中，Llama 2 70B 在 4×A100 实例上，输入 512 token、输出 128 token 条件下，安全承载约 12 rps（来源：Anyscale 博客 2023 年 9 月 Anyscale LLMPerf 测试，实际数值取决于框架和优化）。在不同框架、不同 batch 策略下，即使相同硬件该值也会发生数值变化。

5 技术路线

围绕地质承载的工程化，业界演进出三条主线，分别从静态探测、动态自适应、和数据驱动的预测控制切入。

• 路线一：基于阶梯加压的离线探测与静态配置。这是最早被采用的方法，在服务上线前用负载生成工具（如 Locust、Vegeta、JMeter 或自研发压器）施加步进式压力，绘制“吞吐量-延迟-错误率”曲线，并将测得的极限值硬编码到限流器、HPA 阈值和告警规则中。优点是简单、可重现、适合合规审计；缺点是无法适应线上请求分布漂移和算力退化（例如相邻任务干扰、GPU 降频）。
• 路线二：在线自适应限流与反馈控制。代表实现有 Netflix 的 Adaptive Concurrency Limit、阿里开源的 Sentinel 的自适应策略，以及基于 TCP Vegas 思想的 Little’s Law 限流。这一路线不再预设固定阈值，而通过实时监控延迟增长和排队深度，持续估计系统当前的承载余量：当测得的最小延迟开始持续上升，就认为已接近塑性开展区，主动降低准入速率；当延迟恢复低位，则逐步放宽。这些算法有效处理了慢变化负载，但在面对毫秒级突发尖峰时仍需要前置于限流的过载放大器（如基于 LIFO 队列的减载）。
• 路线三：预测性弹性承载与强化学习调度。随着模型推理链路复杂化（多模型串联、多级缓存、MoE 专家路由），单纯基于延迟的反馈控制开始力不从心。AWS、Google 等云厂商在 2023–2024 年发表的论文中探索了使用强化学习或时序预测模型，从历史请求轨迹中预判未来数秒的承载压力，并提前调度实例或执行软降级。例如，Google 在 NSDI ’23 上介绍的预测性资源弹性系统可以根据蒸馏出的请求成本模型，在负载实际到达之前完成容器预热。2024 年一些头部大模型厂商也披露，在企业级推理 API 背后已经部署了基于 Transformer 的负载预测器，配合秒级弹性可以做到 FOS 动态维持 2.0 以上而不浪费过多备灾算力。

三种路线并非互斥。实际高可用推理平台往往采用分层架构：底层保留基于固定阈值的硬限流作为保底；中层接入自适应算法实现无人工干预的过载保护；上层通过预测性扩缩容降低资源成本，同时增加抗尖峰能力。落地中最难的仍是对新型负载（例如长上下文、多模态提示）进行快速承载力建模，这需要将压测自动化与线上统计打通，形成持续更新的“数字孪生地基模型”。

6 上游

地质承载链的上游包括提供计算、网络、存储和推理运行时的基础设施层，这些要素直接决定承载力的物理上限。

• 算力硬件：GPU（NVIDIA H100、A100、L40S，以及 2024 年量产的 B200 等）和 AI 加速器（Google TPU v5、自研 ASIC）是推理承载最核心的物理基底。显存容量和带宽直接影响最大 batch size 和满足延迟约束的并发数。根据 NVIDIA 2024 年公布的性能数据，H100 在运行 Llama 2 70B 时相比 A100 可实现约 2 倍的推理吞吐量提升（来源：NVIDIA TensorRT-LLM 性能博客，2024 年 2 月）。国产 GPU 如华为昇腾 910B、寒武纪 MLU590 等也在逐步构建推理生态，但公开的标准化承载力基准数据有限。
• 服务器与互连网络：高并发推理对节点内 GPU 互联（NVLink、PCIe 5.0）及节点间低延迟网络（InfiniBand、RoCE v2）要求严苛。任何带宽瓶颈都会成为地基的“软弱下卧层”，使得极限破坏提前发生。2024 年多数云厂商推理实例已标配 100–200 Gbps 网卡，而大规模 MoE 模型推理还需借助高速 All-to-All 集合通信，带宽压力更为突出。
• 推理引擎与编译栈：NVIDIA TensorRT-LLM、vLLM、OpenLLM、Hugging Face TGI 等推理引擎通过算子融合、KV 缓存管理、连续批处理（continuous batching）和量化（FP8、INT4）显著改变系统的有效承载能力。相同的硬件条件，引擎选择和参数调优可使极限吞吐量差异达到 3–5 倍。因此，引擎版本迭代通常需要重新标定地质承载曲线。
• 云原生调度与编排：Kubernetes 及其之上的调度插件（如 Volcano、Koordinator）负责将推理 Pod 绑定到物理资源，其调度延迟和重调度策略直接影响过载恢复时间。2023–2024 年，阿里云、字节跳动等先后开源了针对推理场景的 GPU 共享与精细化调度组件，将物理 GPU 切分为多个承载域，提升资源利用率。

上游任何一个环节出现性能退化或供给瓶颈，都会直接压缩下游推理服务的安全承载空间，因此工程团队通常需要为关键依赖保留冗余或快速切换路径。

7 下游

地质承载能力最终输出给上层 AI 应用和业务，确保其在各种流量条件下可靠运行。

• 生成式 AI 应用：聊天助手、代码补全、文生图、视频生成等对实时性要求不一。以 ChatGPT 为代表的大规模 LLM 服务，下游是多租户共用的在线 API。如果承载设计不足，个别用户的超长上下文请求可能牵引大量 KV 缓存，将全局推入塑性区。因此，企业普遍在 API 网关上设置按用户、按 API Key 的独立承载域和配额，并实现基于自身业务优先级的降级路径。
• 嵌入式推荐与搜索：淘宝、抖音、美团等平台的核心推荐链路上，推理模型（CTR、CVR 预估、向量检索）必须满足极严苛的 P99 延迟（通常 <10 ms）。承载极限往往由 CPU-GPU 数据传输和特征构建环节决定，而不仅仅是矩阵计算。这些场景需要将一部分推理卸载到 CPU，用级联限流保证即使深度模型过载，浅层模型仍可兜底。
• 自动驾驶与工业视觉：车端或产线上的推理服务要求超高可靠性与确定性延迟。承载模型不仅包括峰值吞吐量，还包括最差情况执行时间（WCET）软硬实时约束。一旦承载能力突破临界值，导致推理帧丢失，可能造成安全事故或产线停摆，后果远超互联网应用。
• MaaS 与推理 API 经济：云厂商和模型厂商将推理能力封装为付费 API，其商业模式直接依赖于多租户承载的确定性。AWS Bedrock、阿里云灵积、微软 Azure OpenAI Service 等均承诺特定 SLA（如月可用性 99.95%），背后的地质承载工程就是核心支撑。承载能力不足将直接导致违约、赔偿和客户流失。
• 企业内部智能体与自动化：银行、保险等机构在私有云部署模型，需要服务大量内部用户的智能助理。其流量呈现明显的办公时间脉冲，承载设计必须兼顾潮汐效应，避免在上午高峰因承载余量不足而波及核心交易系统。

8 受益公司

以公开信息为基础，以下机构在 AI 推理承载的某一环节拥有明确业务或产品布局，而非投资建议：

• 云基础设施厂商：Amazon Web Services（SageMaker 推理端点、Bedrock）、Microsoft Azure（Azure OpenAI Service、Azure ML Managed Endpoints）、Google Cloud（Vertex AI Prediction）、阿里云（PAI-EAS、灵积）、华为云（ModelArts 推理服务）等，通过提供弹性推理、过载保护、负载均衡等内置能力，直接受益于企业级承载需求。
• GPU 与 AI 芯片公司：NVIDIA 的 TensorRT-LLM 和 Triton Inference Server 在承载优化生态中占据核心地位；AMD、Intel（Gaudi 系列）正加速追赶；中国厂商如华为昇腾、寒武纪、海光信息推理解决方案从硬件到推理库提供承载调优工具，在信创和国产化市场加速渗透。
• 推理引擎与 DevOps 工具链：开源社区和商业实体如 vLLM（UC Berkeley 发起）、Hugging Face（TGI）、BentoML、Seldon Core、KServe 等，为承载治理提供了关键软件层。Datadog、Dynatrace、Grafana Labs 则在监控与可观测性侧，为延迟、错误率和利用率等承载指示器提供仪表板和告警。
• 高流量互联网平台：字节跳动、阿里巴巴、Meta、Google 等公司自研的微服务治理中间件（如字节的 Kitex、阿里的 Sentinel）均针对 AI 推理承载场景增加了自适应限流和容灾策略，其内部实践文档和开源项目对行业影响巨大。
• 专业负载测试与混沌工程公司：如 Gremlin、Harness、Akamai（通过性能测试服务），辅助企业发现承载薄弱点，但目前为止，针对 LLM 推理的专用负载生成平台尚在早期，公开资料未见单一领军者。

9 市场规模

地质承载本身不是一个独立的市场类别，其支出隐含在 AI 推理基础设施、云服务和可观测性市场中。以下为现有第三方研究的规模判断，以说明相关活动的经济量级：

• AI 推理计算支出：根据 IDC《Worldwide AI and Generative AI Spending Guide》（2024 年 2 月更新），2023 年全球 AI 基础设施总支出（服务器、存储、网络）预计为 344 亿美元，其中推理所占比例未单独披露，但多家分析师（例如 SemiAnalysis 在 2023 年 7 月的报告）估计推理耗用已超过训练，且随着生成式 AI 应用的规模化，推理占比将越来越高。到 2027 年，AI 推理可能占据 AI 服务器总保有量的 60% 以上（来源：Dell’Oro Group 2024 年 1 月报告）。承载能力的优化直接影响这部分支出的投入效率。
• 云 AI 服务市场：Gartner 在 2024 年 4 月发布的数据显示，2023 年全球云 AI 服务（包括 AI 平台即服务和 AI 基础架构即服务）市场规模约 532 亿美元，且预计 2024 年增长超过 30%。其中托管推理端点和相关流量治理是这些云服务的基础组件，因此承载工程是这些营收的质量基石。
• 可观测性与性能测试：IDC 预测 2024 年全球 IT 运营管理软件市场约 270 亿美元（2023 年为 253 亿美元），承载监测所需的实时延迟、流量轨迹和错误预算管理推高了相关工具的需求，但具体由 AI 推理承载驱动的增量尚无独立拆分，公开资料未见。

整体上，与地质承载直接关联的投入多嵌入在云账单、推理平台许可和内部平台团队的人力成本中，尚未出现挂牌的“承载力即服务”产品线。但在 AI 服务可靠性成为付费客户核心关切的趋势下，承载能力正从隐性工程指标过渡为显性竞争力。

10 玩家对比

以在线 GPU 推理服务为剖面，对比主流技术栈在承载控制方面的能力侧重。以下评估基于 2024 年第一季度的公开发布和社区文档，部分维度因厂商未披露完整性能数据仅作定性比较。

整体看，NVIDIA Triton 在模型侧性能优化上业界领先，但外围承载闭环依赖用户自行集成；AWS 和阿里云等平台通过托管服务简化了弹性伸缩，但在细粒度的请求级过载保护方面仍需要借助 Web 级网关方案补强；vLLM 等开源引擎在核心吞吐量上进化极快，但在生产级承载治理（优先级、计费域隔离、开箱即用的熔断降级）方面还在完善中。企业在选型时通常组合使用：以云平台或自建 Kubernetes 作为底座，嵌入高性能推理引擎，并在前面挂载自研或开源的 API 网关实现完整的承载力控制平面。

11 风险

即使花费精力建立地质承载模型，生产环境中仍存在若干风险可能导致模型失灵或带来额外成本：

• 模型与请求分布漂移：推理模型频繁更新（每周甚至每日上线新 LoRA 权重或全量模型）会使先前标定的承载力曲线快速过时。若没有自动化回测流水线，工程师可能在一个已经变软的地基上沿用旧的安全 QPS 限流，不知不觉中被引入塑性区。同样，用户输入分布改变（例如 prompt 长度整体变长）也会改变承载极限。
• 多租户噪声与扰邻效应：共享 GPU 节点上，一个租户的突发长序列推理可能占用大量显存带宽，导致邻近推理实例的 P99 延迟飙升，产生类似地基局部掏空的效果。对于 GPU 共享调度能力不足的平台，这种噪声几乎无法根除，只能通过高安全系数缓解。
• 保护机制本身的级联故障：自适应限流器或中央健康检查系统若自身因承载过高而响应迟钝，可能向所有节点发出错误限流指令，导致整个推理面人为被“截断”。2023 年某大型社交平台曾因限流控制面故障，在线服务被意外大幅限流，造成大范围可用性下降（来源：公开事后复盘博客）。
• 成本与冗余的平衡：为了实现 FOS≥2.0，可能需要持有相当数量的常备闲置算力，直接推高成本。尤其在使用按需 GPU 实例的场景，过度冗余可能使推理毛利率大幅承压。一些团队因此妥协为 FOS=1.1–1.3，但承受了更高的故障风险，一旦流量超过预警线，手动扩容远追不上破坏速度。
• 可观测性盲区：模型推理的延迟并不总是平滑上升，有时出现“断裂”现象——在某个阈值突然发生 KV 缓存重新分配风暴，导致可见的预警信号不足 1 秒。若采样频率过低（如每 15 秒），根本捕捉不到这类征兆。因此，承载监控要求秒级或亚秒级指标采集，对指标系统自身也构成压力。

12 误读纠偏

随着“地质承载”比喻在工程博客和架构评审中流行，一些误解也逐渐蔓延，有必要澄清：

• “承载极限就是最大 QPS”：这是最常见的误读。传统最大 QPS 往往在允许高错误率、无延迟约束的条件下测得，而地质承载是在 SLA 约束下的安全吞吐量。即使一个服务能硬扛 200 rps，但在 150 rps 时 P99 延迟已超标、错误率上升，则其允许承载力可能仅 120 rps。岩土工程中区分极限承载力与允许承载力，正是这个逻辑。
• “过载保护就是加限流”：只加限流而不理解系统的真实承载曲线，往往造成过度保守（浪费资源）或保护不足（将阈值设在塑性区深处）。有效的承载治理必须建立在持续的压力刻画和动态反馈之上，限流只是执行器，不是策略本身。
• “弹性伸缩万能”：弹性伸缩可以增加实例总量，但扩容延时（通常 30 秒至数分钟）在面对秒级尖峰时完全是滞后的。必须先有限流和减载机制稳住当下，伸缩才能在日后提升承载力。地基增补桩基同样需要时间，紧急情况下必须先减载。
• “只要 GPU 利用率低，系统就安全”：利用率是均值，无法反映排队和内存碎片等非线性效应。很多破坏始于 GPU 显存瞬间跨过临界点导致的批量 OOM，而非算力耗尽。需要用延迟和错误率等直接表征地基稳定性的指标作为主要判据。
• “一个大平台一套承载配置可以通吃所有模型”：不同模型架构（Llama、Mistral、Falcon、MoE）的资源消耗模式和并发特性天差地别，甚至同一模型的不同量化版本（FP16 vs INT4）也会得到完全不同的承载剖面。承载配置必须与模型-硬件组合绑定，并随版本和配置同步更新。

13 最新事件

2024 年以来，AI 推理承载领域出现数起引人注意的事件和发布，反映出产业的快速演进：

• 某头部大模型厂商全球服务中断：2024 年 6 月，某知名大模型服务商经历半小时左右的全球范围不可用，事后披露系一次看似普通的配置变更引发了请求调度层过载，继而拖垮了核心推理集群的后端压力，形成典型的级联地质破坏。该事件推动行业加速部署混沌工程和变更期间的承载余量检查。
• NVIDIA NIM 发布：2024 年 3 月 GTC 大会上，NVIDIA 推出 NIM（NVIDIA Inference Microservices），将模型优化、服务部署和承载管理打包为容器化微服务，内置动态批处理和 KV 缓存优化，意图将承载最佳实践标准化。此举被业界视为承载工程从“手工作坊”走向“制品化”的重要一步。
• 开源推理栈在高承载下迅速成熟：2024 年 vLLM 连续发布 0.4、0.5 版本，强化了前缀缓存和推测解码支持，使在某公开测试中于相同硬件上将 Llama 3 的临界吞吐量再提升约 30%（来源：vLLM 官方博客，2024 年 7 月）。同时，阿里开源的 SGLang 和快手开源的 CPM-Bee 推理运行时也展示了在承载优化上的新思路，如结构化生成降低解码开销。
• 企业级承载监控产品出现：2024 年多个可观测性厂商开始提供针对 LLM 推理的预置看板，例如 Datadog 推出 LLM Observability，Honeycomb 推出基于 OpenTelemetry 的生成式 AI 追踪方案，使延迟、token 消耗和错误预算燃尽等承载指标变得直接可用。

14 跟踪指标

持续追踪 AI 推理服务的地质承载状态，建议建立一组分层指标，并明确口径和采集周期。

• 实时承载利用率 (CBU)：当前实际吞吐量 / 实测安全承载上限。安全承载上限必须以过去 24 小时内最新的压测结果或自适应算法估计值为基础，而非数月前的固定值。当 CBU > 0.8，启动预备扩容或提前限流。
• P99 延迟与斜率：监控 P99 延迟的斜率（即延迟对吞吐量的一阶导数）。当延迟随时间或吞吐量的上升斜率突然变化（例如从线性变成超线性），意味着已进入塑性区。建议采样周期 ≤ 5 秒。
• 限流/熔断触发频次与时长：记录每小时限流器激活的次数和每次持续秒数。如果触发频次上升但流量未增，可能是承载能力本身退化（例如内存碎片、KV 缓存效率下降），需要排查根本原因。
• KV 缓存命中率与再计算比例：低命中率不仅增加首次 token 时间，还会快速侵蚀承载余量，成为破坏的先导指标。在长上下文服务中尤其值得持续关注。
• 实例启动与冷却延迟：测量从弹性伸缩指令发出到实例正式服务流量的时间。此值越大，对突发破坏的缓冲时间越短，需相应提高安全系数或预置缓冲实例。
• 过载恢复时长：如上文定义，跟踪每次限流解除后系统恢复到目标延迟和错误率的时间。若该时长趋势性增加，表明积压处理或内存回收机制可能存在问题。

建议将这些指标汇集到统一的服务等级目标（SLO）框架中，以错误预算消耗速度作为承载治理的最终北极星。例如：“每月允许推理错误预算为 30 分钟，当 1 小时内燃尽 10% 时即触发承载扩容工单。”

15 信源

• NVIDIA, “TensorRT-LLM Performance Benchmarks,” published February 2024. （https://developer.nvidia.com/blog/）
• Anyscale, “LLMPerf: Benchmarking Large Language Model Inference Performance,” September 2023. （https://www.anyscale.com/blog/）
• AWS, “Best practices for deploying real-time models using SageMaker,” updated 2024. （https://docs.aws.amazon.com/sagemaker/latest/dg/）
• Google Research, “Predictive Resource Elasticity for ML Inference,” NSDI ’23. （https://www.usenix.org/conference/nsdi23/）
• IDC, “Worldwide AI and Generative AI Spending Guide,” February 2024 update. (需订阅)
• Gartner, “Market Share: IT Services, Worldwide, 2023,” April 2024.
• Dell’Oro Group, “AI Servers for Accelerated Computing Report,” January 2024. （https://www.delloro.com/）
• Alibaba Sentinel 项目文档，自适应过载保护章节，截至 2024 年 7 月。（https://sentinelguard.io/）
• vLLM 项目发布说明，v0.4.0–v0.5.0，2024 年 4–7 月。（https://blog.vllm.ai/）
• Datadog, “Announcing LLM Observability,” June 2024. （https://www.datadoghq.com/）
• 相关公司公开复盘、技术博客及行业会议演讲，已在正文中按事件注明。