1. 项目概述为什么 FastAPI 上 Saturn Cloud 不是“部署”而是“开箱即用的服务编排”FastAPI 是我过去三年里在数据科学团队和工程侧最常被问到的技术选型之一——它快、类型安全、文档自动生成写个 API 接口像写 Python 函数一样自然。但真正卡住大多数人的从来不是“怎么写”而是“写完之后怎么让别人能稳定、可复现、带监控地用上”。我见过太多团队把 FastAPI 项目打包成 Docker 镜像后扔进本地docker-compose up -d结果一上生产环境就掉链子CPU 突增没人告警、并发请求卡死没日志、模型加载耗时 8 秒却无法预热、甚至因为依赖版本冲突导致/docs页面直接 500。这时候再翻官方文档查 Uvicorn 启动参数、Gunicorn worker 并发模型、健康检查路径配置……时间全花在运维缝合上了。而Saturn Cloud Deployments这个功能本质上不是另一个“容器托管平台”它是专为数据科学工作流设计的服务生命周期抽象层。它把“启动一个 FastAPI 服务”这件事从“写 Dockerfile 配置 Nginx 搭监控 设自动扩缩容”的 7 步流程压缩成 3 个确定性动作定义环境conda 或 pip、声明入口main:app、设置资源规格CPU/GPU/Memory。背后自动完成的包括Uvicorn 多 worker 进程管理、HTTP/HTTPS 终止、TLS 自动续签、Liveness/Readiness 探针注入、Prometheus 指标暴露、请求日志结构化采集、以及最关键的——所有环境变量与 secrets 的零接触式注入不写进代码、不存进 Git、不硬编码进 config.py。这个标题里的 “Hosting FastAPI with Saturn Cloud Deployments”核心价值不在“Host”这个词而在 “Deployments” 这个复数名词。它意味着你不是部署一个服务而是部署一套可版本化、可回滚、可灰度、可审计的服务实例集合。比如你今天上线 v1.2 版本的推荐 API明天要测试 v1.3 加入新特征工程的版本你不需要改任何基础设施代码只需在 Saturn Cloud 控制台点选新镜像、调整流量权重、观察 A/B 对比指标——整个过程对下游调用方完全透明。这正是数据科学家和 ML 工程师真正需要的“部署体验”不碰 Kubernetes YAML不学 Istio不配 Traefik但又能享受企业级服务治理能力。如果你正卡在“模型 API 写好了但不敢上线”、“每次部署都要找 DevOps 开会排期”、“测试环境和生产环境行为不一致”这些痛点上那么这个项目不是教你“怎么把 FastAPI 跑起来”而是帮你把“FastAPI 服务交付”这件事从手工作坊升级成标准化工厂。2. 核心设计逻辑为什么 Saturn Cloud 不走传统 PaaS 路线而选择“环境即服务”范式2.1 传统部署路径的隐性成本有多高先说一个真实案例去年帮一家做金融风控的客户迁移 API 服务。他们原有 FastAPI 服务跑在 AWS EC2 上用 systemd 管理 Uvicorn 进程Nginx 做反向代理日志靠journalctl查监控靠 CloudWatch 自定义指标。迁移前我们做了基线压测单节点 4C8GQPS 稳定在 210 左右P95 延迟 142ms。但上线后第三天凌晨因上游数据源格式突变服务开始大量抛pydantic.ValidationError错误日志刷屏但 Nginx 默认不透传 422 错误码前端只看到空白页更糟的是systemd 没配RestartSec进程崩溃后没自动拉起整整 22 分钟无人发现。事后复盘发现光是修复这个问题就涉及 5 个环节修改 Uvicorn 启动参数加--log-level warning、重写 Nginx 配置透传状态码、给 systemd service 加Restartalways和RestartSec10、在 CloudWatch 创建新的告警规则、还要补上 Pydantic 的全局异常处理器——这不是部署一个 API这是在组装一台精密仪器。这就是传统 PaaS如 Heroku、Render或 IaaSEC2/ECS的典型困境它们提供的是“运行时基础设施”但 FastAPI 服务的稳定性高度依赖于运行时上下文的精确控制——比如Uvicorn 的--workers数不能简单设为 CPU 核数 × 2而要结合模型推理耗时、IO 等待比例动态计算--limit-concurrency必须与数据库连接池大小严格匹配否则出现连接耗尽/health探针必须区分 Liveness进程存活和 Readiness服务就绪前者检查进程 PID后者要真实调用一次模型加载逻辑所有敏感配置API Key、数据库密码、S3 访问密钥必须与代码完全解耦且在不同环境间不可复用。这些细节90% 的 FastAPI 教程不会讲但 100% 的线上事故都源于此。2.2 Saturn Cloud 的破局点“环境即服务”Environment-as-a-ServiceSaturn Cloud 没有把自己定位成“又一个容器托管平台”而是定义了一套Data Science Environment ModelDSEM。它的核心假设很务实数据科学家最熟悉的不是 YAML而是 conda 环境文件和 requirements.txt最信任的不是 CI/CD 流水线而是本地能pip install -e .成功运行的代码。所以 Saturn Cloud Deployments 的设计哲学是把“环境”作为第一公民把“服务”作为环境的自然输出。具体体现在三个层面环境定义即部署契约你提交的environment.ymlconda或requirements.txtpip不是构建镜像的输入而是服务运行时的唯一可信源。Saturn Cloud 会基于此生成一个完全隔离的、可复现的 Python 环境并自动注入uvicorn[standard]、gunicorn、prometheus-client等运维必需依赖——你不用在requirements.txt里写uvicorn0.23.2系统会按最佳实践自动选择兼容版本。服务声明即运行时契约你只需在 Saturn Cloud 控制台填写Module: main和Attribute: app对应main.py中的app FastAPI()实例系统会自动生成符合 ASGI 规范的启动命令uvicorn main:app --host 0.0.0.0:8000 --port 8000 --workers 4 --limit-concurrency 100 --timeout-keep-alive 5注入标准化的健康检查端点GET /healthzLiveness、GET /readyzReadiness暴露/metrics端点供 Prometheus 抓取含http_request_duration_seconds、uvicorn_worker_count等 12 个关键指标自动配置反向代理超时默认 300 秒避免大文件上传中断资源规格即 SLA 契约你选择 “4 CPU / 16 GB RAM / 1 GPU” 不是分配虚拟机而是声明“该服务实例必须满足的最小资源保障”。Saturn Cloud 会据此设置 Linux cgroups 内存/CPUs 限制防止 OOM Killer 杀进程预分配 GPU 显存通过 NVIDIA Container Toolkit避免 CUDA 初始化失败在资源紧张时优先保障该服务实例的 CPU 时间片而非简单 kill 进程。提示这种设计让 Saturn Cloud 天然规避了 Kubernetes 常见的 “Resource Request vs Limit” 陷阱。你不需要纠结requests.memory: 8Gi和limits.memory: 12Gi的差值是否合理因为 Saturn Cloud 的资源规格就是硬性保障没有“请求”和“限制”之分——你要 16GB就给你 16GB 可用内存不多不少。2.3 与 Kubernetes 原生部署的本质差异很多工程师第一反应是“这不就是 K8s Ingress Deployment 吗” 实际上差异远比表面深刻维度Kubernetes 原生部署Saturn Cloud Deployments环境一致性需手动维护Dockerfile易出现 “works on my machine” 问题直接复用本地environment.yml环境哈希值全程可验证配置管理ConfigMap/Secret 需 YAML 定义更新需kubectl apply环境变量在控制台图形化管理修改实时生效历史版本可追溯扩缩容逻辑需编写 HPAHorizontal Pod AutoscalerYAML依赖 Prometheus 指标内置基于请求延迟P95和 CPU 使用率的双因子自动扩缩容阈值可调调试体验kubectl logs -f查日志kubectl exec -it进容器权限受限控制台一键打开 Web Terminal直接curl http://localhost:8000/docs调试支持 VS Code Remote-SSH安全边界Pod 默认共享节点内核需 NetworkPolicy 限制东西向流量每个 Deployment 实例运行在独立 Firecracker microVM 中硬件级隔离最关键的是Kubernetes 的目标是“通用工作负载编排”而 Saturn Cloud 的目标是“数据科学工作负载交付”。前者要求你理解PodDisruptionBudget、TopologySpreadConstraints等概念后者只要求你理解 “我的模型加载需要多少显存”、“这个 API 的平均响应时间是多少毫秒”。3. 实操全流程拆解从本地 FastAPI 项目到 Saturn Cloud 生产环境的 7 个确定性步骤3.1 步骤 1本地项目结构标准化决定后续 90% 的顺利程度很多团队失败的第一步就栽在本地项目结构太随意。Saturn Cloud 对项目结构有明确约定不是“能跑就行”而是“必须按规范组织”否则后续会触发各种隐性报错比如找不到main.py、环境变量注入失败、健康检查返回 404。我建议采用以下经过 12 个生产项目验证的结构my-fastapi-app/ ├── README.md # 必须包含简要说明、API 端点列表、环境要求 ├── environment.yml # 【核心】conda 环境定义必须存在 ├── requirements.txt # 【可选】若用 pip替代 environment.yml ├── main.py # 【核心】FastAPI 实例定义必须含 app FastAPI(...) ├── api/ │ ├── __init__.py │ ├── v1/ │ │ ├── __init__.py │ │ ├── endpoints.py # 路由定义 │ │ └── models.py # Pydantic 模型 │ └── v2/ ├── core/ │ ├── __init__.py │ ├── config.py # 配置管理禁止硬编码 │ └── database.py # 数据库连接含连接池配置 ├── models/ │ ├── __init__.py │ └── predictor.py # 模型加载与推理逻辑支持 lazy load └── tests/ └── test_api.py # 基础端点测试非必须但强烈推荐为什么environment.yml比requirements.txt更推荐因为 conda 能精确锁定二进制依赖如numpy1.24.3py39h1a59cdd_0而 pip 只能锁版本号numpy1.24.3。在涉及 CUDA、OpenBLAS、LLVM 等底层库时conda 的二进制兼容性远高于 pip。实测对比同一requirements.txt在 Saturn Cloud 构建出的镜像GPU 推理吞吐量比 conda 环境低 18%原因就是 cuDNN 版本不匹配。environment.yml示例务必包含dependencies和channelsname: fastapi-env channels: - conda-forge - nvidia dependencies: - python3.9 - pip - pip: - fastapi0.104.1 - uvicorn[standard]0.23.2 - pydantic2.4.2 - scikit-learn1.3.0 - torch2.0.1 - torchvision0.15.2 - pandas2.0.3注意environment.yml中不要写uvicorn的启动参数如--workers那是 Saturn Cloud 的职责。你只负责定义“环境里有什么”不负责“环境怎么运行”。3.2 步骤 2FastAPI 应用改造——3 个必须做的初始化优化原生 FastAPI 项目往往忽略生产环境的关键初始化逻辑。我在 Saturn Cloud 上踩过最深的坑就是模型加载耗时 12 秒但健康检查/readyz在 5 秒内就返回成功导致流量打进来时大量 503。以下是必须加入main.py的初始化段# main.py from fastapi import FastAPI, HTTPException, Depends from fastapi.middleware.cors import CORSMiddleware import time import logging from core.config import settings from models.predictor import Predictor # 初始化日志Saturn Cloud 会自动收集 stdout/stderr但结构化日志更佳 logging.basicConfig( levellogging.INFO, format%(asctime)s - %(name)s - %(levelname)s - %(message)s, ) logger logging.getLogger(__name__) # 全局模型实例单例模式避免重复加载 _predictor: Predictor | None None def get_predictor() - Predictor: Dependency to inject predictor instance global _predictor if _predictor is None: start_time time.time() logger.info(Loading model from %s..., settings.MODEL_PATH) try: _predictor Predictor.load(settings.MODEL_PATH) load_time time.time() - start_time logger.info(Model loaded successfully in %.2f seconds, load_time) except Exception as e: logger.error(Failed to load model: %s, str(e)) raise HTTPException(status_code500, detailfModel load failed: {str(e)}) return _predictor # FastAPI 实例 app FastAPI( titleRecommendation API, descriptionReal-time item recommendation service, version1.2.0, # 关键禁用 docs 和 redoc 在生产环境Saturn Cloud 有独立 API 文档门户 docs_urlNone if settings.ENVIRONMENT production else /docs, redoc_urlNone if settings.ENVIRONMENT production else /redoc, ) # 添加 CORS 中间件Saturn Cloud 默认允许所有来源但显式声明更安全 app.add_middleware( CORSMiddleware, allow_origins[*], allow_credentialsTrue, allow_methods[*], allow_headers[*], ) # 健康检查端点Saturn Cloud 会自动调用 /readyz但你需确保它真实反映服务就绪状态 app.get(/readyz) def readyz(): Readiness probe: checks if model is loaded and ready to serve try: predictor get_predictor() # 可选执行一次轻量级推理验证 # predictor.predict([test_item]) return {status: ok, model_loaded: True} except Exception as e: logger.error(Readiness check failed: %s, str(e)) raise HTTPException(status_code503, detailModel not ready) app.get(/healthz) def healthz(): Liveness probe: checks if process is running return {status: ok} # 主 API 端点 app.post(/v1/recommend) def recommend(items: list[str], predictor: Predictor Depends(get_predictor)): start_time time.time() try: result predictor.predict(items) latency_ms (time.time() - start_time) * 1000 logger.info(Recommendation completed in %.2f ms, latency_ms) return {recommendations: result} except Exception as e: logger.error(Prediction failed: %s, str(e)) raise HTTPException(status_code500, detailPrediction error)核心要点解析模型懒加载Lazy Loadget_predictor()依赖注入确保模型只在首次请求时加载避免启动时阻塞。Saturn Cloud 的/readyz探针会触发第一次加载后续请求直接复用。健康检查分离/healthz只检查进程存活几乎瞬时/readyz必须验证模型加载成功。Saturn Cloud 默认用/readyz作为 Readiness 探针确保流量只打到真正就绪的实例。日志结构化使用logging.info()而非print()Saturn Cloud 的日志系统能自动解析时间戳、日志级别、消息体便于在控制台按关键词过滤。3.3 步骤 3配置中心化管理——core/config.py的正确写法硬编码配置是线上事故的温床。Saturn Cloud 提供环境变量注入能力但你需要一个健壮的配置解析层。core/config.py是整个项目的配置中枢必须支持多环境、类型安全、默认值兜底# core/config.py from pydantic import BaseSettings, validator from typing import Optional class Settings(BaseSettings): # 必填项无默认值必须通过环境变量提供 ENVIRONMENT: str # development, staging, production MODEL_PATH: str # S3 或本地路径如 s3://my-bucket/models/v1.2/ # 可选配置有默认值环境变量可覆盖 LOG_LEVEL: str INFO UVICORN_WORKERS: int 4 UVICORN_TIMEOUT_KEEP_ALIVE: int 5 DATABASE_URL: Optional[str] None # 若服务需访问 DB # 自动推导字段基于 ENVIRONMENT validator(LOG_LEVEL, alwaysTrue) def set_log_level(cls, v, values): if values.get(ENVIRONMENT) production: return WARNING # 生产环境降低日志量 return v or INFO validator(UVICORN_WORKERS, alwaysTrue) def set_workers(cls, v, values): # 根据 CPU 核数动态调整Saturn Cloud 会注入 CPU_COUNT 环境变量 import os cpu_count int(os.getenv(CPU_COUNT, 4)) if values.get(ENVIRONMENT) production: return max(2, min(cpu_count * 2, 12)) # 生产环境2~12 个 worker return 1 # 开发环境单 worker方便调试 class Config: # 从环境变量读取配置前缀可选如 FASTAPI_ env_prefix FASTAPI_ # 允许任意额外字段避免因新增环境变量报错 extra allow settings Settings()为什么这样设计env_prefix FASTAPI_意味着你设置环境变量FASTAPI_ENVIRONMENTproductionPydantic 会自动映射到settings.ENVIRONMENT。这避免了环境变量名污染全局命名空间。validator装饰器实现动态计算UVICORN_WORKERS不是固定值而是根据 Saturn Cloud 注入的CPU_COUNT环境变量实时计算。实测表明在 8C 实例上worker 数设为 12 比设为 8 QPS 高 23%因为 FastAPI 的异步特性允许更多并发 worker。extra allow是关键容错机制。Saturn Cloud 会注入大量运维相关环境变量如SATURN_DEPLOYMENT_ID,SATURN_CLUSTER_NAME如果Config.extra forbidPydantic 解析会直接崩溃。3.4 步骤 4在 Saturn Cloud 控制台创建 Deployment图形化操作详解登录 Saturn Cloud 后进入Deployments标签页点击Create Deployment。整个过程无需写一行 YAML全部图形化操作但每个选项都有其技术含义Deployment Name输入recommendation-api-v1-2建议包含服务名版本号便于识别Source Code选择 GitHub 仓库支持私有库填写Repository:your-org/my-fastapi-appBranch:mainPath to Environment File:environment.yml或requirements.txtRuntime ConfigurationEnvironment Type: 选择Conda推荐或PipPython Version: 自动从environment.yml读取如python3.9不可修改Entry Point:Module:main对应main.py文件名Attribute:app对应app FastAPI()实例ResourcesCPU: 选择4 CPUs对应 Saturn Cloud 的 4 核实例Memory:16 GB注意这是硬性保障不是 limitGPU:1 x NVIDIA T4若模型需 GPU 加速Storage:50 GB挂载到/home/jovyan/work用于缓存模型、临时文件Networking SecurityPublic URL: 自动生成https://recommendation-api-v1-2.your-org.saturncloud.io可自定义子域名HTTPS: ✅ Enabled自动申请 Lets Encrypt 证书90 天自动续签Authentication: 选择None公开 API或Saturn Cloud Users需登录 Saturn Cloud 账户访问Advanced OptionsHealth Check Path:/readyz默认必须与代码中一致Health Check Interval:10 seconds默认可调至 5 秒提高灵敏度Startup Timeout:300 seconds关键给模型加载留足时间避免因超时被 killEnvironment Variables: 点击Add Variable填入Key:FASTAPI_ENVIRONMENT, Value:productionKey:FASTAPI_MODEL_PATH, Value:s3://my-bucket/models/v1.2/Key:AWS_ACCESS_KEY_ID, Value:{{ secrets.AWS_ACCESS_KEY_ID }}引用 Saturn Cloud SecretsKey:AWS_SECRET_ACCESS_KEY, Value:{{ secrets.AWS_SECRET_ACCESS_KEY }}提示{{ secrets.XXX }}语法是 Saturn Cloud 的 Secrets 引用机制。你需先在Settings Secrets中创建AWS_ACCESS_KEY_ID和AWS_SECRET_ACCESS_KEY它们不会出现在任何日志或 UI 中仅在容器启动时注入。3.5 步骤 5Secrets 安全管理——杜绝硬编码密钥的终极方案把AWS_SECRET_ACCESS_KEY写进代码或environment.yml是严重安全风险。Saturn Cloud 的 Secrets 管理是其企业级能力的核心体现进入Settings Secrets点击Add Secret输入 Secret Name:AWS_ACCESS_KEY_IDValue:AKIA...你的实际密钥点击Add Secret再添加AWS_SECRET_ACCESS_KEY返回 Deployment 配置在Environment Variables中用{{ secrets.AWS_ACCESS_KEY_ID }}引用技术原理Saturn Cloud 在容器启动前会将 Secrets 解密并注入为环境变量整个过程密钥加密存储在 Saturn Cloud 后端使用 AWS KMS注入时通过 Linuxseccomp机制限制容器对/proc/self/environ的读取防止恶意进程 dump 环境变量支持 Secrets 轮换更新 Secret 值后所有关联 Deployment 会自动滚动更新旧实例优雅终止新实例用新密钥启动实测对比某客户曾将密钥硬编码在config.py中Git 提交后被扫描工具捕获导致 AWS 账户被滥用。迁移到 Saturn Cloud Secrets 后密钥泄露风险归零。3.6 步骤 6部署后验证与监控——5 分钟定位 90% 的问题Deployment 创建后Saturn Cloud 会自动克隆代码仓库解析environment.yml构建环境启动容器调用/readyz探针成功后将流量路由到该实例验证清单5 分钟内完成检查构建日志在 Deployment 详情页切换到Build Logs标签。正常应看到Building conda environment from environment.yml... Installing dependencies: python3.9, fastapi0.104.1, torch2.0.1... Successfully built environment.检查运行日志切换到Logs标签等待 30 秒应看到INFO: Started server process [1] INFO: Loading model from s3://my-bucket/models/v1.2/... INFO: Model loaded successfully in 11.32 seconds INFO: Application startup complete.手动触发健康检查在终端执行curl -I https://recommendation-api-v1-2.your-org.saturncloud.io/readyz # 应返回 HTTP/2 200 OK访问 API 文档若未禁用curl https://recommendation-api-v1-2.your-org.saturncloud.io/docs # 应返回 Swagger UI HTML查看监控面板在 Deployment 详情页Metrics标签下重点关注HTTP Requests Total确认有请求流入HTTP Request Duration (P95)应稳定在预期范围内如 200msUvicorn Worker Count应等于你配置的 worker 数如 8Memory Usage应平稳无陡升陡升可能表示内存泄漏注意若Memory Usage在 5 分钟内从 2GB 涨到 14GB立即点击Restart按钮并检查models/predictor.py是否有全局缓存未清理。3.7 步骤 7灰度发布与版本回滚——如何零 downtime 升级 API生产环境最怕“一升级就炸”。Saturn Cloud 的 Deployments 原生支持蓝绿部署创建新版本 Deployment重复步骤 4但Name:recommendation-api-v1-3Branch:release/v1.3Environment Variable:FASTAPI_MODEL_PATHs3://my-bucket/models/v1.3/等待新版本就绪在Deployments列表确认recommendation-api-v1-3状态为Running流量切分点击recommendation-api-v1-2的Edit在Traffic Splitting区域将recommendation-api-v1-2流量设为80%将recommendation-api-v1-3流量设为20%点击Save Changes观测指标在Metrics面板对比两个版本的HTTP Request Duration (P95)和HTTP Requests 5xx Total。若 v1.3 的 5xx 错误率 0.1%立即切回 100% v1.2全量发布确认 v1.3 稳定 30 分钟后将流量 100% 切到 v1.3然后删除 v1.2 Deployment整个过程无需修改 DNS不中断服务所有操作在 Saturn Cloud 控制台 2 分钟内完成。相比 Kubernetes 的 Helm Chart 版本管理这种图形化流量切分对数据科学家更友好。4. 高频问题排查手册从构建失败到性能瓶颈的 12 个实战解决方案4.1 构建失败类问题问题 1CondaResolveError: UnsatisfiableError现象Build Logs 中出现Found conflicts! Looking for incompatible packages.根因environment.yml中指定了互斥依赖如同时要求torch1.13.1和tensorflow2.12.0二者 CUDA 版本冲突解决使用conda search --info torch1.13.1查看其依赖的cudatoolkit版本在environment.yml中显式指定兼容的cudatoolkit例如dependencies: - cudatoolkit11.7 - torch1.13.1 - tensorflow2.11.0 # 适配 CUDA 11.7 的版本问题 2ModuleNotFoundError: No module named main现象容器启动失败日志显示找不到main.py根因代码仓库根目录下没有main.py或main.py不在仓库根路径如放在src/子目录解决确保main.py在仓库根目录或在 Saturn Cloud 控制台Runtime Configuration中将Path to Environment File设为src/environment.yml同时确保src/main.py存在问题 3Connection refusedon/readyz现象Build 成功但 Deployment 状态卡在Starting日志无Application startup complete根因Uvicorn 未监听0.0.0.0:8000或端口被占用解决检查main.py中是否显式设置了--host 0.0.0.0 --port 8000不要写Saturn Cloud 会自动注入确认main.py中没有if __name__ __main__: uvicorn.run(...)这类手动启动逻辑会与 Saturn Cloud 的启动命令冲突4.2 运行时异常类问题问题 4503 Service Unavailableon all endpoints现象/readyz返回 503日志显示Model load failed根因模型文件路径错误或 S3 权限不足排查在 Deployment 控制台点击Terminal执行aws s3 ls s3://my-bucket/models/v1.2/ # 检查路径是否存在 cat /home/jovyan/.aws/credentials # 确认 credentials 已注入若aws s3 ls报错AccessDenied检查 Secrets 中的AWS_ACCESS_KEY_ID是否有s3:GetObject权限问题 5422 Unprocessable Entityon POST requests现象请求体 JSON 格式正确但 FastAPI 返回 422 错误根因Pydantic 模型字段类型与请求体不匹配如定义items: List[str]但传入{items: single_string}解决在endpoints.py中为模型添加详细错误处理from fastapi.exceptions import RequestValidationError from starlette.responses import JSONResponse app.exception_handler(RequestValidationError) async def validation_exception_handler(request, exc): # 记录详细错误日志 logger.error(Validation error for %s: %s, request.url.path, exc.errors()) return JSONResponse( status_code422, content{detail: Invalid input format. Please check documentation.} )问题 6504 Gateway Timeout现象请求超过 300 秒无响应Saturn Cloud 网关返回 504根因Saturn Cloud 默认网关超时为 300 秒但你的模型推理耗时 300 秒解决优化模型量化、剪枝、改用更小模型或在Advanced Options中将Startup Timeout提高到600最大支持 600 秒不推荐延长网关超时这会阻塞其他请求4.3 性能瓶颈类问题问题 7QPS 上不去CPU 使用率 30%现象压测时 QPS 卡在 150但 CPU 监控显示只有 25%根因Uvicorn worker 数不足或数据库连接池耗尽排查查看Uvicorn Worker Count指标确认是否等于配置的UVICORN_WORKERS