让系统不倒 · 可靠性 · 可观测性 · 存储 · 成本经济学

0. 先接受一个反直觉的事实:在这个规模上,故障是常态

先给你一个数字,它会重塑你对「可靠」这个词的理解。Meta 训练 Llama 3 405B 时用了 16384 张 H100,在 54 天的训练窗口里,系统一共被打断了 466 次,其中 419 次是意料之外的故障,平均下来大约每 3 小时就崩一次。而其中将近六成的故障来自 GPU 本身(GPU 故障加上 HBM 显存出错),因为一张 700 瓦的卡长期满负荷运转,本就是整个系统里最脆弱的一环。

这个数字背后有一条能自己推的账,值得你亲手算一遍。假设单张 GPU 平均每 5 万个 GPU 小时才坏一次,这听起来已经相当可靠了。但当你把 16384 张卡并在一起跑,期望的故障间隔就变成 5 万除以 16384,约等于 3 小时,正好对上 Meta 的实测。再往上推,一个 10 万张卡的集群(比如 xAI 的 Colossus 那个量级),故障间隔会掉到大约每半小时一次。这条账揭示的事实很硬:即使每一张卡都很可靠,把足够多张并在一起,整个集群的平均无故障时间就会坍缩到以小时甚至分钟计。

所以在这个规模上,「可靠」的含义彻底变了。它不再是「想办法不出故障」,而是「假设系统里随时有东西是坏的,照样把服务稳稳交付出去」。这一站的第一节就讲这件事怎么做到;接下来的可观测性、存储、成本,则是支撑这个目标的另外三根柱子。

1. 在故障是常态的规模上,让系统不倒

要在故障常态下负责一个系统,第一步是把「可靠」从一句口号变成可度量的数字。这套语言由三个层层递进的词组成。SLI(service level indicator,服务等级指标)是你实际测量的那个数,通常站在用户的角度,比如成功率、延迟、错误率;延迟这种指标必须看百分位数(p95、p99)而不是平均值,因为一个飞快返回的错误并不是好响应。SLO(service level objective,服务等级目标)是你给自己定的内部目标,比如「30 天内 99.9% 的请求成功」。SLA(service level agreement,服务等级协议)则是你对客户的法律承诺,违约要赔钱。

这套语言里最妙的一个概念,叫错误预算(error budget),它等于 1 减去 SLO。一个 99.9% 的 SLO,意味着你每个月有 0.1% 的预算可以「花」在宕机上,换算过来正好是约 43.2 分钟。把它当成一笔预算而不是一个失败计数,瞬间就把工程团队那个永恒的矛盾(求稳的运维 vs 求快的开发)调和了:预算还有,就放手快跑、大胆上线;预算花光了,就冻结新功能、回去加固。报警也不再盯着指标的瞬时抖动,而是盯着错误预算的「燃烧速度」,这样的报警才真正可行动。

大规模可靠性是一堵墙:在足够大的规模上,故障是系统的稳态,而不是例外。你无法靠「预防」绕过它,只能假设系统持续地、部分地在坏,然后据此设计。

有了目标,接下来是怎么扛住故障。这里有一整套久经考验的容错招式,我挑几个最能说明问题的。健康检查把「活着」和「能服务」分开:Kubernetes 的存活探针(liveness)失败就重启容器,就绪探针(readiness)失败则只是停止给它派流量、但不杀它,这个区分让滚动升级能安全地一边扩新版本、一边缩旧版本,只在新副本通过就绪探针后才推进。熔断器(circuit breaker)在一个依赖连续出错时「跳闸」,快速失败而不是死等,免得一个挂掉的下游把调用方的线程全耗光、引发雪崩。还有优雅降级(坏了就返回缓存或默认值,而不是直接报错)和负载卸除(逼近过载时主动丢弃低优先级请求,保住高价值流量)。

