服务65万医生：OpenEvidence的架构与成本优化之路

当一款软件直接关系到医生的临床决策时，技术架构的可靠性与效率就不仅仅是工程问题，而是医疗安全问题。OpenEvidence 为医生提供基于同行评审文献的医学证据搜索服务，其工程团队在 Vercel 平台上实现了快速部署、弹性伸缩与成本大幅优化，支撑起覆盖全美超过 10,000 家医院和医疗中心的庞大用户群。

医疗场景下的技术挑战：不可接受的错误与停机

OpenEvidence 的定位是帮助医生在诊疗现场快速找到有引用来源的医学证据。无论是重症监护查房时核对剂量，还是在没有专科医生在场的情况下处理跨专科病例，医生都需要一个稳定、快速且值得信赖的工具。

工程负责人 Kush Khosla 直言："说实话，生死攸关并不夸张。我们面对的是急诊室场景，他们真的需要立刻知道发生了什么。正常运行时间对我们来说至关重要。"

另一名工程负责人 Andy Yoon 补充道，许多医生习惯了过时的软件，但更现代的体验必须满足他们对速度、稳定性和信息可信度的期望。团队规模虽小，却需要一种能在生产环境前测试更新、出错时快速回滚的机制。

这构成了 OpenEvidence 技术选型的底层逻辑：部署流程必须足够简单，回滚必须足够迅速，性能必须足够可靠。

小团队、大流量：Next.js + Vercel 的部署工作流

OpenEvidence 的医生端 Web 应用基于 Next.js 框架构建。团队的工作流与 Vercel 的预览部署能力深度整合：工程师将改动推送到开发分支后，Vercel 会自动构建并部署一个预览版本，生成链接供现场演示和同事试用；推送到生产分支则触发生产构建与部署；若发布需要回退，团队可以回滚到之前的部署版本。

Andy 解释了这套工具链对团队构成的适配性："我加入时，团队里几乎只有我一个人有真正的前端背景。大多数人做 Python 和机器学习。"正是这种人员结构，让 Vercel 的托管式部署能力成为团队规模扩展的关键支撑。

Kush 则从责任角度描述了这种工作流带来的心理影响："如果我推送一个前端改动，我知道大约五分钟内 65 万名医生就会看到这个改动。Vercel 直接接收并部署给所有人。每次推送代码时，这件事每天都在提醒我。"

流量洪峰下的零额外配置

OpenEvidence 曾意外在 TikTok 上走红，一周内获得约两百万次浏览。Andy 在 Slack 上看到消息时，流量已经开始攀升。他检查日志后发现，响应时间保持快速，错误率接近零，且无需配置任何额外容量——他随即回到了正常工作中。

Andy 表示："Vercel 完全跟上了使用量的增长。我们从未因容量问题宕机，也从未需要额外配置任何东西。能够信任它就在那里，甚至到了我们不太需要考虑它的程度，这非常了不起。"

这种弹性不仅应对突发峰值，也支撑了持续增长。Kush 提到，医生数量增长到原来的五倍时，他从未需要思考页面加载或首次绘制时间发生了什么变化。

Next.js 是一个基于 React 的开源前端框架，支持服务端渲染（SSR）、静态站点生成（SSG）和增量静态再生（ISR），并内置了文件系统路由、API 路由和图片优化等能力。对于 OpenEvidence 这类需要快速呈现医学证据、同时保证首屏加载速度的 Web 应用，Next.js 的 SSR 能在服务端完成数据获取与页面渲染，减少客户端等待时间；其路由与构建约定也让前端背景较弱的团队成员更容易上手。Vercel 正是 Next.js 的创建者，平台对 Next.js 的构建、预览部署和边缘网络做了深度集成，这是团队选择该组合的重要背景。

