前两个月一个做 AI 应用的团队找我聊技术方案。他们的产品刚上线用户量还不大但已经按“未来百万用户”的标准把服务拆成了十几个微服务上了 Kubernetes配好了完整的链路追踪和灰度发布平台。结果呢团队一半的时间花在维护基础设施上核心的 Agent 交互链路反而没有精力优化。我问他们这个阶段你们真的需要这么复杂的 Scale 策略吗这个问题放到两年前答案可能很明确早规划早受益。但今天在 AI 大规模进入应用层的这个时间点上情况已经变了。模型的能力在快速迭代应用的交互范式还没稳定用户需求往哪个方向演化根本看不清。这时候把所有资源压在“横向扩展”上很可能是在为一个还没有发生、甚至不会发生的峰值提前买单。这篇文章想聊的就是“Dont Scale Yet”背后的逻辑。不是反对扩展而是要重新定义什么时候扩展、以什么方式扩展以及 AI 在这个决策里到底改变了什么。我会从传统 Scale 逻辑的失效原因说起分析 AI 应用真正的性能瓶颈再给出“先别扩展”的替代方案以及最终切换到大规模扩展时的判断信号和落地路径。无论你是 AI 应用开发者、后端架构师还是正在从传统业务转向 AI 工程实践的团队这篇文章应该能帮助你在“扩展”这件事上做出更务实的决策。1. 这篇文章真正要解决的问题先说清楚在 AI 时代Scale 这个词的含义正在发生变化。过去我们谈 Scale谈论的是请求量、并发连接数、数据库吞吐量、CDN 命中率核心是 Web 服务的承载能力。一个业务起量了流量上来了服务器撑不住了那就横向加节点、加缓存、加消息队列。这套方法论非常成熟Kubernetes、微服务、云原生本质上都是在解决“水平扩展”这件事。但 AI 应用的扩展逻辑不一样。AI 应用的瓶颈不只是请求量还包括模型推理成本、上下文窗口管理、Token 消耗、向量数据库的召回效率、以及 Agent 编排时的任务链复杂度。用户量增长一倍传统 Web 层可能只需要加两台服务器但 AI 应用如果有大量实时推理请求成本可能是线性甚至超线性上升的。更关键的是AI 技术本身还在快速演进半年前你规划的“扩展方案”很可能已经不适应新模型和新架构。所以这篇文章要解决的核心问题是当你想基于 AI 构建产品时应该把有限的技术资源投到哪里是提前搭建一套面向大规模的基础设施还是先把核心链路跑通、验证需求再按需扩展我的判断是除非你的业务已经验证了稳定增长否则“先别 Scale”往往是更优解。原因有三个第一AI 技术栈的高层架构仍然在快速变化过早基础设施化会锁死你的技术选择。第二AI 应用的核心竞争力通常不在并发承载而在业务逻辑、数据质量和交互体验这些不是 Scale 能解决的。第三现代云平台和工具链已经让“按需扩展”的代价大幅降低提前扩展的“未雨绸缪”显著贬值。后面我会逐个展开这些判断并给出具体的技术实践。2. Scale 的传统逻辑为什么正在失效2.1 传统 Scale 体系的三个支柱要理解“AI 改变了 Scale”的说法先要知道传统扩展体系建立在哪些假设之上。传统 Web 应用的扩展体系有三个支柱第一支柱是无状态服务。把应用设计成无状态任意节点都可以处理任意请求这样才能水平扩展。Session 状态被挪到 Redis 或数据库里本地文件系统不再保存持久数据。第二支柱是流量可预测性。系统架构师通过容量预估来规划资源比如根据注册用户数、日活跃用户数、高峰时段访问量来推算服务器数量。双十一这类大促虽然流量暴涨但时间是确定的规模也有历史数据参考。第三支柱是稳定接口契约。微服务之间通过 API 通信接口定义一旦确定就尽量不变通过版本兼容来保证扩展过程中系统不崩溃。这三个支柱在传统业务里非常有效。但它隐含了一个前提业务逻辑是稳定的扩展只是为了承载更多的存量逻辑。2.2 AI 让这些假设全部松动AI 应用破坏了这个前提。先看无状态。传统 Web 应用的逻辑是确定的输入参数读取数据库返回结果。但 AI 应用尤其是 Agent 类应用往往有上下文状态。一次用户会话可能涉及多轮工具调用、记忆读写、上下文窗口滑动。你需要决定哪些状态放内存、哪些放向量库、哪些交给模型上下文。这个设计本身还在演进中很难做成一个“任意节点等价”的无状态体系。再看流量的可预测性。传统业务的需求相对稳定但 AI 产品的新一轮融资、模型能力突然升级、某个 Agent 在社交网络引爆流量可能在一夜之间从 100 QPS 冲到 10000 QPS。而且这种爆发往往是无法预判的也没有历史数据支撑容量规划。最后看接口契约。传统微服务的接口变化频率是周或者月级但 AI 应用的模型行为、Prompt 结构、Token 消耗可能每天都要调整。更麻烦的是模型本身也会升级升级后同一段 Prompt 可能返回完全不同的结果。这意味着你的“业务逻辑”本身就不是稳定的你很难为不稳定的逻辑去做精细化的容量规划。2.3 核心变化从“承载压力”到“验证假设”传统 Scale 解决的问题是“系统能不能扛住更多请求”这是一个工程问题。AI 时代的核心矛盾是“产品方向是否正确、模型链是否有效、用户是否真的买单”这是一个产品问题。很多团队把工程问题放到了产品问题前面结果就是烧了很多钱在基础设施上产品却还没有跑通。AI 创业公司的第一优先级应该是用最小成本验证核心假设——包括模型选型、Prompt 链、数据管线和用户价值。在这些问题没有答案之前大规模 Scale 是无效支出。这种变化对团队的技术判断提出了更高要求你不能再靠“把系统做大”来掩盖架构问题而必须靠“做聪明的小系统”来快速试错。3. AI 时代真正的瓶颈在哪里说完了“不该扩展”的理由再来看 AI 应用里真正的瓶颈。只有知道瓶颈在哪才知道什么时候该扩展、以什么方式扩展。3.1 推理成本与 Token 预算传统应用的成本是服务器租金和带宽费成本相对固定扩展简单。AI 应用最大的成本是模型推理按 Token 计费。一次用户交互Prompt 和 Completion 加起来可能消耗几千个 Token如果使用复杂 Agent 编排一轮任务可能要调用十几次模型Token 消耗轻松破万。这意味着什么意味着并发扩展和成本增长是同比例的。传统应用加十台服务器成本也可能只增加十倍但 AI 应用如果用户量增长十倍模型调用成本可能增长十五倍、二十倍因为还要算上更复杂的上下文管理。如果你在设计阶段没有做 Token 预算扩展得越快亏得越多。很多团队在做 AI 应用时成本模型还是传统的“服务器成本”思维。他们估算用户量增长时只算了 CPU/内存/带宽成本忘了把 Token 成本算进去。结果用户量真的增长之后第一个崩溃的不是系统是财务预算。3.2 上下文窗口与状态管理AI 应用的另一个瓶颈是上下文窗口。主流模型都有 context window 限制虽然窗口在变大但你的业务可能需要的是超长历史记忆、大量知识库切片、多轮工具调用结果这些都会消耗上下文。更麻烦的是上下文窗口管理不是简单的“内存不够就加内存”那种扩展逻辑。你需要考虑哪些信息留在上下文里、哪些转到向量库、哪些任务需要递归总结。这个逻辑本身就和业务耦合没法靠加服务器解决。从扩展的角度来看这是一个设计问题不是一个容量问题。3.3 延迟与质量之间的权衡传统 Web 应用追求低延迟加缓存、加 CDN、加多级缓存池都是为了降低响应时间。但 AI 应用存在一个独特的权衡你想要多好的回答质量就意味着要多长的推理时间。如果让模型经过多轮推理、自我反思、工具验证回答质量会更高但延迟可能从 1 秒变成 10 秒。如果你为了扩展性把复杂的 Agent 链改成单轮 Prompt延迟降了但用户对回答质量的满意度可能大降。这个权衡必须由产品决策者来做不是一个纯技术问题。而很多团队在做扩展规划时把这个问题当成了瓶颈问题来解要么盲目加资源硬跑复杂链路要么简单粗暴地牺牲质量来换速度。这两种做法都缺少对“质量—延迟—成本”三角关系的整体思考。3.4 模型迭代带来的架构漂移这是很多人忽略的一点AI 模型的迭代速度远快于基础设施的规划周期。你今天用的模型可能是三个月后模型的一个小版本但模型升级后可能需要调整 Prompt 结构、重做评测集、甚至更换工具调用方式。如果你的架构是“为了这个模型的这个版本深度定制”的模型一升级你的整个扩展体系都变成了包袱。所以在 AI 应用里架构的中间层应该尽量与模型解耦。比如通过统一接口封装模型调用通过配置管理 Prompt 和参数通过插件机制支持工具扩展。这些都不是 Scale 问题但比 Scale 更优先。4. 哪些场景应该“先别 Scale”这个章节给出具体的判断什么类型的 AI 产品在什么阶段应该明确“先别 Scale”。4.1 早期验证阶段的 AI 产品如果你的 AI 产品还处于“验证用户是否认可”的阶段那么最重要的是跑通最小闭环用户进来输入一个问题系统调用模型、检索知识库返回一个高质量回答。这个阶段用户量可能只有几百到几千瓶颈完全不在服务器而在回答质量和产品体验。但很多团队在这个阶段就按“未来十万用户”的设计来写代码数据层分库分表服务层微服务化外部接口 API 化。结果核心链路还经常出错却要在几百个文件之间排查故障。更合理的做法是用一个单体应用把全链路打通等到业务逻辑稳定后再做拆分。这个阶段我会推荐“模块化单体”把 AI 调用、知识库、Agent 编排都做成内部模块但部署上仍是一个服务。这样做的好处是核心链路清晰出现问题好排查部署成本低代码量可控。等用户量和业务逻辑都稳定了再按模块边界做拆分成本反而更低。4.2 Agent 编排与工具调用类应用Agent 应用是目前 AI 工程实践中最复杂也最容易过度设计的领域。一个 Agent 应用通常包含任务规划模块、工具调用模块、记忆管理模块、结果验证模块。如果你一开始就把它做成一堆微服务通信开销和链路成本会吞噬掉 Agent 本该有的灵活性。Agent 的编排逻辑本质上是一个内部流程更适合在一个进程内完成。更关键的是Agent 的工具调用策略、规划算法、验证机制都还在快速演进你的“编排架构”很可能过几个月就要推倒重来。这时候 Scale 做得越精细沉没成本越高。正确姿势是先用一个中心化编排脚本把 Agent 链跑通重点验证“工具调用的准确性”和“用户对最终输出的满意度”而不是去优化一个可能不存在的性能瓶颈。4.3 需要大量 bespoke 数据处理的场景很多 AI 应用的核心竞争力不在算法而在数据。比如用 AI 做法律文书分析、医疗病历摘要、金融研报解读这些场景需要针对特定数据格式做清洗、实体识别、关系抽取、知识图谱构建。这些工作的计算量通常不在在线推理而在离线数据处理。你不需要大规模扩展在线服务而是需要一个稳定的批处理流水线按业务节奏定期更新数据。把这个流水线做得越可靠对业务的杠杆越大。如果把大量投入放到在线服务的 Scale 上就是在错误的地方花时间。4.4 刚切换到 AI 基础设施的团队还有一类场景是传统团队刚刚引入 AI 能力比如在已有业务里接入大模型做智能客服、内容摘要、语义搜索。这时候团队对模型特性还不熟悉最需要的是通过小流量试验来积累经验而不是一上来就构建一套复杂的 AI 基础设施。先跑一个小功能观察模型的效果、成本和用户反馈再决定是否加大投入。这种小步快跑的方式比“一次到位”的 AI 平台建设更稳妥也更符合工程上的渐进式演进原则。5. 什么时候必须 Scale五个信号“先别 Scale”不是永远不 Scale。当出现下面这些信号时说明系统已经到了必须认真对待扩展的阶段。这些信号不是猜测而是可以从监控和业务数据里观察到的。5.1 核心指标持续恶化且无法通过优化解决如果请求延迟持续上升而且你已经做过数据库索引优化、缓存引入、代码层面排查依然没有改善这时候再考虑水平扩展。特别要注意的是AI 应用的延迟指标要分层来看模型推理延迟、前置处理延迟、后置校验延迟。如果瓶颈在模型推理扩展到没多大用因为模型调用是串行的如果瓶颈在前置处理比如向量检索太慢那可以考虑单独扩展检索服务。5.2 成本增长开始侵蚀毛利如果你的用户量在增长模型调用成本也在增长但收入的增长速度赶不上成本增速这不是扩展能解决的问题而是需要从产品层面调整成本结构。比如改用更便宜的模型、优化 Prompt 减少 Token 消耗、引入缓存层匹配历史问题、对高消耗功能做配额限制。如果这些问题已经优化完成本还是高而且是因为用户量确实太大导致的那才考虑用更高效的基础设施来摊薄单位成本比如买更大批量的 GPU 卡、优化推理引擎、做批量推理。5.3 团队协作效率因为单体结构而严重下降单体应用不是问题但当一个百人团队都在改同一个代码仓库、同一个部署包频繁产生冲突和互相阻塞这时候就需要按业务模块拆分了。这个信号更多是团队规模的信号而不是用户量的信号但它同样值得重视。如果你在 AI 应用里遇到了这种情况我建议优先按“数据面”和“控制面”拆分而不要急着按“业务线”拆。数据面负责知识库、向量检索、数据库访问控制面负责模型调用、Agent 编排、流程控制。这种拆法更符合 AI 应用的执行链路。5.4 真实用户量已经跨越一个数量级用户量从一万到十万或者从十万到一百万这是两个完全不同的阶段。跨越一个数量级时很多设计假设都会失效。比如原来单机缓存就能抗住的读流量变成了必须用分布式缓存原来一个库就能放下的数据变成需要考虑读写分离和分片。从“按需扩展”的实践来看最佳时机不是在流量真正到来前而是在流量趋势已经可以用数据明确预测之后。当增长模型显示出明显的指数趋势时提前一个季度做扩展规划比提前两年做“完美架构”更有效。5.5 业务功能开始依赖更复杂的多服务协作如果你的 AI 产品开始从“单个模型调用”演进到“多模型协同”从“单 Agent”演进到“多 Agent 协作”那系统内部的服务边界会自然变得复杂需要引入服务编排、状态存储、任务队列等基础设施。这不是为了扩展而扩展而是为了支撑更复杂的业务逻辑。这时候扩展方案的设计要和 Agent 自身的状态管理放在一起考虑。多 Agent 系统对状态一致性的要求远高于单 Agent你需要在设计时明确哪些状态是共享的、哪些是私有的、哪些可以最终一致。6. 延迟 Scale 的替代方案先做对四件事如果暂不扩展那怎么应对增长答案是优化核心链路让现有资源发挥更高效率。以下是四个优先级最高的实践方向。6.1 缓存策略把重复计算变成命中命中的命中AI 应用最大的浪费是重复调用模型处理相似甚至相同的问题。你的用户可能在问同一个知识库里的相似问题你的系统却每次都调用一遍完整链路。缓存可以大幅降低这部分浪费。缓存可以在三个层面做第一层相同 Prompt 的结果缓存适用于固定模板的生成任务第二层语义缓存通过 embedding 相似度匹配近似问题返回历史答案第三层知识库检索结果缓存避免每次请求都去向量库做全量检索。6.2 异步化把非关键链路挪到后台AI 应用里的很多任务并不需要用户在线等待。比如一个长文档摘要任务可能需要模型处理几十万 Token耗时几十秒这种场景就不适合做同步调用。改成异步方案用户提交任务之后系统返回一个任务 ID后台 Worker 处理完再通知用户。这样用户请求的“在线部分”很短对服务器的压力也小很多。你用一台机器就能支撑高并发的任务提交。6.3 垂直扩展先升级单机再考虑分布很多人一听到“垂直扩展”就觉得老套但在 AI 应用里单机的算力和内存往往比集群规模更重要。一个大型模型推理任务占用的其实是 GPU 显存和内存带宽这些资源不是靠加节点就能轻松解决的。如果你的任务需要 80GB 显存三台 24GB 显存的机器分布式推理远比一台 80GB 显存的机器复杂。在 AI 推理场景里更推荐先把单机配置拉满再考虑横向扩展。因为分布式推理的上层协调逻辑非常复杂涉及模型切分和流水线并行维护成本极高。当你发现单个 GPU 已经不够时先评估新的 GPU、更高效的内存、更强的 PCIe 通道是否足够如果足够优先垂直扩展。6.4 简化架构拥抱模块化单体模块化单体不是放弃工程规范而是把“可扩展性边界”从代码层面后移到部署层面。你仍然可以将 AI 调用封装为独立模块将知识库封装为独立数据访问层将工具调用封装为独立函数但在部署上它们共享同一个进程和服务实例。这样做的最大好处是当核心链路出现性能问题时你可以直接在一个进程内定位不需要跨服务排查。而且当某一块业务真的成长为需要独立部署时你用模块边界作为代码层面合理的拆分点重构成本基本可控。7. 从“先别 Scale”到“该 Scale”的转换路线假设有一天数据真的指向你必须扩展了如何平滑过渡我推荐按下面四个阶段走。7.1 第一阶段建立可观测性基线在动手扩展之前先确保你能回答这些问题当前系统的真实瓶颈是什么请求延迟的 P50/P95/P99 是多少模型调用成本占总成本的比例是多少向量库查询耗时随数据量增长如何变化为此你应该在系统里埋点把 AI 调用耗时、Token 消耗、检索耗时、工具调用耗时、错误率都采集起来接入到你的监控平台。没有这些数据任何扩展决策都是盲目的。7.2 第二阶段做压力测试和容量评估在测试环境构造真实负载模拟用户请求、Agent 调用链、多轮会话看看当前系统在什么 QPS 下开始崩溃哪个环节第一个崩溃。对 AI 应用还有一个特殊的维度大数据量测试。知识库数据量从 10 万向量增长到 100 万向量检索延迟会变成多少这一步对向量数据库的选型至关重要。7.3 第三阶段按瓶颈所在做渐进式扩展扩展不是“拆全部分布式”而是“哪里痛哪里扩展”。如果瓶颈在向量检索先扩展向量数据库如果瓶颈在工具调用高 IO先扩展 Worker 数量如果瓶颈在会话状态存储先引入 Redis 或分布式缓存。这种渐进式扩展的好处是每一步都有明确的目标和验证手段出了问题可以回滚。7.4 第四阶段引入弹性伸缩与自动扩缩容当业务流量已经有了明显的峰谷规律你就可以引入弹性伸缩了。通过 Kubernetes 的 HPA、云平台的自动扩缩容组或 Serverless 平台让系统根据实时指标自动扩缩容。这里需要特别提醒AI 应用的自动扩缩容要谨慎设置。因为模型实例拉起很慢加载模型、预热缓存都需要时间如果扩容策略太激进会经常处于“扩容中”状态如果太保守则可能在流量突增时扛不住。建议先做预热的预留实例再配合指标阈值做弹性调节。8. 常见问题与排查思路问题现象可能原因排查方式解决方案并发量上来后延迟暴涨某些共享资源如数据库连接池、模型实例被占满查看连接池使用率、模型实例并发数增大连接池、模型实例数或增加缓存层明明用户不多但成本很高Token 耗用过高Prompt 重复构建统计每次用户请求的 Token 消耗优化 Prompt引入缓存减少不必要的调用模型响应越来越慢上下文窗口增长单次请求携带的历史信息过多查看 Token 中历史消息的占比实现历史消息自动摘要压缩上下文多 Agent 协作时经常超时Agent 间通信没有统一超时控制查看 Agent 编排日志定位超时节点为每个 Agent 调用设置独立的超时和重试策略扩展后任务仍是串行执行业务代码里存在未异步化的阻塞调用通过链路追踪查看是否有同步阻塞对耗时操作增加异步化或消息队列向量检索命中率变低数据切片策略在数据量增长后失效抽样检查检索结果的相关性优化切片大小、重训 embedding 模型或增加召回策略模型升级后输出质量波动新模型和旧架构不兼容用评测集对比新旧模型的输出增加评测集回归验证升级前做 A/B 测试9. 最佳实践与工程建议回到文章的核心判断。AI 时代的 Scale不应该是一个默认的设计方向而是一个基于数据和验证的决策结果。给读者几条务实建议第一用“假设驱动”代替“规模驱动”。在构建 AI 应用时先明确你想验证的假设是什么。是用户愿意为 AI 回答付费还是 Agent 能解决某类复杂任务然后把有限的资源投入在验证假设上而不是搭建“未来基础设施”。第二重视成本可见性。从第一天起就记录模型调用成本、Token 消耗、单用户平均成本。这些指标会帮你判断什么时候该优化 Prompt、什么时候该换模型、什么时候该引入缓存它们比 QPS 更能反映 AI 应用的业务健康度。第三建立 AI 评测和回归机制。这是 AI 工程实践里最容易忽略、也最值得投入的一环。对每次模型升级、Prompt 调整、Agent 链路修改跑一遍评测集确保不会出现明显的质量倒退。没有评测机制你的扩展和优化都像是在黑夜里开车。第四用“复杂度的门槛”来约束架构演进。一个功能在用户量还没到某个量级时就不该用对应量级的复杂架构。给架构演进设一道门槛新增一个微服务的理由不应该是“将来可能会用到”而应该是“现在的故障隔离或团队协作已经无法接受了”。第五时刻保留回滚能力。无论你做的是扩展、升级模型还是重构 Agent 链路都要确保可以在 30 分钟内回滚到上一个稳定版本。这个能力在快速迭代的 AI 领域尤其重要因为模型和业务的变化都是高频的。说到真实的工程场景我最后再补充一个具体建议在做 AI 应用时把“不 Scale 也活得好”当成一个设计目标而不是妥协。能在一个进程里解决的事就不用消息队列能用缓存解决的事就不加机器能用异步解决的事就不阻塞请求。当你把每一条链路的效率都逼到极限时你会发现大多数团队在大多数阶段真正缺的并不是资源而是对业务和模型更深的理解。如果你正在设计 AI 应用建议先花几天时间确认三件事当前链路的真实瓶颈、单用户成本、扩展后的边际收益。数据会告诉你该不该 Scale。