但有一招特别能体现「大规模」的思维,值得单独讲:请求对冲(request hedging)。它出自 Google 那篇经典论文《The Tail at Scale》,核心洞察是,在一个大扇出的系统里,单台机器偶尔的慢会被放大成几乎每个请求都慢,所以你要「用一堆不那么可预测的部件,搭出一个可预测的整体」。对冲的做法是:如果一个请求超过了比如 p95 的预期延迟还没回来,就向另一个副本再发一个一模一样的,谁先回用谁。论文里的实测很惊人,在一个跨 100 台服务器的场景里,延迟 10 毫秒后再对冲,把 p99.9 延迟从 1800 毫秒压到了 74 毫秒,而代价只是多发了 2% 的请求。这正是你对付 decode 阶段长尾延迟的利器。

最后值得一提的是,这套设计在实践里真的奏效。Meta 那个每 3 小时崩一次的训练,靠的是自动化恢复:419 次意外故障里,只有 3 次需要人工显著介入,整个训练保持了超过 90% 的有效时间。可靠性不是靠运气不出事,而是靠工程把「出事」变成系统能自己咽下去的日常。

2. 看不见就修不动:可观测性

系统会出问题,而你修问题的前提是先看得见它。可观测性传统上由三根支柱组成,它们互补而非冗余:指标(metrics)是廉价的数值时间序列,告诉你「有地方不对」,但说不清在哪;日志(logs)是带时间戳的事件记录,是某次具体故障的现场证据;链路追踪(traces)跟着一个请求穿过多个服务,告诉你延迟或失败到底发生在调用链的哪一环。一句话记住它们的分工:指标报警说延迟尖了,日志告诉你某处数据库超时了,追踪显示故障其实起于上游某个服务间的交接。

但这一节真正的重点,是 LLM serving 的可观测性有它特有的难,这份难恰恰来自你前几章学的东西。难点一是每个请求的开销天差地别:同一个接口,一个输出 50 token 的请求和一个输出 5000 token 的请求,延迟和成本能差上百倍,所以平均值在这里毫无意义,你只能活在百分位数的世界里。难点二是一次请求的延迟其实是两段截然不同的负载(compute-bound 的 prefill 加 memory-bound 的 decode),你必须分开观测,否则根本没法推理。所以该盯的信号也就和普通 web 服务不同:首字延迟 TTFT、字间延迟 TBT、吞吐、排队深度、运行中的批大小,以及最关键的 KV cache 利用率和前缀缓存命中率(这些 vLLM 都内建暴露成指标)。

可观测性设计得好,会带来一个漂亮的回报,它让上一章那张 roofline 图直接显形在你的仪表盘上。vLLM 自己的文档就给了一张瓶颈定位表,本质就是 roofline 的现场版:如果排队深度在涨、而 KV cache 利用率很高,说明你卡在显存上(memory-bound),解法是缩短最大上下文长度,或者把 KV cache 降成 FP8(这正是上一章的招);如果排队在涨、但 KV cache 利用率很低,说明你卡在算力上(compute-bound),解法是加卡、加副本。你看,判断瓶颈的 roofline 心智(Ch8)加上设计良好的可观测性,合起来就让你能读懂一个活的系统正卡在哪、该往哪动手。这就是为什么可观测性是「设计」出来的,而不是事后随便接个仪表盘。

3. 数据洪流的地基:存储

前面讲的可靠性引出了一个具体的工程需求:既然故障随时发生,训练就必须频繁存档(checkpoint),崩了能快速从最近的存档恢复。DeepSeek 训练 V3 时,每隔约 5 分钟就把参数和优化器状态异步存一次,写入速度高达每节点 10 GiB/s 以上,一次存档几秒就完成,靠的就是这套机制做到了整个训练零回滚。但你算一下:几千张卡的模型,一个 checkpoint 就是 TB 级,每 5 分钟存一次,这个 I/O 洪流靠普通的网络存储根本扛不住。这就是存储成为一堵墙的地方。

