Stanford CS 153: Infra @ Scale - Cursor CTO & Co-Founder Sualeh Asif

Cursor联合创始人兼CTO Sualeh Asif在Stanford CS 153分享基础设施百倍增长实战：数据库生死事故、对象存储迁移、模型供应商谈判链

• Cursor 过去一年规模增长约 100 倍，自研模型每天处理约一亿次调用，自动补全在每次按键时运行，峰值每秒约两万次模型调用，跑在全球分布的约一千到两千张 H100 上。 占前沿模型（Frontier Model）流量的"相当大比例"，索引系统每天处理约十亿份文档，累计达数千亿份。这已经是一个真正的全球规模大型服务。
• Cursor 的三大基础设施支柱是索引、模型和产品层。 索引包括检索系统和 Git 历史理解；模型包括自研自动补全模型和前沿模型调用；产品层包含 apply 模型等让用户体验流畅的工程技巧——apply 看起来像复制粘贴，实际是一个处理十万到二十万 token 的模型。此外还有支撑持续改进的数据流基础设施。
• 两次标志性 Sev 事故揭示了分布式系统的深层挑战：2023 年 9 月索引系统因 DynamoDB 缓存 bug 和 Merkle 树竞态条件引发无限循环；后来 Postgres 数据库 22TB 膨胀导致 vacuum 失败、数据库完全卡死。 后者的解决方案是联合创始人 Arvid 在事故现场用两小时将核心存储重写到对象存储（S3/R2）上——一个临时救急方案最终成为正式架构方向。
• 与模型提供商的容量博弈是日常运营的核心痛点。 Cursor 可能是多家前沿模型提供商最大的客户之一，经常面临速率限制和提供商宕机。应对策略是同时跑多个提供商、多云部署、实时在提供商之间平衡流量。新模型发布前夕打电话要配额是常态——3.5 Sonnet 发布前夜联合创始人 Aman 还在找人帮忙联系 Anthropic 要更高配额。
• 贯穿全场的核心线索是"用小团队做大规模基础设施"的哲学。 从选 Postgres 弃 YugaByte 的"不要搞花活"原则，到事故现场实时重写系统迁到对象存储，到用 AI 辅助覆盖远超团队规模的基础设施面积，Sualeh 反复展示的是同一个理念：简洁的架构 + 极强的个体能力 + AI 杠杆，比堆人堆复杂系统更有效。

核心要点：Cursor 过去一年增长百倍，自研模型日处理一亿次调用，索引系统日处理十亿文档，已是全球规模的大型基础设施服务。

• 自动补全模型在用户每一次按键时运行，峰值每秒约两万次模型调用，跑在约一千到两千张 H100 上。从输入 token 量看，自动补全远超前沿模型调用，因为每次按键都命中几万个 token。
• GPU 集群分布在美国东海岸（Virginia）、西海岸（Phoenix）、伦敦和东京。曾尝试在法兰克福部署但不太稳定。全球分布确保日本用户的自动补全体验依然相对快速。
• 索引系统每天处理约十亿份文档，公司成立以来累计达数千亿份。部分用户的代码仓库规模达到 Instacart 等大公司的水平。
• Cursor 占前沿模型流量的"相当大比例"，同时也开始自己托管一些大模型。

"过去一年我们的规模大概增长了 100 倍，有些方面甚至更多。" —— Sualeh Asif

核心要点：Cursor 的基础设施分为三大支柱——索引系统理解代码仓库、模型层处理自动补全和前沿推理、产品层用精巧工程让体验感觉"不像在用模型"。

• 索引系统：包括检索系统（用户向 agent 提问时搜索代码仓库）和 Git 历史索引（理解代码仓库的演变过程）。设计原则是完全自动化——用户打开编辑器就自动索引，不问任何问题，成本由 Cursor 承担。
• 模型层：自研自动补全模型在每次按键时运行；前沿模型（Anthropic、OpenAI 等）处理更复杂的推理任务。两者的流量特征完全不同。
• 产品层：apply 模型是核心代表。用户感受是"像复制粘贴一样快"，实际上是一个模型在处理十万到二十万个 token。这种"让你觉得根本没有在使用模型"的体验，背后是大量推理层面的优化技巧。
• 第四个隐藏支柱是数据流基础设施：存储和处理输入数据，用于筛选和后台改进。不是用户直接交互的东西，而是"每天让 Cursor 变得更好"的引擎。

