2026 年如何搭建 DeepSeek 应用：从托管 API 到本地与自建推理

最后更新：2026 年 4 月 5 日

这几年 DeepSeek 的产品形态已经完全不同于早期的 V3 / R1 时代。现在的托管 API 只暴露两个主要模型名：deepseek-chat 和 deepseek-reasoner，底层统一映射到 DeepSeek-V3.2，支持 128K 上下文；开源权重生态则覆盖原始 R1、各类 distill、V3.1 / V3.2 变体，以及多种高性能推理方案。

因此，2026 年真正要回答的问题不再是“能不能跑 DeepSeek”，而是：在延迟、成本、隐私和运维容忍度之间，哪条 DeepSeek 路线最适合你？

核心结论概览

对大多数产品团队来说，托管 DeepSeek API 是最快的上线路径：
- OpenAI 接口兼容
- 也提供 Anthropic 兼容端点
- 当前 deepseek-chat / deepseek-reasoner 均映射到 DeepSeek-V3.2（128K 上下文）
做 本地原型，优先考虑 Ollama：
- DeepSeek-R1 模型从 1.5B 到 70B 的量化版本一应俱全
- 全部标注为 128K 上下文
- 本地 /api/chat 已是消息式接口，接入简单
做 严肃的自建旗舰推理，不要默认只用 Transformers：
- DeepSeek 官方推荐 SGLang、LMDeploy、TensorRT-LLM、vLLM 等专门推理栈
老教程经常混淆：上下文长度、最大输出长度、原始 checkpoint 体积、量化运行体积，这些是完全不同的概念，搞混会直接导致硬件和部署决策出错。

DeepSeek 目前的产品形态

截至 2026 年 4 月 5 日，托管 API 的表面模型列表远比底层模型谱系简单：

公共文档只列出两个模型名：deepseek-chat 与 deepseek-reasoner
当前价格与模型文档显示：两者都映射到 DeepSeek-V3.2，上下文 128K
区别在于行为：
- deepseek-chat：非思维模式（non-thinking）
- deepseek-reasoner：思维模式（thinking），会显式输出推理内容
API：
- 使用 DeepSeek 标准 endpoint
- 支持 OpenAI 兼容 schema
- 也提供 Anthropic 兼容路由

理解版本演进很重要，因为大量文章停留在最初的 V3 / R1 阶段。官方 changelog 大致顺序如下：

2024-12-26：DeepSeek-V3
2025-01-20：DeepSeek-R1
2025-03-25：DeepSeek-V3-0324
2025-05-28：DeepSeek-R1-0528
2025-08-21：DeepSeek-V3.1
2025-09-22：DeepSeek-V3.1-Terminus
2025-09-29：DeepSeek-V3.2-Exp
2025-12-01：DeepSeek-V3.2

2025 年之后，变化不只是“模型更强”：

V3-0324：强化推理与工具调用
R1-0528：加入 JSON 输出与函数调用
V3.1：引入“思维 / 非思维”混合架构，并更新托管 API 映射
V3.2：在托管 API 上把思维模式直接融入工具调用流程

因此，“推理用 R1、其他用 V3”这类老建议已经过时。现在：

托管侧：主要是在 V3.2 非思维 与 V3.2 思维 之间做选择
开源权重侧：R1 家族仍然重要，但只是整个生态的一部分

如何选择合适的 DeepSeek 路线

真正的选择标准不是“我更喜欢哪一代模型”，而是：你能接受怎样的运维复杂度和成本结构。

下面是基于当前 DeepSeek API 文档、Ollama DeepSeek-R1 列表以及官方 / 推理框架维护者的部署建议，抽象出的决策思路：

1. 初创团队 / 内部产品：优先托管 API

直接获得最新 V3.2 行为
无需自建推理集群
DeepSeek 默认为所有用户开启 上下文缓存（context caching）：
- 对重复前缀（如系统提示、长文档）能显著降低输入成本

2. 个人开发者 / 小型内部工具：优先 Ollama

与其一上来就自建旗舰开源权重推理，不如先用 Ollama：

DeepSeek-R1 的量化标签在 Ollama 中大致为：
- 1.5b：约 1.1GB
- 7b：约 4.7GB
- 8b：约 5.2GB
- 14b：约 9.0GB
- 32b：约 20GB
- 70b：约 43GB
这些体积指的是 本地量化产物，不是原始 checkpoint 大小
本地 /api/chat 已是消息式接口，方便与现有 OpenAI 风格代码对接

3. 生产级自建：只在“必须掌控基础设施”时上

如果你确实需要：

完全可控的部署环境
特定吞吐 / 并发目标
合规或数据主权要求

那么才值得投入精力做旗舰模型自建推理。此时应优先选择：

