AI 后端开发

如果说模型训练是”造引擎”，那么后端开发就是”造车架和方向盘”——再强大的 AI 模型，如果没有一个健壮、高性能的服务层对外暴露，也只能停留在 Jupyter Notebook 里自娱自乐。本页聚焦于如何用 Python 构建生产级 AI 推理服务，覆盖 FastAPI 框架、REST / WebSocket / SSE 三种通信协议、并发模型选型等核心主题。

本页是 Python 工程进阶的自然延伸——前者解决了”代码怎么写得 Pythonic”的问题，本页解决”服务怎么跑得稳、跑得快”的问题。涉及数据持久化与缓存的细节（如 PostgreSQL、Redis），请参阅数据库与中间件；涉及模型部署监控与版本管理的工程化话题，请参阅 MLOps 实践。

核心直觉：AI 后端的特殊挑战

传统 Web 后端处理的是”短请求、快响应”——查询数据库、拼接 JSON、返回结果，延迟通常在毫秒级。而 AI 后端面对的是长推理、重资源、不确定输出：

推理延迟高：一次 LLM（Large Language Model，大语言模型）生成可能耗时数秒到数十秒，远超 HTTP 普通请求的超时阈值。
显存与 GPU 是稀缺资源：模型常驻显存，并发请求需要排队或批处理（batching），否则 OOM（Out of Memory，内存溢出）。
流式输出需求：像 ChatGPT 那样”逐字蹦出”的效果，不是普通 JSON 一次返回能做到的。
冷启动问题：模型加载到显存动辄几秒到几十秒，不能像普通微服务那样随意扩缩容。

一句话总结：AI 后端 = 传统高性能 Web 后端 + GPU 资源管理 + 流式通信。本页将逐一拆解这三块。

原理详解

FastAPI：Python AI 后端的事实标准

FastAPI 是一个基于 Python 类型提示（type hints）的现代 Web 框架，由 Sebastián Ramírez 于 2018 年创建。截至 2025 年，它已成为 Python 生态中构建 API 服务的首选框架，Star 数超过 Flask，在 AI / ML 领域更是近乎垄断——Hugging Face TGI、vLLM、Ollama 的 Python SDK 等项目都基于或兼容 FastAPI。

它的核心卖点可以用四句话概括：

特性	说明	为什么 AI 开发者需要它
路径操作（Path Operations）	用装饰器将 URL 路径绑定到处理函数	几行代码就能暴露一个推理接口
依赖注入（Dependency Injection）	`Depends()` 声明式地复用逻辑（认证、数据库连接、模型加载）	模型只在启动时加载一次，全局复用
Pydantic 集成	请求 / 响应体自动用 Pydantic 模型校验和序列化	告别手写 `if "text" not in body` 式的防御代码
自动文档	启动即可访问 `/docs`（Swagger UI）和 `/redoc`	前端同事直接在浏览器里测试接口
原生异步	`async def` 基于 ASGI 事件循环	等待 GPU 推理时不阻塞其他请求

路径操作与 Pydantic 校验

FastAPI 最基本的功能是将 HTTP 请求路由到 Python 函数。所有路由通过装饰器注册：

from fastapi import FastAPI
from pydantic import BaseModel, Field

app = FastAPI(title="Sentiment Analysis API", version="1.0.0")

# ── Pydantic 模型：自动校验请求体 ──
class SentimentRequest(BaseModel):
    text: str = Field(..., min_length=1, max_length=5000, description="待分析的文本")
    model_name: str = Field(default="distilbert-sst2", description="使用的模型名")

class SentimentResponse(BaseModel):
    label: str        # "POSITIVE" 或 "NEGATIVE"
    score: float      # 置信度，0~1
    model_name: str

@app.post("/api/v1/sentiment", response_model=SentimentResponse)
async def analyze_sentiment(req: SentimentRequest):
    """
    情感分析接口。
    FastAPI 自动完成：
    1. 解析 JSON body → SentimentRequest 对象
    2. 校验 text 长度是否在 [1, 5000]，不合法直接返回 422
    3. 响应按 SentimentResponse 序列化
    """
    # 这里省略实际模型推理，详见后文完整示例
    return SentimentResponse(label="POSITIVE", score=0.9998, model_name=req.model_name)

