PyTorch Conference China 2026 于 9 月 8 日至 9 日在上海举行，并与 KubeCon + CloudNativeCon、OpenInfra Summit 同期举办；此前一天还有由赞助商组织的联合活动。这样的会议组合释放了一个清晰信号：AI 工程已经不再局限于模型训练，团队需要把框架、推理服务、容器、调度和基础设施作为一套完整系统来建设。
开放 AI 栈正在跨越框架边界
PyTorch 位于开发者最熟悉的模型层，但生产环境中的调用链通常更长：
- 使用 PyTorch 开发、训练和验证模型。
- 通过稳定的模型格式或导出机制交付产物。
- 将推理逻辑封装成 HTTP 或 RPC 服务。
- 使用容器固化运行时、系统库和模型文件。
- 交给 Kubernetes 或其他基础设施管理扩缩容、资源隔离和故障恢复。
- 采集延迟、吞吐量、显存占用和模型版本等运行指标。
PyTorch 社区与云原生、开放基础设施社区同期交流的价值，正在于打通这些层次。模型能在笔记本上运行只是起点；能否被重复构建、稳定发布、观测和回滚，才决定它是否真正进入生产系统。
这里也需要控制解读边界。来源摘要只提到会议时间、地点、同期活动和技术讨论，没有列出具体发布、版本更新或基准测试结果，因此不应据此推断某项产品已经正式上线。更可靠的关注点是开放技术栈各层之间的协作方式。
一个最小的模型交付链路
下面是一套可以改造的实践示例：训练一个简单的 PyTorch 模型，将其导出为 TorchScript，再通过 FastAPI 提供预测接口。示例假设使用 Python 3.11，适合验证从模型代码到服务接口的基本流程，不代表会议公布的官方方案。
创建 requirements.txt：
fastapi==0.115.8
uvicorn[standard]==0.34.0
torch==2.6.0
创建 build_model.py：
import torch
from torch import nn
class ScoreModel(nn.Module):
def __init__(self) -> None:
super().__init__()
self.linear = nn.Linear(4, 1)
def forward(self, features: torch.Tensor) -> torch.Tensor:
return torch.sigmoid(self.linear(features))
model = ScoreModel().eval()
example = torch.zeros(1, 4)
scripted = torch.jit.trace(model, example)
scripted.save("model.pt")
print("saved model.pt")
创建 app.py：
from contextlib import asynccontextmanager
import torch
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field
model: torch.jit.ScriptModule | None = None
class PredictRequest(BaseModel):
features: list[float] = Field(min_length=4, max_length=4)
@asynccontextmanager
async def lifespan(_: FastAPI):
global model
model = torch.jit.load("model.pt", map_location="cpu")
model.eval()
yield
model = None
app = FastAPI(lifespan=lifespan)
@app.get("/healthz")
def health() -> dict[str, str]:
return {"status": "ok"}
@app.post("/predict")
def predict(request: PredictRequest) -> dict[str, float]:
if model is None:
raise HTTPException(status_code=503, detail="model is not ready")
inputs = torch.tensor([request.features], dtype=torch.float32)
with torch.inference_mode():
score = model(inputs).item()
return {"score": score}
本地启动并调用服务：
python -m venv .venv
. .venv/bin/activate
pip install -r requirements.txt
python build_model.py
uvicorn app:app --host 0.0.0.0 --port 8000
在另一个终端发送请求：
curl -s http://localhost:8000/healthz
curl -s -X POST http://localhost:8000/predict \
-H 'Content-Type: application/json' \
-d '{"features":[0.2,0.4,0.6,0.8]}'
这个示例故意保持简单。真实系统还需要记录模型版本、校验输入分布、限制请求大小，并根据 CPU、GPU 和批处理策略选择合适的服务框架。
将推理服务放入 Kubernetes
要把上述服务接入云原生运行环境，可以先构建一个 CPU 镜像。创建 Dockerfile：
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt build_model.py app.py ./
RUN pip install --no-cache-dir -r requirements.txt \
&& python build_model.py
EXPOSE 8000
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]
构建并推送镜像时，将仓库地址替换成自己的镜像仓库：
docker build -t registry.example.com/ai/score-service:0.1.0 .
docker push registry.example.com/ai/score-service:0.1.0
创建 deployment.yaml，并同步替换其中的镜像地址：
apiVersion: apps/v1
kind: Deployment
metadata:
name: score-service
spec:
replicas: 2
selector:
matchLabels:
app: score-service
template:
metadata:
labels:
app: score-service
spec:
containers:
- name: api
image: registry.example.com/ai/score-service:0.1.0
ports:
- name: http
containerPort: 8000
resources:
requests:
cpu: 250m
memory: 512Mi
limits:
cpu: "1"
memory: 1Gi
readinessProbe:
httpGet:
path: /healthz
port: http
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
httpGet:
path: /healthz
port: http
initialDelaySeconds: 15
periodSeconds: 20
---
apiVersion: v1
kind: Service
metadata:
name: score-service
spec:
selector:
app: score-service
ports:
- port: 80
targetPort: http
部署并验证：
kubectl apply -f deployment.yaml
kubectl rollout status deployment/score-service
kubectl port-forward service/score-service 8080:80
curl -s -X POST http://localhost:8080/predict \
-H 'Content-Type: application/json' \
-d '{"features":[0.2,0.4,0.6,0.8]}'
生产环境中不应把模型构建步骤长期留在镜像构建过程里。更常见的做法是由训练流水线生成带校验和的模型产物，再让发布流水线引用不可变版本。对于大型模型，还要评估镜像层、对象存储、节点本地缓存和启动耗时之间的取舍。
团队应把讨论落到哪些决策上
开放源码并不会自动带来可移植性。PyTorch 版本、CUDA 版本、驱动、算子实现和硬件架构仍然可能形成紧密约束。准备采用或升级技术栈时，可以检查以下问题：
- 模型产物是否包含明确的框架版本、代码提交号、数据版本和校验和？
- 在线服务是否区分进程存活与模型就绪，避免流量过早进入实例？
- CPU 与 GPU 工作负载是否使用独立的资源配置和扩缩容指标？
- 延迟指标是否拆分排队、预处理、模型执行和后处理阶段？
- 新模型能否灰度发布，并在质量或延迟退化时快速回滚？
- 依赖、容器基础镜像和模型文件是否进入安全扫描与软件物料清单？
PyTorch Conference China 2026 所体现的方向，可以概括为模型开发与云原生基础设施的进一步汇合。对工程团队而言，最实际的行动不是一次性更换所有组件，而是先建立可重复的模型导出、镜像构建、部署和观测链路，再根据吞吐量、成本及硬件需求逐层优化。