1. 从一次账单异常说起DynamoDB 做向量检索到底贵在哪去年年底我帮一个团队做 RAG 知识库的成本复盘他们的技术栈很典型文档切片后调用嵌入模型生成向量向量存进 DynamoDB检索时用原生向量搜索能力做近邻查询再把召回片段喂给大模型生成答案。上线头两个月一切正常第三个月账单突然翻了三倍团队第一反应是大模型调用量涨了结果拉出明细一看推理费用只涨了不到两成真正的大头全在数据库侧。这个场景其实非常普遍。很多人选 DynamoDB 做 RAG 的存储层看中的是它托管、免运维、能扛住高并发写入而且原生向量搜索省掉了单独部署向量数据库的麻烦。但省掉一个组件和省掉一笔钱完全是两回事。DynamoDB 的计费模型和传统向量数据库差异极大它不是一个按存储量查询次数简单计价的系统而是把成本拆成了好几个互相耦合的维度任何一个维度失控都会在账单上放大。这篇文章我想把这件事讲透DynamoDB 原生向量搜索的成本到底由哪几块构成为什么它和你在用的 RAG 存储层可能不匹配以及在什么情况下应该换、什么情况下不该换。核心关键词会围绕DynamoDB、向量搜索、RAG、存储层、计费这几个点展开同时也会聊到 RAG 瓶颈、RAG 知识库、RAG 实战这些大家真正关心的问题。不管你是刚在 Mac 上搭完第一个 RAG 知识库的新手还是已经在生产环境跑着千万级向量的老手这篇内容应该都能帮你少交一点学费。先说结论方向DynamoDB 原生向量搜索的成本账本质上是三向计费——存储向、读写向、索引向三者叠加而 RAG 场景的访问模式写入密集、读取稀疏但突发、向量维度高恰好会同时踩中这三条线。理解这一点你才能判断自己的 RAG 存储层要不要换。2. 拆开 DynamoDB 向量搜索的计费结构三向成本到底怎么算2.1 存储向向量不是一行数据而是一行很胖的数据很多人对 DynamoDB 存储成本的第一反应是按 GB 收费能贵到哪去。问题在于向量数据的体积和你直觉里的一条记录完全不是一个量级。一个 1536 维的浮点向量如果按 32 位浮点存储单个向量就是 1536 × 4 6144 字节也就是 6KB。这还只是向量本身没算上原始文本、元数据、分片 ID、时间戳这些字段。假设你的 RAG 知识库有 100 万个切片光向量部分就是 100 万 × 6KB ≈ 6GB。听起来还好但别忘了 DynamoDB 的存储计费是按表数据 索引数据分别计算的而且它有一个容易被忽略的点每个二级索引都会独立复制一份数据。如果你为了支持向量搜索建了额外的索引结构那这份向量数据可能被存了不止一次。100 万切片、6GB 向量加上索引复制实际计费存储量可能到 12GB 甚至更多。再叠加 DynamoDB 存储单价比普通对象存储高出一个数量级这个事实存储向的成本就上来了。这里有个实操心得在估算存储成本前先确认你的向量维度能不能压缩。很多嵌入模型支持降维输出比如从 1536 维降到 768 维甚至 512 维检索质量下降通常在可接受范围内但存储直接砍半。我在一个中文知识库项目里做过对比768 维和 1536 维在 Top-10 召回率上只差 2 个百分点左右但存储和后续的读写成本都明显下降。这个取舍在 RAG 实战里非常值得做。2.2 读写向RAG 的访问模式是写多读少但读很贵DynamoDB 的读写计费分两种模式按需模式和预置容量模式。按需模式按实际读写请求数收费预置模式按预留的容量单位收费。RAG 场景的麻烦在于它的访问模式非常不均衡。写入侧知识库构建阶段是典型的批量写入。文档解析、切片、调用嵌入模型、写入向量这个过程可能一次性灌入几十万甚至上百万条记录。如果用的是按需模式这一波写入会直接体现在账单上如果用预置模式你得提前把写入容量调高否则会被限流但调高之后构建完又用不上白白浪费。读取侧更微妙。RAG 的查询不是均匀分布的用户提问是突发的而且每次查询要做的向量近邻搜索在底层可能触发多次读操作。一次向量搜索请求消耗的读容量单位RCU往往远高于一次普通主键查询因为它需要扫描或比较多个候选向量。如果你的向量搜索实现依赖全表扫描或者大范围扫描那读成本会非常夸张。我见过一个反面案例某团队用 DynamoDB 存向量检索时先按分区键拉出一大批候选再在应用层做余弦相似度计算。结果每次查询要读几千条记录RCU 消耗是普通查询的几十倍。后来他们改成用原生向量搜索的索引能力读放大才降下来。这个教训说明读写向的成本高度依赖你的检索实现方式不是数据库本身决定的。2.3 索引向向量索引是隐形的成本放大器这是最容易被低估的一块。DynamoDB 原生向量搜索依赖索引来加速近邻查询而索引不是免费的。索引会带来三个成本第一索引本身占用存储前面已经提到它会复制数据。第二写入时索引需要同步更新这会增加写入消耗的容量单位。第三索引的维护在数据量大时可能触发后台操作间接影响性能表现。更关键的是向量索引的效果和参数强相关。比如近邻搜索的候选数量、索引的更新频率、向量的归一化方式这些参数既影响检索质量也影响成本。参数调得太激进召回率高但成本飙升调得太保守成本下来了但 RAG 答非所问。这个平衡点没有通用答案必须结合你的数据分布和查询模式实测。提示在正式上线前务必用真实数据量做一次成本压测。用 10 万条和 100 万条数据分别跑一遍完整的写入查询流程记录实际消耗的容量单位再外推到生产规模。很多成本问题在测试阶段就能暴露。把这三向加起来看DynamoDB 向量搜索的成本结构就清楚了存储向是基数读写向是变量索引向是放大器。三者互相影响单独优化任何一个都可能被另外两个抵消。这也是为什么很多团队明明优化了查询账单却没降——因为写入和索引的成本被忽略了。3. RAG 存储层的真实需求DynamoDB 到底匹配不匹配3.1 RAG 知识库对存储层的四个硬性要求要判断要不要换存储层得先搞清楚 RAG 知识库到底需要存储层做什么。我把它归纳成四条高维向量的高效近邻检索这是核心要求存储层能在合理延迟内返回 Top-K 相似向量。元数据过滤能力RAG 检索经常需要先按条件筛再做向量搜索比如只检索某个部门、某个时间段、某种文档类型的切片。存储层要支持向量搜索和结构化过滤的组合。写入吞吐和更新灵活性知识库不是一次性的文档会增删改切片会重新生成向量会更新。存储层要能扛住批量写入和增量更新。成本可预测这是最容易被忽视但最致命的。RAG 知识库的规模会增长查询量会波动如果成本模型不可预测预算就没法做。拿这四条去对照 DynamoDB第一条它能做但成本随数据量和查询模式变化大第二条它支持但过滤条件和向量搜索的组合可能触发额外的读放大第三条它擅长写入但更新向量意味着重写整条记录加索引同步第四条恰恰是它的弱项三向计费叠加让成本预测变得复杂。3.2 什么时候 DynamoDB 是合理选择我不是说 DynamoDB 不能做 RAG 存储层。在几种情况下它其实很合适场景一数据量中等且增长可控。如果你的知识库切片在几十万级别向量维度不高查询量稳定DynamoDB 的托管优势能省掉大量运维精力成本也在可接受范围。场景二已经在用 DynamoDB 做业务数据。如果团队的技术栈本来就围绕 DynamoDB 构建业务数据、用户数据、权限数据都在里面把向量也放进去能减少组件数量和数据同步的复杂度。这种就近存储的价值有时候超过单纯的成本考量。场景三写入远大于读取且读取模式简单。比如一个内部知识库主要是定期批量导入查询量不大那读写向的成本压力就小DynamoDB 的写入能力反而是优势。场景四对延迟要求不是极致。DynamoDB 原生向量搜索的延迟在毫秒到几十毫秒级别对大多数 RAG 应用够用。如果你追求的是个位数毫秒的极致检索可能需要专门的向量数据库。3.3 什么时候该认真考虑换存储层反过来以下几种信号出现时我建议认真评估换存储层账单里数据库侧占比超过推理侧这说明存储层成了成本瓶颈继续优化查询的边际收益很低。向量数据超过千万级这个量级下DynamoDB 的存储和索引成本会快速上升专用向量数据库的性价比开始显现。查询模式复杂需要多条件过滤、混合检索、多路召回时DynamoDB 的组合查询容易触发读放大。需要频繁更新向量嵌入模型升级、文档重新切片都会导致向量重写DynamoDB 的更新成本较高。成本需要精确预测如果预算管理严格DynamoDB 的按需计费波动性会带来麻烦。这里要强调一点换存储层不是非黑即白的选择。很多成熟方案是混合的——热数据、高频查询的向量放专用向量库冷数据、归档向量放 DynamoDB 或对象存储。这种分层思路在 RAG 实战里很常见也能兼顾成本和性能。4. 换与不换的决策框架一张表帮你算清楚4.1 成本对比的关键变量要做出决策得把几个关键变量量化。我整理了一张对比表把 DynamoDB 和典型专用向量数据库在 RAG 场景下的成本维度列出来成本维度DynamoDB 原生向量搜索专用向量数据库典型存储计费按表索引数据量单价较高按向量数据量单价中等写入计费按写入容量单位批量写入成本明显多数按节点/内存规格写入不单独计费查询计费按读取容量单位向量搜索读放大明显多数按查询次数或包含在节点费用中索引成本索引复制数据写入同步隐性成本高索引通常包含在存储和内存中成本可预测性低随访问模式波动中到高节点规格固定则成本固定运维成本极低全托管中需要管理集群和容量这张表不是要证明谁更好而是帮你定位自己的成本结构。如果你的账单里写入和索引占比高那 DynamoDB 的劣势就明显如果查询量小、数据量中等那 DynamoDB 的托管优势可能更值钱。4.2 一个可落地的估算方法我通常用这个方法来估算先算出三个数——向量总量、月写入次数、月查询次数。然后分别乘以 DynamoDB 的对应单价得到一个基准成本。再拿同样的三个数去套专用向量数据库的计价模型得到另一个成本。两者对比差距超过 30% 就值得深入评估。具体操作上DynamoDB 的容量单位消耗可以用 CloudWatch 的指标反推。写入侧看 ConsumedWriteCapacityUnits读取侧看 ConsumedReadCapacityUnits把向量搜索相关的请求单独打标签就能算出向量部分到底占了多少。这个数据比拍脑袋估算靠谱得多。注意估算时一定要把索引的写入同步算进去。很多人只算了主表写入忽略了索引更新带来的额外消耗结果实际成本比预估高出一大截。4.3 迁移的隐性成本不能忽略换存储层不是免费的。迁移成本包括数据导出和重新导入的时间、双写过渡期的复杂度、检索逻辑的适配改造、团队的学习成本、以及迁移期间可能出现的服务波动。这些成本在决策时必须计入。我的经验是如果迁移的隐性成本超过一年内能省下的费用那就不值得换。除非你有其他非成本的理由比如性能瓶颈、功能缺失、合规要求。单纯为了省钱而迁移往往会发现省下的钱被迁移成本吃掉了。5. 如果决定不换把 DynamoDB 向量成本压下来的实操手段5.1 向量维度与精度的取舍最直接的手段是降维。前面提到过1536 维降到 768 维存储直接减半读写和索引成本同步下降。具体怎么选维度建议做一次小规模对比测试用同一批查询分别用不同维度的向量跑召回看 Top-K 命中率的变化。如果降维后命中率下降在 5% 以内那这个取舍通常划算。另一个手段是量化。把 32 位浮点向量转成 16 位甚至 8 位整数存储体积能再降一半到四分之三。代价是精度损失但对很多 RAG 场景来说召回阶段本来就有冗余精度损失可以通过多召回几条来弥补。这个技巧在 RAG 知识库规模大、成本敏感时特别有用。5.2 分区设计对读写成本的影响DynamoDB 的分区键设计直接影响读写效率。如果分区键选择不当会导致热点分区某些分区的读写容量被过度消耗而其他分区闲置。在 RAG 场景里一个常见的做法是按知识库 ID 或文档类型做分区让查询能定位到少数分区减少扫描范围。但要注意向量搜索往往需要跨分区检索。如果分区太细每次查询要访问大量分区读放大反而更严重。这个平衡需要根据查询模式来定。我的建议是先分析你的查询是否带结构化过滤条件如果有就用过滤字段做分区键如果没有分区键的选择要尽量让数据均匀分布避免热点。5.3 批量写入与预置容量的配合写入成本可以通过批量操作来优化。DynamoDB 支持批量写入接口把多条记录打包提交能减少请求次数。但批量写入不等于免费容量单位还是按数据量算只是减少了网络开销和请求开销。预置容量模式在写入可预测时更省钱。如果你的知识库构建是定期批量进行的可以提前把写入容量调高构建完再调低。这种弹性预置的策略比一直用按需模式便宜。但要注意调整的粒度和频率频繁调整反而增加管理成本。5.4 查询侧的缓存与降级查询侧最大的优化空间是缓存。RAG 的查询有很强的重复性很多用户问的是相似问题。把高频查询的检索结果缓存起来能大幅减少对 DynamoDB 的读取。缓存可以放在应用层也可以用专门的缓存服务。另一个手段是降级策略。当查询量突增时可以临时降低召回数量或者跳过某些非关键的过滤条件用质量换成本。这种策略在流量高峰期特别有效能避免账单因为突发流量而失控。6. 如果决定换迁移路径与混合架构的落地细节6.1 迁移的三种路径迁移不是只有全量搬迁一条路。我见过三种常见路径路径一全量迁移。把向量数据全部搬到新存储层DynamoDB 只保留业务数据。适合数据量不大、迁移窗口充足的情况。风险是迁移期间检索服务可能中断需要做好双写和灰度切换。路径二双写过渡。新数据同时写入 DynamoDB 和新存储层查询逐步切到新存储层旧数据按需迁移。这种方式平滑但双写期间成本翻倍过渡期不能太长。路径三分层混合。热数据放新存储层冷数据留 DynamoDB查询时先查热数据不够再查冷数据。这种方式成本最优但查询逻辑复杂需要处理两边的结果合并和排序。6.2 混合架构的查询编排混合架构的难点在查询编排。一次 RAG 检索可能要同时查两个存储层然后把结果合并、去重、重排序。这里有几个实操要点统一向量表示两个存储层的向量必须用同一个嵌入模型生成否则相似度不可比。结果合并策略可以用加权分数合并也可以先各自召回再统一重排。加权合并简单但可能漏掉跨层的高相似结果统一重排准确但计算量大。超时和降级如果其中一个存储层响应慢要有超时机制避免拖垮整个查询。6.3 迁移后的验证清单迁移完成后必须做一轮验证确认检索质量没有下降。验证清单包括用同一批测试查询对比迁移前后的 Top-K 召回结果看重合度。检查端到端延迟确认没有因为多一层查询而变慢。核对成本确认实际账单符合预期。压测新存储层的写入和查询极限确认容量规划合理。检查监控和告警是否覆盖新组件。这套流程我在几个项目里跑过最容易被忽略的是第三步——很多人迁移完就不看账单了结果发现省下的钱没想象中多因为新存储层也有自己的隐性成本。7. 几个真实项目里的经验与踩坑7.1 别用向量条数估算成本我最早做 RAG 成本估算时习惯用多少条向量来算。后来发现这个指标极具误导性。同样 100 万条向量维度不同、元数据字段多少不同、索引配置不同成本能差好几倍。正确的做法是用实际存储字节数和实际容量单位消耗来估算这两个数据在控制台和监控里都能拿到。7.2 嵌入模型升级是成本炸弹有一次团队升级嵌入模型从旧模型换到新模型向量维度从 768 变成 1024。结果不仅存储涨了三分之一所有向量都要重新生成和写入那一周的写入成本直接爆表。这个教训是嵌入模型的选择要提前考虑长期成本不要只看检索效果。如果模型可能升级要预留向量重写的预算和窗口。7.3 查询日志比账单更早暴露问题账单是月底才看到的但查询日志是实时的。我习惯在应用层记录每次向量搜索的耗时、扫描条数、返回条数。当发现某类查询的扫描条数异常高时就知道成本要出问题了。这个习惯帮我提前发现过好几次读放大避免了月底的惊喜。7.4 小规模测试不能完全代表生产在 Mac 上搭 RAG 知识库做测试时数据量小、查询少DynamoDB 的成本几乎可以忽略。但生产环境的数据量和并发完全是另一个量级。测试阶段的成本结论只能作为参考真正的成本评估必须用接近生产规模的数据做压测。这一点我在 RAG 教程里反复强调但很多人还是会踩。7.5 结构知识库和向量知识库的成本差异顺便聊一个相关话题RAG 知识库和结构知识库的成本模型完全不同。结构知识库用传统数据库查询成本主要是存储和索引查询成本低且可预测。向量知识库的成本大头在向量存储和近邻检索波动大。如果你的 RAG 系统里两者都有要分开核算成本不要混在一起看否则会误判瓶颈在哪。8. 回到那个账单翻三倍的团队他们最后怎么做的回到开头那个案例。那个团队最后没有全量迁移而是做了三件事第一把向量维度从 1536 降到 768存储和索引成本直接砍半。第二给高频查询加了缓存层读取容量消耗降了六成。第三把冷数据归档到对象存储DynamoDB 只保留近三个月的热数据。三招下来数据库侧成本降到了原来的三分之一检索质量几乎没有感知下降。他们的经验说明换存储层不是唯一解甚至不是首选解。在动手迁移之前先把维度、缓存、分层这三件事做到位往往能解决大部分成本问题。只有当这些手段都用尽、成本还是压不下来时才值得考虑换存储层。我个人在实际操作中的体会是DynamoDB 原生向量搜索的成本问题本质上是用通用数据库做专用负载的必然结果。它不是一个缺陷而是一个权衡。你享受了托管和免运维的便利就要接受成本模型不够优化的代价。判断要不要换关键看这个代价是否超过了便利带来的价值。对中小规模、增长可控的 RAG 知识库DynamoDB 依然是合理选择对大规模、高并发、成本敏感的 RAG 系统专用向量数据库或混合架构更值得投入。这个判断没有标准答案只能结合你自己的数据量、查询模式、团队能力和预算约束来定。
