第1章-基础与挑战

第 1 章 基础与挑战

很多团队在立项"支持百万级 QPS 的 AI 对话引擎"时，第一反应是去查"哪款推理框架最快""要不要上裸金属 GPU""向量数据库选哪家"。这些当然重要，但真正决定项目生死的，往往不是这些具体的技术选型，而是立项前有没有想清楚三个更朴素的基础问题：你说的百万 QPS 到底是什么口径？支撑它的系统由哪几层组成？第一道必须守住的关口又在哪里？

本章是整本教程的"地基"。我们不急着写代码，也不急着画复杂的架构图，而是先把口径校准、把地图画清、把最前线的难题点透。读者读完这一章，会建立起一套贯穿后续四章的统一语言：在什么口径下谈容量，用什么分层去拆解问题，以及为什么接入层是整个系统的生死线。

我见过太多团队，在"百万 QPS"四个字上栽跟头，不是因为技术弱，而是因为从一开始就和这个数字"鸡同鸭讲"。有人按业务 QPS 规划 GPU，结果瓶颈在长连接管理；有人按平均值预留容量，结果一次热点事件就让系统雪崩；还有人把"限流每秒次数"当成万能钥匙，结果用户开五十个标签页就把推理集群打满。这些坑，本质上都是"基础与挑战"这一章没想透。

本章由三节组成，呈清晰的递进关系：

• 1.1 AI 对话请求的特征与流量画像：我们先把"百万 QPS"这个模糊目标翻译成可计算的指标。你会看到，连接层、业务层、推理层的 QPS 含义完全不同；对话流量具备长尾流式、大小不对称、延迟可拆解、突发不可预测四个本质特征；我们还会给出从 SLA 倒推容量的公式，以及一份可以立刻照着填的"流量画像"清单。
• 1.2 核心组件全景与分层架构：镜头拉远，看全局。我们把一个生产级的 AI 对话后端抽象成五层——接入层、网关编排层、上下文与缓存层、模型服务层、支撑与观测层，论证为什么必须分层而非揉成一个大服务，明确层与层之间靠什么契约协作，并列出一张"量级跃迁问题清单"，提醒你哪些在千级时无所谓的小事，到了百万级会变成致命问题。
• 1.3 百万长连接难题与限流哲学：下到最前线。我们讲清为什么传统短连接架构在百万长连接下会失灵，连接管理的三个工程要点，以及限流的真正本质——你限的应该是"并发资源"而非"请求次数"，需要多维组合，并用资源池隔离避免"一个大客户拖垮所有人"的惨剧。

这一章的基调是"先慢后快"。我刻意把最容易让人兴奋的"高并发技巧"放在最后，而把最朴素的"口径与地图"放在最前。因为在我见过的所有失败案例里，九成不是技术不够强，而是在错误的口径上、用错误的分层、去攻错误的关口。地基歪了，上面盖得越漂亮，塌得就越快。

值得一提的是，本章刻意不绑定任何具体的厂商产品或框架版本。AI 基础设施的迭代速度极快，今天最快的推理引擎，半年后可能就被新方案超越；但"口径校准、分层拆解、关口防守"这套思维方式，是长期有效的。我建议你在读后续章节时，始终把具体技术当成"实现手段"，而把本章的方法论当成"判断标准"——当你面对一个新的工具或架构提案时，问自己：它改善了哪个口径？它强化了哪一层？它守住了哪道关口？

带着本章建立的统一语言，我们从第 2 章开始，一层一层地把这座"百万级对话引擎"真正搭起来。请记住一条主线，它会在每一章反复出现：流量画像 → 分层地图 → 关口防线。只要这条主线不断，无论流量涨到多大，你的架构都有章可循。

本章导读：基础不牢，地动山摇。先把 QPS 口径、系统分层、第一道关口想清楚，再谈技术选型。后续每一章都会回扣本章建立的"流量画像—分层地图—关口防线"这条主线，确保整套架构在百万量级下依然有章可循。