Vercel Functions 的 WebSocket 支持转正：连接按函数调用计价，只有在处理消息时才算 CPU

Vercel 在 2026-10-20 宣布 Vercel Functions 的 WebSocket 支持正式可用（GA），从 6 月底的公测转为正式功能。官方给出的关键口径是：WebSocket 连接与其他函数调用遵循同样的限额与计价方式，在 Active CPU 计价下只对处理消息的时间计费，不按连接挂着的时间计费。官方点名 AI 聊天、流式输出与实时多人应用是主要用法，并说明 AI Gateway 的实时模型也跑在 WebSocket 上。

这次发布的是什么

Vercel 在 2026-10-20 宣布其 Functions 产品的 WebSocket 支持正式可用（一般可用性，GA），页面记录的发布时间是 2026-10-20T20:00Z。这项能力此前从 2026 年 6 月底开始公测，这次是把它从公测状态转为正式功能。

对做 AI 应用的团队来说，这件事的分量不在「能不能用长连接」——那在公测阶段就已经可用——而在于计费口径被明确了：官方说明 WebSocket 连接遵循与其他函数调用相同的限额与价格，并且在 Active CPU 计价模式下，只有真正在处理消息时消耗的 CPU 才计费。长连接应用最怕的是「挂着就烧钱」，这句话直接回答了那个担心。

官方点名的三类用法是 AI 聊天、流式输出和实时多人应用；另外还提到 AI Gateway 的实时模型本身就跑在 WebSocket 上，也就是说，如果你在用网关的实时类模型，底下这条链路已经依赖这项能力。

可用性与限制

• 形态：Vercel Functions 的一项能力，正式可用状态；无需额外产品，按函数的方式部署即可。
• 计费口径：连接与其他函数调用遵循同样的限额与计价；Active CPU 计价下只对处理消息的时间计费，空闲挂着的连接不计 CPU 时间。具体单价与额度以官方定价页为准。
• 计费模式依赖：这个「只算处理时间」的效果依赖于项目使用 Active CPU 计价模式，其他计价模式下的账要按官方文档自行核算。
• 限制：连接数与并发上限跟函数调用共用一套限额，长连接占用的并发会挤占其他调用的配额，需要按业务量规划。
• 兼容：官方文档给出了一节专门的 WebSocket 说明；具体支持的运行时与框架以文档当期内容为准。

主要功能

• 在函数里直接处理 WebSocket 连接，不需要另起长连接服务。
• 消息处理阶段按 CPU 时间计费，连接空闲不产生 CPU 账单。
• 与函数调用共用同一套限额与观测，运维沿用原有面板。
• 官方点名支持 AI 聊天的双向消息与流式输出。
• 支撑 AI Gateway 的实时模型调用链路。

技术原理

要理解这次发布解决了什么，得先看 Serverless 函数与长连接之间原本的矛盾。传统函数模型是「来一个请求、起一次执行、返回、结束」，执行时长有限，空闲时没有实例。WebSocket 是反过来的：一条连接要维持很久，中间大部分时间没有数据。

Vercel 的思路是在函数执行模型上开出长连接的能力：连接建立之后由函数侧持有，消息到达时唤醒处理逻辑。之所以能在空闲时不烧钱，靠的是 Active CPU 计价把「时间」拆成两段——连接挂着的时间，与真正在处理消息的时间，只对后者计 CPU 费用。

这个拆分对 AI 应用尤其关键。流式输出的场景里，模型在生成时服务端主要在做转发与拼接，CPU 占用很低但连接需要一直开着；如果按连接时长计 CPU，这类负载会被算成「长时间高占用」，与实际资源消耗严重不符。改成按处理时间计费之后，账与负载的形状才对齐。

另一层是网关侧。AI Gateway 的实时模型走的就是 WebSocket，这次把 Functions 的这条能力转正，等于给「函数直接和模型做双向实时通信」提供了一条官方支持的路径，不需要再自己搭一层转发。

实际体验

想判断这个方案是否适合你的应用，可以按下面几步实测。