这段代码同时充当了”路由定义 + 类型校验 + API 文档”三种角色。当用户发送一个缺少 text 字段或 text 为空字符串的请求时，FastAPI 会自动返回 HTTP 422（Unprocessable Entity）及详细的错误位置——你无需手写任何校验逻辑。

Pydantic v2（2023 年发布） 是一次重大重写：底层用 Rust 编写，校验速度比 v1 快 5~50 倍。FastAPI 0.100+ 已全面支持 Pydantic v2。如果你在旧项目里看到 class Config: orm_mode = True 的写法，那是 v1 风格；v2 应改为 model_config = ConfigDict(from_attributes=True)。

依赖注入（Dependency Injection）

FastAPI 的 Depends() 机制让”资源初始化”与”请求处理”彻底解耦——这在 AI 后端尤其关键，因为模型加载极其昂贵，必须做到进程启动时加载一次、所有请求共享。

from fastapi import Depends, FastAPI
from contextlib import asynccontextmanager
import torch
from transformers import AutoModelForSequenceClassification, AutoTokenizer

# ── 全局模型持有者 ──
class ModelRegistry:
    model = None
    tokenizer = None

# ── lifespan：应用启动时加载模型，关闭时释放显存 ──
@asynccontextmanager
async def lifespan(app: FastAPI):
    """FastAPI 0.93+ 推荐的生命周期管理方式（取代旧的 on_event）。"""
    print("⏳ 正在加载模型到 GPU...")
    model_name = "distilbert/distilbert-base-uncased-finetuned-sst-2-english"
    ModelRegistry.tokenizer = AutoTokenizer.from_pretrained(model_name)
    ModelRegistry.model = AutoModelForSequenceClassification.from_pretrained(
        model_name, torch_dtype=torch.float16
    ).to("cuda")          # 加载到 GPU 显存
    ModelRegistry.model.eval()
    print("✅ 模型加载完成")
    yield                  # ← 应用运行期间一直在这里"挂起"
    # yield 之后是清理逻辑
    del ModelRegistry.model
    torch.cuda.empty_cache()   # 释放 GPU 显存

app = FastAPI(lifespan=lifespan)

# ── 用 Depends 依赖注入复用模型引用 ──
def get_model():
    """任何路由都可以 Depends(get_model) 来拿到已加载的模型实例。"""
    if ModelRegistry.model is None:
        raise RuntimeError("模型尚未加载")
    return ModelRegistry

@app.post("/api/v1/sentiment")
async def predict(text: str, registry: ModelRegistry = Depends(get_model)):
    inputs = registry.tokenizer(text, return_tensors="pt", truncation=True, max_length=512)
    inputs = {k: v.to("cuda") for k, v in inputs.items()}
    with torch.no_grad():
        logits = registry.model(**inputs).logits
    pred_id = logits.argmax(dim=-1).item()
    label = registry.model.config.id2label[pred_id]
    return {"label": label, "score": torch.softmax(logits, dim=-1)[0, pred_id].item()}

关键点：lifespan 中的模型加载发生在 worker 进程启动时，之后所有请求共享同一个模型实例。Depends(get_model) 本身开销极小——它只是返回全局引用，不重复加载。

自动文档：Swagger UI 与 ReDoc

启动 FastAPI 应用后，直接在浏览器访问：

http://localhost:8000/docs —— Swagger UI，可交互式测试每个接口
http://localhost:8000/redoc —— ReDoc，适合生成只读的 API 参考文档
http://localhost:8000/openapi.json —— OpenAPI 3.1 规范 JSON，可导入 Postman / Apifox

这些文档完全自动生成，依据就是你的 Pydantic 模型和函数签名上的类型提示、Field() 描述、docstring。这也是 FastAPI 名字中 “Fast” 的核心来源——文档不再是额外负担。

原生异步：`async def`

在 FastAPI 中，路由函数可以写成 async def 或普通 def：

