5.1 高并发大模型服务参考架构与容量规划

5.1 高并发大模型服务参考架构与容量规划

前四章把分层和原理讲透了，但很多工程师反馈：原理看懂了，真到要落地时，还是不知道"我支撑 50 万 QPS 到底要多少台机器、怎么配比"。这一节把前四章的四层抽象落成一张可部署的参考架构，并给出从 QPS 反推资源的容量规划方法——让你面对"支撑 N 万 QPS 需要多少资源"这类问题时，有公式可依，而不是拍脑袋。

我自己做过多次容量规划，最深的体会是：容量规划的本质是"用结构化的算式，替代直觉和拍脑袋"。没有公式的规划，要么过度预留（浪费成本），要么预留不足（大促崩盘），很难刚好。有了公式，至少能算出一个基线，再根据业务特征做调整。

参考架构全景

把前四章的四层抽象细化成可部署的组件，就是这张参考架构图：

接入层是 L4/L7/AGW 三件套，负责流量入口。编排层 ORC 是大脑，做多模型路由和 Agent 编排。推理层分三个池——旗舰主集群、小模型分流集群、Agent 独立池，这是 4.1 和 4.2 节的设计。状态层包含上下文压缩和语义缓存，是降本杠杆。每个组件都对应前文某一章的详细论述，这里只是把它们组装到一起。

容量规划方法

容量规划的核心是从业务 QPS 反推各层资源。我从最贵的推理层开始算，因为它是成本大头，算清楚了其它层就好办。

第一步：推理层（最贵，先算）

推理层的基础公式是：

所需 GPU 数 = 业务峰值QPS × 单请求平均tokens / (单GPU tokens/s × 利用率)
​

举个具体例子。假设业务峰值 100 万 QPS，单请求平均生成 200 token，单张 A100 在该模型上能提供 2000 tokens/s 的吞吐，利用率 70%：

GPU 数 = 1000000 × 200 / (2000 × 0.7) ≈ 143000 张
​

这个数字显然不现实——14 万张 A100 的成本是天文数字。但这个"不现实"恰恰揭示了为什么需要缓存和分流：

• 语义缓存命中 25%，推理负载直接降 25%；
• 小模型分流 60% 的请求到便宜得多的集群，旗舰集群的负载再降 60%；
• 综合后，旗舰集群的实际负载只有原来的 0.75 × 0.4 = 30%，约 43000 张。

（实际容量还要考虑冗余、峰值系数、故障切换等，这里只是演示方法论，数字仅供说明。）

这个推导过程的价值在于：它让你清楚地看到每个优化手段的杠杆有多大。语义缓存把 14 万降到 10.7 万，小模型分流再把 10.7 万降到 4.3 万——每一步的节省都明明白白。没有这个推导，你不会知道该往哪个方向使劲。

我再展开几个估算的实战细节。第一，"单请求平均 tokens"这个数要从生产日志里取实测值，不能拍——它受业务类型影响极大（闲聊类可能 50 token，代码生成类可能 800 token）。取值要用 p50 还是 p75？我建议用 p75，因为容量规划要覆盖大部分请求而不是只覆盖最短的，但用 p99 又会过度预留。第二，"单 GPU tokens/s"要从你自己的 benchmark 取，不要用厂商宣传值——vLLM 在真实负载下的吞吐通常是厂商值的 60%-70%（厂商值是在理想 batch、特定 prompt 长度下测的）。第三，"利用率"是个常被高估的值，长期稳定运行下 70% 已经是上限（要留余量给突发、维护、故障切换），新手常按 90% 算然后大促崩盘。

第二步：接入层（网关）

网关相对便宜（CPU/内存机器），通常按并发连接数规划：

网关实例数 = 并发连接数 / 单实例最大并发连接
​

一个优化得好的网关实例能扛 10 万到 50 万并发连接（取决于配置和机器规格），百万并发连接大约需要几台到十几台网关。要留 1.5 倍余量应对峰值和故障切换。接入层在总成本里占比很小（5% 到 10%），不需要过度优化，重点是稳定性。

举个完整推演。假设百万并发长连接，单台网关（16 核 32G，Envoy 优化后）能稳定扛 30 万连接。裸算需要 4 台（100/30 ≈ 3.3），加 1.5 倍余量变 6 台。但要再考虑：每台机器平均 CPU 利用率不超过 60%（留 headroom），且要能扛住单台故障（N+1 容错）。N+1 意味着 6 台里挂 1 台，剩下 5 台要能承接全部流量——5 × 30 万 = 150 万 > 100 万，OK。所以最终配 6 台 16 核机器。带宽上每台机器按 1Gbps 估算（长连接的 keep-alive 心跳很轻，主要带宽在请求/响应数据），6 台共 6Gbps 入口带宽，对应机房要预留这个量。这一层一年成本几十万，相对推理层的几亿，确实是小头。