SGLang
vLLM
LMDeploy
TensorRT-LLM
以及 DeepSeek 官方文档明确支持的其他路径

而不是对旗舰模型简单“from transformers import AutoModelForCausalLM 就完事”。

不要被“模型大小”误导：四个要分清的概念

老教程最常见的坑，就是把以下四类数字混在一起：

旗舰 / 全尺寸模型
- DeepSeek-V3.1 模型卡：
  - 671B 总参数，37B 激活参数
  - 128K 上下文
- DeepSeek-V3.2 模型卡：
  - 685B 参数
  - MIT License 开源
- 这类模型是“基础设施级别”，不是“随手下载本地跑一跑”的体量。
偏推理的开源权重（R1 家族）
- 原始 DeepSeek-R1 README：
  - 671B 总参数、37B 激活参数、128K 上下文
- 适合做深度推理研究和高质量 agent，但部署门槛高。
Distill 变体
- 官方 R1 仓库列出基于 Qwen / Llama 的 distill：
  - 1.5B、7B、8B、14B、32B、70B
- 明确说明：这些 distill 的使用方式与对应 Qwen / Llama 家族类似
- 这意味着：
  - 对 distill 来说，Transformers 是合理选择
  - 对旗舰模型，则应优先考虑专门推理栈
原始 checkpoint 体积 vs 本地量化产物体积
- 例如：
  - DeepSeek-R1-Distill-Qwen-1.5B 在 Hugging Face 上约 3.55GB
  - Ollama 中对应 1.5b 量化产物约 1.1GB
  - 7B distill 在 Hugging Face 上约 15.2GB，Ollama 本地构建约 4.7GB
- 这些数字并不矛盾，只是：
  - 格式不同
  - 精度不同
  - 运行时假设不同

同样的谨慎也适用于 上下文长度 vs 输出长度：

托管 API 文档：
- deepseek-chat / deepseek-reasoner 均为 128K 上下文
但同一页面会给出不同的 输出窗口限制：
- deepseek-chat 默认 / 最大输出窗口低于 deepseek-reasoner
- 思维模式文档说明：
  - max_tokens 包含 chain-of-thought（推理）token
  - 默认约 32K，最大约 64K

换句话说：上下文预算 与 生成 token 预算 是两套独立控制项。

当前可用的部署选项

托管 DeepSeek API

对大多数产品来说，这是最干净的路径：

托管 endpoint
OpenAI 兼容请求结构
支持 JSON 输出、工具调用、流式响应
默认使用最新 V3.2 行为
提供 Anthropic 兼容端点，方便已有 Claude 生态集成

Ollama

适合本地 DeepSeek-R1 家族实验：

/api/chat 为消息式接口
响应中包含 thinking 与 tool_calls 字段
本地开发默认无需鉴权（仅限 localhost），非常适合快速原型

vLLM / SGLang / LMDeploy / TensorRT-LLM

这些才是自建生产环境的主力：

DeepSeek V3 仓库明确列出：
- SGLang、LMDeploy、TensorRT-LLM、vLLM、LightLLM 等推荐路径
- 并说明旗舰模型 暂未直接支持 Hugging Face Transformers
SGLang 文档：
- 声明有 DeepSeek 专项优化
- 从一开始就被官方推荐
vLLM、LMDeploy、TensorRT-LLM：
- 均发布了对 DeepSeek V3.x / R1 级别模型的支持与部署指南

Transformers 的定位

Transformers 依然有用，但要用在对的地方：

适用场景：
- 各类 distill 模型
- 实验室 / 研究型工作流
这些模型行为类似 Qwen / Llama 指令模型：
- 应使用模型自带的 chat template 格式化消息
- 不要直接塞“裸 prompt”
对 DeepSeek 旗舰模型，自建部署时 Transformers 不是官方推荐路径。

应用搭建示例

示例一：Python 后端 + 结构化 JSON 输出

DeepSeek API 支持通过 response_format={"type":"json_object"} 强制 JSON 输出。文档也提醒：

提示词中要 明确要求返回 JSON
否则模型可能输出空白或自由文本，导致 JSON 解析失败

import os
import json
from fastapi import FastAPI
from pydantic import BaseModel
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

app = FastAPI()

class NotesRequest(BaseModel):
    title: str
    transcript: str

@app.post("/api/extract-notes")
def extract_notes(req: NotesRequest):
    prompt = f"""
    Return valid JSON only.
    The JSON must contain these keys:
    summary, action_items, risks

    Title: {req.title}
    Transcript:
    {req.transcript}
    """

    response = client.chat.completions.create(
        model="deepseek-chat",
        messages=[
            {
                "role": "system",
                "content": "You extract structured meeting notes and return valid JSON.",
            },
            {
                "role": "user",
                "content": prompt,
            },
        ],
        response_format={"type": "json_object"},
    )

    return json.loads(response.choices[0].message.content)