# 异步写法：适合 I/O 密集（调外部 API、查数据库）
@app.get("/async-route")
async def async_handler():
    data = await some_async_http_client.get("https://...")
    return {"data": data}

# 同步写法：FastAPI 会自动放到线程池中运行，不阻塞事件循环
@app.get("/sync-route")
def sync_handler():
    result = some_cpu_bound_computation()  # CPU 密集任务
    return {"result": result}

AI 推理的异步陷阱：PyTorch 的 model(input) 是同步阻塞调用，会占用当前线程。如果你在 async def 里直接调用它，会阻塞整个事件循环，导致其他请求全部排队等待。正确做法是把推理调用放到线程池：result = await run_in_executor(None, model, input)，或者干脆用普通 def 让 FastAPI 自动处理。详见后文”并发模型”一节。

REST API 设计最佳实践

REST（Representational State Transfer，表述性状态转移）是一种基于 HTTP 的 API 设计风格，由 Roy Fielding 在 2000 年的博士论文中提出。虽然 AI 后端常常不走”标准 CRUD”，但遵循 REST 约定能让接口更可预测、更易维护。

资源命名与 HTTP 方法语义

REST 的核心思想是：URL 表示资源名词，HTTP 方法表示操作动词。

HTTP 方法	语义	幂等性	安全性	示例
`GET`	获取资源	✅ 是	✅ 是	`GET /api/v1/models`
`POST`	创建资源	❌ 否	❌ 否	`POST /api/v1/jobs`
`PUT`	全量替换资源	✅ 是	❌ 否	`PUT /api/v1/jobs/123`
`PATCH`	部分更新资源	❌ 否	❌ 否	`PATCH /api/v1/jobs/123`
`DELETE`	删除资源	✅ 是	❌ 否	`DELETE /api/v1/jobs/123`

幂等性（Idempotency） 指同一个请求执行一次和执行多次的效果相同。GET、PUT、DELETE 是幂等的；POST 不是——提交两次可能创建两个订单。这在 AI 后端的”提交推理任务”场景中需要特别注意。

命名规范：

✅ 用名词复数：/api/v1/models、/api/v1/inference-jobs
❌ 不要用动词：~~/api/v1/getModels~~、~~/api/v1/runInference~~
✅ 用连字符（kebab-case）：/api/v1/embedding-models
❌ 不要用下划线或驼峰：~~/api/v1/embedding_models~~

AI 后端的特殊考量：任务式推理

对于耗时较长的推理（如视频生成、大规模批处理），不适合在一个 HTTP 请求里同步等待。标准模式是异步任务：

# 步骤 1：提交任务
POST /api/v1/jobs
  Body: {"type": "text-to-image", "prompt": "a cat on Mars", ...}
  Response: 202 Accepted
           {"job_id": "job_abc123", "status": "queued",
            "poll_url": "/api/v1/jobs/job_abc123"}

# 步骤 2：轮询状态（或用 Webhook / SSE 推送）
GET /api/v1/jobs/job_abc123
  Response: 200 OK
           {"job_id": "job_abc123", "status": "running", "progress": 0.65}

# 步骤 3：获取结果
GET /api/v1/jobs/job_abc123/result
  Response: 200 OK
           {"image_url": "https://...generated.png"}

这种”提交 → 轮询 → 获取”的模式在 OpenAI（DALL·E）、Stability AI、Replicate 等平台的 API 中被广泛采用。

状态码

状态码	含义	AI 后端典型场景
`200 OK`	请求成功	推理成功返回结果
`201 Created`	资源已创建	注册了一个新模型
`202 Accepted`	已接受，异步处理中	提交了推理任务，后台排队中
`400 Bad Request`	客户端参数错误	prompt 为空、字段格式不对
`401 Unauthorized`	未认证	缺少或无效的 API Key
`404 Not Found`	资源不存在	查询的 job_id 不存在
`422 Unprocessable Entity`	语义校验失败	Pydantic 校验不通过（FastAPI 自动返回）
`429 Too Many Requests`	限流	QPS（Queries Per Second，每秒请求数）超限
`500 Internal Server Error`	服务器内部错误	模型推理异常、显存溢出
`503 Service Unavailable`	服务暂不可用	模型正在加载中

