百万日活月烧18万：AI Agent规模化的成本账没人算过

10万日活，月成本1800美元。100万日活，月成本18万美元。没有Cache，就是这个数字。

按GPT-4价格，每次请求消耗3000个Token，这不是假设，是真实账单。很多团队Demo阶段欢天喜地，用户量一上来，财务直接找上门。传统Web服务的规模化直觉是流量增加加几台Server。放到LLM系统上，会让你踩一个很贵的坑。

LLM系统的规模化，跟Web服务是两回事

传统Web服务的规模化直觉很简单：流量增加，多加机器，问题解决。成本模型是基础设施，基本线性。加一台服务器，扛多N个请求，边际成本递减。

LLM系统的现实完全不同。

流量增加，每个请求都要花钱调用LLM API。 成本模型是Token按量计费，跟你有多少台服务器没关系。你加一百台负载均衡，每个请求还是得付Token钱。

三个特性让LLM系统很难规模化：

高延迟：每次推理2到10秒，用户等不了。你没法靠多线程解决，因为瓶颈在LLM推理本身。

成本跟请求线性相关。传统服务有边际成本递减，LLM没有。第1万个请求和第10万个请求，单位成本一样。

有状态性：对话历史、Session State、Memory都是状态。水平扩展在传统无状态Web服务里是标配，到Agent这里就不直接适用了。

少调用LLM，比让LLM跑得快更重要

看到这个成本结构，第一反应可能是让每个LLM调用更快更便宜。换个小模型、做量化压缩、上推理加速框架。有用，但不是核心策略。

规模化的核心策略是：减少不必要的LLM调用。

总请求量里，能靠Cache直接返回的，零LLM成本。能降低Token数的，缩短上下文，同样调用花更少的钱。只有真正需要LLM推理的，才走计费路径。

一个优秀的FDE，在构建系统时花在缓存和成本控制上的时间，应该和花在功能开发上一样多。这不是浪费。这是保险。

▎ 好的Agent系统，80%的请求不该走到LLM计费路径。走了，说明你缓存设计有问题。

三层Cache：把每一分Token成本榨干

缓存是规模化的命根子。三层Cache架构，从L1到L3逐层榨取成本。

L1：Application Cache（Redis）

最简单的一层。完全相同的查询，直接返回缓存的答案。TTL设5到15分钟。预期命中率约15%，延迟低于5毫秒。Hot Query精确匹配加Session State缓存。用户问了同样的问题，不用再调LLM，Redis里直接取。

L2：Semantic Cache（Vector DB）

这是最值得投入的缓存层。

传统Exact Match因为文字不同不会命中。"Q4销售数字是多少"和"Q4的销售业绩"，意思一样但文字不同。Semantic Cache通过向量相似度判断语义，语义接近的问题复用已有答案。

命中条件是Cosine Similarity≥0.92。TTL根据问题类型设1到24小时。FAQ类场景命中率可达50%以上。延迟约50到150毫秒，包含Embedding和向量搜索的时间。

这一层省下的钱最多。FAQ场景一半以上的请求能命中，意味着一半以上的LLM调用被省掉了。

L3：KV Cache（LLM Provider层）

这是LLM推理层的加速器。当System Prompt和知识库前缀被重复使用时，没有KV Cache的情况下，每次请求的System Prompt都要重新计算。有了KV Cache，System Prompt的计算结果从缓存读取，只计算新增的Query部分。

以Gemini 1.5 Pro为例，拿Cache的Token成本比没有Cache便宜4倍。同一个Prefix被使用2次以上，KV Cache就开始省钱。Prefix越长（50K+ Tokens）、使用次数越多，越划算。

Semantic Cache的阈值：0.95还是0.85，这是个判断题

Semantic Cache最关键的设计决策是相似度阈值。设高了命中率低，设低了误命中风险大。

0.95——保守策略。 几乎不会回传错误缓存答案，但命中率低，省钱效果有限。适合财务数字、法规查询等对答案精确性要求极高的场景。算错了要出事的地方，用0.95。

0.90：平衡策略，也是推荐起点。 命中大多数语义相近的查询。企业FAQ、知识库问答，从0.90开始调。

0.85：激进策略。 命中率最高，但误命中风险明显。不推荐，除非问题领域非常同质化。

