要上线一个对内的智能体，老板第一个问题不是"准不准"，是"一个月烧多少钱、扛得住多少人同时用"。我答不上来，于是上线前老老实实做了一次容量压测。这篇把我怎么估 token 账单、怎么压并发、压出来什么数据，全贴出来。

先搞清楚一次请求到底花多少 token

这是估账单的地基。很多人只算"用户问的那几个字"，大错特错。一次 RAG 智能体的请求，token 是这么堆起来的：

组成	这部分大概多少 token	说明
系统提示词	固定 ~400	每次都带，是固定开销
检索召回的知识片段	~1200	大头！top-k 片段全塞进上下文
用户问题	~50	反而最小
对话历史（多轮）	~600	看你保留几轮
模型输出	~300	回答本身
单次合计	~2550	输入约 2250 + 输出约 300

看清楚没——真正吃 token 的是检索塞进去的知识片段，不是用户那句问话。 我一开始只按"问题 + 回答"估，估出来的账单是实际的五分之一，差点闹笑话。

估月账单

有了单次 token，剩下就是乘法。我们预估日活 200 人，人均 8 次会话，按工作日算：

单次 token ≈ 2550（输入 2250 + 输出 300）
日请求量 = 200 × 8 = 1600 次/天
月请求量 = 1600 × 22 个工作日 ≈ 35200 次/月

月输入 token ≈ 35200 × 2250 ≈ 7920 万
月输出 token ≈ 35200 × 300 ≈ 1056 万

按你用的模型的输入 / 输出单价分别乘一下，就是月账单。我这里就不贴具体单价了（各模型差很多），方法是这个。关键提醒：输入和输出单价不一样，通常输出贵几倍，要分开算，别用一个均价糊弄。

并发压测

账单是平均量，并发是峰值能力。我用脚本模拟并发请求，从 10 路慢慢加，看响应时间和错误率：

并发数	平均响应时间	P95 响应时间	错误率
10	2.1 s	3.4 s	0%
30	2.8 s	5.2 s	0%
50	4.5 s	9.1 s	0.4%
80	8.7 s	18 s	3.2%
100	超时大量出现	—	11%

从这表能看出我们这套配置的安全水位在 50 并发左右——再往上 P95 就破 9 秒，用户体感开始难受，80 并发后错误率失控。

考虑到日活 200、峰值大概率不会真有 50 人同一秒发请求（实际峰值并发约 25），结论是当前容量够用，但没多少余量，大促或全员培训那种场景得提前限流或加配额。

几个压测中才发现的事

RAG 检索本身也是延迟来源。 我一开始以为慢全是模型推理，拆开看才发现，向量检索 + 上下文拼装占了响应时间的三成多。优化时不能只盯着模型。

长上下文是并发杀手。 把 top-k 从 5 调到 3、保留对话历史从 5 轮砍到 3 轮之后，单次 token 降了快四成，同样并发下响应时间明显好转。省 token 既省钱又提并发，一举两得。 但召回会掉一点，得权衡。

别用"理想问题"压测。 我第一版压测全用短问题，数据好看得不真实。后来混入长问题、多轮追问，数据才贴近真实负载。压测语料要有代表性。

没解决干净的

这次压测我没把"突发尖峰"压进去——比如某个时刻全员被通知"去问那个机器人"，瞬时并发可能远超 50。这种我目前只能靠限流和排队兜底，没做真实的尖峰演练，算个隐患。

---

底层模型走的讯飞 MaaS，现成大模型 API，按调用付费，不用自己买卡部署，容量这块省心不少。

你们上线 Agent 前压测吗？token 账单实际和预估差多少，评论区交流下踩坑经验。