分页

当接口返回列表数据时（如模型仓库列表、推理历史记录），必须分页：

from fastapi import Query

@app.get("/api/v1/jobs")
async def list_jobs(
    page: int = Query(default=1, ge=1, description="页码，从 1 开始"),
    page_size: int = Query(default=20, ge=1, le=100, description="每页条数，最多 100"),
):
    total = await db.count_jobs()
    items = await db.list_jobs(offset=(page - 1) * page_size, limit=page_size)
    return {
        "items": items,
        "page": page,
        "page_size": page_size,
        "total": total,
        "total_pages": (total + page_size - 1) // page_size,
    }

游标分页（Cursor Pagination）：当数据频繁新增时，传统的 page/offset 分页可能出现数据重复或遗漏。游标分页用”上一页最后一条记录的 ID”作为锚点，更适合时间线类数据（如推理日志流）。GitHub API、Twitter API 都采用这种方式。

版本管理

在 URL 中嵌入版本号是最常见的做法：/api/v1/...、/api/v2/...。当接口有不兼容变更时，新建一个版本号，旧版本保留一段过渡期后再下线。OpenAI 的 API 版本管理（v1、v2）用的就是这种方式。

WebSocket：实时双向通信

WebSocket 是 HTML5 标准中定义的全双工通信协议，在一条 TCP 连接上可以双向收发消息。它通过一次 HTTP Upgrade 握手将连接”升级”为 WebSocket 协议（ws:// 或加密的 wss://），之后不再遵循 HTTP 的请求-响应模型。

与 HTTP 的对比

特性	HTTP（含 SSE）	WebSocket
通信方向	单向（客户端请求 → 服务端响应）	全双工双向
连接生命周期	短连接（HTTP/1.1）或复用（HTTP/2）	长连接，持续保持
数据格式	文本为主（JSON、HTML）	文本 + 二进制（Protobuf、音频流）
协议开销	每次请求有完整 HTTP 头部	握手后帧头仅 2~14 字节
典型 AI 场景	模型推理 API、流式文本生成	实时语音对话、多模态流

FastAPI WebSocket 路由

from fastapi import FastAPI, WebSocket, WebSocketDisconnect
from typing import List

app = FastAPI()

# ── 简单的连接管理器 ──
class ConnectionManager:
    """维护所有活跃的 WebSocket 连接，支持广播。"""
    def __init__(self):
        self.active: List[WebSocket] = []

    async def connect(self, ws: WebSocket):
        await ws.accept()              # 完成 WebSocket 握手
        self.active.append(ws)

    def disconnect(self, ws: WebSocket):
        if ws in self.active:
            self.active.remove(ws)

    async def broadcast(self, message: str):
        """向所有连接广播消息（如：模型推理进度推送给所有客户端）。"""
        for ws in self.active:
            await ws.send_text(message)

manager = ConnectionManager()

@app.websocket("/ws/chat/{client_id}")
async def websocket_endpoint(ws: WebSocket, client_id: str):
    await manager.connect(ws)
    try:
        while True:
            # 接收客户端消息
            data = await ws.receive_text()
            # ... 调用模型处理 ...
            response = f"[模型回复 to {client_id}]: {data.upper()}"
            await ws.send_text(response)
    except WebSocketDisconnect:
        manager.disconnect(ws)
        await manager.broadcast(f"客户端 {client_id} 已断开")

适用场景：实时语音助手（客户端持续上传音频帧、服务端持续返回合成语音）、多人协同标注、在线游戏 AI 对手等。对于”客户端发一条文本、服务端流式返回文本”的普通聊天场景，WebSocket 其实杀鸡用牛刀——SSE 更简单合适。

SSE（Server-Sent Events）：LLM 流式输出的标准方案

SSE（Server-Sent Events，服务器发送事件）是一种基于 HTTP 的单向推送协议：服务端在一条长连接上持续向客户端发送数据，客户端只接收不发送。它正是 ChatGPT “逐字蹦出”效果背后的技术基础。

