OpenAI Habitat 扩展通过共享存储实现读取速度提升 12 倍

OpenAI 表示，其 Habitat 存储平台目前可将全球读取中位数降至约 10 毫秒，低于此前的 120 毫秒。该公司在 10 月 23 日发布的工程说明中介绍了 OpenAI Habitat scaling 如何通过共享数据库容量、区域缓存以及与 Microsoft 更紧密的协作实现。核心矛盾在于运营层面：共享基础设施可以提高利用率，但要保护彼此无关的工作负载，则需要超越单纯增加容量的控制机制。

相关比较对象，是面向单个工作负载的专用存储，与具有可执行边界的共享存储。Meta 在分布式缓存方面的经验提供了历史参照。挑战在于，既要让常规操作保持快速，又要确保更新、流量高峰和故障期间的行为依然正确。

对开发者和企业买家而言，这关乎 AI 模型周边的应用基础设施。当应用无法检索服务请求所需的信息时，模型能力的重要性便大打折扣。存储性能同样需要谨慎解读：更快的数据库读取，并不意味着 ChatGPT 的回答会以同等幅度加快。

OpenAI Habitat 扩展重回共享容量

这一架构变化的核心，是让共享资源切实可行，而不必将容量规划重新交回每个产品团队。

根据 OpenAI 的存储扩展说明，Habitat 在尝试专用容器后重返共享容器。容器是一种保存记录、并关联容量设置的数据库分组。该公司称，热点键限流、请求优先级以及 Azure 容量调整，都是支撑这一转变的保障措施。热点键限流会在异常繁忙的记录或标识符压垮共享资源前，对其加以限制。

这一转变之所以重要，是因为隔离具有直观吸引力。为每个工作负载分配独立资源，所有权似乎更容易理解。团队可以检查自身流量、调整设置，并梳理直接依赖关系。当工作负载位于不同的资源边界中时，问题似乎也更容易得到控制。

然而，专用分配会带来各自独立的规划责任。每次发布都需要可信的流量预测，每项分配也必须为需求变化留出足够余量。一个组织可能在大量工作负载间积累闲置容量，却仍让某次单独发布准备不足。其他位置的可用资源不会自动帮助受限的工作负载。

共享容量通过汇集需求来解决这种错配。一个闲置工作负载可以为另一个工作负载腾出空间，前提是平台的控制机制允许。这使请求的分布与其总量同样重要。核心运营问题随之变为：系统如何在不牺牲常规流量的前提下处理异常情况。

Microsoft 的多租户数据库指南描述了隔离与可持续资源利用之间同样的根本冲突。多租户意味着多个租户或工作负载共享基础设施。Microsoft 解释称，即使容器仍有未使用的吞吐量，不均衡的访问模式也可能导致限流。限流是指当资源无法安全接纳更多工作时，对传入任务进行限制。

这种区别避免了对云容量的误导性理解。数据库整体可能仍有空间，而其中某个特定部分却已饱和。在不了解流量分布的情况下增加容量，可能无法消除原有瓶颈。反过来，将一切彻底分离，可能只是分散了瓶颈，而没有简化其管理。

实际含义是，共享需要一套明确的争用策略。产品团队需要知道哪些请求会受到保护，哪些请求可以等待。平台团队需要具备足够的可见性，以便在事故期间解释这些决策。缺少这些责任划分时，共享数据库就会变成一项只在需求保持舒适区间内才有效的约定。

因此，OpenAI Habitat scaling 除了技术变化外，也带来了一项组织层面的启示。存储架构决定了谁必须预测需求、谁可以介入，以及谁要承担错误预测的后果。

产品团队承担数据库边界的成本

当存储平台能够减少产品交付所需的基础设施决策时，它才真正体现价值。

OpenAI 早前关于 Habitat 服务设计的说明提供了组织层面的背景。该文于 9 月 11 日发布，描述了如何将数据库逻辑从客户端库迁移到独立服务中。客户端库是嵌入应用程序中的代码；独立服务则独立运行，并通过网络为这些应用程序提供服务。

该公司称，协调各产品服务中的库变更带来了部署问题。将逻辑集中化，使存储团队拥有一个统一位置来管理变更、访问控制和可观测性。可观测性是指收集足够的运营信息，以了解系统的运行状况。