预览部署（Preview Deployment） 是现代前端托管平台的一项核心能力：每次向非生产分支推送代码，平台都会自动构建并生成一个带独立 URL 的临时部署环境。它让代码评审从“看 diff”升级为“看运行效果”，产品、设计和临床顾问可以在真实链接上验证交互，而不必在本地搭建环境。对于 OpenEvidence 这样前端人力有限、又需要医生参与试用反馈的团队，预览部署把测试与演示的成本降到了接近零。生产分支则对应正式部署，历史部署版本可随时回滚，形成“预览—验证—发布—回滚”的闭环。

成本优化：Fluid compute 与 90% 的服务端费用削减

随着使用量增长，工程副总裁 Micah Smith 开始关注计算成本。团队为 Vercel 上的函数启用了 Fluid compute，效果显著。

据 Micah 的描述："我们在保持同等性能的情况下将服务端费用降低了 90%，即便规模增长到 1000 倍，Vercel 在我们整体基础设施支出中的占比也不到 5%。"

Fluid compute 的核心机制是让多个请求共享一个运行中的函数实例，从而在某个请求等待数据库或 AI 后端响应时，实例可以处理其他工作。配合 Active CPU 定价模式，这段等待时间不产生 CPU 费用，但请求进行期间的内存仍会计费。

对于 OpenEvidence 这类需要频繁调用 AI 后端和数据库的服务而言，这种计费模型与工作负载特征高度契合。

Fluid compute 是 Vercel 提出的一种函数计算模型，针对传统 Serverless 函数“一个实例一次只处理一个请求”的冷启动与资源闲置问题。它允许同一运行实例在多个并发请求之间复用，当某个请求处于 I/O 等待（如调用数据库或 AI 推理后端）时，实例可以转去处理其他请求，从而提升单实例利用率并减少冷启动。与之配套的 Active CPU 定价只对请求实际占用 CPU 的时间计费，I/O 等待期间不计 CPU 费用，但内存按请求存续时间计费。这种模型特别适合 OpenEvidence 这类以等待外部 AI 和数据库响应为主的服务端负载。

面向患者的延伸：独立项目的隔离式部署

OpenEvidence 的第一款患者端应用 Take Home 允许医生将临床答案转化为通俗语言并分享给患者，患者登录后可以查看并保存证据。临床试验匹配也在该应用的计划方向中。

团队沿用了早期数十个概念验证项目形成的模式：每个应用作为独立的 Vercel 项目部署，拥有自定义域名。Take Home 同样拥有独立的项目和域名，工程师更新患者体验时无需部署其他应用。

Kush 解释了这种模式的延续逻辑："我们对 Next 和 Vercel 非常熟悉，能够获得独立部署、无缝运行且彼此隔离的效果。我们还有很多想进入的领域，那就把它做成一个新的 Vercel 项目。"

通过 Take Home，原本在问诊过程中帮助医生的证据，可以转化为患者在离开诊室后继续查阅的资料。

Vercel 项目（Project） 是平台上的部署与配置单元，每个项目绑定一个代码仓库、拥有独立的环境变量、构建配置、域名和部署历史。将不同应用拆分为独立项目，意味着一次发布只影响对应应用，故障域和回滚范围都被限制在单个产品内；同时各项目可以按自身流量独立伸缩，避免患者端流量波动波及医生端关键服务。对于产品线仍在扩张的小团队，这种“一个新方向就是一个新项目”的模式降低了多应用并行迭代时的耦合与运维负担。

工程效率背后的医疗价值

OpenEvidence 的案例展示了一条清晰的路径：对于资源有限但责任重大的工程团队，选择与自身技术栈匹配的托管平台，可以在不牺牲可靠性的前提下实现快速迭代与成本控制。据其官方信息，2026 年 1 月该平台支持了超过 2000 万次临床咨询，2025 年有超过 1 亿美国患者接受了使用 OpenEvidence 的医生的治疗。

当部署时间以分钟计、当流量洪峰无需人工干预、当基础设施成本占比降到个位数，小团队才能把注意力放回真正重要的事情上——帮助医生在关键时刻找到可信的医学证据。