为什么 SSE 而不是 WebSocket？

对比维度	SSE	WebSocket
底层协议	HTTP	独立的 ws 协议
方向	单向（服务端 → 客户端）	双向
实现复杂度	极低（普通 HTTP 响应）	较高（握手、心跳、状态管理）
断线自动重连	浏览器内置	需手动实现
HTTP/2 多路复用	天然兼容	需独立连接
反向代理穿透	普通 HTTP，天然穿透	需要额外配置 Upgrade 头
典型 LLM 场景	✅ 文本流式生成	实时语音 / 多模态

LLM 流式输出之所以选择 SSE，根本原因是它的通信模式是一个请求（用户 prompt）→ 一串流式响应（逐 token 生成的文本），本质是”服务端单向推送”，SSE 完美匹配且实现最简单。

`text/event-stream` 格式

SSS 的响应头必须为 Content-Type: text/event-stream，消息体由若干 data: 行组成，每条消息以空行结尾：

data: {"token": "你"}

data: {"token": "好"}

data: {"token": "，"}

data: [DONE]

FastAPI 实现 SSE 流式输出

import json
import asyncio
from fastapi import FastAPI
from fastapi.responses import StreamingResponse

app = FastAPI()

@app.post("/api/v1/chat/stream")
async def chat_stream(prompt: str):
    """
    SSE 流式聊天接口。
    使用 FastAPI 的 StreamingResponse 返回 text/event-stream。
    """
    async def event_generator():
        # 模拟 LLM 逐 token 生成
        mock_tokens = ["你", "好", "！", "我", "是", "AI", "助手", "。"]
        for token in mock_tokens:
            chunk = {"token": token}
            # SSE 格式：每条消息以 data: 开头，以 \n\n 结尾
            yield f"data: {json.dumps(chunk, ensure_ascii=False)}\n\n"
            await asyncio.sleep(0.1)   # 模拟推理延迟
        yield "data: [DONE]\n\n"        # 结束标记

    return StreamingResponse(
        event_generator(),
        media_type="text/event-stream",
        headers={
            "Cache-Control": "no-cache",           # 禁用缓存
            "X-Accel-Buffering": "no",             # 告诉 Nginx 不要缓冲（关键！）
            "Connection": "keep-alive",
        },
    )

客户端用浏览器原生 EventSource API 即可消费：

const es = new EventSource("/api/v1/chat/stream?prompt=你好");
es.onmessage = (event) => {
    if (event.data === "[DONE]") {
        es.close();
        return;
    }
    const chunk = JSON.parse(event.data);
    document.getElementById("output").textContent += chunk.token;
};

生产环境必读：在 Nginx 反向代理后面使用 SSE 时，必须设置 proxy_buffering off 或在响应头中加 X-Accel-Buffering: no，否则 Nginx 会缓冲整个响应体，导致客户端看不到流式效果——这是最常见的”SSE 在本地正常、部署后变一次性返回”问题的根因。

服务并发模型：从单进程到 GPU 批处理

ASGI：异步网关接口

ASGI（Asynchronous Server Gateway Interface，异步服务器网关接口）是 WSGI（其同步版本）的异步继任者。FastAPI 本身只是一个框架，真正接收 HTTP 连接、管理事件循环的是 ASGI Server，最常用的是 Uvicorn。

HTTP 请求 → Uvicorn (ASGI Server) → FastAPI (框架) → 你的处理函数

Uvicorn 与 Gunicorn 的配合

Uvicorn：基于 uvloop（libuv 的高性能 Python 绑定）和 httptools 的 ASGI 服务器，单进程内通过事件循环处理大量并发 I/O。适合开发环境。
Gunicorn：成熟的预派生（pre-fork）多进程 WSGI/ASGI 服务器管理器。在生产中通常用 Gunicorn 管理 多个 Uvicorn worker 进程，每个进程内部再跑事件循环。

# 开发：单进程 + 热重载
uvicorn main:app --reload --host 0.0.0.0 --port 8000