这种模式非常适合：

内部 Copilot
会议纪要类应用
CRM 信息补全
任何需要“确定字段而非聊天文本”的产品场景

示例二：TypeScript 路由 + 流式输出 + 思维模式

当前 DeepSeek API：

支持流式响应
支持在流中返回用量数据
通过 thinking 字段开启思维模式
在流中以 reasoning_content 与普通 content 并行输出

export async function POST(req: Request) {
  const { messages } = await req.json();

  const upstream = await fetch("https://api.deepseek.com/chat/completions", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Authorization": `Bearer ${process.env.DEEPSEEK_API_KEY}`,
    },
    body: JSON.stringify({
      model: "deepseek-chat",
      messages,
      stream: true,
      stream_options: { include_usage: true },
      thinking: { type: "enabled" },
    }),
  });

  if (!upstream.ok || !upstream.body) {
    return new Response("Upstream error", { status: 502 });
  }

  return new Response(upstream.body, {
    headers: {
      "Content-Type": "text/event-stream",
      "Cache-Control": "no-cache, no-transform",
      Connection: "keep-alive",
    },
  });
}

这类传输方式非常适合真正的聊天产品：

降低用户感知延迟
在流中拿到用量数据，方便计费与观测
可以在内部工具中展示思维过程，在面向用户的界面中隐藏

提示词与推理模式的实践建议

托管 API：把“思维模式”当成 API 功能，而不是提示词黑魔法

当前文档：
- 通过 deepseek-reasoner 或请求体中的 thinking 字段开启推理
- 返回专门的 reasoning_content 流
推理模式下：
- temperature、top_p、各类 penalty 不受支持，会被忽略

非思维模式：按任务类型调整采样参数

DeepSeek 参数指南比很多通用教程更具体：

编码 / 数学：建议 极低 temperature
对话 / 翻译 / 创作：可以适当提高 temperature

不要把同一套采样参数硬套到所有任务上。

自建 R1 家族：严格按具体版本文档来

老一代 R1 文档的典型建议：

temperature 0.5–0.7
避免使用 system prompt
有时需要强制输出以 \n 开头，避免模型跳过推理模式

但在更新的 R1-0528-Qwen3-8B 指南中：

已说明 支持 system prompt
不再需要强制 \n

正确的做法不是“永远不用 system prompt”，而是：

严格遵循你所部署的那一款模型的官方提示词建议。

工具调用：注意版本差异

当前文档：
- 从 V3.2 开始，思维模式下的工具调用 得到正式支持
- 严格函数调用（beta）需要：
  - 使用 beta base URL
  - 工具 schema 满足文档约束
如果你在做真正的 agent：
- 不要再照抄 2025 年只展示“纯文本推理、无工具循环”的示例

用 DeepSeek 做真实产品的路线

聊天应用

默认从 托管 API 起步，除非你有强隐私 / 离线要求
优先级顺序：
1. 先接入流式输出
2. 当模型知识覆盖不足时，再加检索（RAG）
3. 当助手需要“执行动作”而非只回答时，再引入工具调用

RAG 助手

充分利用：
- DeepSeek 的上下文缓存
- 结构化输出能力
检索适用于：
- 语料更新频繁
- 需要精确回溯到原文档
上下文缓存适用于：
- 系统提示 + 检索前缀在多轮对话中高度重复

内部知识 Copilot

比起“模型多新”，可观测性更重要：
- 检索层要显式、可调试
- 记录提示词与输出（注意脱敏）
- 在小范围灰度前，用固定任务集做评估
尤其在使用推理模式 / 工具调用时：
- 失败可能被“长推理轨迹”掩盖
- 更需要日志与可视化分析

编码助手

有两条现实可行的路线：

托管 API：
- 追求速度与托管基础设施
- 可利用 Anthropic 兼容端点，接入 Claude Code 风格工具
本地 / 自建：
- 有强隐私 / 合规要求
- 优先选择 distill 或精心部署的旗舰推理栈
- 不要试图把超大模型硬塞进“随便一台机器”里

成本与基础设施

托管 API 成本

价格高度时效化，发布或上线前务必以官网为准。当前公开页面大致说明：

Token 计费：
- 输入按 cache-hit / cache-miss 区分单价
- 输出单独计费
不同模式（deepseek-chat vs deepseek-reasoner）的输出窗口限制不同
上下文缓存对所有用户默认开启

自建推理成本

自建成本远不止“GPU 每小时多少钱”：

量化方案
并发目标
吞吐需求
上下文长度
batch 策略
额外内存开销

