1.1 AI对话请求的特征与流量画像

1.1 当我们在谈百万 QPS 时，我们到底在谈什么

很多架构文章的灾难，都始于一个被模糊使用的数字。

"百万级 QPS 的 AI 对话引擎"，这句话里的每一个词都值得停下来追问。百万，是峰值还是均值？QPS 是加了一层网关后的入站请求，还是打到模型推理集群的 token 生成请求？"AI 对话"，是简单的单轮问答，还是带长期记忆、工具调用、多轮检索的 Agent？这三个问题的答案，会把你的架构图纸从根本上改写。

这一节我们要做一件朴素但关键的事：把"百万 QPS"这个笼统的目标，翻译成一组工程上可计算、可拆分、可验证的指标。读者读完这节，应该能一句话说清楚：我面对的，是哪一种流量画像，以及它如何决定了我的架构取舍。

1.1.1 先校准：QPS 的口径决定了架构的走向

工程上最容易踩的坑，是把不同口径的 QPS 混为一谈。下面这张图把一条对话请求从用户端到模型端会经过的"计数点"画了出来，每一个计数点上的 QPS 含义都不同：

• 连接层 QPS：用户长连接（WebSocket / SSE）建立的入口压力。对话是流式响应，一个用户连接可能持续几十秒，因此"在线连接数"往往比"QPS"更能刻画接入层压力。
• 业务 QPS：一次完整的对话请求，从 API 服务看是一次调用。这是产品侧最常引用的数字。
• 推理 QPS / 并发：真正打到 GPU 的请求。由于一次对话请求会触发模型生成成百上千个 token，且可能拆成多轮子调用（检索、工具、再生成），业务 QPS 与推理并发之间往往有 3~10 倍的放大比。

我建议你在动手前先做一个"口径表"：把连接层、业务层、推理层的峰值和均值分别写出来。我见过太多团队按"业务 100 万 QPS"去规划 GPU，结果真实瓶颈在接入层的长连接管理——方向错了，加再多卡也没用。

1.1.2 对话流量的四个本质特征

AI 对话流量和传统的 Web API 流量有本质差异，理解这四个特征，是后面所有架构决策的起点。

特征一：请求是"长尾流式"的，而非"请求-响应"的。

传统 REST API 一次调用几十毫秒就返回，连接可以快速释放。但 AI 对话一次回答可能要生成上千 token，按每秒 3060 token 的生成速度，单条响应就要持续 2040 秒。这意味着你的接入层必须支持流式、长连接、慢释放，而不能用"短连接 + 连接池"的老思路硬套。

特征二：请求大小极度不对称。

用户输入可能只有 20 个字，但结合系统提示词、历史上下文、检索增强内容，真正送进模型的 prompt 可能高达数千 token；而模型返回又是一个持续的 token 流。这种"小输入、大上下文、长输出"的不对称性，让缓存、批处理、流量整形的策略都和传统服务不同。

特征三：延迟敏感但容忍"首字延迟"与"生成速度"的不同。

用户能容忍首字出现需要 1~2 秒，但一旦开始生成，就要求稳定不卡顿（通常要求每秒 20 token 以上，否则像"打字机卡住"）。这把延迟拆解成了两个独立指标——TTFT（Time To First Token，首字延迟） 和 TPS（Tokens Per Second，生成速度），二者优化路径完全不同。

特征四：流量高度突发且难以预测。

对话流量受热点事件、营销活动、甚至一个爆款 Prompt 影响，会在分钟级别内暴涨数倍。它不像电商大促那样可以提前压测和扩容预案，更接近"黑天鹅式突发"。

90% 的人会在这里踩坑：用平均 QPS 规划容量，结果在突发峰值时雪崩。正确做法是按峰值 QPS 的 1.5~2 倍预留弹性，配合自动扩缩容。

1.1.3 把 SLA 翻译成可计算的容量公式

架构不是拍脑袋定出来的，是从 SLA 倒推出来的。假设你承诺的 SLA 是：

• P99 首字延迟 TTFT ≤ 2 秒
• 生成速度 TPS ≥ 30 token/s
• 可用性 ≥ 99.95%（月度不可用时间 < 22 分钟）

那么一个简化但可用的容量模型如下：