# 生产：Gunicorn 管理 4 个 Uvicorn worker（推荐）
gunicorn main:app \
    -w 4 \
    -k uvicorn.workers.UvicornWorker \
    --bind 0.0.0.0:8000 \
    --timeout 120 \          # AI 推理耗时长，超时调大
    --graceful-timeout 30 \
    --max-requests 1000 \    # 防止内存泄漏，定期重启 worker
    --max-requests-jitter 100

GPU 与多进程的矛盾：每个 Uvicorn worker 进程都会加载一份模型到显存。一个 7B 模型（约 14 GB fp16）开 4 个 worker 就要 56 GB 显存——远超单卡容量。因此 AI 推理服务通常只用 1~2 个 worker，配合 连续批处理（continuous batching） 框架（如 vLLM、TGI）在进程内部并发处理请求，而不是靠多进程。这是 AI 后端与传统 Web 后端最大的运维差异之一。

Workers vs Threads vs Async

并发模型	适用场景	AI 后端中的角色
多进程（workers）	CPU 密集、绕过 GIL	传统 Web 后端主力；AI 后端受显存限制慎用
多线程（threads）	I/O 密集、需兼容同步库	PyTorch 推理可放线程池执行
异步（async/await）	大量并发 I/O 连接	等待数据库、调用外部 API、接收请求

GIL（Global Interpreter Lock，全局解释器锁） 是 CPython 的一个互斥锁，同一时刻只允许一个线程执行 Python 字节码。这意味着多线程无法利用多核 CPU 来加速纯 Python 计算——但 I/O 操作（网络、磁盘）和 C 扩展（如 PyTorch 的 C++ 后端）会释放 GIL，因此多线程在 I/O 密集和 GPU 推理场景依然有用。

Nginx 反向代理

生产环境几乎总在 FastAPI 前面放一层 Nginx：

server {
    listen 80;
    server_name api.example.com;

    # 限制上传体积（模型文件可能较大）
    client_max_body_size 50M;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        # ── SSE / WebSocket 必需配置 ──
        proxy_buffering off;           # 关闭缓冲，流式输出才能实时到达客户端
        proxy_read_timeout 300s;       # AI 推理耗时长，读超时调到 5 分钟
        proxy_http_version 1.1;        # WebSocket 需要 HTTP/1.1
        proxy_set_header Upgrade $http_upgrade;   # WebSocket 握手
        proxy_set_header Connection "upgrade";
    }
}

AI 后端架构总览

将以上组件组合起来，一个典型的生产级 AI 推理服务架构如下：

架构要点解读：

Nginx 负责终止 TLS、限流（防止单一客户端打满 GPU）、静态资源缓存，以及对 SSE/WebSocket 的透明转发。
FastAPI 应用 是业务逻辑中枢，处理认证、请求校验、任务调度，但不直接做重度推理——它将推理委托给专门的推理引擎进程。
推理引擎（vLLM、TGI 等）独立运行，内部实现连续批处理（continuous batching）、PagedAttention 等优化，通过 HTTP 或 gRPC 对 FastAPI 提供服务。
PostgreSQL 存储结构化数据（用户、API Key、任务记录）；Redis 用作会话缓存、限流计数器、轻量消息队列；向量数据库 支持 RAG（Retrieval-Augmented Generation，检索增强生成）场景的语义检索。

想深入了解 RAG 的全栈架构，请参阅 LangChain 与 RAG 技术栈。关于向量数据库的选型对比，请参阅数据库与中间件。

实践要点

