最近一次核对时间：2026 年 4 月 21 日。

你是不是也纠结过：到底要不要买显卡把 DeepSeek 拉到本地跑，还是老老实实用官方 API？很多团队一上来就装本地模型，结果发现钱花了、时间搭进去了，效果还不如直接调接口。选错路线，后面每一步都在还债。

如果你只记住一句话：DeepSeek 本地部署和 DeepSeek 官方 API，是两种完全不同的产品形态，不是「同一个模型换个壳」。

快速结论：什么时候用 API，什么时候用本地？

一句话推荐

官方 DeepSeek API 适合你追求：托管服务、省心集成、最新模型别名、OpenAI 风格接口、无需自己管 GPU 和推理服务。

本地运行 DeepSeek 更适合：必须离线、对数据边界极度敏感、想深度实验和调参、需要控制 checkpoint 和推理栈、或准备自建推理集群的团队。

有用户反馈，一个小团队用 API 做内部工具，3 天就能上线；而同样的功能如果从本地部署起步，光是驱动、CUDA、模型下载和监控，就能折腾一两周。这话听着有点扎心，但挺真实。

三种典型场景

  • 只想先试试 Prompt、感受效果：用浏览器聊天页面即可。
  • 正式做应用、需要稳定接口：优先选官方 DeepSeek API。
  • 做隐私敏感或离线实验：用小一点的本地模型起步。

我自己的习惯是：先用 API 把产品跑通、验证需求，再根据真实用量和隐私要求，决定要不要上本地或混合架构。

DeepSeek API：现在到底指的是什么？

官方 API 的含义

本文里说的 DeepSeek API，指的是 DeepSeek 官方提供的托管开发者接口，不是你电脑上的本地模型，也不是官网聊天网页或官方 App 的前端体验。

官方 API 使用 OpenAI 兼容格式，基础 URL 为：https://api.deepseek.com。DeepSeek 也说明 https://api.deepseek.com/v1 可用于 OpenAI 兼容，但路径里的 v1 只是 API 路径，不代表模型版本是 V1。

截至 2026 年 4 月 21 日，官方公开的主要模型别名是：

  • deepseek-chat：DeepSeek-V3.2 的非思维链（非 thinking）模式。
  • deepseek-reasoner：DeepSeek-V3.2 的思维链（thinking）模式。

两者都标注为 128K 上下文长度。官方模型与定价页面中：

  • deepseek-chat 默认输出预算约 4K，最大约 8K tokens；
  • deepseek-reasoner 默认约 32K，最大约 64K tokens。

官方模型和价格会变动，做生产决策前，一定重新核对 DeepSeek 自己的文档和价格页，不要只靠记忆或旧截图。

一个常见误解：本地标签 ≠ 官方别名

很多人会看到本地模型标签，比如 deepseek-r1:8b，就以为等同于官方 API 的 deepseek-reasoner。这是错误的。

  • deepseek-reasoner：官方托管 API 的模型别名。
  • deepseek-r1:8b：本地推理栈（如 Ollama）里的 checkpoint / 变体标签。

截至上面核对日期，Ollama 把 deepseek-r1 和 deepseek-r1:8b 描述为 DeepSeek-R1-0528-Qwen3-8B 的本地变体，其它标签则对应更小或更大的蒸馏 checkpoint。它们和官方 API 的行为、上下文、工具调用支持，都不必然一致。

本地运行 DeepSeek：到底在做什么？

本地部署的真实含义

本地运行 DeepSeek，指的是你在自己的电脑、工作站、服务器或私有云里，加载一个开源权重的 DeepSeek checkpoint，由本地或自建的推理服务来对外提供接口，而不是走 DeepSeek 官方托管 API。

常见的本地路径包括：

  • Ollama：对新手最友好的本地小模型方案，可一键拉取和运行，支持简单的命令行和 HTTP 接口。
  • LM Studio：提供桌面界面 + 本地 OpenAI 兼容服务器，适合想要 GUI 又想要 API 的开发者。
  • vLLM / SGLang：更偏向专业自建推理服务，支持 GPU 批量推理、OpenAI 兼容端点和复杂基础设施集成。

本地模型名称和官方 API 别名是两套体系。比如：

  • deepseek-r1
  • deepseek-r1:1.5b
  • deepseek-r1:7b
  • deepseek-r1:14b
  • deepseek-r1:32b
  • deepseek-r1:70b

