AI 后端选 Python 还是 Node
这是 AI 项目里最容易被想简单了的技术选型问题。常见的做法是基准测试对比：Node 每秒多少请求、Python 每秒多少请求、谁快就选谁。
对 AI 后端来说，这个对比几乎没有意义——瓶颈是模型调用，不是框架。一次 LLM 请求 200 毫秒到 3 秒，框架在 JSON 序列化上差出来的那几毫秒完全被淹没了。
真正决定这个选择的是另外几件事。
1. 先把吞吐量从决策里拿掉
1.1 数字要带条件看
公开基准里常见的量级（单核、简单 JSON 响应、特定框架组合）：Node 通常在几万 req/s 这一档，Python + FastAPI 大致是它的二分之一到三分之二，也就是 Node 快 1.5–2 倍。具体数字不用记，比例才是重点——而且这类基准对框架配置极其敏感，换一台机器就能变一个样。
但这个差距在 AI 端点上会消失，因为请求时间由上游模型决定。所以：
- 纯 I/O 的 CRUD 服务：吞吐量差异是真的，Node 有优势
- LLM 端点：差异消失，选谁都行
- 冷启动敏感的场景（serverless、突发流量）：Node 优势明显（Lambda 上 Node 约 150–250ms，Python + Mangum 约 200–800ms）——这个差距是真的，且在低频服务上直接体现为响应延迟
- 长连接并发（WebSocket、SSE）：Node 的单事件循环在高并发连接上更省资源
1.2 内存与进程模型的差异是实的
Python worker 空闲内存通常高于 Node，且 CPU 密集任务要靠多进程绕开 GIL。这在容器密度高的部署里是实际成本。
但同样地——AI 服务里 CPU 密集的部分（embedding 计算、向量检索）通常在 C 扩展或远程服务里完成，GIL 的影响远小于传统 Web 服务。不过 Python 侧也有自己的 CPU 热点：tokenizer、JSON 序列化、Pydantic 校验、日志格式化，这些都在请求路径上。另外 Python 3.13+ 的 free-threading（no-GIL）正在改变这条论证的前提，只是生态兼容还需要时间。
2. 真正的差异在库
2.1 Python 侧领先的地方
检索与编排生态的成熟度。 LangChain、LlamaIndex、Haystack 的 Python 版本是"一等公民"，新特性、新论文的实现、社区示例基本都先出现在 Python 侧，JS 版通常要滞后几个版本。这个滞后期没有固定月数，但在多智能体这类快速演进的领域，等待期本身就是成本——你会在文档里看到"该功能暂仅支持 Python"。
Pydantic v2 不只是校验库。 它是 Python 侧 AI 工具的 schema 层：Pydantic AI 用它定义工具输入输出，LangChain Python 用它定义工具。也就是说同一份模型定义同时承担了类型、校验、OpenAPI 文档、工具 schema 四个角色。
TypeScript 侧要凑齐同样的能力需要三件套：Zod 做运行时校验、OpenAPI 生成器做文档、类型生成做客户端。能做，但是重复工作，且工具 schema 要另写一份 Zod。这一点在《结构化输出与自愈》里已经体现过——schema 定义越集中，改动时越不容易漏。
2.2 Node 侧领先的地方
流式 UI 的端到端体验。 Vercel AI SDK 把服务端 streamText 和客户端 useChat 打通，流式从模型一直到 React 组件是一套东西。Python 侧没有等价的完整方案（见《对话界面的状态机》）。
与前端同语言同类型。 全栈 TypeScript 时，请求/响应的类型可以前后端共享，不需要靠代码生成来同步。
冷启动与边缘部署。 Vercel Functions 天然偏向 TypeScript；Python 在这个平台上受限于包体积（numpy、torch、sentence-transformers 都会超出限制）。反过来，Modal 和 RunPod 是 Python 原生、面向 GPU 推理的。Node 侧如果要把能力打成 SDK 给别人用，还多一层双格式打包的功课，见《双格式 SDK 发布自检》。
2.3 MCP Server 的情形
MCP Server 的语言选择有个特殊约束：跟着工具要操作的运行时走。
如果你的工具要操作 Python 生态的东西（数据处理、ML 模型），用 Python 写 MCP Server 更自然；如果操作的是前端项目、Node 服务、浏览器，用 TypeScript。这一条跟吞吐量无关，跟"你的工具实际要碰什么"有关（见《无状态 MCP Server 要点》）。
3. 按场景分
| 场景 | 倾向 | 理由 |
|---|---|---|
| 生产 RAG | Python + FastAPI | 检索库成熟、asyncpg + pgvector 模式稳定 |
| 多智能体编排 | Python + LangGraph | 特性领先 JS 版半年以上 |
| 单次推理调用 | 都行 | I/O 为主，库差异不影响 |
| 流式聊天 UI | Node + AI SDK | 端到端流式一套打通 |
| MCP Server | 跟工具运行时 | 见 2.3 |
| Serverless / 边缘 | Node | 冷启动、包体积 |
| 需要 GPU 或本地模型 | Python | 生态与平台支持 |
| 已有 Node 服务上加 AI 功能 | Node | 不要为了 AI 单独起一套技术栈 |
最后一行值得强调：如果只是给现有 Node 服务加一个 AI 功能，就别为此引入 Python 服务。跨语言调用的运维成本会超过库生态带来的收益。
4. 分层栈：什么时候值得分
到一定规模之后，最常见的形态不是二选一，而是分层：
浏览器 → Node BFF（流式转发 · 鉴权 · 限流 · 会话）→ Python 推理层（RAG · 编排 · 模型调用）
4.1 什么时候值得
- 两端都有真实需求：既要复杂检索编排，又要高质量流式体验
- 团队里两种语言都有人
- 规模已经到了"单栈的性能或体验短板开始被用户感知"的程度
4.2 什么时候不值得
规模没到就别分。 分层带来的成本是实的：两套部署、两套监控、一个内部接口契约、跨语言的 trace 串联。这些成本在小团队里会吃掉收益。
一个务实的判断：如果你的 AI 服务只有两个以内的接口，先别分层。
4.3 边界怎么划
分层之后最容易出的问题是边界模糊——业务逻辑慢慢渗进 BFF，最后变成两个地方都有业务规则。
三条纪律：
- BFF 只做与传输和身份有关的事：鉴权、限流、审计、流式转发、请求裁剪。业务逻辑不属于它（见《流式链路上的缓冲点》）
- 推理层不直接对外：只暴露内部接口，所有外部流量必须经过 BFF
- 异步任务走消息队列：Redis Streams、RabbitMQ、Kafka 之类，不要让两层之间形成同步的长调用链
第三条尤其重要：同步链路会让两层的超时、重试、熔断互相纠缠，多模型接入与降级链 里那些策略就很难配了。
5. 团队与运维的现实约束
技术因素之外，有几件事经常才是真正的决定因素：
团队技能背景。 前端主导的团队用 TypeScript 更容易维护；有数据/算法背景的团队用 Python 更快。这个权重往往高于技术指标。
现有代码。 已经有一套 Node 微服务体系，加一个 Python 服务意味着监控、日志、部署、值班全都要支持第二种语言。Node 侧要不要引入 Nest.js 这类带 IoC 的框架，是另一层的选择，见《Nest.js 在 AI 链路里》。
部署平台。 Vercel 偏 TypeScript；Modal、RunPod、各类 GPU 平台偏 Python；Railway、Fly、ECS 两者都可以。平台约束会反过来限制选择。
评测与 CI。 无论选哪个，评测都要能在 CI 里跑起来（见《评测集怎么变成门禁》）。如果因为语言选择导致评测跑不进 CI，这个选择就是错的。
6. 两个反模式
6.1 为了"统一语言"把 AI 逻辑硬塞进 Node
如果核心是检索与编排，而团队因为"我们都是前端"就全用 TypeScript，结果通常是：自己实现一堆 Python 侧现成的东西（文档解析、切分、重排、评测），且质量更差。
库生态的差距是真实的，不因团队偏好而消失。
6.2 为了"AI 就该用 Python"把流式 UI 也塞进 Python
反过来同样成立。流式体验是前端体验的一部分，用 Python 手写一套 SSE + 前端状态同步，最后得到的东西通常不如直接用现成方案。
7. 决策清单
按顺序问，答完基本就有结论：
- 核心是检索/编排，还是流式交互？ 前者偏 Python，后者偏 Node
- 是不是在已有服务上加功能？ 是 → 跟着现有栈，别为 AI 单独起一套
- 需要 GPU 或本地模型吗？ 是 → Python
- 冷启动敏感吗？（serverless、突发、低频）是 → Node
- 团队谁能维护？ 这一条的权重经常高于前四条
- 规模到了需要分层吗？ 没到就单栈；到了就按第 4 节划边界
还有一个务实的收尾建议：原型期用能最快验证的那个，生产期再评估要不要换。检索策略的验证速度与生产环境的长期可维护性是两个目标，不必要求同一个选择同时最优。
真正要避免的不是"选错了语言"，而是"在没有理由的情况下分了层"——前者可以换，后者会成为长期负担。