DeepSeek与FastAPI构建后端AI服务的教程-人工智能-PHP中文网

最稳妥路径是用ollama或官方api代理而非fastapi直载模型，因后者易显存溢出、启动卡死、首次请求延迟高；ollama适合本地开发，官方api适合生产，长上下文需加max_tokens限制。

☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜

deepseek与fastapi构建后端ai服务的教程

直接用 FastAPI 封装 DeepSeek 模型提供 API 服务，最稳妥的路径不是自己加载模型跑推理，而是走 ollama 或官方 API 代理——前者适合本地开发调试，后者适合生产环境快速上线。自己用 transformers 加载 deepseek-ai/deepseek-7b 这类大模型，极易在显存、dtype、device_map 上踩坑，且 uvicorn 多进程下模型重复加载还会导致 OOM。

为什么不该在 FastAPI 里直接调用 transformers.load_model

常见错误现象是启动时卡死、torch.cuda.OutOfMemoryError、或首次请求延迟超 20 秒。根本原因是：

AutoModel.from_pretrained() 默认加载 full precision（fp16/bf16），7B 模型在单卡 RTX 4090 上也要占 14GB+ 显存
uvicorn --workers 4 会启动 4 个进程，每个都加载一遍模型 → 显存 ×4
没设 device_map="auto" 或手动 .to("cuda:0")，可能把全部参数塞进 CPU 内存，触发 swap
PyTorch 的 CUDA 上下文初始化在子进程中不稳定，容易报 Cannot re-initialize CUDA in forked subprocess

推荐方案：用 ollama 作后端模型服务，FastAPI 做轻量代理

这是目前本地开发最省事、最不容易崩的方式。ollama 已内置模型调度、GPU 显存复用和流式响应支持，FastAPI 只需转发请求、做鉴权和日志。

Unified LLM Gateway - One API for 70+ AI models. Route to GPT, Claude, Gemini, Qwen, Deepseek, Grok and more

统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。

下载

实操要点：

先确保 ollama 正在运行：ollama run deepseek-r1:1.5b（小模型起步，别一上来就拉 deepseek-67b）
FastAPI 中用 httpx.AsyncClient（非 requests）调用 http://localhost:11434/api/chat，保持异步链路不阻塞
请求体必须 match ollama 的 schema：{"model": "deepseek-r1:1.5b", "messages": [{"role": "user", "content": "你好"}], "stream": false}
别忘了加 timeout：timeout=httpx.Timeout(30.0, connect=10.0)，防止模型卡死拖垮整个服务

生产环境该用 DeepSeek 官方 API 还是自建 ollama？

看三个硬指标：

如果日均请求 https://api.deepseek.com/v1/chat/completions，配好 DEEPSEEK_API_KEY 环境变量就行，省心又稳
如果要处理敏感数据、禁止出内网、或需定制 prompt 模板 → 必须自建 ollama，但建议只部署 deepseek-r1:1.5b 或 deepseek-v3.2-think 这类轻量版，别硬刚 67B
如果并发 > 200、要求 sub-800ms P95 延迟 → 放弃单机 ollama，改用 vLLM + FastAPI，但这时你得自己管 tokenizer 对齐、logprobs 截断、stop_token 处理——这些细节文档里从不提，全靠 debug 日志反推

最容易被忽略的一点：DeepSeek 的上下文长度标称 128K，但实际在 ollama 或 vLLM 中，超过 32K token 后推理速度会断崖式下降，而且 stream 响应可能卡在中间不动。真要用长上下文，务必在 FastAPI 层加 max_tokens 硬限制，并在前端做分块摘要预处理。