"你希望 apply 感觉非常快，快到你觉得根本没有在使用模型，感觉就像是复制粘贴一样。但实际上当然不是复制粘贴，而是一个模型在处理十万到二十万个 token。" —— Sualeh Asif

核心要点：Cursor 采用大单体架构（monolithic architecture），但通过严格的服务隔离确保关键服务不受实验代码影响；服务端代码以简洁为最高原则。

• 用户请求打到东海岸的服务器，整体是一个大的 monolith 部署。这种规模下的关键是：把真正重要的东西放在安全隔离区域，与实验性代码分开。
• 2023 年 6-7 月的教训：所有东西跑在一个大服务器上，有人写了一个"特别恶心"的无限循环，结果把别人的 chat 服务搞挂了。此后服务器隔离划分变得核心优先级。
• 用户使用 Composer 写代码时，后台有大量请求在判断代码仓库中哪些内容该被选入最终的 prompt。服务端和全球客户端之间维持双向流。
• 架构核心原则："服务端代码必须保持严格的简洁。如果太复杂你就无法理解，无法理解就没法可靠运行。"

核心要点：索引系统用客户端-服务端 Merkle 树协调文件变化，但 DynamoDB 缓存的隐蔽 bug 加上 Merkle 树的竞态条件，引发了一场痛苦的级联故障。

索引系统的核心机制是 Merkle 树同步：客户端和服务端各维护一棵树，每个文件有哈希值，文件夹哈希由子节点组合而来。当用户关机重开或 checkout 旧版本时，通过对比根哈希逐层下降找到变化的文件。

Sualeh 在 MIT 时是数据库迷，最初选了 YugaByte（Google Spanner 的后代），认为它能"无限扩展"。结果"死活搞不定它"，花了很多钱缩减节点数也跑不起来。教训是迁移到 RDS Postgres——"不要选复杂的数据库，用超大规模云厂商的就好，他们知道自己在干什么。用 Postgres，别搞花活。"

迁到 Postgres 后流量飙升，暴露了一个级联故障链：

1. 缓存层 bug：DynamoDB 缓存有个隐蔽 bug——如果文件够大就不会被缓存，而团队没有监控这个数据库的错误率，完全没发现。

2. Embedding 模型过载：大文件绕过缓存直接打到 embedding 模型，推高负载。

3. Merkle 树竞态条件：分块和 embedding 完成后要更新 Merkle 树上层节点的哈希，这个操作在队列上存在竞态条件，大文件无法提交。

4. 无限循环：客户端发现大文件没提交就重试，重试时缓存又 miss，又打到 embedding 模型，又提交不了——永远循环。

• 全局错误率看起来完全正常——问题只出在那些约六十行的大文件上，正是这些关键文件引发了所有连锁反应。诊断花了"非常痛苦的一周"。
• 修复路径：先注意到缓存命中率异常，修复缓存 bug 后追查提交失败的原因，最终定位竞态条件。Sualeh 强调即使知道大概率存在竞态条件，在生产环境中找到它也"极其艰难"，"最终靠的就是大量仔细的思考"。

"分布式系统中的竞态条件——上过分布式系统课的人都会告诉你，它们极其隐蔽难以发现。而在实际生产中找到它们同样困难。" —— Sualeh Asif

核心要点：RDS Postgres 膨胀到 22TB 后因 vacuum 失败完全卡死，无法重启。联合创始人 Arvid 在事故现场用两小时将核心存储重写到对象存储上，成为比所有其他修复方案更快的解决路径。

索引系统修复后"漂亮地运行了大概八个月，没有任何事故"，Sualeh 甚至忘了有监控仪表盘。然后某天被大量告警吵醒——缓存和 embedding 模型全面报警。