这张图给出了一个量级直觉：当业务 QPS 到达百万，推理并发是千万量级，需要的 GPU 是"十万卡"级别的规划问题。当然真实世界里你会用多模型路由、缓存命中、小模型分流来大幅削减这个量级，但先按全量算，再逐步用架构"打折"，才是稳妥的思路。

关键公式（请记下来）：

设计并发 = 峰值 QPS × 平均请求时长
推理需求 = 设计并发 × 平均每请求子调用数 ÷ 单卡并发承载
缓存收益 = (1 - 缓存命中率) × 推理需求
​

缓存命中率每提升 10 个百分点，推理集群压力就下降约 10%——这就是为什么后面第 3 章要把"上下文与缓存"单独成章，它是整个架构的"杠杆点"。

1.1.4 流量画像：给自己画一张"流量地图"

在写第一行代码、画第一张架构图之前，我强烈建议你先输出一份流量画像文档。它至少包含：

1. 请求来源：自有 App、Web 端、开放 API、第三方集成各占多少？开放 API 的流量最不可控，需要最严的限流与隔离。
2. 请求类型占比：纯闲聊、知识问答、带检索的 RAG、带工具调用的 Agent，各自比例如何？Agent 类请求最重，要单独隔离资源池。
3. 峰值曲线：日内是否有明显波峰（如晚高峰）？是否事件驱动（突发）？这决定你是"预留固定容量"还是"弹性伸缩 + 缓冲队列"。
4. 上下文长度分布：短会话（<2K token）、长会话（>32K token）占比？长上下文是显存和 KV Cache 的杀手。
5. 模型使用分布：多少流量能由小模型/蒸馏模型承接？这是降本的关键变量。

1.1.5 一个常被忽略的视角：用户感知的"容量"是连接数，不是 QPS

最后落到一个实操结论。对话系统里，用户感知到的"系统满了"，通常不是 QPS 到了上限，而是可服务的并发连接数到了上限——比如网关的连接表被打满、或者推理队列的积压让首字延迟飙升到用户主动离开。

所以请记住本章最核心的一句话：百万 QPS 不是终点，它是入口；真正要设计的是"百万用户同时在线流畅对话"的并发能力。 后面四章，都是围绕如何把"高并发对话"这个难题，拆成接入、缓存、路由、实战四个可攻克的子问题。

1.1.6 一个具体场景的容量推演（把公式用起来）

前面给了量级直觉，但很多读者更需要一个"我能照着算"的中等规模例子。我们假设一个更贴近现实的稳态目标：业务 QPS 50 万（而非一步到百万峰值），看容量如何推导，以及架构手段如何"打折"原始需求。

推演参数：

• 稳态业务 QPS = 500,000
• 峰值放大系数 = 1.6 → 设计峰值 800,000 QPS
• 平均对话时长 = 20 秒（流式长连接）
• 每请求平均触发推理子调用 = 3 次（首轮生成 + 一次检索重排 + 一次总结）
• 单卡并发承载（量化后）= 35

先算"裸需求"：

• 设计并发连接 ≈ 800,000 × 20 = 1600 万长连接
• 推理并发 ≈ 800,000 × 3 = 240 万
• 裸 GPU 需求 ≈ 240 万 ÷ 35 ≈ 6.9 万张

这个数字很大。但注意，它假设"每一个业务请求都 100% 打到模型"。而真实架构会做三件事来削减它：

1. 语义缓存：相似问题命中缓存直接返回，假设命中率 25%，推理并发立刻 ×0.75 → 180 万。
2. 小模型分流：约 40% 的流量（闲聊、兜底、简单问答）由小模型承接，小模型单卡并发高一个数量级，等效把这部分推理"折算"掉。折算后等效大模型并发再降约 35% → 约 117 万。
3. 上下文复用与批处理：通过连续批处理把单卡并发从 35 提升到 60+，GPU 需求再降约 40% → 实际折到约 4~5 万张量级。

关键认知：架构的价值，就是把"裸需求"通过缓存、分流、批处理一层层打折。这就是为什么第 3 章（缓存）和第 4 章（路由）是降本的主战场——它们每提升一点，乘以百万基数都是惊人的算力节省。

1.1.7 成本视角：把 QPS 翻译成"每轮对话成本"

技术容量之外，还有一个老板和客户都关心的维度：钱。百万级对话系统的推理成本，往往是一家公司 AI 业务线能否盈利的分水岭。这里给一条最简的成本公式：