阈值选择的核心逻辑：缓存错误答案的代价，必须远大于省下的Token钱。

但并非所有内容都适合缓存。FAQ、产品规格、政策说明，答案稳定，问法多样，适合缓存。定义类问题、历史资料查询，也适合。

不适合缓存的：个性化回答（依赖用户Profile）、即时数据（库存、股价、天气）、有副作用的操作（发邮件、下订单）。这些绝对不能缓存。缓存了一个下单操作，两个用户下了同一个单。省钱省出祸来了。

Agent有状态，加机器等于白加

Stateful Agent的水平扩展，是另一个核心难题。

传统Web服务是无状态的。任意一台Server都能回答任意请求，挂了一台还有其他台顶上。水平扩展是标配。

Agent是有状态的。Session 1在Server A上有完整上下文。Session 2的请求被负载均衡路由到Server B，B没有上下文，直接失败。你加了十台机器，用户还是只能跟原来那台对话。

破解方案：把所有状态外部化。

错误的设计是把Session状态存在Instance里。Server挂了，数据就丢了，用户对话断了接不上。

正确的设计是把所有状态存入外部存储。Redis存Session State和Hot Query Cache，快但易失，适合热数据。Vector DB放Semantic Cache和Episodic Memory，做语义检索，适合长期记忆。PostgreSQL或Firestore存User Profiles和Semantic Memory，持久化，适合用户画像。

任意Instance可以处理任意Session。Instance挂了不影响Session。可以根据流量自由增减Instance，水平扩展重新成立。

▎ Agent的水平扩展，本质上就是把状态从Instance里搬出去。搬不出去，加机器就白加。

10万日活到底花多少钱：成本估算五步法

一个成熟的FDE应该能随时估算系统成本。不用精确到分，但量级要对。

Step 1：估算请求规模。 DAU乘以平均请求次数等于每日总请求数。

Step 2：估算每次请求的Token数。 Input Tokens等于System Prompt加Retrieved Context加History加Query。Output Tokens等于平均回答长度。

Step 3：计算无Cache的成本。 每日请求数乘以（Input Tokens乘Input价格加Output Tokens乘Output价格）。

Step 4：估算Cache节省。 L1命中率乘节省比例，加L2命中率乘节省比例，加KV Cache节省。

Step 5：算出最终成本和ROI。

来看个真实例子。10万DAU的RAG Agent：

100K DAU，每人日均3次请求，300K请求/天。

Input约2500 Tokens/请求（System 500 + RAG 1500 + History 400 + Query 100）。Output约400 Tokens/请求。

用Gemini Flash（$0.075/1M Input，$0.30/1M Output），无Cache月成本约169美元。加上三层Cache后，实际成本降到50到70美元。

同样的10万日活，用GPT-4是月18000美元，用Gemini Flash加三层Cache是月50到70美元。差了两个数量级。

模型选择和缓存策略加在一起，就是这么大的差距。FDE在项目初期就要做这个估算，别等用户量上来了才发现跑不起。

课堂实训：算一笔账，画一张架构图

三个任务，完成后产出《成本估算与缓存架构设计文档》。

任务一： 某制造业企业500名员工使用跟单Agent，日均10万请求。估算月成本，设计三层Cache架构。

任务二： 针对一个FAQ知识库问答场景，选择Semantic Cache的相似度阈值，说明理由。

任务三： 为一个Stateful Agent设计外部化状态存储方案，包含Redis、Vector DB、PostgreSQL的职责划分。

这份文档不是练习题。它是后续项目交付时判断资金可行性的依据。客户问"这个系统跑起来多少钱一个月"，你得能掏出这张表。

第七讲结束。你掌握了三样东西：成本估算的方法论、三层Cache的架构设计、状态外部化的扩展方案。

这三样东西组合起来，就是你能站在客户面前说的那句话：

"这个系统，百万级日活也跑得起。"

不是吹牛。是你算过账、设计过缓存、外部化了状态。

下一讲，我们进入智能体协同的深层领域。多Agent怎么分工、怎么协作、怎么解决一个Agent搞不定的复杂业务问题。单个Agent再强，也有搞不定的时候。那时候，你需要的是一个团队。