DeepSeek 与 vLLM 等官方资料对旗舰部署给出的建议包括：

FP8 / FP4 等低精度方案
H200 / B200 等高端 GPU 的配置示例

这再次说明：旗舰开源权重 ≠ 轻量本地模型，不要混为一谈。

安全与生产可用性

API Key 必须放在服务端
DeepSeek 错误码文档明确列出：
- 鉴权失败
- 配额 / 支付失败
- 参数校验错误
- 限流错误
- 服务可用性问题
应用层要：
- 友好处理这些错误
- 不要把底层 provider 的原始错误直接暴露给终端用户

限流与重试

文档中关于限流的描述存在差异：

某些 quickstart 页面写“API 不限制用户速率”
FAQ 中则说明：
- 速率上限会根据整体流量与近期使用情况 动态调整
- 当前无法按账号单独提升

实务上的结论：

一定要实现：
- 重试机制
- 熔断 / 降级
- 备用路径（如多模型或多 provider）
不要根据某张旧截图，硬编码一个“固定速率上限”假设

本地 Ollama 的安全边界

本地开发时，localhost 默认无需鉴权
一旦端口暴露到局域网 / 公网：
- 要像对待任何内部服务一样加上认证与访问控制

老 DeepSeek 教程中的常见错误

把 DeepSeek-V3 / R1 当成整个平台
- 忽略了 V3-0324、R1-0528、V3.1、V3.2-Exp、V3.2 等后续演进
- 更忽略了托管 API 现在统一指向 V3.2 的现实
假定旧版价格 / 基础设施截图仍然有效
- 忽视了：
  - 实时价格页面
  - 上下文缓存对成本的影响
  - 不同模式的输出限制差异
混淆量化产物体积与原始 checkpoint 体积
- 把 Ollama 标签体积当成“模型真实大小”
- 忽略量化带来的精度与内存差异
混淆上下文长度与最大输出长度
- 只看到“128K 上下文”，却没注意：
  - 实际生成窗口更小
  - 且随模式不同而变化
把 Transformers 当成旗舰部署的默认答案
- 忽视官方对 SGLang、LMDeploy、TensorRT-LLM、vLLM 等专门栈的推荐
- 忽略“Transformers 更适合 distill 与实验”的定位
照搬早期 R1 提示词“民间秘方”
- 如强制 \n、一律不用 system prompt 等
- 忽略：
  - 托管思维模式有自己的 API 语义与参数行为
  - 不同 R1 版本的提示词建议已经更新

总结：2026 年搭建 DeepSeek 应用的合理默认路线

如果你在 2026 年用 DeepSeek 搭建产品，可以把默认策略简化为：

大多数产品：先用托管 API
本地 / 离线原型：优先 Ollama
只有在确实需要基础设施掌控权时，才上自建旗舰推理栈

更大的教训是：

DeepSeek 已经是一个持续演进的平台，而不是某个静态模型版本
想要获得好效果，需要：
- 分清当前 API 行为与旧 R1 时代建议
- 区分“量化本地便利”与“真正的基础设施需求”
- 在纠结 benchmark 之前，先选对部署架构

事实核查提示

价格、输出限制、限流策略都具有 强时效性：
- 上线前务必重新核对 DeepSeek 的价格、模型与 FAQ 页面
托管 API 当前：
- deepseek-chat 与 deepseek-reasoner 均映射到 DeepSeek-V3.2
- 与只围绕 V3 / R1 的老教程现实完全不同
自建部署时：
- 不要用 Ollama 量化体积估算原始 checkpoint 存储或完整运行时内存需求
- 这两者是完全不同的部署形态

参考资料

DeepSeek API 文档：快速开始、首次调用、模型与价格、Chat Completion、JSON 输出、函数调用、思维模式、上下文缓存、Anthropic API、错误码、FAQ
DeepSeek 发布日志：V3、R1、V3-0324、R1-0528、V3.1、V3.1-Terminus、V3.2-Exp、V3.2
DeepSeek GitHub 仓库：DeepSeek-V3 与 DeepSeek-V3.2-Exp 部署指南
DeepSeek Hugging Face 模型卡：DeepSeek-V3.1、DeepSeek-V3.2、DeepSeek-R1、DeepSeek-R1-0528-Qwen3-8B、各类 distill checkpoint
Ollama 文档与模型库：DeepSeek-R1 标签、/api/chat、鉴权行为
vLLM 文档：DeepSeek 支持与部署说明
SGLang 文档：DeepSeek 专项优化与部署指南
LMDeploy 文档：支持的 DeepSeek 模型与推理引擎
TensorRT-LLM 文档：DeepSeek 优化与部署实践
Hugging Face Transformers 文档：chat template 与消息格式化