单轮对话成本 ≈ 输入 token 数 × 输入单价 + 输出 token 数 × 输出单价
实际成本 = 单轮成本 × (1 - 缓存命中率) + 缓存命中固定开销
​

关键变量依然是缓存命中率和模型选择：

• 输入 prompt 往往含大量"重复的公共系统提示词 + 检索片段"，通过前缀缓存可以把这部分重复计算的算力省掉，相当于变相降低输入单价。
• 输出 token 是大头（生成越多越贵），通过"先小模型后大模型"的级联策略，让简单问题在小模型上以极低成本解决，只有复杂问题才升档到大模型。
• 缓存命中率从 0 提升到 30%，意味着 30% 的对话几乎零推理成本——这就是缓存的经济价值，也是第 3 章要反复强调"缓存是第一杠杆"的原因。

把上面两节合起来看，1.1 的核心方法论就完整了：先校准口径，再画像，再倒推容量，最后翻译成成本。带着这套框架，无论你的目标是 10 万还是 1000 万 QPS，路数都是一样的。

1.1.8 三个真实误判案例（避免重蹈覆辙）

方法论讲完，我用三个我亲见或业内公开过的"口径误判"案例收尾，它们都源于 1.1 反复强调的那个点：没校准口径就开干。

案例一：按业务 QPS 买 GPU，结果瓶颈在连接。 某团队拿到"峰值 80 万 QPS"的需求，按业务 QPS 反推 GPU 数量，却忽视了接入层要维持 80 万 × 平均 18 秒 ≈ 1400 万长连接。首波流量一来，接入机 fd 耗尽、内存被打满，用户全掉线，而 GPU 利用率才 30%。教训：连接层容量要先于算力规划。

案例二：用平均值预留，热点事件雪崩。 日均 50 万 QPS，按均值备了 1.2 倍容量。某天一个爆款话题带来 5 分钟 300 万 QPS 尖峰，排队堆积、首字延迟飙升到 15 秒，用户大规模离开。教训：必须按峰值而非均值预留，且峰值要叠突发缓冲。

案例三：把推理并发当业务 QPS 报，惊动老板。 一份周报写"我们的对话系统已达百万 QPS"，其实那是推理集群的 token 生成并发计数，真实业务 QPS 仅 12 万。口径混乱导致资源申请被放大数倍。教训：对外汇报前，先统一口径表，避免"数字通胀"。

这三个案例的共同根因，都是一个：跳过 1.1 直接进 1.2。所以请务必在动架构之前，先把"流量画像"那张表填出来——它不性感，但能救你的项目。

1.1.9 本节要点回顾

读到这里，1.1 应该给你留下这几条可复述的结论：

1. 口径先行：连接层、业务层、推理层的 QPS 含义不同，动手前必须写出口径表，否则整个容量规划都会偏。
2. 对话流量四个本质特征：长尾流式、大小不对称、延迟可拆（TTFT/TPS）、突发不可预测。这四条决定了不能用传统 Web 架构硬套。
3. 容量从 SLA 倒推：设计并发 = 峰值 QPS × 时长；推理需求 = 并发 × 子调用数 ÷ 单卡并发；缓存与分流是降本杠杆。
4. 先算裸需求，再靠架构打折：缓存命中率、小模型分流、连续批处理，每一步都能大幅削减 GPU 需求。
5. 容量要翻译成成本：缓存命中率与模型选择直接决定每轮对话成本，这是业务能否盈利的分水岭。

把这张要点图存在脑子里，下一节我们去看：支撑这一切的系统，在逻辑上由哪几层组成。

下一节（1.2），我们会正式盘点这些子问题——也就是一个 AI 对话引擎后端，到底由哪些核心组件构成，以及每个组件在百万量级下会暴露出什么"非百万量级时根本不会遇到"的难题。

小结：本节我们校准了 QPS 的口径（连接层 / 业务层 / 推理层），归纳了对话流量的四个本质特征，给出了从 SLA 倒推容量的公式，并用一个 50 万 QPS 的具体推演展示了缓存、分流、批处理如何把裸需求层层"打折"，最后把容量翻译成成本。三个真实误判案例提醒我们：口径不校准，架构必翻车。带着这张图，我们进入 1.2 的组件全景。