devgo.cn如果你所在的公司正在纠结要不要上生成式 AI、怎么上、谁来建平台，那么 DoorDash 内部 GenAI 平台团队的故事很值得听。他们从 2023 年 4 月签下第一份 OpenAI 合同时的忐忑，到今天内部 5000+ 用户、每天新增 45 人、其中 40% 是非工程师，这个历程里包含了大量踩坑、原则和转向的决策，比任何“AI 赋能企业”的通稿都具体得多。
先交代背景：2022 年 11 月 ChatGPT 引爆之后，很多公司开始尝试用大模型，但真正把 GenAI 做成一个内部平台、让整个公司的人都用得上的，并不多见。DoorDash 的做法是成立一个专门的 GenAI Platform 团队，隶属于 ML Platform 组织。你可能觉得这不就是搞个内部工具吗？但真正难的点在于：这不仅仅是技术问题，更是组织、原则、产品定位的问题。演讲者 Swaroop 和 Sidd 分享了他们从一开始就定下的四条原则：客户痴迷（不是老板痴迷）、构建产品而非系统（别让用户自己拼装流程）、让正确的事情变得容易（把最佳实践固化到平台里）、持续证明价值。这些原则听起来像正确的废话，但关键在于它们是后面所有决策的锚点——行业天天变，模型从 Llama 到 Claude 再到 Gemini，如果没有原则，很容易被牵着鼻子走。
他们踩的第一个坑是“客户变了”。原本团队服务的是机器学习工程师，习惯了聊 notebook、GPU、算力。但很快发现，真正会用 GenAI 的人是产品工程师，甚至是非技术人员。一次对话中，他们建议对方用 notebook，对方反问“什么是 notebook？”——那一刻他们意识到，受众已经完全变了。于是产品定位从基础设施转向 API First：不提供 GPU 或 notebook，而是提供统一的 API 和 SDK，让任何工程师（甚至法务、销售、运营）都能调用来构建自己的 AI 功能。
这个转变很关键，因为大模型使用的门槛不在于懂模型，而在于懂怎么接入。他们看到的需求集中在自动化（降低运营成本）和推荐/个性化（提升收入），最终把价值定位为帮产品团队在“准确性、延迟、成本”三者之间做最优权衡。
第二条主线是“采用带来责任”。当用户多了、场景杂了，尤其是非工程师也能调用 API 时，平台必须考虑可靠性、安全性和治理。他们做的一个核心项目是 LLM Gateway——一个统一的大模型网关。当时市面上模型非常多，OpenAI、Anthropic、Google 还有开源模型，每个接口都不一样，每个都有速率限制。如果每个产品团队自己去接各家 API，光是搞鉴权、重试、故障转移就够呛。于是他们提供一个统一 API 和 SDK，只写一个接口，内部自动路由到不同模型，还处理频率限制和 fallback。举个例子：你新出了一个开源模型，团队想测试效果，只需改一行配置，不用重写调用逻辑。
这听起来像是标准的企业中间件，但难点在于要跟上模型迭代的速度——每几个月就有一个新模型宣称更优，而你的平台要能让实验者快速切换、不阻塞生产服务。
更让我意外的是他们关于“容量”的教训。你以为买够 API 额度就完了？实际生产中，高并发下 OpenAI 也会限流，你需要设计好降级策略。平台的价值往往体现在这些看不见的地方：一个稳定、可观测、有兜底的入口，比一堆炫酷模型更重要。此外，他们明确不做聊天机器人、不做编码代理，而是聚焦业务影响。这个“克制”很重要——团队精力有限，什么都做会分散，结果什么都做不好。
对我们有什么启发？这套思路完全适用于任何想在公司内部普及大模型能力的团队：先想清楚服务谁、提供什么价值，再定原则，然后以 API 为标准交付，最后用统一网关解决多样性和稳定性。如果你正在建内部 AI 平台，别急着堆模型，先回答“你的客户是工程师还是非工程师？他们需要什么粒度的手段？”DoorDash 选择了 API 订阅式，你也许需要更细粒度的控制。另外，原则不能写在 PPT 里，要变成决策过滤器——当 OpenAI 涨价、新模型出现、业务方提出奇葩需求时，照原则判断就清晰多了。至于坑，最值得警惕的是以为技术领先就能覆盖治理和易用性，实际上非工程师占了 40% 用户，意味着你的产品必须像商业软件一样重视引导、文档和错误提示，否则他们根本不会用。
这条路没有终点，从模型到工作流再到 Agent，行业还在变，但这套“原则—赌注—转向”的方法论，确实是平台团队最值得抄的作业。
内容与图片版权归原作者所有 · 原文: https://www.infoq.com/presentations/doordash-genai-platform-architecture/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global