构建RAG应用示例的成本模型，将助您认清主要成本来源，并了解不同选择如何影响您的总开销。
场景：“IntelliDocs”问答系统
假设有“IntelliDocs”系统，这是一个内部问答系统，旨在帮助员工从大量技术文档、API指南和工程维基中查找答案。
系统配置：
- 知识库容量：
- 初始文档数量：100,000
- 平均文档长度：1,500字（大约2,000个token）
- 分块策略：每个分块512个token，有重叠部分。这大致产生了 100,000 文档×(2000 token/文档/512 token/分块)≈390,625 个分块。为简便起见，我们四舍五入为400,000个分块。
- 每月更新：5%的文档是新增或修订的，需要重新嵌入 (embedding)受影响的分块。
- 用户活跃度：
- 每月查询量：50,000
- 平均查询长度：30个token
- 每次查询平均检索到的分块数：3
- 平均生成回复长度：200个token
- 模型选择（用于估算）：
- 嵌入模型：
- 选项1（自托管开源模型，例如
sentence-transformers/all-mpnet-base-v2）：主要为计算成本。对于此模型，我们假设一个简化的嵌入操作成本，相当于每1k个token $0.00005（包含计算和维护）。
- 选项2（专有API，例如 OpenAI
text-embedding-ada-002）：每1k个token $0.0001。
- 生成器大型语言模型（基于API）：
- 选项A（高端大型语言模型，例如GPT-4级别）：每1k个prompt token 0.03，每1k个completiontoken0.06。
- 选项B（中档大型语言模型，例如GPT-3.5-Turbo级别）：每1k个prompt token 0.001，每1k个completiontoken0.002。
- 基础设施：
- 向量 (vector)数据库：托管服务，包含存储和查询费用。
- 应用逻辑：无服务器函数（例如AWS Lambda）。
- 日志/监控：标准云服务。
步骤1：认清主要成本组成部分
对于IntelliDocs系统，主要的成本驱动因素将是：
- 初始数据摄取： 嵌入 (embedding)整个知识库。
- 持续数据更新： 嵌入新增或修改的文档。
- 向量 (vector)数据库： 嵌入存储和查询操作。
- 查询处理：
- 计算/编排： 运行应用逻辑（例如，无服务器函数、API网关）。
- 数据存储（原始文档和日志）： 存储原始文档和系统日志。
- 监控： 与监控工具和服务相关的费用。
步骤2：估算各组成部分成本
为简化初始计算，我们先使用嵌入 (embedding)模型选项2（专有API），然后进行比较。我们将分析生成器大型语言模型选项A和B。
2.1 初始数据摄取（嵌入成本）
- 总分块数：400,000
- 每个分块的token数：512
- 初始摄取的总token数： 400,000 分块×512 token/分块=204,800,000 token
- 使用嵌入模型选项2（API）的成本： (204,800,000 / 1000) \times \0.0001 = $20.48$
2.2 持续数据更新（每月嵌入成本）
- 需更新的文档数： 5%×100,000=5,000 文档
- 假设每个更新的文档需要重新嵌入其分块（平均4个分块/文档）： 5,000 文档×4 分块/文档=20,000 分块
- 用于更新的token数： 20,000 分块×512 token/分块=10,240,000 token
- 每月更新成本（嵌入模型选项2）： (10,240,000 / 1000) \times \0.0001 = $1.02$
2.3 向量 (vector)数据库成本（每月）
向量数据库定价变化很大。让我们假设一个简化的托管服务模型：
- 存储：400,000个向量，768个维度（例如
all-mpnet-base-v2 或 ada-002），float32（4字节/维度）。
- 每个向量的大小： 768×4 字节=3072 字节
- 总存储量： 400,000×3072 字节≈1.23 GB
- 对于此规模，我们估算托管向量数据库的存储和基本运营成本为每月**$50**。这只是一个粗略估算；实际成本可能因供应商、功能和性能层级而有很大差异。一些供应商可能会按每百万个存储向量或按实例小时收费。
2.4 查询处理成本（每月）
2.4.1 查询嵌入成本
- 每月查询量：50,000
- 平均查询长度：30个token
- 查询总token数： 50,000×30=1,500,000 token
- 每月查询嵌入成本（嵌入模型选项2）： (1,500,000 / 1000) \times \0.0001 = $0.15$
2.4.2 大型语言模型生成成本
这通常是主要的经常性成本。
- 查询数量：50,000
- 每次查询的上下文 (context)token数：
- 查询：30个token
- 检索到的分块： 3 分块×512 token/分块=1536 token
- 每次查询的总prompt token数： 30+1536=1566 token
- 每次查询的completion token数：200个token
使用生成器大型语言模型选项A（高端）：
- 每次查询的prompt成本： (1566 / 1000) \times \0.03 = $0.04698$
- 每次查询的completion成本： (200 / 1000) \times \0.06 = $0.012$
- 每次查询总成本（选项A）： \0.04698 + $0.012 = $0.05898$
- 每月大型语言模型成本（选项A）： 50,000 \times \0.05898 = \textbf{$2949.00}$
使用生成器大型语言模型选项B（中档）：
- 每次查询的prompt成本： (1566 / 1000) \times \0.001 = $0.001566$
- 每次查询的completion成本： (200 / 1000) \times \0.002 = $0.0004$
- 每次查询总成本（选项B）： \0.001566 + $0.0004 = $0.001966$
- 每月大型语言模型成本（选项B）： 50,000 \times \0.001966 = \textbf{$98.30}$
2.5 计算/编排成本（每月）
对于处理50,000个请求的无服务器函数，每个请求涉及嵌入、向量搜索和大型语言模型API调用，计算持续时间可能为几秒。
- 让我们估算每个请求平均2秒，使用512MB内存函数。
- 总计算秒数： 50,000×2s=100,000 GB-秒 （假设1GB内存等价定价，根据实际提供商层级调整）。
- 典型的无服务器函数成本可能约为每GB-秒 $0.00001667。
- 每月计算成本： 100,000 \times \0.00001667 \approx $1.67。
- API网关成本：对于50,000个请求，这可能约为每月**$2-5**。
- 编排总估算：每月**$10**。这很大程度上取决于具体的架构和云提供商。
2.6 数据存储（原始文档和日志）（每月）
- 原始文档：100,000个文档，平均1500字。如果每个字大约5个字符，且文档为文本格式： 100,000×1500×5 字节≈750 MB。
- 日志：取决于详细程度。我们估算每月10GB的日志量。
- 标准云存储（例如S3/GCS）： \approx \0.023 \text{ 每GB/月}$。
- 每月存储成本： (0.75 \text{ GB} + 10 \text{ GB}) \times \0.023 \approx $0.25。我们四舍五入为每月**$1**。
2.7 监控成本（每月）
- 用于指标、仪表盘和警报的基本云监控服务，对于此规模，可能范围从每月**10到50**，取决于粒度和保留期。我们使用每月**$20**。
步骤3：汇总每月成本
让我们创建一张汇总表。我们将使用嵌入 (embedding)模型选项2（基于API）计算嵌入成本。
| 成本组成部分 |
每月成本（大型语言模型选项A：高端） |
每月成本（大型语言模型选项B：中档） |
备注 |
| 嵌入更新 |
$1.02 |
$1.02 |
基于API的嵌入模型 |
| 向量 (vector)数据库 |
$50.00 |
$50.00 |
托管服务估算 |
| 查询嵌入 |
$0.15 |
$0.15 |
基于API的嵌入模型 |
| 大型语言模型生成 |
$2949.00 |
$98.30 |
模型选择带来的显著差异 |
| 计算/编排 |
$10.00 |
$10.00 |
无服务器函数，API网关 |
| 数据存储（原始/日志） |
$1.00 |
$1.00 |
|
| 监控 |
$20.00 |
$20.00 |
|
| 总估算月成本 |
$3031.17 |
$180.47 |
|
初始的一次性摄取成本为$20.48。
步骤4：成本影响可视化
简单的可视化可以突出显示影响最大的成本组成部分。大型语言模型的生成成本显然占据主导地位，特别是在使用高端模型时。
估算IntelliDocs RAG系统的每月总运营成本，比较高端生成器大型语言模型（选项A）与中档生成器大型语言模型（选项B）。
步骤5：分析模型并找出优化点
这个成本模型，虽然简化了，但显现出几个重要方面：
- 大型语言模型生成是主要因素： 生成器大型语言模型的选择以及每次查询处理的token数量是目前最大的成本驱动因素。
- 优化： 采纳“最小化大型语言模型token使用量的技术”中的策略（例如，prompt压缩、上下文 (context)窗口优化、请求大型语言模型给出更简洁的答案）非常重要。转向更具成本效益的大型语言模型（选项B）会带来显著的成本降低（在此示例中超过90%）。如果可行，针对特定任务微调 (fine-tuning)更小的开源模型可以节省更多。
- 嵌入 (embedding)成本： 尽管在此场景中嵌入成本不如大型语言模型生成高，但对于非常大的数据集或频繁更新，嵌入成本可能会变得很高，尤其是在使用基于API的嵌入模型时。
- 优化： 考虑自托管开源嵌入模型（如我们的选项1，每1k个token成本为0.00005）。对于持续更新，这将是每月0.51而不是每月1.02。对于查询嵌入，这将是微不足道的。初始摄取成本将是10.24而不是$20.48。尽管这里的节省不大，但它们会随用量增加。权衡是运营开销。
- 向量 (vector)数据库： 成本差异很大。对于非常大的系统，优化索引策略、选择适当的实例类型或考虑分片（如“向量数据库优化”中讨论的）可以带来节省。
- 计算/编排： 无服务器通常对于可变负载具有成本效益。然而，对于非常高且持续的吞吐量 (throughput)，预置资源可能更经济。批量请求也可以减少每个请求的开销。
- 缓存： 对大型语言模型响应（针对具有相同上下文的相同查询）或频繁访问的检索文档实施缓存，可以减少大型语言模型调用和向量数据库查询，直接影响成本。如果10%的查询可以从缓存中提供，那么这些查询的大型语言模型生成成本将直接节省10%。
构建您自己的成本模型
这个练习提供了一个模板。要为您的RAG应用构建成本模型：
- 定义您的场景： 详细说明您的数据量、更新频率、预期查询负载和性能需求。
- 列出组成部分： 认清所有产生费用的服务和操作（嵌入 (embedding)、向量 (vector)数据库、大型语言模型API、计算、存储、监控等）。
- 收集定价： 获取您选择的云服务和模型API的当前定价。请注意价格可能会变化。
- 估算用量： 量化 (quantization)每个组成部分的使用量（例如，token数量、API调用次数、存储GB、计算小时数）。
- 计算成本： 使用电子表格或简单脚本计算每个组成部分的成本并进行汇总。
- 输入变量：queries/month, avg_prompt_tokens, avg_completion_tokens, embedding_cost_per_token, llm_prompt_cost_per_token, llm_completion_cost_per_token等。
- 公式：
total_llm_cost = queries_per_month * ((avg_prompt_tokens * llm_prompt_cost_per_token) + (avg_completion_tokens * llm_completion_cost_per_token))
- 分析和迭代： 认清最大的成本来源。研究不同的架构选择、模型选用或优化技术（如本课程中讨论的）将如何影响总成本。例如，如果您通过更好的上下文 (context)选择将平均prompt token数减少20%会怎样？
实践总结
成本建模是一个迭代过程。您的初始模型将是一个估算，但随着您对系统使用模式的更多了解以及研究不同的配置，您可以对其进行完善。定期重新审视您的成本模型，特别是在考虑系统变化或扩展时，对于在生产环境中维护成本效益高的RAG系统非常重要。这种实践为您提供了结构化的方法来预测、分析和管理这些运营开销。
