Habitat

Habitat 是 OpenAI 自建的在线存储平台，让各产品代码不必直连数据库就能快速、可靠地读写所需数据。截至 2026 年 9 月，它每秒处理超过 7,000 万次请求，服务每周超过 10 亿人使用的产品，覆盖近 40 个地域，承载超过 500 PB 数据。OpenAI 将其定位为 ChatGPT、API、Codex与内部服务的公共存储层。本文依据 官方系列第一篇整理。

Habitat 的独特之处不是绝对规模——大型公司早有同量级系统——而是增长速度：过去三年每年增长超 10 倍，团队必须一边在现有栈上榨性能、抵御容量危机，一边补做基础建设。本条目对应 OpenAI 两部曲系列的第一部分（平台演进与 Python→Rust 迁移）；存储层优化、多租户可靠性与读性能分层留待 Part II。

平台职责

Habitat 在客户端与底层存储资源之间承担的工作：

底层存储资源包括 Azure Cosmos DB、Nanobase（在线存储）、Valkey（缓存）和 blob storage；变更数据捕获（CDC）服务把在线存储的变更近实时流出，供 Databricks、Rockset、Kafka 等离线系统消费。

从库到服务

Habitat 最初在 DevDay 2023 为支持 GPTs 上线，是一个连到单个 Azure Cosmos DB 的 Python 客户端库：schema 查找、路由、授权、加密、序列化、请求整形和连接池都藏在库里，产品工程师甚至不需要知道数据到底存在哪。这个库在没有中央强制推动的情况下自发普及，产品团队还自己往库里加客户端缓存、压缩和加密。

到 2025 年年中，客户端库形态达到极限：服务数量增多后，向后兼容的协议变更已不可行。压垮它的直接事件是要把最关键数据集迁到多个地域分布的 Cosmos DB 账户以缩小单地域故障的爆炸半径——客户端要加路由逻辑、藏进 feature flag、等所有团队升级客户端、再开开关。协调几十个服务的部署花了几天，加影子验证又几天，修 bug 又几天；等终于要开 flag 时，一个团队因无关原因把服务回滚到了带 bug 的旧客户端，正好造成这次迁移想避免的故障。

由此 OpenAI 把存储逻辑抽成独立服务，换来单一控制点：部署、可观测性和平台增强集中一处落地；同时它成为数据安全的咽喉——集中执行访问控制、审计日志，并收敛对底层存储资源的访问，防范外部、内部和 Agent 行为者的未授权访问。

Python 服务：把技术债写进排期

明知 Python 做高吞吐服务会带来更高的网络延迟和可观的 CPU/内存成本，团队仍然选择先用 Python 起服务，并称之为"战略性引入技术债"：当务之急不是成本优化，而是解除产品开发阻塞、建立核心 API、搭好基础设施。他们同时下了一个赌注——等 Python 必须被替换时，Codex 和 GPT 模型的进步会让迁移变得可行。这个赌注后来兑现了。

Python 服务能撑住的关键前提是尾延迟管理：一次用户请求平均触发数百次数据库调用，用户感受到的是最慢的那一次。痛点不是吞吐而是尾部：

• asyncio 提供 I/O 并发，但受 GIL 限制没有 CPU 并行；而 Habitat 的路由、压缩、加密、校验和、下游健康检查、请求影子与 hedging 都是 CPU 密集工作。
• 通过周期性调度后台任务并记录"预期与实际执行时间的差值"，可以实时测量事件循环调度延迟。高负载下，即使每进程并发请求数不大，调度抖动也能到数百毫秒，个别极端情况达数秒。
• 对策是让每个进程只服务少量并发请求，转而把 Python worker 进程数量大规模横向铺开——代价是把问题转嫁给下游（见下文"下游洪泛"）。OpenAI 明确建议：Python 服务除内存/CPU/网络/磁盘的标准利用率与饱和度指标外，必须监控 asyncio 循环繁忙度并据此调优。

尾延迟根因一：feature flag 配置解析

CPU profiling 找到的第一根因是 Statsig 的 feature flag 配置轮询：默认每分钟拉取一次、无 jitter，且配置包含所有服务全部生产规则；叠加每 pod 最多跑 8 个 Python 进程的架构决策，结果就是每分钟每个 pod 都有一个时刻，全部 worker 停下在途请求、把 CPU 花在解析一个大配置文件上。修复：改用更小的定向配置、拉长刷新间隔、给后台任务加 jitter。

尾延迟根因二：连接池 LIFO 复用

第二根因由一次意外事故暴露：停掉压垮服务一部分的客户端后，部分进程仍持续降级，且不断收到更多请求直到重启。元凶是 aiohttp TCPConnector 默认的 LIFO 连接复用：突发期间，慢服务器（已过载）的连接更晚归还连接池，于是被后续请求更频繁选中，流量逐渐集中到已不堪重负的 pod。把连接池改成 FIFO 复用打破了这个反馈循环，还顺带降低了稳态请求方差。