根因是 Postgres 的工作负载特性与存储机制的冲突：Postgres 的更新不是原地修改（MySQL 的做法），而是一次删除加一次插入。用户每次打字都触发大量删除和重新插入，空间不释放，只靠后台 vacuum 进程清理。当 vacuum 和 anti-wraparound vacuum 都出问题后，数据库变成"一辆启动后就磨磨蹭蹭最终完全停下来的车"——限流、清理积压、恢复流量、又停，反复循环。

折腾几个小时后数据库甚至无法重启。Sualeh 给朋友 Martin 打电话求助 RDS 专家，AWS 支持"完全不知道怎么回事"。团队中有一位 GitHub 前基础设施副总裁对数据库了如指掌。最后甚至跟 RDS 架构师——"写这个数据库的人"——通了电话，对方说："呃，我也帮不了你们太多，你们的情况很严重。"

Sualeh 同时分配多路任务：一人删除所有外键（22TB 中有些表有四个外键关联，给数据库增加大量指针追踪负担）；一人重写工作负载（22TB 中一张表占 20TB）；其他人尝试各种疯狂方案。所有参数已调到最大——"这是 AWS 上能找到的最大的 RDS 实例，不可能再大了。"

关键转折：Sualeh 在事故中间对联合创始人 Arvid 说"试试把这个迁到对象存储上"。Arvid 的任务是把占 20TB 的 chunk 存储表重写到对象存储。结果他竟然比所有其他修复方案更快完成——因为这是 Cursor 经历过的持续时间最长的 Sev 之一。大约十个小时后团队决定放弃救活当前实例，将流量切到 Arvid 两小时前刚写好的新系统。

"就是有人跟你说'我的代码没 bug，不需要测试，我两小时前刚写的'——然后你要把你跑的最高吞吐量的服务放上去。" —— Sualeh Asif

Sualeh 强调他对 Arvid 有"绝对的信任"。现在 Cursor 还有一个新项目要把整个系统都迁到对象存储上，"干掉中间所有的数据库。因为扩展数据库的最好方式就是——不要数据库。"

Andre 指出这个故事的节奏与 CS 153 第一课讲的 Midjourney Sev 事故惊人相似——"事故响应的物理规律最终看起来惊人地相似。总有基础设施团队中的一个人成为关键人物，他的重构方案最终成为比你预期稳定得多、持续得多的正式方案。"

核心要点：Sualeh 认为"把数据库构建在对象存储（S3/R2/Azure Blob）之上"是近年数据库领域最重要的趋势——对象存储极度可靠、扩展性极强，写数据库最难的存储层问题直接消失。

• 数据库领域的三个"传奇"：Google Spanner（全球规模）、FoundationDB、Redis 等 KV 存储。"基本上有了这三个你可以搞定一切——也许再加个分析引擎。"
• 2010 年代早期的趋势是大型分析引擎（Snowflake、Databricks），以向量化操作著称。最近的趋势是将数据库构建在对象存储之上。
• 代表案例：Warp Stream（被 Confluent 收购），将 Kafka 重写为运行在 Blob 存储上。Sualeh 补充说"如果你要组建基础设施团队，人们会告诉你的第一件事就是'永远不要自己跑 Kafka'——它就像癌症一样难以根除。"
• Cursor 依赖的 Turbopuffer：一个基于对象存储的向量数据库。
• 对象存储的核心优势："世界上没有什么比对象存储可靠性更高的东西。"写数据库最难的是存储层，容易出现数据损坏；基于对象存储可以绕过这个问题。

核心要点：推理服务的冷启动问题被严重低估——全部节点宕机后如果不做流量管控就恢复，先起来的少数节点会被所有用户请求冲垮，"还没来得及变健康就被打死了"。

