Vercel后端新布局：Python正式版、容器与Daemons

Vercel正在从"前端部署平台"向"全栈应用运行平台"转型。在旧金山Vercel Ship大会上，官方一口气抛出三项后端能力更新：Python支持正式GA、容器运行时开放、以及面向常驻后台任务的Vercel Daemons进入公测。

Python后端正式可用，15万团队已在跑

Python on Vercel结束预览阶段，转为通用可用（GA）。开发者可以用熟悉的Vercel工作流——本地开发、预览部署、生产发布——来运行FastAPI、Flask、Django等框架，底层是标准CPython加上来自PyPI的依赖。框架识别、构建和弹性伸缩由Vercel接管。

官方披露，目前已有15万团队在Vercel上运行Python后端，其中不乏OpenAI、Polymarket、Exa等明星公司。配套的Python SDK让应用可以直接调用Vercel的产品矩阵：用Vercel Blob存文件、用Queues投递后台任务、用Workflows编排持久化步骤、在Sandbox中运行不受信任的代码，以及通过AI SDK for Python做模型响应流式输出和工具调用。

一个值得关注的案例是Delphi——这家用书籍和演讲构建"AI数字心智"的公司，把Python后端从AWS ECS整体迁到了Vercel。团队只有十名工程师，没有专职基础设施岗，却能每天向生产环境发布超过100次，并用Queues处理后台任务。其创始工程师Spencer Schoeben的评价很直接："用Vercel，我们几乎完全不用考虑基础设施。"

GA（General Availability，通用可用） 是云服务生命周期中的一个阶段标志，介于预览（Preview/Beta）与正式商用之间。进入GA通常意味着三件事：API 和行为被冻结并承诺向后兼容、服务等级协议（SLA）生效、可以放心用于生产环境。在GA之前，平台往往保留随时调整接口或暂停能力的权利，因此很多企业团队会刻意回避预览阶段的功能。Python on Vercel 从预览转GA，实质上是把此前「可以用但不建议上生产」的状态，变成了可承载关键业务的正式能力，这也是官方强调「15万团队」这一规模数据的意义所在。

容器运行时：任何语言都能上Vercel

Vercel容器运行时允许部署任意语言编写的应用，并把所需的操作系统库和可执行文件一并打包。该能力从公测至今，已有5000个团队完成了15万次容器部署。

容器的定位是"Vercel Functions"的一种形态，跑在Fluid compute之上，随流量伸缩，并采用Active CPU定价——等待API响应、数据库查询或LLM推理的闲置时间不计费。配合Vercel Services，前后端可以一起开发部署，CDN负责流量分发，WAF负责防护，日志用于排查问题，回滚可以恢复早前版本。

官方给了一个视频应用的例子：用容器做后处理，为每个上传片段生成播放副本和缩略图。Dockerfile把Python处理器、依赖和ffmpeg打包进同一个镜像，通过Git或Vercel CLI部署时，Vercel会构建镜像并存入Vercel Container Registry。

FROM python:3.12-slim
RUN apt-get update \
  && apt-get install -y --no-install-recommends ffmpeg \
  && rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY processor.py .
CMD ["python", "processor.py"]

Fluid compute 是 Vercel 对传统无服务器执行模型的一种改造思路。经典 FaaS 一个请求对应一个函数实例，实例闲置即销毁，冷启动和资源复用效率都受限。Fluid compute 让多个并发请求共享同一实例，并在请求之间保留已初始化的运行时环境，从而降低冷启动开销、提高资源利用率。对定价的直接影响是：只有当 CPU 真正在计算时才计费，等待外部 I/O（如调用第三方 API、查询数据库、等待 LLM 返回 token）的时间不计入。这正是文中「Active CPU 定价」得以成立的技术前提，对以模型推理为主的 AI 应用尤其有利。

Daemons：常驻后台工作进程

传统Serverless函数按请求触发、执行完即退出，不适合需要持续轮询任务的场景。Vercel Daemons填补的正是这块空白：把容器作为持续运行的后台工作进程部署在Fluid compute上，你可以指定每个区域的实例数量，Vercel负责维持这个容量——进程退出或崩溃时自动重启。

Daemons公测阶段支持"拉取式"工作负载，也就是代码主动向其他系统请求任务并处理，比如消费队列消息，或者从数据库拉取待处理作业。在视频应用的例子里，Daemons让视频处理器持续运行，从Vercel Queues拉取任务。

配置写在vercel.toml中：定义Next.js前端服务并路由请求到它，再用Dockerfile声明处理器作为daemon。

#:schema https://openapi.vercel.sh/vercel.json

[services.frontend]
framework = "nextjs"
root = "."

[[routes]]
src = "/(.*)"
destination.service = "frontend"

[daemons.videos]
root = "."
entrypoint = "Dockerfile"
instances.iad1 = 1

这段配置的含义是：在iad1（华盛顿特区）区域保持一个视频处理器实例常驻。

拉取式（pull-based）与推送式（push-based） 是后台任务处理的两种典型范式。推送式由调度方主动把任务「推」给工作者，工作者通常需要暴露一个可被调用的端点；拉取式则反过来，由工作者持续向队列或数据库轮询、主动领取任务。拉取式的优势在于工作者不必对外暴露入口、天然支持水平扩展、并由队列统一控制消费速率和重试，因此更适合长耗时、可重试、需要削峰的场景。Daemons 公测阶段只支持拉取式，意味着它更接近传统 worker 集群的用法，而非事件驱动的短函数；这也解释了为什么它可以常驻运行——没有外部请求进来时，进程仍在轮询等待。

这三项更新对开发者意味着什么

把三条线放在一起看，Vercel的后端叙事变得完整：Python GA解决主流语言的支持问题，容器解决"非Node生态依赖"的兼容问题，Daemons解决"函数不能常驻"的执行模式问题。三者叠加后，一个原本需要ECS、Kubernetes或独立worker集群的应用，理论上可以整体搬到Vercel。

从Delphi的案例看，这种整合的价值不在于单项能力有多强，而在于运维复杂度被平台吸收——十人团队、无专职SRE、日均百次发布，这个组合在自建基础设施上很难实现。当然，Daemons仍处于公测，常驻进程的成本模型、多区域容量规划、故障恢复行为都需要更多真实负载验证。Vercel能否承载更重的后端场景，接下来的实践会给出答案。

SRE（Site Reliability Engineer，站点可靠性工程师） 是负责系统可用性、容量规划、监控告警与故障响应的专职角色，其职责往往与基础设施运维高度重叠。文中提到 Delphi「没有专职基础设施岗」、「无专职 SRE」，并不是说这些工作消失了，而是被平台的自动化机制接管：弹性伸缩由 Vercel 按流量调度，进程崩溃由 Daemons 自动重启，日志、回滚、WAF 防护则由平台内置提供。判断一个托管平台能否真正替代自建栈，关键就在于它吸收了多少这类原本需要人力的运维职责，以及在被吸收之后，团队对异常行为的可观测性和可控性是否仍然足够。