这些都是本地 runtime 的标签或 checkpoint 变体，不是官方 API 的模型别名。每个 runtime（Ollama、LM Studio 等）对标签的映射可能更新，写文档或做内部规范前，务必先看当前的模型页面说明。

哪些模型适合作为本地起点？

对大多数人来说，R1-Distill 系列或 R1-0528-Qwen3-8B 这类模型，才是本地实验的现实起点。

  • DeepSeek-R1 / DeepSeek-V3 / DeepSeek-V3.2：参数量巨大，是「数据中心级」目标，不适合作为普通笔记本的入门模型。
  • 有公开信息显示，DeepSeek-R1 / R1-Zero 模型卡中写明：总参数约 671B，激活参数约 37B，上下文 128K。
  • R1-Distill 家族则包含 1.5B、7B、8B、14B、32B、70B 等更适合本地的变体，底座来自 Qwen 或 Llama 系列。

DeepSeek-V3.2 虽然在 Hugging Face 上以 MIT 许可证开源权重，但模型卡写明参数量约 685B，对显存和算力要求极高，不适合作为「我就想在家里电脑上玩玩」的目标。

成本对比：API Token vs 本地基础设施

官方 API 的计费方式

官方 DeepSeek API 采用按 token 计费。以 2026 年 4 月 21 日官方页面为例，每 100 万 tokens 价格大致为：

  • 输入 token，缓存命中：约 0.028 美元 / 1M tokens。
  • 输入 token，缓存未命中：约 0.28 美元 / 1M tokens。
  • 输出 token：约 0.42 美元 / 1M tokens。

API 默认开启上下文缓存（KV Cache）。如果你的请求前缀重复，比如固定的 system prompt、长文档前缀或会话前缀，重复部分可能按「缓存命中价」计费，从而降低输入成本。不过，只有重复的前缀部分才会命中缓存，不能指望所有请求都享受低价。

有团队用长 system prompt 做客服机器人，据他们的统计，开启缓存后输入成本大约下降了 30% 左右，但输出成本几乎没变，这个比例仅供参考，我也不太确定在所有场景都能复现。

本地部署真的「免费」吗？

**本地 DeepSeek 不等于零成本。**你只是把「按 token 付费」换成了「基础设施 + 人力」成本：

  • GPU 服务器采购，或云上 GPU 租赁费用。
  • 电费、散热、机房空间、硬盘存储和硬件折旧。
  • 工程师安装、调优、更新、监控所花的时间。
  • 安全审计、日志管理、访问控制和备份策略。
  • 如果对外提供服务，还要考虑扩容、故障转移和 SLA。

没有一个通用的「盈亏平衡点」。

  • 低到中等流量、产品早期验证、团队缺乏 GPU 运维经验：API 往往更划算。
  • 高并发、高隐私或必须离线、团队已有成熟基础设施：本地或自建推理才可能在长期成本上占优。

隐私与数据控制：本地一定更安全吗？

使用官方 API 时要看什么

隐私是很多人纠结「本地 vs API」的核心原因之一。调用官方 DeepSeek API 时，你的 Prompt 和输出会发送到 DeepSeek 的托管服务。

在把个人数据、敏感业务数据、受监管数据或客户数据接入 API 前，务必阅读：

  • 官方隐私政策（Privacy Policy）。
  • 开放平台服务条款（Open Platform Terms of Service）。

这些文档会说明数据是否用于训练、保留多久、存在哪个区域、是否支持数据删除等关键问题。

「本地 = 私有」是个危险误解

本地部署确实有机会把数据边界收紧，但前提是：整条链路都在你的可控范围内。

很多团队以为「模型在我机器上跑」就万事大吉，结果桌面应用自带遥测、插件把数据发到第三方、日志没加密，最后数据还是飞出了内网。

做隐私敏感场景时，至少要逐项确认：

  • Prompt、文件、输出是否被日志系统长期保存？
  • Runtime 是否开启了遥测或外部集成？
  • 插件 / 工具是否会把数据发给第三方服务？
  • 模型文件是否来自可信仓库，有无篡改风险？
  • 内部哪些人可以访问历史 Prompt 和输出？
  • 组织是否有数据保留、用户同意、地域合规等要求？