• Sualeh 直言"推理这件事没有人已经完全搞明白"，虽然各家都在全球规模运行，但"大家都还相对不成熟"。
• 某个不具名提供商在 Cursor 扩容过程中刚搭起推理服务。Cursor 每天要求"每分钟多一千万 token，不对，一亿 token"，结果对方在三四千万 token/分钟时就崩了——"缓存还没搞定。"
• 冷启动场景：假设跑着每秒十万次请求的服务，所有节点都挂了。从一千个节点中先拉起十个——这十个会被全部流量冲垮。解决方案：要么杀掉一部分流量，要么做用户优先级划分，要么像 WhatsApp 那样先恢复某些关键前缀路由。
• "看看各大模型提供商的状态页面吧，历史可靠性都很糟糕，没有人的可靠性是好的。"

"我不认为推理这件事有人已经完全搞明白了。虽然我们和其他人都在全球规模上运行这些服务，但大家都还相对不成熟。" —— Sualeh Asif

核心要点：Cursor 大约一周半前经历了一次约 230 分钟的宕机，起因仅是一个单行代码改动——"如果你看那个改动，你根本不会发现问题"。Sualeh 认为 AI 模型审查代码在捕获此类隐蔽 bug 上已接近实用。

• 在严重级别一到五的尺度上（一最严重），这次事故被评为一级。Andre 开玩笑说"可能应该是零级"。
• Sualeh 透露如果当时跑了团队正在开发的 bugbot，就能抓住那个 bug。Chris 正在发布这个 bugbot 工具。
• 关于事故中的人："有两种人——一种是变得焦躁的，另一种是真正活过来的。我们有一位联合创始人，他不喜欢日常运维工作，但他热爱 Sev。你能见到他最开心的时候就是在一场 Sev 的正中间，一切都在崩溃。"

核心要点：Cursor 可能是多家前沿模型提供商最大的客户之一，容量谈判是日常运营核心。从 Cursor 到 Anthropic 到 Google TPU 团队到 Borg 团队，需求沿着一条长长的电话链向上传递。

• 系统中"最混乱的部分之一"就是处理速率限制和 token 配额的那套系统。Cursor 同时跑在多个提供商上，它们"经常宕机"。
• Andre 描绘了一条生动的电话链：Cursor 联合创始人 Aman 在 3.5 Sonnet 发布前夜给 Andre 发邮件，问谁认识 Anthropic 的人、能不能帮拿到更高配额。然后 Anthropic 打电话给 Google 要更多 TPU，Google TPU 团队打电话给 Borg 团队问什么时候能上架更多服务器。"取决于具体哪天，以及在这个链条中谁是瓶颈。"
• 应对策略：同时联系多个提供商（AWS、Google Cloud、OVH），问"谁能先给我们更多 token"，然后在提供商之间平衡用户流量。"各提供商的销售团队之间基本上形成了竞态条件，争着来找你。"
• Sualeh 将此比喻为"云计算时代早期的容量预留谈判"，但"没有人预料到当前推理工作负载跳跃式增长的幅度"。

核心要点：Cursor 创始团队在 MIT 时就关注 scaling laws，最初认为 Copilot 背后的 Microsoft+OpenAI 是"不可战胜的梦之队"。但 Copilot 有一年半没做任何改进，"拥挤"是后视镜偏差。

• 创始团队最初的想法就是做编程产品，但因为 Copilot 的存在先去尝试了"一些其他复杂的方向"。直到发现 Copilot 停滞不前才回到编程方向。
• Sualeh 认为天花板"一直延伸到自动化大部分工程工作"，但当时除了自动补全什么都看不到。"最长的一段时间里，基本上没有人在做真正的竞争。"
• 关于代码安全：即使在 embed 代码时也使用加密技术，向量数据库中的所有向量用存在用户设备上的密钥加密。"即使有人拿到了向量数据库——这本身就很难——最坏情况下他们也无法解读。"Sualeh 说虽然 99.99% 确定无法从向量反推代码，但"因为这不是一个可证明的事实，有这层加密更安全。"

核心要点：Cursor 投入大量精力应对创造性的滥用者，同时坚持 20 美元定价——"比起涨价，我们花大量精力优化系统就是想让大家能轻松用得起"。