这一选择为评估较新的存储变更建立了有用标准。集中化应当减少应用团队的工作，而不是仅仅迁移配置文件的位置。如果每项功能仍需要专门的容量规划，那么该服务只是隐藏了实现细节，并未消除运营负担。

以一次示例性的应用发布为例。内部测试期间，一项功能的使用量适中且可预测。公开发布则会带来不同的请求模式，包括流量突发以及客户之间不均衡的活跃度。功能团队了解预期体验，但这种了解未必能转化为准确的数据库需求预测。

专用分配会使该团队的预测变得至关重要。共享平台可以吸收一部分预测误差，前提是它具备充足容量和适当控制机制。这并不会消除发布准备工作，而是改变了哪些决策需要产品知识，以及哪些决策可由基础设施团队集中处理。

同样的分工在事故期间也很重要。应用开发者应识别受影响的用户旅程，并评估可接受的降级程度。存储运维人员则应判断争用、资源放置还是底层依赖是否是原因。当两个团队都必须各自重新梳理数据库架构时，恢复工作就更难协调。

对于企业买家而言，这会影响基础设施声明应如何纳入采购考量。基准测试描述的是特定条件下的性能。运营模式则说明供应商在这些条件发生变化时如何应对。两者都值得关注，尤其是在应用服务于优先级不同的多个部门或客户时。

后台报表任务与交互式用户请求也具有不同的容忍度。保护交互式请求可能合理，但延迟的报表任务仍需监控和明确归属。当低优先级任务最终能完成，同时又不威胁高优先级任务时，优先级策略才算成功。

这些选择应记录在团队能在发布或故障期间找到的技术文档中。维护一个可搜索的知识库有助于工程师保留资源边界与例外情况背后的决策逻辑。

因此，产品团队面临的压力是具体的：他们需要一份会随使用情况变化而依然易于理解的基础设施契约。平台团队面临的压力同样具体：让这份契约真正有用，而无需每位应用开发者都成为数据库运维人员。

全球缓存改变读取耗时的位置

最显著的性能改进，来自于避免请求路径上不必要的距离和工作。

OpenAI 将其报告的改进归因于选择性复制、Valkey 缓存和 Rust 重写。复制是在多个位置维护数据副本。Valkey 是一种内存数据存储，在这里用于保存缓存副本。Rust 是一种用于重构 Habitat 服务的编程语言。

这些变化针对不同的延迟来源。将数据放置在更靠近请求的位置，可以减少传输时间。复用附近副本可以避免重复检索同一信息。减少服务开销则会缩短应用程序与其存储数据之间的处理环节。若无单独测量，无法将它们的综合效果归因于某个单一组件。

在评估 ChatGPT 存储性能时，这一区别尤为重要。一次存储请求可能花时间等待网络、等待资源，或执行应用逻辑。某一类别的改进，并不能说明其他类别还剩下多少耗时。有价值的分析会追问：哪些等待被消除了，哪些请求仍会遇到它们。

缓存通过保留可复用的数据副本以加快访问，改变了高频重复读取的成本结构。底层数据库不再需要直接处理每一次访问。不过，应用程序现在依赖一种机制，来判断附近副本是否仍然适用。

一个示例性的设置查询可以具体说明这一问题。从附近缓存读取未变更的偏好设置，可以避免一次远程数据库请求。偏好设置变更后，同一缓存值便不再适用。基础设施必须将这次写入与仍保存旧值的位置连接起来。

Meta 的缓存一致性分析解释了这为何会变得困难。缓存一致性关注缓存值是否与底层数据保持一致。Meta 描述了缓存填充与失效操作之间的竞争，后者会移除过期副本。一个延迟操作可能以某种方式与更新的更新交互，进而让错误值仍可被获取。

更广泛的启示是，读取优化会带来写入侧责任。看似简单的读取之所以能够快速完成，是因为其他流程维持了让它保持安全的条件。只评估读取路径，会忽略支撑这一结果的机制。

对于 OpenAI storage architecture 而言，这是性能与正确性之间的重要边界。只有返回的信息适合当前操作时，更快的访问才有价值。不同数据类型可以容忍不同的新鲜度要求，因此通用存储接口仍需提供明确的行为保证。

报告中的中位数也值得精确理解。中位数代表测量分布中的中间观测值。它并不描述每一个请求，也不能证明每个地区的体验。中位数的大幅改善，仍可能与走不同路径的慢请求同时存在。