第三步：状态层（缓存/上下文）

缓存节点内存 = 命中率 × QPS × 平均响应大小 × TTL
​

缓存层用内存数据库（Redis 等）或专用向量库，按预期命中率和 TTL 估算所需内存。这一层的成本占比 10% 到 15%，但它带来的推理成本节省远超自身成本——是一个"投入产出比极高"的层。

也展开一个推演。假设语义缓存命中率 25%，QPS 100 万，平均响应大小 2KB（响应文本 + embedding 向量），TTL 1 小时。同时存活在缓存里的 key 数 ≈ 100 万 × 3600 秒 × 命中请求占比。简化算：每秒命中请求 25 万，每个响应存 1 小时，峰值同时在缓存里的条目数 = 25 万 × 3600 = 9 亿条。每条 2KB，总内存 9 亿 × 2KB = 1.8TB。Redis 单实例内存上限通常 256GB，需要分片——用 10-15 个 Redis 分片，每片 128-180GB。这是个不小的集群，但比起它省下的推理算力（25% 的推理负载，对应上万元的 GPU），缓存集群的成本九牛一毛。另外 embedding 向量如果单独存到专用向量库（如 Milvus），计算方法不同（按向量维度 × 条数算），要分开估算。

资源配比的经验法则

一个粗略但实用的成本配比（按总成本占比）：推理层（GPU）60% 到 70%，接入层（网关）5% 到 10%，状态层（缓存/存储）10% 到 15%，编排层及其它 10% 到 15%。

推理层永远是成本大头，所以降本的核心永远是优化推理利用率（缓存、分流、KV 复用），而不是省网关或省存储。我见过有团队在网关层抠 5% 的成本，却对推理层 30% 的闲置视而不见，这是抓芝麻丢西瓜。降本的精力应该优先投在推理层。

补充几个资源配比的分析。第一，这个比例不是一成不变的，会随业务阶段变化——产品初期流量小、缓存命中率低，推理层占比可能 80%；产品成熟、缓存和分流优化到位后，推理层占比会降到 50%-60%，缓存层占比反而上升（因为缓存容量随流量线性增长）。第二，"编排层及其它"看着占比小（10%-15%），但它是隐性大头——编排层通常用 CPU 机器（多模型路由、Agent 编排、流式聚合），如果 Agent 流量大，编排层的 CPU 机器数量会很可观，别忘了算进去。第三，跨地域部署时每个地域都要按峰值独立规划，不能"全国总流量除以地域数"——因为流量在地域间分布不均（一线城市流量远高于其他），且要考虑单地域故障时流量转移到其他地域的余量。

容量规划的实操清单

把容量规划要做的事整理成一份清单，方便落地时逐项核对。

业务侧：确认业务峰值 QPS 和峰值倍数（峰值/均值），这是所有规划的输入；估算单请求平均 token 数（含上下文和生成），这决定推理负载。推理侧：按公式估算 GPU 数，并考虑缓存命中率和分流比例的优化；预留 1.3 到 1.5 倍冗余应对峰值和故障。接入侧：按并发连接规划网关实例，留 1.5 倍余量。缓存侧：按命中率和 TTL 估算内存。全局：确保全链路有过载保护（限流/降级/熔断）兜底，容量算得再准，没有过载保护也可能在极端情况雪崩。

我再补几条容易被漏的核对项。峰值系数要按业务类型取——to C 大促类业务峰值/均值可能到 5-10 倍，to B 企业类通常 2-3 倍，按错峰值系数要么浪费要么崩盘。GPU 冗余的 1.3-1.5 倍里，要细分"峰值余量"（应对流量波动）和"故障余量"（应对单节点/单机房故障），一般各占一半——比如峰值系数 1.3、故障切换余量 1.2，合计 1.56 倍。多模型部署时每个模型档次独立算（旗舰、标准、小模型各自 GPU 数），不要混算——它们的 tokens/s 和成本差几个数量级。Agent 池要单独按"并发任务数 × 单任务平均 token"估算，不能用普通对话的 QPS 公式（Agent 是长任务，并发模型不同于短请求）。

这一节的关键交付

参考架构把四层抽象落成了可部署的组件图。容量规划从推理层（最贵）起步，用结构化公式替代拍脑袋，并揭示每个优化手段的杠杆。资源配比上，推理层占成本 60% 以上，是降本的主战场。

下一节 5.2 给故障推演模板，并展望架构演进方向。