Durable 6人团队扛住3600亿token

每天处理11亿token，一年3600亿，团队只有6个工程师。这个数字放在任何一家AI公司都够开一场发布会，但Durable选择沉默——他们正忙着把省下来的人力，塞进产品里。

创始人James Clift的出发点很朴素：让创业比打工简单。美国60%成年人想当老板，实际做到的只有4%。差距不在野心，在摩擦——注册、建站、SEO、内容运营，每一步都是劝退点。Durable的解法是把AI塞进每个缝隙，让用户"几分钟启动，然后交给代理去跑"。

听起来像又一个AI建站工具？他们的客户确实这么以为。但底层架构完全是另一回事：多租户、多产品、数百万独立业务在同一套系统里跑，流量波动能差100倍。Clift的原话是："小企业死于工具、登录、流程和设计的千刀万剐。"Durable要当的是那把一次性拆完所有刀的剪刀。

自托管的代价：团队一半精力在修水管

早期Durable试过自己扛基础设施。结果很现实：维护多区域集群、给海量自定义域名配SSL、防DDoS攻击别波及邻居租户——这些活加起来，"足够做成第二个产品"。

工程负责人Khan列过几张痛苦账单：SSL终止费用按千美元计；基础设施工程师得盯着地理上分散的集群；某个客户被攻击时，得保证其他站点不受影响；最头疼的是成本归因——数百万租户里，谁吃了多少算力，必须算清楚才能定价。

这些问题在传统SaaS里存在，但AI代理的加入把复杂度翻了倍。模型调用不是网页请求， latency（延迟）、成本、可靠性波动都更大。Durable需要随时切换模型和供应商，不能被长期合同绑死，更不能每次换模型都重构系统。

他们选了激进路线：合并。一个代码库，一个基础设施平台，全部押在Vercel上。

从"AI当水管"到"AI当产品"

代理成为核心功能后，Durable遇到三个新问题，和托管网站完全不是一回事。

模型编排是第一道坎。不同任务需要不同模型，成本控制要求随时比价，稳定性要求多供应商备份。自托管意味着自己写调度层，而他们的团队规模不允许。

多模态处理是第二道。客户上传的图片、文档、语音，需要嵌入（embedding）、解析、再生成内容。每一步都涉及不同模型链，自己搭Pipeline（处理流程）的维护成本会压垮6人团队。

代理协作是最麻烦的。SEO代理、内容代理、运营代理之间要共享状态、避免冲突、统一记忆。这相当于在系统里跑多个异步进程，自托管的复杂度指数级上升。

迁移到Vercel后，这些被转交出去。按他们的说法，基础设施成本降到自托管的1/3到1/4，每个工程师、产品经理、设计师的生产力被放大10倍。

10倍杠杆从哪来

数字听起来像PR话术，拆解后更具体：部署频率从"数周"变成"单日"。新功能从代码到客户手里，以前要跨团队协调，现在一个人能端到端。

更隐蔽的收益在决策层。小团队的特点是信息损耗少——工程师直接听客户反馈，产品经理自己调模型参数，没有层层翻译。Clift提到过一个细节：他们能在一天内把生产级代理推给客户，不是因为流程快，是因为"需要说服的人少"。

这种结构也有代价。多租户架构下，成本隔离永远是紧张关系。某个客户的流量 spike（突增）可能吃掉邻居的预算，定价策略必须足够细才能公平。Durable的解法是实时归因+动态限流，但承认"还在迭代"。

另一个未解问题是供应商锁定。All-in Vercel省了当下的麻烦，如果平台政策变化或涨价，迁移成本同样巨大。Khan的回应很直接："我们赌的是，省下来的时间能让我们跑得够快，快到有谈判筹码。"

这个赌局目前看赢了第一步。3600亿token的年处理量，6个工程师，人均600亿。作为对比，OpenAI 2023年的API调用量是千亿级别，团队规模是数百人——当然业务完全不同，但这个数量级差异足够让中小团队重新算一笔账。

Durable的客户反馈里有一条被Clift反复引用：用户说"我以为自己在用一个工具，后来发现是一个团队在帮我干活"。这句话的潜台词是，技术架构的复杂性被成功藏在了产品体验后面。而藏复杂性的能力，可能是小团队打大公司的唯一护城河。

现在的问题是：当Vercel上的AI应用从几十个变成几千个，平台本身的资源竞争会不会让这套打法失效？Durable的工程师已经开始研究边缘缓存和模型蒸馏，但答案要等下一个流量 spike 来验证。