这使该结果具有意义，但不能将其解读为普遍的产品速度声明。它表明常见的存储路径已显著缩短。至于不常见读取、更新可见性以及存储对完整应用响应时间的贡献，仍有待进一步解答。

Azure 和 AWS 面临同样的需求不均问题

当云数据库比较聚焦于工作负载行为，而不是把容量视为单一数字时，才真正具有参考价值。

Amazon DynamoDB 是 AWS 的托管数据库服务，为共享资源管理提供了一个相关的比较案例。其自适应容量文档介绍了如何自动提高流量较大分区的容量。分区是数据库分布式存储与处理工作的一部分。

AWS 还表示，自适应容量仍受表容量和分区限制的约束。这一限定比泛泛承诺弹性更重要。弹性意味着随着需求变化调整资源，但并不意味着每一种访问模式都能无限扩展而不会遇到局部约束。

这只是补充背景，并非 DynamoDB 对 Habitat 而言表现更好或更差的证据。两项服务的设计、配置和运行关系各不相同。现有说法并未提供在相同工作负载下进行的受控比较。基于此对供应商进行排名，将超出证据所能支持的范围。

共同的工程问题是需求不均。某个热门客户、对象或工作流可能将请求集中到系统中的狭小部分。整体流量看似可控，但这种集中仍可能造成延迟。相关架构必须识别这种失衡，并在其发生的层级作出响应。

不同的应对方式也有不同成本。重新分配工作可以提升利用率，但需要安全的迁移机制。限制最繁忙的请求可以保护其他用户，但会改变受限工作负载的体验。保留冗余容量可提升准备程度，但会在资源真正需要之前就消耗资源。

专用设计会让某些边界更清晰，但并不能消除每项分配内部的需求集中。共享设计提供了更多整合闲置容量的机会，但需要更强的协调能力。两种方案都无法避免理解应用访问模式的必要性。

对买家而言，有价值的比较应从具有代表性的工作负载开始。测试应包括集中需求、常规混合流量以及中断后的恢复。与产品发布期间不可预测的客户活动相比，均匀分布于各条记录的稳定工作负载回答的是一个更狭窄的问题。

同样的原则也适用于有关自动扩缩容的说法。应询问什么会触发调整、调整生效期间会发生什么，以及哪些边界仍然固定。还应询问，应用是否必须在已知事件前预先准备容量。这些细节决定了自动化是减少运维工作，还是仅仅改变其发生时点。

AWS 的文档化应对方式支持对 OpenAI Habitat 扩缩容作出更广泛的理解：管理需求不均是分布式数据库的核心问题。它并不专属于某一家云服务商或 AI 产品。

因此，有意义的竞争在于不同运营模式能否成功控制资源争用。供应商功能固然重要，但其价值取决于工作负载、周边控制措施以及负责使用它们的团队。

更快的中位数仍留下新鲜度与恢复问题

这一性能数字是公司自行报告的测量结果，本身无法证明正确性或韧性。

OpenAI 的说明是一项工程披露，而非独立复现的基准测试。读者可以评估其机制和报告结果，同时保留这一差异。恰当的结论是：该公司报告称其生产环境测量下取得了显著改进，但仍有重要维度需要单独的证据支持。

其中一个维度是中位数背后的分布。尾延迟描述请求耗时中较慢的一端。对于需要执行多次相互依赖查询的应用，偶发的一次慢操作可能主导用户的等待时间。要理解这种体验，仅看中间值并不够。

另一个维度是更新可见性。变更数据捕获，即 CDC，会将数据库变更信息分发给其他系统。OpenAI 表示，它利用 Cosmos DB 的更改源，在数秒内推动全球范围的缓存失效。该机制带来了有关延迟投递、恢复，以及消费者落后时系统行为的问题。

Microsoft 的更改源模式文档说明了为何实现细节至关重要。最新版本模式会报告创建和更新，但不会将删除作为变更捕获。全版本及删除模式则有不同的覆盖范围和配置要求。

这些文档化差异并不能证明 Habitat 存在缺陷。它们指出了任何使用变更流的系统都必须回答的问题。变更流是持续不断的数据库更新通知序列。其消费者需要具备与其支持操作相匹配的行为。