模型加载放在 lifespan，不要放在模块顶层：模块顶层加载会导致 uvicorn --reload 每次改代码都重新加载模型，开发体验极差。
推理调用放进线程池：在 async def 路由中直接调用 model(input) 会阻塞事件循环。用 await run_in_threadpool(model, input) 或把路由写成普通 def。
始终设置超时与降级：模型推理可能卡死（显存碎片、死锁）。给每个推理调用加超时，超时后返回 503 并记录告警。
限流不可少：GPU 是昂贵资源，一个恶意用户高频请求就能把服务打满。用 Redis + 令牌桶算法实现按用户 / 按 API Key 的 QPS 限流。
日志结构化：用 structlog 或标准库 logging 输出 JSON 格式日志，记录 request_id、model_name、latency_ms、token_count——这些是后续 MLOps 监控的基础。详见 MLOps 实践。
健康检查接口：实现 GET /health（轻量存活检查）和 GET /ready（检查模型是否加载完毕、GPU 是否可用），配合容器编排做就绪探针。
SSE 场景务必关闭 Nginx 缓冲：这是线上最常遇到的”流式不流”问题，一行 proxy_buffering off; 解决。

2025–2026 最新进展

FastAPI 与 Pydantic v2 全面融合：2024 年起 Pydantic v2 成为默认选择，FastAPI 0.110+ 的性能基准测试显示，相比 v1 时代请求吞吐量提升约 2~3 倍。2025 年发布的 FastAPI 0.115 进一步优化了 Annotated 类型提示的依赖注入语法。
OpenAPI 3.1 支持：FastAPI 现已全面支持 OpenAPI 3.1 规范（JSON Schema 2020-12）， nullable 字段写法从 Optional[T] 演进为 T | None，与 Python 3.10+ 的类型语法保持一致。
vLLM / TGI 成为推理服务标配：2024–2025 年，vLLM 凭借 PagedAttention 和连续批处理技术，成为开源 LLM 推理引擎的事实标准。它本身提供 OpenAI 兼容的 HTTP API，FastAPI 层常作为”业务网关”在其前面做认证、计费、日志。
gRPC 与 streaming RPC 的回潮：在内部微服务间通信用 gRPC 替代 JSON-over-HTTP 可降低序列化开销，尤其适合传输大量 embedding 向量或音频帧。FastAPI 本身不直接支持 gRPC，但可以与 grpcio 服务共存于同一进程。
Python 3.13 Free-Threaded 模式（实验性）：Python 3.13（2024 年 10 月发布）引入了无 GIL 的实验性构建（PEP 703）。虽然目前 PyTorch 等核心库的兼容性仍在推进中，但一旦成熟，AI 后端的并发模型可能迎来重大变化——多线程真正利用多核成为可能，worker 数量不再是唯一的水平扩展手段。
Server-Sent Events 标准化推进：随着 LLM API 的爆发，SSE 从一个”小众协议”变为 HTTP 流式输出的标准方案。OpenAI、Anthropic、Google Gemini API 的流式接口全部采用 SSE，各大语言 SDK 也内置了 SSE 客户端支持。

术语表

术语	英文全称	中文解释
ASGI	Asynchronous Server Gateway Interface	异步服务器网关接口，WSGI 的异步版本，FastAPI 运行的协议基础
SSE	Server-Sent Events	服务器发送事件，基于 HTTP 的单向流式推送协议
WebSocket	—	全双工双向通信协议，适合实时交互场景
GIL	Global Interpreter Lock	全局解释器锁，CPython 中限制同一时刻只有一个线程执行字节码的机制
WSGI	Web Server Gateway Interface	Web 服务器网关接口，Python 同步 Web 应用的标准协议
ORM	Object-Relational Mapping	对象关系映射，用 Python 对象操作数据库表的技术
Idempotency	—	幂等性，同一操作执行一次和多次效果相同的性质
QPS	Queries Per Second	每秒请求数，衡量接口吞吐量的指标
PagedAttention	—	vLLM 提出的显存分页管理技术，大幅提升 LLM 推理吞吐量
Continuous Batching	—	连续批处理，动态将新请求插入正在处理的 batch 中，避免 GPU 空闲
RAG	Retrieval-Augmented Generation	检索增强生成，从知识库检索相关内容再喂给 LLM 生成回答的架构
OOM	Out of Memory	内存溢出，通常指 GPU 显存不足导致的程序崩溃
Swagger UI	—	OpenAPI 规范的可视化交互界面，FastAPI 在 `/docs` 自动提供
ReDoc	—	另一种 OpenAPI 文档渲染器，FastAPI 在 `/redoc` 自动提供