这类失效有专名：metastable failure——小扰动触发后经反馈循环自我放大，诱因早已消失、系统却仍停留在失效状态，直到人工重启。OpenAI 团队成员对此并不陌生，事故当时就有人凭先前经验识别出方向；该概念出自 Bronson 等人的 HotOS 2021 论文。

flowchart LR
    B["请求突发"] --> S["慢/过载服务器\n响应晚"]
    S --> P["连接更晚归还池"]
    P --> L["LIFO 优先复用\n最新归还的连接"]
    L --> M["后续请求集中到慢服务器"]
    M --> S

如今 OpenAI 基础设施主要依赖 Istio 和 Envoy 做连接池与服务端负载感知的均衡策略，从根上避开这类问题。

下游洪泛与 Envoy 收敛

把进程数横向铺开一个数量级后，下游连接数极易失控（thundering herd）：不调慢的日常部署会造成连接反复建立的 CPU churn；一次连接泄漏就可能打满 NAT 网关。这些不是罕见问题，但进程基数放大了一个数量级后，触发阈值大幅降低。

收敛手段靠 Envoy 做连接扇入（fan-in）：把 Python 的 HTTP/1 连接升级为 HTTP/2 以利用多路复用，再集中池化并延长连接寿命；限流和熔断也集中在这里实现——散落在各自独立的 Python 进程里效果会差得多。官方图示的量化对比：6 个 pod 峰值各 3 个请求，直连时 18 条连接打开但 12 条空闲；Envoy 池化后 6 条连接、零空闲；升级 HTTP/2 后稳态下 1 条连接承载 6 个并发流。

Why Habitat does less：故意削弱查询 API

Python 能撑到这个规模，另一半功劳是 Habitat 的受限 API。它只暴露简单 NoSQL 接口，而非允许任意 SQL——大表扫描、多表 join 这类不可预测 fanout 的请求正是运营危险的来源：破坏隔离与负载均衡，制造难以扩容应对的延迟断崖。设计目标是简单、可预测、常量工作量的请求；昂贵查询在客户端就显而易见。

这个取舍来自 Postgres 时代的教训：早期 OpenAI 在线数据大多在 Postgres 上，团队尚能逐条审查查询与 schema 变更确保走索引；随着团队和产品增长这变得不可管理，“热路径上一条昂贵的新查询拖垮整个数据库"是常见故障根因。文章将底层问题概括为成本不对称：写出昂贵难跑的 SQL 很便宜，跑起来却很贵。

Habitat 的数据模型是受 TAO 启发的对象-边结构：客户端预定义对象、边及其关系，但不定义每类的内容。结果像图，但 Habitat 不支持真正的图遍历——只能查某对象的直接边。分区时对象与其边同置（colocate）在存储级分区，但不刻意把对象与边指向的远端对象放在一起；于是水平扩展容易，图遍历低效——一跳可能要跨不同地域的两个 Cosmos DB 账户各取一次。

需要复杂查询的团队有逃生舱：CDC 把变更近实时流出，同步到各团队独立扩缩的隔离 Rockset 实例。配置多一层摩擦，但这是刻意取舍——简单查询做默认，复杂查询走带摩擦的旁路，把重读的分析/搜索负载与在线存储隔离。

从 Python 到 Rust：两个工程师一个季度

推迟重写一年让团队在超增长期先专注更紧迫的问题。到平台成熟、增长继续加速时，Habitat 已是 OpenAI 按核数计第二大的服务（Envoy 足迹第四），Python 峰值每秒服务超过 2,000 万次请求。

2026 年 Q2，仅 2 名工程师加上 Codex 和 GPT‑5.5，整个服务被重写为 Rust。新 Rust 服务已承接 95% 的生产请求，Python 将在数周内完全退役。官方给出的对比数据：Rust 版 CPU 效率高 6 倍、内存效率高 15 倍，平均和尾延迟显著更低；具体测试条件与延迟数字未披露，留待后续博客。这是"押注自家编码模型让迁移可行"这一赌注的直接验证——但 6x/15x 本身是 Rust 对 Python 的正常预期范围，模型贡献的是迁移工时，不是效率倍数。另一个值得留意但文中未讨论的问题：两名工程师承接整个服务的迁移，意味着新服务绝大部分代码由模型产出，这类交付的长期维护者理解成本正是 Comprehension Debt（理解债）所刻画的工程风险。

Azure Cosmos DB 与 Part II

服务层只是 Habitat 的一面。存储层——多租户可靠性、读性能分层策略，以及与 Azure Cosmos DB 合作扩展到 500 PB / 70M RPS 的方式——留待系列第二部分。