本文不构成法律意见。涉及金融、医疗、教育、政务等强监管场景，一定要让法务、安全、合规团队参与决策，无论你选 API 还是本地。

质量与模型行为：API vs 本地的差异

官方 API 的优势：行为更可预期

使用官方 API，你拿到的是 DeepSeek 当前托管版本的行为：

  • 模型别名稳定（如 deepseek-chat、deepseek-reasoner）。
  • 文档里写明支持的特性（JSON 输出、工具调用、思维模式等）。
  • 官方会维护兼容性和升级路径。

对需要长期维护的应用来说，这种「可预期」非常重要。

本地模型质量受哪些因素影响？

本地模型的体验差异巨大，取决于：

  • 你选的是哪一个 checkpoint（R1、R1-0528、Distill 变体等）。
  • 模型大小，以及是否做了蒸馏、量化、剪枝。
  • 使用的 runtime（Ollama、LM Studio、vLLM、SGLang 等）。
  • Prompt 模板、对话格式、系统提示的写法。
  • 上下文长度配置和内存限制。
  • 采样参数（temperature、top-p 等）。
  • Runtime 是否正确支持工具调用、结构化输出、思维链字段等。

有公开模型卡信息显示：

  • DeepSeek-R1 / R1-Zero：总参数约 671B，激活参数约 37B，上下文 128K。
  • R1-Distill：包含 1.5B、7B、8B、14B、32B、70B 等多个变体，底座来自 Qwen / Llama，更适合本地部署。
  • DeepSeek-V3.2：模型卡写明约 685B 参数，且 V3.2-Speciale 变体专注深度推理，不支持工具调用。

如果你的应用严重依赖工具调用，就不能简单假设「所有 V3.2 变体行为都一样」。

性能与延迟：别只看宣传 Benchmark

API 延迟：网络 + 负载 + Prompt 长度

API 的响应时间取决于：

  • 提供方的基础设施和当前流量。
  • 你和数据中心之间的网络距离。
  • Prompt 长度和输出长度。
  • 推理调度和排队策略。

DeepSeek 的速率限制文档提到：

  • 官方不会用固定 QPS 限制用户，但高峰期请求可能排队，HTTP 连接保持打开；
  • 如果 10 分钟内推理尚未开始，服务器可能关闭连接。

实践中，仍然可能收到 429 Rate Limit Reached 错误码，所以生产客户端必须实现：超时、重试、指数退避、请求节流和降级策略。

本地延迟：硬件和调度说了算

本地延迟主要看你的硬件和 runtime：

  • 小一点、量化过的模型，在高性能本地 GPU 上会非常快；
  • 大模型 + 长上下文，很容易因为显存不足或内存抖动而变慢甚至失败；
  • 自建服务器还要考虑并发、批处理、冷启动、GPU 利用率等问题。

不要迷信「某某模型每秒几千 token」的宣传，真正有用的是你自己场景下的指标：

  • TTFT（Time To First Token）：首 token 时间，直接影响体感。
  • Tokens/s：在真实 Prompt 下的生成速度。
  • p95 延迟：在高并发下 95% 请求的响应时间。
  • 错误率：超时、OOM、服务器错误、格式错误的比例。
  • 单次请求成本：API token 成本或摊到每次调用的基础设施成本。

很多团队的经验是：

  • 早期用 API 更容易「先跑起来」，再慢慢优化；
  • 有基础设施经验的团队，才有余力把本地推理调到一个稳定、可扩展的状态。

运维与可靠性：你到底想把坑挖在谁那边？

用 API：把一部分坑交给官方

官方 DeepSeek API 帮你省掉大部分基础设施工作，但你仍然依赖：

  • 服务可用性和状态；
  • 账号余额和计费系统；
  • 网络连通性；
  • 提供方的限流和错误处理策略。

官方错误码文档中列出了常见问题：

  • 请求格式错误；
  • 鉴权失败或余额不足；
  • 参数非法；
  • 速率限制；
  • 服务器错误或过载等。

本地部署：坑在你自己这边

