先回答一个我最近被反复问到的问题“DeepSeek v1 这种老模型现在还有人用吗”说实话我不仅还在用而且每次给别人讲 DeepSeek 整个家族的技术路线都得从 v1 讲起。不是因为情怀而是因为后面那些出圈的模型——不管是 V2、V3 还是 R1——几乎所有关键设计都能在这一代模型上找到源头训练数据怎么清洗、模型怎么从小尺寸往上扩、长上下文怎么一点点解锁。这篇文章我能给你的不是论文复述而是一套我自己验证过的实操链路从官方 API 调用到本地部署再从 VSCode、Codex 这类开发工具接入到排查日常报错。适合两类人一类是刚接触 DeepSeek、想搞懂“入口”在哪的新手另一类是已经在用 V3/R1但想补课了解 v1 定位的老手。看完你会发现折腾“老模型”得到的经验放到新模型上一样能吃香。1. DeepSeek v1 到底是什么这一代模型的起点1.1 从 DeepSeek-LLM 说起如果严格翻族谱DeepSeek v1 对应的其实是 DeepSeek-LLM 这一代最初公开的有 7B 和 67B 两个尺寸发布时间在 2023 年底前后。这一代模型刚出来的时候关注度远没有后来 V3 发布时那么夸张但它做的事情很关键把一条从数据到训练再到评估的完整流水线跑通了。很多人以为大模型发布就是一锤子买卖实际上不是。v1 时代团队主要解决的是三件事。第一是数据质量中文语料和英文语料怎么配比、去重做到什么粒度、代码数据算多少比例这些决策直接影响下游模型的上限。第二是训练稳定性几十亿参数的模型还好说一旦往上百亿规模走学习率、batch size、loss spike 的处理都是经验活。第三是评估体系靠什么 benchmark 判断模型行不行决定了后续迭代往哪个方向使劲。我印象比较深的一点是v1 这代在代码能力上就表现出了一些不同寻常的苗头。当时很多同体量开源模型在代码评测上的分数接近但实际写代码的手感差异很大DeepSeek 系模型的代码风格更干净很少出现那种为了通过测试硬凑出来的答案。这也是后来 deepseek-coder 能单独成为一个产品线的原因之一。1.2 为什么今天还要折腾 v1你可能要问了现在 API 上跑的都是 V3、R1本地部署也有各种蒸馏版折腾 v1 图什么我总结下来有三个实际用途。第一个用途是做基线对比。如果你想评估一个新的微调方案或者测试一个新的推理框架拿一个参数规模小、行为稳定的 v1 模型做基线比直接上几百 B 的大模型省太多钱和时间。第二个用途是资源受限场景。很多内部工具、边缘设备、离线环境根本跑不动大模型7B 级别的 v1 量化之后普通消费级显卡甚至纯 CPU 都能跑这给了一批“先跑起来再说”的落地场景。第三个用途是学习。v1 的结构相对简单没有 V3 那种复杂的 MoE 路由和注意力优化方案拿它来理解 transformer 推理过程、调试显存占用比直接面对大模型容易得多。另外还有一个很现实的理由v1 时代发布的权重协议比较宽松很多社区微调模型都是以它为底座做的。你如果想研究“底座模型和微调模型到底差在哪”v1 是很好的样本。1.3 从 v1 到 V3/R1演进脉络值得单独拉一张表我经常被问“这几个版本到底啥关系”这里直接用一张表把关键差异列出来方便你后面看文章时能对上号。版本参数规模约核心设计适合场景v1 / DeepSeek-LLM7B、67B标准 decoder-only、长上下文探索本地部署、微调基线、学习用V2236BMoE高效注意力机制、DeepSeekMoE高性价比 API、大规模推理V3671BMoE无辅助损失负载均衡、FP8 训练综合能力强的在线 APIR1与 V3 同源强化学习推理链路数学、代码、逻辑推理提示这张表是简化版本具体参数量和技术细节以官方技术报告为准。我在这里强调的其实是“定位差异”——v1 解决的是从无到有后面的版本解决的是从有到优。顺便说一句社区里偶尔能看到“DeepSeek V5 已发布”之类的说法至少在我写这篇文章的时候官方公开的主力版本里并没有一个叫 v5 的东西。这类消息大多是把第三方微调模型或者自媒体标题当成了官方发布遇到这种信息一定要回官方渠道核对别被带节奏。2. 官方 API 怎么调OpenAI 兼容接口的细节2.1 拿 Key、配环境这些基本功先用最直白的话说结论DeepSeek 的 API 兼容 OpenAI 的接口格式也就是说凡是支持 OpenAI 接口的工具基本都能通过改 base_url 和 api_key 直接接上。官方文档入口在平台页面注册后在“API Keys”里创建 key。这里提醒一句key 创建之后只显示一次复制到本地环境变量里存好不要提交到 Git 仓库。环境变量建议这样配。Linux/macOS 在~/.bashrc或~/.zshrc里加一行export DEEPSEEK_API_KEYsk-xxxxxxxxWindows 用户在系统环境变量里加同名变量。配好之后在终端里执行echo $DEEPSEEK_API_KEYWindows 用echo %DEEPSEEK_API_KEY%确认没拼错。还有一个我踩过的坑有些工具读的是OPENAI_API_KEY而不是DEEPSEEK_API_KEY所以如果你同时装了多种开发工具最好在工具的配置里显式指定它该读哪个环境变量名别让默认值接管。2.2 第一个请求curl 和 Python 双版本这里先明确一件事虽然标题是 v1但官方 API 上并不会有一个叫 “deepseek-v1” 的模型 ID 可以选平台一般提供的是 deepseek-chat 这类通用对话模型。v1 的权重主要在开源渠道提供适合自部署你要快速体验直接调 API 上的当前模型即可。先看 curl 版本curl https://api.deepseek.com/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $DEEPSEEK_API_KEY \ -d { model: deepseek-chat, messages: [ {role: system, content: 你是一个简洁的助手}, {role: user, content: 用三句话解释什么是 transformer} ], temperature: 0.7, max_tokens: 2048, stream: false }Python 端我建议直接用官方 openai SDK不用自己拼 HTTPfrom openai import OpenAI client OpenAI( api_keysk-xxx, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个简洁的助手}, {role: user, content: 用三句话解释什么是 transformer}, ], temperature0.7, max_tokens2048, streamFalse, ) print(resp.choices[0].message.content)这里最容易被坑的是 base_url 写错。有人习惯写成https://api.deepseek.com/v1有人只写域名两种写法在大部分 SDK 里都能通但如果你用的工具固定拼/chat/completions那 base_url 必须以能拼出完整路径为准。最简单的判断方法完整请求 URL base_url “/chat/completions”拼出来是什么就是什么。2.3 参数调优和计费逻辑参数方面我平时最常用的是 temperature、top_p、max_tokens 和 stream 这四个。temperature 控制随机性0.7 左右适合通用对话代码生成我更喜欢 0.2 到 0.4高温度容易出现“创造力过剩”的幻觉。max_tokens 要留够尤其是需要长输出的场景默认值如果太小结果会被截断你看到的就是一段没说完的话。注意 max_tokens 计的是 token 不是汉字一个汉字大约等于 1 到 2 个 token。stream 改成 true 后接口会按 token 流式返回体验上更接近打字机效果也方便做实时展示。计费按 token 数算输入和输出单价通常不同。调用返回的 usage 字段里会明确告诉你 prompt_tokens 和 completion_tokens拿这个数去乘单价就能估算一次请求的成本。大批量任务上线前先拿一小批数据跑通并记录 token 消耗比事后看账单要稳得多。还有限流如果并发拉满可能会收到 429 错误这时候要做指数退避重试别一股脑猛刷。经常有人问我豆包、元宝、千问和 DeepSeek 到底哪个好。我的看法是这类问题本质上不是模型能力题而是场景题你要考虑数据是否出域、接口是否兼容现有链路、成本结构是什么样。与其反复横向比跑分不如拿自己的真实任务各跑一遍用同一份测试集看结果。跑分是别人的场景才是你的。3. 本地部署 DeepSeek v17B 模型也能流畅跑3.1 先算算硬件账本地部署第一件事不是敲命令而是算账——算显存账。以 7B 模型为例fp16 精度下权重就需要大约 14GB 显存加上 KV cache 和中间激活值整卡 16GB 的显卡勉强能跑但上下文稍微长一点就容易 OOM。如果换成 Q4_K_M 量化权重压到 4GB 到 5GB8GB 显存甚至纯 CPU 都能跑速度慢一点但能出结果。67B 模型就别想着消费级卡了fp16 需要 130GB 以上显存量化后也要 40GB 左右。一般个人玩家和中小团队老老实实用 7B 或更小的量化版本就行。模型规模精度/量化权重大小约最低配置建议体验7Bfp1614GB16GB 显存流畅7BQ4_K_M4.5GB8GB 显存流畅质量略降7BQ4_K_M4.5GB32GB 内存纯 CPU慢但可用67BQ4_K_M40GB多卡/大显存可跑配置门槛高3.2 llama.cpp 跑通全过程模型权重建议去模型托管平台搜 DeepSeek v1 对应模型仓库下载 GGUF 格式的量化文件不要直接下原始的 safetensors 再自己量化除非你想折腾。GGUF 文件下载好后用 llama.cpp 来跑。git clone https://github.com/ggerganov/llama.cpp cd llama.cpp make -j4 # 简单生成测试 ./main -m /path/to/deepseek-llm-7b.Q4_K_M.gguf \ -p 请写一个快速排序的 Python 实现 \ -n 256第一次跑建议加-n 128左右限制输出长度先把链路验证通。看到正常输出之后再调--temp和--ctx-size。ctx-size 决定上下文窗口大小默认 512 通常不够用代码生成和对话场景我一般给到 4096 或更高但显存会相应增加这里要自己权衡。除了 llama.cpp另一条更省心的路是用 Ollama。它把模型管理、下载、服务启动都封装好了适合不想跟编译细节纠缠的人。在 Ollama 里确认 DeepSeek v1 对应模型的标签后直接ollama run 模型名就能交互式对话ollama serve起服务之后也是 OpenAI 兼容的接口端口默认 11434。我的习惯是快速验证用 Ollama调底层参数和做性能测试用 llama.cpp。3.3 把本地模型变成 OpenAI 兼容服务单机跑 main 只适合验证真正要接 IDE 或写脚本调用得把 llama.cpp 的 llama-server 跑起来它默认提供一个 OpenAI 兼容的 HTTP 接口./llama-server \ -m /path/to/deepseek-llm-7b.Q4_K_M.gguf \ --host 127.0.0.1 \ --port 8080 \ --ctx-size 4096启动成功后访问 http://127.0.0.1:8080/v1/models 应该能看到模型列表。这时候你本地就有一个“假 OpenAI 服务”了任何支持自定义 base_url 的工具都能接上来只要把 base_url 指到 http://127.0.0.1:8080/v1api_key 随便填一个非空的字符串本地服务一般不做鉴权。这里有个很容易踩的坑不同工具对 base_url 的拼接逻辑不一样。有的工具会自动帮你加/v1有的不会写配置的时候多试两个写法看到 404 就换另一种。判断标准还是那句完整请求 URL 拼出来对得上就行。注意局域网内其他机器要访问把--host 127.0.0.1改成--host 0.0.0.0但要确认网络环境可信别把没有鉴权的服务裸奔到公网。4. 接入开发工作流VSCode、Codex、Claude Code4.1 VSCode 用 Continue 接 DeepSeek现在 VSCode 里接大模型主要两类方案一类是 Continue 这类开源插件另一类是 Cline 这类偏向自主编码的插件。两者都支持自定义 OpenAI 兼容 provider配置思路大同小异。以 Continue 为例在它的配置文件 config.json 里加一个 model 条目{ models: [ { title: DeepSeek Local 7B, provider: openai, model: deepseek-llm-7b, apiBase: http://127.0.0.1:8080/v1, apiKey: EMPTY } ] }如果接官方 API把 apiBase 换成https://api.deepseek.com/v1apiKey 换成你的真实 key。改完配置记得在插件面板里重新加载很多时候配置看着没问题但没生效就是没重载。实操里我的经验是本地 7B 模型适合做“补全助手”比如写注释、补小函数、解释报错让它写完整模块或者做复杂重构质量还是不如在线大模型。所以我会在 Continue 里同时配两个模型本地和官方 API 各一个按任务切换。这个“本地兜底 在线主力”的组合是我目前觉得性价比最高的开发接入方式。4.2 Codex CLI 指向 DeepSeek 的配置OpenAI 的 Codex CLI 是一个命令行编程代理很多人拿它来跑深度任务。它本身默认指向 OpenAI但可以通过 config.toml 自定义 provider指到 DeepSeek 的兼容接口。典型配置如下# ~/.codex/config.toml model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY配置完成后在项目目录执行 codex它会读取环境变量里的 DEEPSEEK_API_KEY 去请求 DeepSeek。这里我踩过的一个坑是Codex 内部有些调用走的是新版 Responses API 路径/v1/responses而 DeepSeek 兼容的是/chat/completions两者一旦不匹配就会出现 404 或者参数报错。遇到这类问题优先查是不是 provider 配错、是不是工具版本把请求打到了不存在的端点上。Claude Code 的接入思路类似它支持通过环境变量指定 Anthropic 兼容的 base_url把地址指到 DeepSeek 的兼容端点即可。不同版本的 CLI 对环境变量名要求略有差异启动前先看一眼官方 README别凭记忆配。4.3 用 ccswitch/网关做团队统一接入热词里频繁出现的 ccswitch其实是社区做的一个配置切换工具主要用于在 Claude Code、Codex 这类工具之间快速切换不同模型提供商。它解决的真实痛点是团队里有人用 A 模型、有人用 B 模型配置文件五花八门换模型还要翻半天文档。ccswitch 这类工具通常包含两部分一个是交互式命令行负责管理 provider 配置另一个是本地代理进程负责把 OpenAI/Anthropic 格式的请求转发到你配置的上游。配置 DeepSeek 时你要在它的 provider 列表里填上 base_url、api_key、model 名称保存后它会生成对应的客户端配置。如果你不想依赖第三方工具也可以自己写一个极简反代用 FastAPI 起一个本地服务接收/v1/chat/completions请求转发到 DeepSeek 上游再把响应原样返回。核心就十几行代码好处是团队统一走一个入口日志、限流、审计都能放在这一层。如果你想把模型接到企业微信这类办公协作工具里思路也是一样的——写一个中间服务把消息管道来的内容转成对 DeepSeek 的 API 请求拿到回复再转回去。企业微信本身只是消息管道真正干活的是模型服务。4.4 社区生态里的 harness 与 hermes别再把它们搞混这部分专门说说社区生态里两个常被混淆的名字DeepSeek Harness 和 DeepSeek Hermes。Harness 在这类语境里通常指“封装层/运行套件”作用是把模型跑起来、接好工具调用、暴露统一接口。你可以把它理解成一个蒸馏了各种配置细节的启动器不用手动记住 llama-server 那一堆参数也不用自己写转发脚本装好后填个模型路径就能把服务拉起来。社区里这类工具更新很快安装方式一般就是 clone 仓库加安装依赖具体看项目 README关键是你要搞清楚它帮你做了什么、还有哪些参数暴露给你控制。Hermes 则是社区微调模型系列的名字研究团队基于 DeepSeek 等开源底座做对齐微调在对话体验、工具调用、指令跟随上做了不少优化。如果你想在本地用一个“更会说人话”的 DeepSeek 系模型Hermes 这类微调版值得试试但要记住微调版本的能力边界和底座不完全一样涉及代码能力或专业知识的任务最好先拿自己的用例验证。选择建议很简单要省事跑服务用 harness 类工具要更好的对话对齐效果尝试 Hermes 系列微调模型。两者不冲突甚至可以组合着用。5. 实战踩坑502、404 和 reasoning_content5.1 502 Bad Gateway 排查实录502 Bad Gateway 应该是接入 DeepSeek 时最常见的报错了。它的本质是你请求的代理或网关已经把请求转发到上游但上游返回了错误响应于是网关把错误包装成 502 还给你。所以看到 502第一反应不应该是“DeepSeek 挂了”而是先定位是哪一层出了问题。常见的排查顺序是这样如果你用了本地代理比如 ccswitch 或自建反代先看代理进程的日志确认它有没有把请求真正发出去。直接用 curl 打上游接口看通不通。通了问题在代理层不通问题在上游或网络。看是不是超时。本地模型推理速度慢如果工具默认超时只有几十秒长上下文请求很容易超时触发 502这时候调大代理和客户端的 timeout 即可。看并发。上游限流或者本地显存不够导致推理排队也会表现为 502适当降低并发数。我之前遇到过一种很隐蔽的情况本地代理线程池被卡死请求全部排队超过 30 秒客户端直接报 502。查了半天才发现是代理进程的并发上限被默认值卡住了调大之后立刻恢复。这种问题日志里通常不会直接说有“死锁”只会表现成一堆超时所以排查时别只看错误文本要去翻代理进程自己的运行状态。5.2 404 invalid URL端点不匹配unexpected status 404 not found: invalid url (post /v1/responses)这类报错翻译过来就是客户端往/v1/responses这个路径发了 POST但服务端根本没有这个路由。原因一般是客户端默认走了 OpenAI 新的 Responses API而不是大多数兼容服务支持的 Chat Completions API。Responses API 是 OpenAI 后来推出的新接口形态老模型和第三方兼容服务基本都不支持它。解决办法有几个方向升级客户端到支持自定义 API 风格的版本或者在配置里明确指定使用 chat completions 模式如果是自建代理可以在代理层做路径转换把/v1/responses翻译成/v1/chat/completions最省事的是换一个兼容性更好的客户端。我的习惯是接到报错先从“路径对不对”查起别急着怀疑模型。5.3 thinking mode 的 reasoning_content 必须回传这个报错比较有代表性原文大概是“thereasoning_contentin the thinking mode must be passed back to the api”。它出现在使用带思考链thinking/reasoning模式的模型时。这类模型在正式回答之前会先生成一段 reasoning_content也就是思考过程。如果你把历史消息保存下来下次请求时把 assistant 的 message 原样传回去但这些 message 里没有带 reasoning_content 字段上游就会认为上下文不完整直接返回 400。解决方案也不复杂要么不要保存思考链只保留最终的 content 回复要么保存的时候把 reasoning_content 一并存下来再次请求时原样传回要么在配置层面关掉 thinking 模式用非思考模式做多轮对话。这个报错特别容易出现在“先调 API 测试、再接入 Agent 框架”的流程里因为单次请求通常没问题多轮对话缓存历史时才暴露。第一次遇到别慌去查你缓存历史的代码看 reasoning_content 有没有被丢掉。顺便说一句如果你在日志里看到http://127.0.0.1:15721/v1/responses这类本地地址基本都是本地代理进程监听的回环端口报错指向它说明请求已经进入代理层问题多半出在代理和上游之间的协议转换上顺着这个方向查会快很多。5.4 常见问题速查表报错/现象可能原因优先排查方向502 Bad Gateway代理转发失败、上游超时、限流代理日志、curl 直连、超时配置404 /v1/responses客户端走了新版 API 端点切换 chat completions、升级客户端400 reasoning_content思考链字段没回传历史消息保存逻辑、thinking 模式开关429 限流请求过密、并发过高指数退避重试、降低并发输出被截断max_tokens 不够增大 max_tokens本地无法加载模型显存/内存不足降量化等级、减小 ctx-size最后强调一句排查任何报错先分清楚“客户端、代理、上游服务”三层里的哪一层出了问题再动手改配置。这个思路比记住任何一条具体报错的解决办法都管用。文章写到这我想分享一个自己坚持了很久的习惯拿到一个新模型我一定先在本地用最小成本跑一遍再决定要不要把它接进正式流程。DeepSeek v1 这个“过气”模型恰恰是我用来做这件事的最佳样本——它足够轻、足够稳又和后续版本共享同一套技术基因。你完全可以用同样的方法把 v1 当作理解大模型落地的试验田先在这块田里把 API 调用、部署、接工具、排错这些基本功练扎实等真正需要跑大模型的时候你会发现大部分经验和坑都是通用的。对我来说模型会迭代但“先把链路跑通、再谈优化”这个原则始终不过时。