DeepSeek 开源的 3FS(Fire-Flyer 文件系统)就是为这堵墙专门co-design的答案。它把上千块 NVMe 固态盘和上百个存储节点的带宽聚合成一个共享存储,在一个 180 节点的集群上跑出了约 6.6 TiB/s 的聚合读吞吐。它的几个设计决定都很能教人:用 CRAQ(带分摊查询的链式复制)拿到强一致性,写要走完整条复制链(所以写延迟受限于链上最慢的节点),但读可以打到任意副本,把读吞吐拉满;元数据服务做成无状态的,文件系统语义架在一个事务性键值库(FoundationDB)上,于是元数据服务能随意重启升级、客户端自动故障转移。这一层一致性直觉(读多写少、强一致但写受最慢节点限)正是你该有的认识,至于 Paxos 那套共识证明,不在本路书范围。

存储是另一堵墙:I/O 带宽墙。当数据集要被上万张卡随机访问、checkpoint 是每几分钟存一次的 TB 级洪流、KV cache 大到 DRAM 装不下,存储带宽就成了绑定约束,逼你 co-design 一套围着 RDMA + NVMe 转的文件系统。

而 3FS 最让人眼睛一亮的,是它把这套存储能力接回了 serving。它明确把「KV cache 作为存储」列为一大用途:KV cache 在第四章你已经知道它主宰显存、卡住并发,而 3FS 提供了一个比 DRAM 便宜得多、容量大得多的去处,单客户端的 KVCache 读吞吐能到 40 GiB/s。把它想成 KV cache 的一层内存层级:最热的 KV 留在 GPU 显存,稍温的(比如可复用的长前缀)卸载到 3FS 这种 SSD 支撑的快存储,只在未命中时才重算。这等于在不加显存的前提下,扩大了有效 KV 容量、抬高了前缀缓存命中率,和上一章那个 FP8 KV cache 是一对互补的招:一个让每份 KV 更小,一个给 KV 更多地方放。

4. 算得清账:成本经济学

负责一个生产系统,最后绕不开钱。先看硬件这头:一张 H100 租多少钱,2026 年的现实比你以为的复杂。超大云厂商按需价大约每卡每小时 3.4 到 7.5 美元,专做 GPU 的新云便宜些、约 2 到 2.65 美元。但要特别记住一个反直觉的当下事实:GPU 价格并不是一路下跌的。2026 年初闹了一轮供给紧张,一年期合约价从 2025 年 10 月的低点每小时约 1.7 美元,反弹到 2026 年 3 月的约 2.35 美元,涨了四成,按需产能更是各型号全面售罄。所以此刻真正的约束往往不是单价,而是你抢不抢得到卡,别想当然地说「GPU 只会越来越便宜」。

接下来是这一章最该让你记住的一笔账,它又是上一章 roofline 的回响,这次直接印在了账单上。几乎所有大模型 API,输出 token 的价格都是输入 token 的 5 到 6 倍(比如有的旗舰模型输入每百万 token 5 美元、输出 25 美元)。这个倍数跨厂商、跨模型、跨硬件惊人地一致,这本身就在告诉你:它是物理,不是利润。为什么?输入 token 走的是 prefill,一次并行把整段 prompt 算完,权重搬一次给所有 token 共用,compute-bound,所以便宜;输出 token 走的是 decode,逐个生成、每个都要把权重和 KV 重新搬一遍,memory-bound,所以贵。最精妙的一点是:单看浮点运算量,处理「100 输入 + 生成 900 输出」和「900 输入 + 生成 100 输出」几乎一样多,所以那个输出溢价根本不是算力的溢价,而是显存搬运的溢价。上一章那句「decode 是 memory-bound」,到这里就变成了你账单上实打实的数字。

这笔账直接给你两条设计直觉。第一,长输入短输出的活(比如 RAG:几万 token 上下文换两百 token 答案)很便宜,短输入长输出的活(比如让模型写一大段代码,或者推理模型那一长串思考)很贵,因为思考 token 也是按输出价计费的。第二,也是省钱的头号杠杆:prompt caching(提示缓存)。两大厂商都对命中缓存的输入 token 大幅打折,缓存读通常只要正常输入价的十分之一,等于九折优惠的反面、是打到一折。做法是把稳定不变的前缀(系统提示、工具定义、检索来的文档、对话历史)放在最前面、让它能被缓存复用,这正是上一节那个前缀缓存命中率信号在账单上的意义。对那些反复发送同一大段前缀的 agent 和多轮对话,这是决定性的成本杠杆。