• Sualeh 公开邀请：如果有人能找到获取免费 token 的方法并负责任地报告，Cursor 会给予免费订阅——前提是"负责任披露"。
• 最近的案例：有人创建了数万甚至数十万个 Hotmail 帐号，用相对稳定的域名（不是垃圾域名），从约一万个 IP 地址发送流量，有十万个分片用户——不是 DDoS，而是"想在免费额度上跑自己的服务，把代码写完"。
• 定价策略：对行业内的人来说 20 美元根本不算什么，涨价是更容易的选择。但 Cursor 选择用大量系统优化来维持低价。"每一次按键都在做大概一千亿次浮点运算，就是很多的算力。"

"模型是贵，但它们太有用了。它们值的比一个汉堡多，就付那 20 美元吧，我保证值得。" —— Sualeh Asif

核心要点：Sualeh 不认为学 CS 是浪费时间，反而认为 AI 会让人更有创造力——"未来会有更多的系统涌现，而不是更少"。IDE 不会消失，但定义可能改变。

• "不现实的版本是'我们都会失业'。现实是：越来越多的工作会被自动化"，但"没有理由花时间去架构和设计新系统"这个说法是不对的。
• Cursor 本身就是例证：用一个"非常有才华但规模不大的团队"覆盖了远超预期的基础设施面积，AI 辅助是关键杠杆。Sualeh 预期这个比例会越来越大。
• 类比："比如给函数调用加个参数——这就像问足球运动员是不是只在动腿。他们确实在动腿，但那是最有意义的部分吗？"
• 关于 IDE 的未来："程序员会不会有一个用来写代码的工具？会。好了下一个。"——形式可能变化，但工具本身不会消失。
• 关于是否该辍学创业："这个选择对你来说应该是显而易见的。如果显而易见就去做，如果不是就别做。"

| 项目 | 详情 |

|------|------|

| Sualeh Asif | Cursor CTO & 联合创始人，MIT 毕业，自称"数据库迷" |

| Arvid | Cursor 联合创始人，在 Postgres 危机中两小时内将核心存储重写到对象存储 |

| Aman | Cursor 联合创始人，3.5 Sonnet 发布前夜找人帮忙要 Anthropic 配额 |

| Michael | Cursor 联合创始人，事故中喊"我们能不能把服务恢复" |

| Chris | Cursor 团队成员，正在发布 bugbot 工具 |

| Martin | Sualeh 的朋友，数据库危机时被求助找 RDS 专家 |

| Andre | CS 153 课程主持人/访谈者 |

| GitHub 前基础设施副总裁 | Cursor 团队成员，数据库危机中发挥关键作用 |

| Ben Mann | Anthropic 联合创始人，上一周 CS 153 嘉宾 |

| 自动补全模型 | 每次按键运行，峰值每秒约 2 万次调用，约 1000-2000 张 H100 |

| Apply 模型 | 处理 10-20 万 token，体验像复制粘贴 |

| Bugbot | Cursor 内部开发中的 AI 代码审查工具 |

| YugaByte | Google Spanner 后代，Cursor 早期使用后因扩展困难放弃 |

| RDS Postgres | 替代 YugaByte 的选择，22TB 时遭遇 vacuum 危机 |

| DynamoDB | 索引系统的缓存层，大文件 bug 引发级联故障 |

| Turbopuffer | 基于对象存储的向量数据库，Cursor 依赖的核心组件 |

| Warp Stream | 将 Kafka 重写为运行在 Blob 存储上，被 Confluent 收购 |

| Merkle 树 | 客户端-服务端文件同步机制，通过哈希值逐层对比定位变化 |

| 每天 1 亿次 | 自研模型日调用量 |

| 每天 10 亿份 | 索引系统日处理文档数 |

| 22TB / 64TB | Postgres 数据量 / RDS 存储上限 |

| 约 230 分钟 | 最近一次一级事故的宕机时长 |

| ~100 倍 | 过去一年的规模增长倍数 |

| 20 美元/月 | Cursor 订阅价格，团队坚持不涨价 |

| 1000 亿次 | 每次按键的浮点运算量级 |