本地部署虽然不依赖托管 API，但会新增一整套运维风险：

  • 机器或 GPU 故障。
  • 模型加载失败或版本不兼容。
  • 内存 / 显存不足导致上下文失败。
  • 驱动、CUDA、ROCm、Runtime 版本冲突。
  • 存储损坏、模型文件损坏或下载中断。
  • 安全补丁、依赖升级、系统加固。
  • 备份、监控、告警、访问控制策略。

如果你的应用面向真实用户，无论选 API 还是本地，都需要一套可靠性方案：

  • API 路线：监控错误率、余额、延迟、官方状态页。
  • 本地路线：监控硬件健康、服务进程、日志、队列长度和容量。

功能差异：工具调用、JSON、思维模式与本地服务器

官方 API 的功能集

官方 DeepSeek API 文档中提到的能力包括：

  • JSON 输出模式；
  • 工具调用（Tool Calls）；
  • Chat Prefix Completion；
  • 支持的 FIM 模式；
  • 思维模式（Thinking Mode）。

在思维模式下，官方示例会返回 reasoning_content 字段，配合最终的 content 一起使用，方便你在后端区分「内部推理」和「对用户可见的回答」。

本地 OpenAI 兼容 ≠ 完全 DeepSeek 兼容

不少本地 runtime 会提供 OpenAI 兼容端点，例如：

  • LM Studio：本地服务器地址类似 http://localhost:1234/v1。
  • vLLM：提供 OpenAI 兼容 HTTP Server。
  • SGLang：同样支持 OpenAI 风格接口。

但「OpenAI 兼容」只说明请求格式长得像，不代表：

  • JSON 输出一定稳定；
  • 工具调用 schema 一定完全一致；
  • 思维字段命名和结构一定相同；
  • Chat 模板和系统 Prompt 行为一致；
  • 不支持的参数会被优雅忽略；
  • 流式输出行为和错误边界完全一样。

有些本地思维模型会直接在输出里展示 ... 这样的可见推理痕迹，这和官方 API 里结构化的 reasoning_content 并不是一回事。对用户暴露内部推理内容前，要先过一遍产品策略和安全评估。

什么时候本地 DeepSeek 可能是错误选择？

这些情况，优先别上本地

  • 你想最快上线产品，但团队几乎没有 GPU / 服务器经验。
  • 你需要官方文档里写明的 JSON 输出、工具调用、FIM、前缀补全、思维模式等特性，而且要行为稳定。
  • 你没法长期维护驱动、Runtime、安全补丁、监控、存储和日志。
  • 你只是觉得「本地应该更便宜、更安全」，但没算过总成本，也没做过隐私梳理。
  • 你需要和官方 DeepSeek API 几乎完全一致的行为。
  • 你没有访问控制、网络暴露、Prompt 日志和滥用防护的方案。
  • 你打算在普通消费级笔记本上跑完整的 DeepSeek-V3.2 或 DeepSeek-R1。

有团队在笔记本上硬拉大模型，结果风扇狂转、显卡过热、系统频繁崩溃，最后还是回到云端 API，这种「绕一圈又回到起点」的代价不小。

安全自查清单：选本地还是 API 前先问自己

在决定用 DeepSeek 本地还是 API 前，可以先过一遍这份问题清单：

  • 你会把哪些数据发给模型？是否包含敏感信息？
  • 是否有「必须离线」的硬性要求？
  • 谁可以访问 Prompt、输出、日志和上传的文件？
  • 应用、Runtime、代理或分析工具是否会长期存储这些数据？
  • 本地模型文件是否来自可信源，是否校验过完整性？
  • 本地 Runtime 是否完全本地，还是内置了外部服务？
  • API Key 是否安全存放在环境变量或机密管理系统中？
  • 是否有监控错误、延迟、用量和异常流量的机制？
  • 如果 API 或本地服务器挂了，有没有备用方案？
  • 是否审阅过模型许可证、服务条款和隐私政策？

一个更现实的答案：混合策略

为什么很多团队最后都走向「混合架构」？

对不少团队来说，最合适的不是「只用 API」或「只用本地」，而是混合工作流：

  • 用官方 DeepSeek API 做首发和对外生产流量，享受托管的稳定性和最新特性。
  • 用本地 R1-Distill 或 R1-0528 变体做离线草稿、内部测试或高敏感数据实验。
  • 用更小的本地模型做预处理（分类、路由、摘要），把真正难的任务再转给 API。
  • 一边用 API 跑真实流量，一边记录用量和成本，再评估是否值得自建推理。