例如，一个示例性的知识应用可能需要从搜索结果和缓存摘要中移除已删除的内容。仅接收更新通知，并不能证明删除处理有效。应用需要明确的删除路径，并提供下游副本按预期响应的证据。

授权构成了另一条重要边界。授权决定某个行为主体是否可以执行特定操作。不能想当然地认为通用缓存策略能够提供每项权限决策所需的新鲜度。读者应寻找与相关操作相绑定的保证，而不是从总体性能中外推结论。

恢复带来了另一项考验。一个系统可以在所有依赖项可用时运行很快，却在中断后难以恢复。缓存数据、待处理更新和底层存储必须恢复到一致的运行状态。相关证据包括恢复演练，以及依赖项故障期间观察到的行为。

这些是分析性问题，并非对未披露事故的指控。它们有助于区分公告所测量的内容与企业用户必须针对自身需求评估的内容。它们还避免一个常见错误：让一项解释充分的性能提升替代无关的保证。

因此，ChatGPT 存储性能最好被理解为一组属性。速度、新鲜度、可用性和恢复能力彼此关联，但每一项都需要恰当的测量。可信的架构会让这些相互作用足够可见，以便运营者管理、客户评估。

关注尾延迟、共享工作负载稳定性与存储部署

下一批有价值的证据将显示，这一运营模式能否在更复杂的请求和不断变化的工作负载中持续有效。

未来几个月，首先值得关注的信号是包含较慢请求的区域延迟细分数据。这样的披露将显示，改进是否延伸到常见路径之外。广泛的改善将增强该架构对用户体验影响的论据。持续存在的区域异常值会缩小这一结论的适用范围，但不会抹去中位数结果。

有价值的细节应将测量结果与请求类别相联系。已缓存和未缓存读取可能面临不同的工作，因此将它们合并会掩盖重要差异。区域测量也有助于区分服务本身的改进与数据放置的改进。

这一信号对产品评估很重要，因为用户体验的是完整工作流。快速查询很有价值，但其实际影响取决于它在该工作流中的位置。将存储变更与应用行为关联起来的证据，会让结果更容易解读。

第二个信号是混合工作负载和重大发布期间的持续稳定性。相关披露应说明，当其他活动增长时，交互式流量是否仍受到保护。成功控制的证据将支持共享容量方法。无关工作负载之间反复相互干扰，则会暴露控制机制或其配置的局限。

最有力的说明还应包括对延迟后台工作的处理。保护前台请求可能将压力转移到其他地方，因此稳定性还应包括最终完成情况和可管理的积压。积压是等待处理的工作。其表现有助于揭示优先级系统是在解决争用，还是仅仅将其推迟。

产品团队还需要证据证明，该运营模式能够减少规划工作。更少的人工干预将支持集中化的组织层面论点。如果仍需要频繁的应用特定例外，则表明复杂性依然分散，即使数据库分配已实现共享。

第三个信号是 OpenAI 计划中的大体量数据定制存储系统的生产证据。该公司称该系统仍在开发中，以较低的峰值请求容量换取更低的闪存需求。部署结果将明确哪些工作负载适合这一权衡。仅凭设计公告无法证明其生产影响。

这一信号应通过工作负载适配性来评估，而不是因定制基础设施本身的吸引力。大型数据的访问需求可能不同于频繁请求的小型记录。成功的部署应解释这些边界，并展示新系统如何与现有存储协同运行。

这些信号共同提供了一种具体方式，用于追踪 OpenAI 的存储架构，而无需期待预定公告。它们是值得关注的证据，而非承诺会披露的内容。每一项都检验核心主张的不同部分：更快的常见读取、可控的争用，以及可持续的增长。

对于开发者和企业买家，应利用这份说明来完善下一次基础设施审查。询问哪些操作需要新鲜数据，哪些工作负载共享容量，以及正常读取路径失效时会发生什么。请求能够将数据库行为与用户实际执行的工作流联系起来的测量结果。记录例外情况，让后续团队理解特定边界存在的原因。OpenAI Habitat 扩缩容提供了一个将运营责任转移到平台中的有用案例研究，但复制其组件并不能复现其结果。请将所报告的机制与自身的需求模式和恢复要求进行比较。从延迟或错误结果影响最大的操作开始，然后检查为其提供服务的完整路径。