在本地跑通一个AI应用的Demo和把它部署到生产环境稳定运行，中间差着一整条鸿沟。Demo只需要关心"能不能跑"，生产要考虑"跑得稳不稳、安不安全、出问题能不能快速恢复"；

这篇文章是一个上线检查清单，每一条都是踩过坑之后才加上去的；

配置管理

用环境变量管理所有配置，不同环境用不同的.env文件：

import os

class Config:
    MODEL_NAME = os.getenv("MODEL_NAME", "deepseek-r1:7b")
    LLM_BASE_URL = os.getenv("LLM_BASE_URL", "http://localhost:11434/v1")
    MAX_TOKENS = int(os.getenv("MAX_TOKENS", "2048"))
    REQUEST_TIMEOUT = int(os.getenv("REQUEST_TIMEOUT", "60"))
    DATABASE_URL = os.getenv("DATABASE_URL")
    API_KEY = os.getenv("API_KEY")
    CORS_ORIGINS = os.getenv("CORS_ORIGINS", "").split(",")

敏感信息（数据库密码、API密钥）不要写在代码里，也不要用.env文件（容易被提交到Git）。用密钥管理服务（Vault、AWS Secrets Manager、K8s Secrets）。

认证和限流

生产环境的API必须有认证。API Key验证是最简单的方式——从请求头里取Bearer token，和数据库里的合法Key对比；

限流用令牌桶算法，按IP或按用户限制每分钟请求数。大模型推理的成本和请求量直接挂钩，不限流就意味着有人可以刷爆你的预算；

错误处理和降级

AI服务的错误处理比传统Web服务复杂，因为除了网络错误还有模型本身的错误：

import asyncio

async def safe_chat(messages, primary_backend, fallback_backend):
    try:
        return await asyncio.wait_for(
            primary_backend.chat(messages),
            timeout=30
        )
    except asyncio.TimeoutError:
        logger.warning("主模型超时，降级到备用模型")
        return await fallback_backend.chat(messages)
    except Exception as e:
        logger.error(f"推理失败: {e}")
        return {"error": "服务暂时不可用，请稍后重试"}

降级策略：模型超时→切换到备用模型或返回缓存结果；模型不可用→返回静态的错误提示而不是500页面；输出质量异常→对输出做基本检查（长度、格式），不合理的输出不返回。

日志

关键日志点：每次请求的输入摘要（不要记完整输入，可能有隐私）、模型名和参数、推理耗时、Token用量、错误信息；

import logging, time

logger = logging.getLogger("ai-service")

async def logged_chat(request):
    start = time.time()
    logger.info(f"Request: model={request.model}, msgs={len(request.messages)}")

    try:
        response = await backend.chat(request)
        elapsed = time.time() - start
        logger.info(f"Done: {elapsed:.2f}s, tokens={response.usage}")
        return response
    except Exception as e:
        elapsed = time.time() - start
        logger.error(f"Failed: {elapsed:.2f}s, error={e}")
        raise

CI/CD流水线

name: Deploy
on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - run: pip install -r requirements.txt
    - run: pytest tests/

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - run: docker build -t ai-app:${{ github.sha }} .
    - run: docker push registry/ai-app:${{ github.sha }}
    - run: kubectl set image deploy/ai-app app=registry/ai-app:${{ github.sha }}

关键原则：测试不过不能部署；镜像tag用commit SHA而不是latest，方便回滚；部署后自动跑冒烟测试验证核心功能。

性能优化

响应缓存：相同或高度相似的问题缓存结果。用Redis存，设置合理的TTL；

请求合并：多个短请求可以合并成一个batch处理，提升GPU利用率；

异步处理：非实时需求的任务（比如批量文档分析）用消息队列异步处理；

上线检查清单

在点"部署"之前过一遍：API认证配了吗？限流配了吗？超时设了吗？日志全吗？监控有吗？告警有吗？数据库有备份吗？有回滚方案吗？压力测了吗？这九个问题，任何一个回答"没有"都不应该上线。

写在最后

Demo到生产的距离不是"再加几个功能"，而是"把工程化体系补齐"。环境配置、认证限流、错误处理、监控告警、CI/CD，每一个都是必修课，没有捷径。