第一步，先算并发账。把长连接的数量换算成占用的函数并发，看它会不会挤掉你现有的接口调用。这一步最容易出错——WebSocket 的价格便宜了，但并发配额是同一本账。

第二步，测一条聊天的完整往返。客户端发起连接、发送一条消息、服务端调用模型并流式返回、客户端收到完整响应。观察面板里记录的 CPU 时间与请求时长是否如预期分离：时长可以很长，CPU 时间应该很短。

第三步，做一次空闲测试。建立连接之后什么都不发，挂上一段时间，回看这段期间的计费记录。如果这段时间产生了可观的 CPU 时间，说明你的处理逻辑有轮询或心跳开销，需要先改掉再看账单。

第四步，测断线重连。移动端网络切换是最常见的断线场景，确认客户端有重连策略、服务端有连接身份的重建方式。WebSocket 不像 HTTP 那样天然幂等，重连时的会话恢复要自己设计。

第五步，再评估要不要上。如果应用本身只是偶尔请求-响应、没有双向实时的需求，用普通的 HTTP 流式响应更简单；WebSocket 的价值在双向与低延迟，不在「更先进」。

项目地址与获取方式

官方公告：https://vercel.com/changelog/websocket-support-is-now-generally-available

Functions 文档（含 WebSocket 一节）：https://vercel.com/docs/functions/websockets

Functions 用量与计费：https://vercel.com/docs/functions/usage-and-pricing

AI Gateway 文档：https://developers.cloudflare.com/ai-gateway/usage/index.md

请以 Vercel 官方控制台与文档为准；第三方教程里的限额数字可能落后于官方页面。

适合谁用

• 做 AI 聊天、实时协作编辑、在线多人游戏这类需要双向低延迟的 Web 团队
• 已经在 Vercel 上部署、不想为了长连接再引入一家实时服务商的团队
• 用 AI Gateway 实时模型、需要把模型输出直接推给前端的应用
• 用 Serverless 但被「长连接计时」挡住、一直绕道轮询的团队
• 不必用的情况：以批处理、定时任务为主的站点；对连接数有硬性且极大要求的实时产品——那类场景通常仍需要自建长连接集群

常见问题

连接一直挂着会不会一直计费？

按官方口径不会按挂着的时长计 CPU 费用：在 Active CPU 计价下只对处理消息的时间计费。但连接仍占用函数并发配额，并且依赖你的代码没在空闲时做轮询。建议按上面「空闲测试」那一步实测一次自己的账单。

这和普通的流式 HTTP 响应有什么区别？

普通流式响应是「一次请求、服务器持续输出、结束就断」，适合单向推送；WebSocket 是双向的，客户端可以在服务端输出过程中继续发消息。做纯生成类应用，前者往往更简单；做协作、游戏、实时对话，后者的语义更自然。

我原来的 WebSocket 服务需要迁移吗？

不需要为了这次 GA 专门迁移。如果你现在用的是第三方实时服务，且没有成本或延迟上的问题，继续用即可。这项能力的价值在于「如果你本来就在 Vercel 上，可以不引入新供应商」。

AI Gateway 的实时模型是什么关系？

官方说明 AI Gateway 的实时模型跑在 WebSocket 上。也就是说，用网关调用实时类模型时，这条链路本身已经依赖 WebSocket 能力；这次 Functions 侧转正，让「函数直接持有这条链路」变得更直接。

并发配额怎么算？

官方说明 WebSocket 连接遵循与其他函数调用同样的限额，也就是与你的调用共用并发配额。具体数值随套餐不同，以官方定价与限额页面为准，本文不给数字。

相关工具与内容

• 工具页：Vercel 上常用的 AI SDK 生态可从 Cursor 入手、Bolt、Lovable
• 分类：AI编程、AI智能体、其他AI工具
• 同题材快讯：Vercel AI Gateway 会话亲和日志（10-17）、MiniMax M3.1 Flash 上架 AI Gateway
• 延伸阅读：智能体可用的 Vercel CLI 域名购买能力