有用户分享，他们用小模型在本地做「请求分流」，只有约 20% 的复杂请求才打到官方 API，整体成本下降明显，同时还能保留官方模型的质量和特性。

混合架构的关键：路由规则要写清楚

混合系统的风险在于「一团乱」。要提前说清楚：

  • 哪类数据可以发给 API，哪类必须留在本地？
  • 哪些任务由本地模型处理，哪些必须走官方 API？
  • API 或本地服务失败时，是否允许自动切换？切到哪里？
  • 日志和监控分别放在哪，谁有权限看？

如果这些规则不写清楚，混合架构很容易变成「谁方便就用谁」，既不安全，也难以维护。

行动建议：现在就选一条 DeepSeek 路线

如果你只想先体验 Prompt 效果，又不想折腾 GPU、本地 Runtime 或 API 配置，可以直接用浏览器聊天体验，感受一下 DeepSeek 风格的回答，再决定要不要往下走。

准备做应用或开发工作流时，可以：

  • 先用官方 DeepSeek API 打通最小可用产品；
  • 再根据隐私、成本和性能需求，评估是否引入本地模型或混合架构；
  • 对于高敏感数据，优先在本地小模型上做实验，逐步放大范围。

这个判断方法在不少团队身上反复被验证有效，值得你收藏下来，等真正要做选型时再翻出来对照一遍。如果你正卡在「买显卡还是买 API」的十字路口，这篇内容往往比问十个朋友更有用。

常见问题

Q：DeepSeek 本地模型的标签（比如 deepseek-r1:8b）和官方 API 模型是一回事吗？

A：不是一回事。本地标签通常是某个 runtime（如 Ollama、LM Studio）内部使用的 checkpoint 名称或变体标记，而官方 API 使用的是 deepseek-chat、deepseek-reasoner 等托管别名。两者在参数规模、训练数据、上下文长度、工具调用支持等方面都可能不同。选型时要分别查「runtime 模型页面」和「官方 API 文档」，不要用本地标签去推断 API 行为，也不要反过来假设 API 就等于某个本地 checkpoint。

Q：什么时候用 DeepSeek 官方 API 更划算，什么时候值得上本地部署？

A：低到中等调用量、产品早期验证、团队缺乏 GPU 运维经验时，用官方 API 通常更划算，因为你省掉了硬件采购、驱动调试和监控告警等隐性成本。只有当调用量非常大、对隐私或离线有强需求，且团队已经有成熟的 GPU 基础设施和运维能力时，本地或自建推理才可能在长期成本上占优。建议先用 API 跑一段时间，记录真实 token 用量和峰值并发，再用这些数据反推本地部署的硬件和人力成本。

Q：本地部署 DeepSeek 就一定更安全、更私有吗？

A：不一定。模型在本地并不代表数据不会外流，桌面应用的遥测、插件调用第三方服务、未加密的日志和监控系统，都可能把敏感信息带出你的环境。真正的隐私保护要看整条链路：从前端到 Runtime、从日志到备份，每一环是否可控、是否加密、是否有访问审计。做隐私敏感项目时，要拉上安全和合规团队一起梳理数据流，而不是只盯着「模型是不是在我机器上」。

Q：DeepSeek 的思维模式（reasoning mode）在本地也能完全复现吗？

A：很难做到「完全一致」。官方 API 的思维模式会通过 reasoning_content 等字段结构化返回推理过程，而本地模型往往只是输出带 ... 的文本片段，具体格式和内容由模型和 runtime 决定。不同 runtime 对思维字段、JSON 输出、工具调用的支持程度也不一样。要在本地复现类似体验，需要自己设计解析逻辑、过滤策略和 UI 展示方式，并接受与官方 API 行为存在差异的现实。

Q：如果我现在什么都不懂，只想做一个稳定的 AI 小工具，该怎么选？

A：直接从官方 DeepSeek API 开始会更稳。你只需要学会调用一个 OpenAI 风格的 HTTP 接口，就能快速做出原型和内部工具，不必先啃驱动、CUDA、模型下载和监控告警。等工具真正跑起来、团队对需求和用量有了清晰认知，再考虑是否引入本地模型做补充。这样既能控制风险，又能保留未来升级到混合架构的空间。