最后把成本放到更大的尺度上看一眼,给下一站的外推埋个头。Anthropic 公开过一组数字:agent 大约比普通对话多烧 4 倍 token,而多 agent 系统大约多烧 15 倍,因为每个子 agent 都有自己的上下文窗口。这解释了为什么 agent 类服务这么贵,也是为什么他们明确划线:多 agent 只在任务价值高过 token 成本时才值得上。再往大看,固定能力下的推理价格大约每年降一个数量级(GPT-3 级别的能力三年里便宜了上千倍),但有个要命的悖论:单 token 越来越便宜,总账单却常常不降反升,因为模型更大了、推理模型一次要烧上百倍的思考 token。每加仑跑得更远,却用了五十倍的油。这个「单价降、总量涨」的张力,本身就是一道墙与轴的题目,我们留到收官章 Ch12 去外推。

综合 · 你现在能对一个生产系统负责了

回头收一下这一章。你先接受了一个反直觉的事实:在成千上万张卡的规模上,故障是常态而非例外(Llama 3 那 16384 张卡每 3 小时崩一次,一条简单的账就能推出来)。于是「可靠」的含义变成了「假设随时有东西坏着,照样稳稳服务」,你学了 SLO/SLI/错误预算这套度量语言,和健康检查、熔断、降级、负载卸除、请求对冲这套容错招式。接着你看清了可观测性为什么要「设计」而不是事后接仪表盘:LLM serving 的信号特殊(TTFT/TBT/KV 利用率),而设计良好的可观测性能让 roofline 直接显形在仪表盘上,告诉你系统此刻卡在显存还是算力。然后你理解了存储为什么是一堵墙,以及 3FS 怎么用 6.6 TiB/s 的聚合带宽同时扛住 checkpoint 洪流和把 KV cache 接成一层便宜的内存层级。最后你算清了那笔最重要的账:输出 token 贵过输入 5 到 6 倍,正是「decode 是 memory-bound」印在账单上的样子,而 prompt caching 是省钱的头号杠杆。

把这四件事合起来,你手里就有了对一个生产 AI serving 系统负责所需要的判断力。当一个系统出问题或烧钱太多,你不再手足无措,而是会问:我的错误预算还剩多少、报警盯的是不是燃烧速度?仪表盘告诉我卡在显存还是算力?KV cache 是不是该往存储里卸一层?这笔账里,贵的到底是 prefill 还是 decode,前缀缓存命中率上得去吗?能答出这些,你就从一个会调系统的人,变成了一个能对生产系统负责的人。

学完这一章,你已经能用 SLO/SLI 把可靠性目标量化、能设计一个 serving 系统的可观测性并据此定位瓶颈、能解释 3FS 这类存储基础设施在扛什么、也能算清一个 LLM 服务的成本结构和省钱杠杆。下一章我们把这一整套运维能力,推向 2026 年一个更新、也更难的对象。前面你一直在把「一个模型」服务到规模,但今天的生产里,跑的常常是成千上万个 agent 会话。下一章 Ch11 就讲怎么把 agent 当成一个生产服务,运营在规模上,这是 #2 系统设计和 #8 Agent 工程的交叉点。

本章关键术语

本章引入的 canonical 术语,点进术语表看更完整的解释:

• SLO / SLI / 错误预算 把可靠性变成可度量目标的一套语言:SLI 是你测的数(成功率/延迟,看百分位)、SLO 是内部目标(如 99.9% = 每月约 43.2 分钟宕机预算)、SLA 是对客户的法律承诺。错误预算 = 1 − SLO,当成可花的预算(还有就快跑、花光就冻结),报警盯燃烧速度
• 请求对冲 request hedging 对付长尾延迟:请求超过 p95 还没回,就向另一副本再发一个、谁先回用谁。出自《The Tail at Scale》—— 跨 100 台延迟 10ms 后对冲,把 p99.9 从 1800ms 压到 74ms,只多发 2% 请求
• 3FS · KVCache-as-storage DeepSeek 开源的分布式文件系统:聚合上千 NVMe + 上百节点带宽到约 6.6 TiB/s,CRAQ 强一致(写受最慢节点限、读打任意副本),无状态元数据架在 FoundationDB 上。把 KV cache 卸到它(单客户端 40 GiB/s)= 给 KV 加一层比 DRAM 便宜的内存层级
• cost-to-serve 成本经济学 服务一个模型的成本结构:输出 token 贵过输入 5–6 倍(decode memory-bound 印在账单上,FLOPs 近似相等、溢价在显存搬运);prompt caching 是头号杠杆(缓存读约一折);agent 4× / 多 agent 15× token

参考文献

Mode A · 引用出处(正文 inline,集中列在此)

• Google SRE Book · SLOs / Monitoring / Handling Overload(Google)· SLI/SLO/SLA、错误预算、四个黄金信号(延迟/流量/错误/饱和度)、负载卸除的权威出处
• The Tail at Scale(Dean & Barroso, CACM 2013)· 请求对冲/绑定请求:用不可预测的部件搭出可预测的整体;p99.9 1800ms→74ms / +2% 请求
• Llama 3 论文 · 训练可靠性(Meta, 2024)· 16384 张 H100、54 天 419 次意外故障(约每 3 小时)、58.7% GPU 相关、>90% 有效时间(仅 3 次人工介入)
• Hardware Failures Won't Limit AI Scaling(Epoch AI)· 由 Llama 3 数据推出的 ~1/50,000 GPU-hr 失败率,本章 MTBF 坍缩账的来源
• vLLM Metrics 设计文档 + Triage vLLM performance(vLLM / Red Hat)· serving 信号(TTFT/TBT/排队/KV 利用率)+「排队↑×KV 高/低 → 显存/算力受限」的瓶颈定位表
• deepseek-ai/3FS + Fire-Flyer AI-HPC(DeepSeek)· 6.6 TiB/s / 180 节点、CRAQ、FoundationDB 元数据、KVCache-as-storage(40 GiB/s/客户端);DeepSeek-V3 第 3.5 节 每 5 分钟 checkpoint
• Anthropic 定价 · prompt caching + OpenAI 定价(as of 2026-06)· 输出:输入 ≈ 5–6×;缓存读约一折
• How we built our multi-agent research system(Anthropic)· agent 约 4× / 多 agent 约 15× token;「任务价值 > token 成本才上多 agent」
• OpenAI · SRE Supercomputing + SWE Reliability(JD · 收录于 research/system-design/job-postings/openai.md)· K8s 集群、「重启时间从小时压到分钟」、SLO/SLI、负载/混沌测试、24×7 on-call

深 dive 资源(可选 · 想往下走再看)

• LLMflation(a16z)· 固定能力下推理价格约每年 10×、GPT-3 级三年 1000× 的趋势(配 Ch12 外推)
• The Origin of Chaos Monkey(Gremlin)· Netflix 混沌工程的由来:「避免失败的最好办法是不断失败」

说明:本章没有 Mode B 视频站 —— 可靠性/SRE 与成本经济学这类主题,网上虽有零散讲座,但缺少贴合「AI serving」语境的合格系统化长视频;Google SRE Book、会议论文与厂商文档在上方按需列出,由 Mode A 原创讲解扛主线。

下一章

下一章 Ch11 是 #2 系统设计与 #8 Agent 工程的交叉点。前面你一直在把「一个模型」服务到规模,但 2026 年的生产里,跑的常常是成千上万个 agent 会话 —— 它们各自有状态、活很久、还会突然爆发地调用工具。#8 已经教你怎么工程化「单个」harness,这一章教你把 agent 当成一个生产服务运营在规模上:万级并发会话的编排 backplane、sandbox-as-a-fleet(几万个隔离环境的调度与回收)、长时 agent 的 durable execution、多租户网关,以及这些 agent 背后那层 model serving 怎么接回你前面学的主脊。这是你把整套系统设计能力,用到当下最前沿的那个对象上。