系统日活从 100 涨到 10 万，架构要变什么？

先做水平扩展，检索服务和应用服务加机器、加负载均衡；向量库要考虑分片；模型调用侧要加限流和排队，避免打爆上游；再加缓存降低重复请求。监控要跟上，看各层的延迟和错误率。数据库读写分离，热点数据加 Redis。

这是通用的 Web 扩容答案，及格但不切题。它没有回答任何和大模型应用相关的特殊性——生成侧的容量约束、长上下文对并发的影响、缓存结构的变化、以及兜底策略的失效。

① 先澄清：涨的到底是什么。 日活 10 万要先换算成峰值并发和每秒请求数——同样是 10 万日活，一天用一次的工具和坐席全天在线的客服，并发差两个数量级。还要问：长上下文请求的占比是多少（这直接决定生成侧的容量），以及数据量是不是同步涨了（用户涨不一定文档涨，两者的扩容路径完全不同）。

② 回到基线：先找当前架构的第一个拐点在哪。 不要三层一起扩。做法是压测，看哪一层先崩。经验上顺序通常是：生成侧 → 检索侧 → 数据侧，因为生成侧的单位成本和资源占用远高于其他两层。

③ 分层说变什么、代价是什么：

• 生成侧（最先出问题的一层）。如果走 API，主要工作是限流、排队、优雅降级和多供应商冗余；如果自建，核心约束是显存：KV Cache 吃掉的显存决定了能同时挂多少条会话，容量限并发、带宽限单步。这里有一个必须说清的效应：上下文越长，并发掉得越快——同一张卡在 8K 上下文下能挂几十条并发，到 128K 可能只剩个位数。所以「支持超长上下文」在规模化之后是一个容量决策，不是一个功能开关。
• 容量规划只能用有效吞吐。峰值吞吐是「不管延迟多难看，一秒能吐多少 token」，而真实业务有延迟约束，满足延迟要求的那部分吞吐才能用于规划。用峰值吞吐做容量规划，上线当天就会发现算少了一半。
• 检索侧：向量索引到一定规模要分片，且召回质量会随库变大而下降——同样的 top-k 在百万级库里的噪声比十万级大得多，所以扩容的同时通常要提高召回数并加强重排。代价：延迟和成本都上升。还要注意增量更新的压力：数据量涨了之后，重建索引从「凌晨跑一次」变成不可行，必须做真正的增量。
• 数据侧：更新频率、一致性、以及权限判定的 QPS（toB 场景里这一项经常被漏，每次检索都要查一遍权限）。
• 缓存结构会变好：用户涨一千倍之后，问题分布会更集中，精确缓存和前缀缓存的命中率通常显著上升——这是规模带来的红利，应该主动去吃。但语义缓存的风险同时放大，因为误命中的绝对次数随请求量线性增长。
• 长尾会变长：100 个用户时你见过的问题类型是有限的，10 万用户会把长尾拉得很长。这意味着评测集会失效——原来的一百条评测题不再代表线上分布，必须按新的真实分布重采。这条最容易被漏，但它是「上线后效果变差」的常见原因之一。
• 兜底策略会直接失效：100 日活时「不确定就转人工」完全可行，10 万日活时人工兜底会被淹没。所以扩容不只是扩机器，是要重新设计兜底——把一部分兜底从人工换成自助（引导到帮助中心、给相似问答、给结构化表单）。

④ 怎么验证扩对了：压测要用真实分布的流量回放而不是均匀请求，因为长上下文请求的资源占用完全不同；监控要分桶看（按请求类型、按上下文长度分桶），总均值会掩盖问题；同时要盯有效吞吐和排队时长，而不只是 QPS 和成功率。

⑤ 什么时候该做下一步：出现「峰值时排队时长超过用户耐心」→ 扩容或降级；出现「长尾问题占比持续上升且转人工被打满」→ 该扩知识覆盖和自助兜底，不是扩机器；出现「同一类请求每天几万次且稳定」→ 才考虑蒸馏小模型或专用路由。退路：任何一次扩容后效果指标下降，先回滚再排查——规模问题最容易和质量问题混在一起，不隔离就查不清。