把提示词搬进DynamoDB，限流天花板消失了

提示词检索卡住了整条推理流水线，模型本身却不是瓶颈。把提示词从托管服务搬进 DynamoDB 之后，限流消失了，这套设计此后一直在生产环境里跑着。

提示词看起来像配置，所以很容易被塞进平台提供的托管提示词管理服务里。版本管理、控制台、干净的 API，一段时间内这是对的选择。问题会在高负载下暴露：提示词检索位于每次推理调用的热路径上，服务开始往回推请求。

这就是撞上的那堵墙。提示词管理层在限流。每次调用都必须先取到提示词才能干正事，这道限流就成了整条流水线的天花板。模型不是瓶颈，提示词查找才是。

托管服务为什么会变成瓶颈

提示词管理服务是为编写和治理设计的，不是为在延迟敏感路径上每分钟被读几千次设计的。它们自带请求配额，而这些配额通常在整个账号层面共享，不会按单个工作负载的读流量来伸缩。读量一涨，先撞上的是配额，跟提示词本身有关的任何限制都还没轮到。

征兆一开始很微妙。提示词检索开始出现限流和请求过多错误，于是加上指数退避重试，也许再加一个服务拒绝时的兜底。这是合理的卫生习惯，但一旦把一次普通的配置查找包进重试逻辑，这个存储就已经悄悄变成了应用的吞吐上限。优化模型、批处理任务、调优下游，全都没用，因为请求早就卡在等提示词那一步了。

DynamoDB 为什么贴合这种访问模式

提示词查找是最简单的访问模式：有一个键，想要拿回对应的条目。按主键做单条读取，正是 DynamoDB 擅长的事。

• 读吞吐随表伸缩，而不是固定服务配额。按需容量吸收尖峰，预置容量加自动伸缩应对稳定负载。原先限流的那份共享配额不再压在路径上。
• 访问模式就是键查找。按提示词标识分区，每次获取都是一次 GetItem。没有扫描，没有过滤，读取延迟可预期地保持在个位数毫秒。
• 读写干净分离。高频读取打到 DynamoDB；少见的编写写入留在托管服务里，评审和治理本来就在那里，再由一个同步步骤把变更推送到 DynamoDB。

让它安全的部分：基于校验和的同步

缓存提示词很容易，让缓存保持诚实才是值得做对的部分。

托管服务仍是提示词内容的真实来源，DynamoDB 保存热路径读取的服务副本。为了在不每次部署都全量重传的前提下让两边一致，同步按校验和进行。

同步是写穿式的。检测到源头有变更时，先把新提示词写进 DynamoDB，之后读者从那里取到。流程很简单：对真实来源里的每个提示词计算内容校验和；把校验和与已存储的值比对；一致就什么都不做，不一致说明提示词变了，把新内容写进 DynamoDB 并记录新校验和。

这样每次同步都变成一次廉价的比对，而不是盲目重写。未变更的提示词只花一次比较、不产生写入，只有源头真正发生编辑才触发写入。由于写入先于任何读取落地，新提示词能干净地传播：热路径来取的时候，服务副本已经更新好了。

好处在于校验和本身就是变更信号。不需要单独的“脏标记”，也不需要手动升版本号。内容相同，校验和就相同，写入被跳过；有人改了提示词，校验和变动，下次同步写入新文本。

需要回滚或审计：在 DynamoDB 里做版本

DynamoDB 不会像提示词管理服务那样直接给你版本管理，但可以自己建模。“DynamoDB 没有版本管理”是一种常见的误读。

如果每个提示词只需要一份当前副本，上面的校验和布局就够了。想要历史、回滚或审计轨迹，就在键里加一个版本：分区键用提示词标识，排序键用版本，单调整数、ISO 时间戳或校验和本身都可以；再加一个当前指针，每个提示词多一条条目，指明活跃版本。

热路径按键读取当前指针，服务仍然是一次键读取。历史用分区键上的 Query 保持可查。校验和依旧决定何时写入新版本行，未变更的提示词不会堆出新版本。如果可能出现并发同步，条件写入（对已存校验和设 ConditionExpression）能防止过期同步覆盖更新的版本。

取舍很直接：单副本布局管理负担更小，版本化布局换来回滚和审计。两者在热路径上都是键读取，都不会把限流问题带回来。

改动本身的形状

迁移本身很小，这也是它成为正确选择的原因之一。

• 围绕查找来建模表。分区键放在提示词标识上，整个 schema 就这些，因为访问模式事先就已知。
• 热路径按键读取。每次推理调用做一次键读取。生产环境不对这张表跑扫描，成本与实际发生的读取成正比。
• 按校验和同步，不靠定时器，也不靠每次部署。真实来源驱动更新，只有真正的变更才跨进 DynamoDB。

结果是提示词检索不再是一个共享的、被限速的依赖，而变成对一个随流量伸缩的存储的键读取。

照抄之前值得记住的几点

这不是对提示词管理服务的反对。它们在编写、评审和治理上有自己的位置。错误在于让同一个服务待在高频读取路径上，而它从来不是按这个规模设计的。

• 症状是吞吐天花板跟着请求量走，而不是模型延迟。如果你正在给提示词检索包限流重试，那就是征兆，下游怎么调都挪不动它。
• 先按访问模式设计表。键查找要的是键 schema。分区键从你实际执行的查询里选，把扫描挡在生产之外。
• 让缓存自我纠正。对真实来源做校验和比对，意味着写穿同步只在内容真正变化时更新服务副本，不用手动折腾版本，也不重写未变更的数据。
• 需要版本就建模，别假设它不存在。排序键版本加当前指针，既给你回滚和审计，又让热路径保持单次键读取。

把提示词搬进 DynamoDB 是一次小改动，回报却不成比例。卡住流水线的限流没了，检索变成干净的键查找，校验和同步让服务副本对真实来源保持诚实。这套东西在生产环境里一直撑得住。