尧图网页设计 
1. 为什么要在本地跑 DeepSeek-R1 再接入统一 API很多人第一次接触 DeepSeek 是从网页版开始的输入问题、等回复体验确实顺滑。但只要你开始写代码、做 Agent、跑批量任务就会遇到一个绕不开的问题本地模型和云端模型的调用方式完全不一样。本地 Ollama 用的是http://localhost:11434这套接口云端各家又有各自的 Base URL、鉴权头和参数命名。项目里同时用两三个模型代码里就全是 if-else维护起来很痛苦。这篇要解决的就是这个场景你已经在个人电脑上用 Ollama 把 DeepSeek-R1 跑起来了现在想让它和云端模型共用一套 Key、一套调用方式切换模型只改一个 Model ID。TaoToken 在这里扮演的角色就是统一通道——它提供 OpenAI 兼容的 API 格式本地服务通过一层适配就能和云端模型走同一套请求结构。先说清楚适合谁看。如果你是完全没碰过命令行的新手这篇也能跟因为 Ollama 的安装和拉取模型基本是一条命令的事。如果你是有经验的开发者重点看第 3 节的配置片段和第 4 节的验证脚本那部分是可以直接复制进项目的。硬件方面DeepSeek-R1 的 1.5B 版本 6GB 显存就能跑7B 版本建议 12GB 以上32B 版本需要 24GB 显存。没有独显也能用 CPU 跑 1.5B只是速度慢一些验证流程完全没问题。我试过在一台只有核显的轻薄本上跑 1.5B首 token 大概等 3 到 5 秒日常问答够用。所以不要被“本地部署”四个字吓到门槛比想象中低。真正需要花心思的是后面接入统一通道那一步因为涉及 Base URL、API Key、Model ID 三个东西的对应关系配错一个就报错。下面按顺序拆开讲。2. Ollama 安装与 DeepSeek-R1 拉取实操2.1 安装 Ollama 并确认服务在跑Windows 用户直接去 Ollama 官网下载OllamaSetup.exe安装时可以指定路径避免占满 C 盘OllamaSetup.exe /DIRE:\ollamaLinux 和 macOS 用一条命令搞定curl -fsSL https://ollama.com/install.sh | sh安装完成后Ollama 会默认在后台起一个服务监听11434端口。验证方法很简单浏览器打开http://localhost:11434/看到Ollama is running就说明服务正常。命令行也可以用 curl 确认curl http://localhost:11434/返回Ollama is running即可。如果这一步失败先检查 Ollama 进程有没有起来Windows 在任务管理器里找ollama.exeLinux 用systemctl status ollama。2.2 拉取 DeepSeek-R1 并跑通对话Ollama 的模型库里有 DeepSeek-R1 的多个尺寸按显存选# 1.5B 版本约 3GB 显存适合入门验证 ollama run deepseek-r1:1.5b # 7B 版本建议 12GB 以上显存 ollama run deepseek-r1:7b # 32B 版本需要 24GB 显存 ollama run deepseek-r1:32b第一次执行会自动下载模型文件1.5B 大约 1GB 出头7B 约 4.7GB32B 约 20GB。下载完成后直接进入对话界面输入“你好”能正常回复就说明本地推理通了。退出对话用/bye。这里有个细节值得注意Ollama 默认只监听127.0.0.1也就是本机访问。如果你后面要用 Docker 里的 Open WebUI 或者别的容器去连它需要设置环境变量让它监听所有网卡# Linux/macOS export OLLAMA_HOST0.0.0.0:11434 ollama serve # Windows PowerShell $env:OLLAMA_HOST0.0.0.0:11434 ollama serve这一步不是必须的但如果你打算用容器化工具做可视化界面提前设好能省掉后面排查连接问题的麻烦。2.3 用 API 方式调用本地模型Ollama 除了命令行对话还暴露了 HTTP API。最常用的是/api/generate和/api/chat两个端点。先用 generate 验证一下curl http://localhost:11434/api/generate -d { model: deepseek-r1:1.5b, prompt: 用一句话解释什么是大模型, stream: false }返回的 JSON 里response字段就是模型输出。注意这里stream设成false方便一次性看到完整结果。如果设成true会一行一行流式返回适合做打字机效果。到这一步本地 DeepSeek-R1 已经能通过 API 调用了。但它用的是 Ollama 自己的接口格式和 OpenAI 那套/v1/chat/completions不一样。接下来要做的就是让本地模型和云端模型走同一套调用方式。3. 接入 TaoToken 统一 API 的配置片段3.1 先拿 Key 和确认 Base URLTaoToken 的 API 入口是https://taotoken.net/api这个地址不加任何查询参数。API Key 在控制台的 API Keys 页面创建创建后复制保存页面关掉就看不到了。拿到 Key 之后你需要记住三个东西的对应关系这是后面所有配置的基础配置项值说明Base URLhttps://taotoken.net/api所有请求的前缀API Keysk-开头的一串放在 Authorization 头里Model ID如deepseek-r1决定实际调用哪个模型如果你用的是 Claude Code 这类工具Base URL 要写成https://taotoken.net/apiKey 填在对应的环境变量里Model ID 按工具要求填。Cline、CC Switch 这些工具也是同样的三件套逻辑缺一个就连不上。3.2 用 settings.json 配置本地代理层最直接的做法是在本地起一个轻量代理把 OpenAI 格式的请求转发到 Ollama。但更省事的方案是用 TaoToken 的统一通道让本地模型和云端模型都通过同一个 Base URL 访问。下面是一个settings.json配置片段路径放在项目根目录的.config下{ api_base: https://taotoken.net/api, api_key: sk-你的Key, default_model: deepseek-r1, local_fallback: { enabled: true, base_url: http://localhost:11434/v1, model: deepseek-r1:1.5b } }这个配置的意思是默认走 TaoToken 统一通道当统一通道不可用时回退到本地 Ollama 的 OpenAI 兼容接口。Ollama 从 0.1.24 版本开始提供了/v1兼容层所以http://localhost:11434/v1是可以直接当 OpenAI 接口用的。如果你用的是 TOML 格式的配置文件等价写法是[api] base_url https://taotoken.net/api api_key sk-你的Key default_model deepseek-r1 [local_fallback] enabled true base_url http://localhost:11434/v1 model deepseek-r1:1.5b注意local_fallback里的base_url结尾是/v1而 TaoToken 的base_url结尾是/api这两个不要写混。写混的典型报错是 404因为路径拼出来不对。3.3 环境变量方式适合容器和 CI如果你不想把 Key 写进配置文件用环境变量更安全export TAOTOKEN_BASE_URLhttps://taotoken.net/api export TAOTOKEN_API_KEYsk-你的Key export TAOTOKEN_MODELdeepseek-r1 export OLLAMA_BASE_URLhttp://localhost:11434/v1在代码里读取这些变量本地和云端就能共用一套初始化逻辑。Python 示例import os from openai import OpenAI client OpenAI( base_urlos.getenv(TAOTOKEN_BASE_URL), api_keyos.getenv(TAOTOKEN_API_KEY), ) response client.chat.completions.create( modelos.getenv(TAOTOKEN_MODEL), messages[{role: user, content: 你好}], ) print(response.choices[0].message.content)这段代码把base_url换成http://localhost:11434/v1、model换成deepseek-r1:1.5b就能直接调本地模型其他代码一行不用改。这就是统一通道的价值。4. 验证请求本地与统一通道都能返回结果4.1 验证本地 Ollama 的 OpenAI 兼容接口先确认本地/v1层是通的curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1:1.5b, messages: [{role: user, content: 说一句话证明你在运行}] }返回结构里应该有choices[0].message.content。如果返回model not found说明模型名写错了用ollama list看一下实际拉下来的模型名。4.2 验证 TaoToken 统一通道再用同样的请求结构打 TaoTokencurl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: deepseek-r1, messages: [{role: user, content: 说一句话证明你在运行}] }两个请求的 body 结构完全一样只有 URL 和 model 不同。如果两边都能返回choices字段说明统一调用方式已经打通。4.3 写一个切换脚本把上面的验证固化成脚本方便以后排查#!/bin/bash # check_model.sh MODE$1 if [ $MODE local ]; then URLhttp://localhost:11434/v1/chat/completions MODELdeepseek-r1:1.5b AUTH else URLhttps://taotoken.net/api/v1/chat/completions MODELdeepseek-r1 AUTHAuthorization: Bearer sk-你的Key fi curl -s $URL \ -H Content-Type: application/json \ ${AUTH:-H $AUTH} \ -d {\model\:\$MODEL\,\messages\:[{\role\:\user\,\content\:\ping\}]} \ | head -c 500执行bash check_model.sh local和bash check_model.sh cloud对比两边返回。这个脚本在排查“到底是本地问题还是通道问题”时特别有用。5. 常见报错排查对照5.1 401 Unauthorized这个最常见原因就三个Key 没填、Key 填错、Key 前面少了Bearer。检查请求头-H Authorization: Bearer sk-你的Key注意Bearer和 Key 之间有一个空格Key 本身不要带引号。如果用的是配置文件确认 Key 字段没有被 YAML 或 JSON 的转义规则吃掉字符。5.2 local proxy failed / connection refused这个报错说明请求根本没到 Ollama。先确认服务在跑curl http://localhost:11434/如果这条都失败说明 Ollama 没启动。如果这条成功但/v1路径失败检查 Ollama 版本低于 0.1.24 的版本没有/v1兼容层升级即可。5.3 reading choices 报错这个通常出现在流式响应解析时。如果你用stream: true返回的是一行行 SSE 数据每行以data:开头。解析时要把data:前缀去掉再 JSON.parse。非流式模式下如果还报这个错检查返回体是不是被中间层改写过比如某些代理会包一层{code, data}这时候choices就不在顶层了。5.4 OAuth 相关报错如果你用的是 Claude Code 或类似工具报 OAuth 错误通常是因为工具在尝试走它自己的登录流程而不是用你配的 API Key。这时候要确认工具是否支持自定义 Base URL以及是否把鉴权方式切到了 API Key 模式。CC Switch 这类工具需要在设置里明确选“API Key”而不是“OAuth”。5.5 模型名不匹配本地报model not found用ollama list看实际名字。云端报模型不存在去 TaoToken 的文档页确认可用的 Model ID。注意本地模型名带:1.5b这种 tag云端通常不带 tag。6. 长期编码场景的接入建议如果你只是偶尔跑一下本地模型做验证上面的配置够用了。但如果你打算把 DeepSeek-R1 接进日常编码流程比如做代码补全、Agent 任务、批量文档处理建议把统一通道的调用封装成一个客户端类本地和云端通过配置切换而不是每次改代码。TaoToken 的 Coding Plan 适合这种长期编码场景它把常用模型的调用额度打包省去每次单独充值的麻烦。接入文档里有各语言 SDK 的示例API Keys 页面管理你的 Key。模型对话页面可以快速验证某个 Model ID 是否可用不用写代码就能测。最后给一个实用技巧在项目里建一个models.yaml把本地和云端的模型配置都列进去代码启动时根据环境变量选择加载哪一组。这样换机器、换环境、切换本地和云端都只改一个环境变量不动业务代码。这个模式在团队协作里尤其省事新人拉下代码配好 Key 就能跑。 DeepSeek从入门到本地部署全攻略：Ollama一键跑通DeepSeek-R1并接入TaoToken统一API
1. 为什么要在本地跑 DeepSeek-R1 再接入统一 API很多人第一次接触 DeepSeek 是从网页版开始的输入问题、等回复体验确实顺滑。但只要你开始写代码、做 Agent、跑批量任务就会遇到一个绕不开的问题本地模型和云端模型的调用方式完全不一样。本地 Ollama 用的是http://localhost:11434这套接口云端各家又有各自的 Base URL、鉴权头和参数命名。项目里同时用两三个模型代码里就全是 if-else维护起来很痛苦。这篇要解决的就是这个场景你已经在个人电脑上用 Ollama 把 DeepSeek-R1 跑起来了现在想让它和云端模型共用一套 Key、一套调用方式切换模型只改一个 Model ID。TaoToken 在这里扮演的角色就是统一通道——它提供 OpenAI 兼容的 API 格式本地服务通过一层适配就能和云端模型走同一套请求结构。先说清楚适合谁看。如果你是完全没碰过命令行的新手这篇也能跟因为 Ollama 的安装和拉取模型基本是一条命令的事。如果你是有经验的开发者重点看第 3 节的配置片段和第 4 节的验证脚本那部分是可以直接复制进项目的。硬件方面DeepSeek-R1 的 1.5B 版本 6GB 显存就能跑7B 版本建议 12GB 以上32B 版本需要 24GB 显存。没有独显也能用 CPU 跑 1.5B只是速度慢一些验证流程完全没问题。我试过在一台只有核显的轻薄本上跑 1.5B首 token 大概等 3 到 5 秒日常问答够用。所以不要被“本地部署”四个字吓到门槛比想象中低。真正需要花心思的是后面接入统一通道那一步因为涉及 Base URL、API Key、Model ID 三个东西的对应关系配错一个就报错。下面按顺序拆开讲。2. Ollama 安装与 DeepSeek-R1 拉取实操2.1 安装 Ollama 并确认服务在跑Windows 用户直接去 Ollama 官网下载OllamaSetup.exe安装时可以指定路径避免占满 C 盘OllamaSetup.exe /DIRE:\ollamaLinux 和 macOS 用一条命令搞定curl -fsSL https://ollama.com/install.sh | sh安装完成后Ollama 会默认在后台起一个服务监听11434端口。验证方法很简单浏览器打开http://localhost:11434/看到Ollama is running就说明服务正常。命令行也可以用 curl 确认curl http://localhost:11434/返回Ollama is running即可。如果这一步失败先检查 Ollama 进程有没有起来Windows 在任务管理器里找ollama.exeLinux 用systemctl status ollama。2.2 拉取 DeepSeek-R1 并跑通对话Ollama 的模型库里有 DeepSeek-R1 的多个尺寸按显存选# 1.5B 版本约 3GB 显存适合入门验证 ollama run deepseek-r1:1.5b # 7B 版本建议 12GB 以上显存 ollama run deepseek-r1:7b # 32B 版本需要 24GB 显存 ollama run deepseek-r1:32b第一次执行会自动下载模型文件1.5B 大约 1GB 出头7B 约 4.7GB32B 约 20GB。下载完成后直接进入对话界面输入“你好”能正常回复就说明本地推理通了。退出对话用/bye。这里有个细节值得注意Ollama 默认只监听127.0.0.1也就是本机访问。如果你后面要用 Docker 里的 Open WebUI 或者别的容器去连它需要设置环境变量让它监听所有网卡# Linux/macOS export OLLAMA_HOST0.0.0.0:11434 ollama serve # Windows PowerShell $env:OLLAMA_HOST0.0.0.0:11434 ollama serve这一步不是必须的但如果你打算用容器化工具做可视化界面提前设好能省掉后面排查连接问题的麻烦。2.3 用 API 方式调用本地模型Ollama 除了命令行对话还暴露了 HTTP API。最常用的是/api/generate和/api/chat两个端点。先用 generate 验证一下curl http://localhost:11434/api/generate -d { model: deepseek-r1:1.5b, prompt: 用一句话解释什么是大模型, stream: false }返回的 JSON 里response字段就是模型输出。注意这里stream设成false方便一次性看到完整结果。如果设成true会一行一行流式返回适合做打字机效果。到这一步本地 DeepSeek-R1 已经能通过 API 调用了。但它用的是 Ollama 自己的接口格式和 OpenAI 那套/v1/chat/completions不一样。接下来要做的就是让本地模型和云端模型走同一套调用方式。3. 接入 TaoToken 统一 API 的配置片段3.1 先拿 Key 和确认 Base URLTaoToken 的 API 入口是https://taotoken.net/api这个地址不加任何查询参数。API Key 在控制台的 API Keys 页面创建创建后复制保存页面关掉就看不到了。拿到 Key 之后你需要记住三个东西的对应关系这是后面所有配置的基础配置项值说明Base URLhttps://taotoken.net/api所有请求的前缀API Keysk-开头的一串放在 Authorization 头里Model ID如deepseek-r1决定实际调用哪个模型如果你用的是 Claude Code 这类工具Base URL 要写成https://taotoken.net/apiKey 填在对应的环境变量里Model ID 按工具要求填。Cline、CC Switch 这些工具也是同样的三件套逻辑缺一个就连不上。3.2 用 settings.json 配置本地代理层最直接的做法是在本地起一个轻量代理把 OpenAI 格式的请求转发到 Ollama。但更省事的方案是用 TaoToken 的统一通道让本地模型和云端模型都通过同一个 Base URL 访问。下面是一个settings.json配置片段路径放在项目根目录的.config下{ api_base: https://taotoken.net/api, api_key: sk-你的Key, default_model: deepseek-r1, local_fallback: { enabled: true, base_url: http://localhost:11434/v1, model: deepseek-r1:1.5b } }这个配置的意思是默认走 TaoToken 统一通道当统一通道不可用时回退到本地 Ollama 的 OpenAI 兼容接口。Ollama 从 0.1.24 版本开始提供了/v1兼容层所以http://localhost:11434/v1是可以直接当 OpenAI 接口用的。如果你用的是 TOML 格式的配置文件等价写法是[api] base_url https://taotoken.net/api api_key sk-你的Key default_model deepseek-r1 [local_fallback] enabled true base_url http://localhost:11434/v1 model deepseek-r1:1.5b注意local_fallback里的base_url结尾是/v1而 TaoToken 的base_url结尾是/api这两个不要写混。写混的典型报错是 404因为路径拼出来不对。3.3 环境变量方式适合容器和 CI如果你不想把 Key 写进配置文件用环境变量更安全export TAOTOKEN_BASE_URLhttps://taotoken.net/api export TAOTOKEN_API_KEYsk-你的Key export TAOTOKEN_MODELdeepseek-r1 export OLLAMA_BASE_URLhttp://localhost:11434/v1在代码里读取这些变量本地和云端就能共用一套初始化逻辑。Python 示例import os from openai import OpenAI client OpenAI( base_urlos.getenv(TAOTOKEN_BASE_URL), api_keyos.getenv(TAOTOKEN_API_KEY), ) response client.chat.completions.create( modelos.getenv(TAOTOKEN_MODEL), messages[{role: user, content: 你好}], ) print(response.choices[0].message.content)这段代码把base_url换成http://localhost:11434/v1、model换成deepseek-r1:1.5b就能直接调本地模型其他代码一行不用改。这就是统一通道的价值。4. 验证请求本地与统一通道都能返回结果4.1 验证本地 Ollama 的 OpenAI 兼容接口先确认本地/v1层是通的curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1:1.5b, messages: [{role: user, content: 说一句话证明你在运行}] }返回结构里应该有choices[0].message.content。如果返回model not found说明模型名写错了用ollama list看一下实际拉下来的模型名。4.2 验证 TaoToken 统一通道再用同样的请求结构打 TaoTokencurl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: deepseek-r1, messages: [{role: user, content: 说一句话证明你在运行}] }两个请求的 body 结构完全一样只有 URL 和 model 不同。如果两边都能返回choices字段说明统一调用方式已经打通。4.3 写一个切换脚本把上面的验证固化成脚本方便以后排查#!/bin/bash # check_model.sh MODE$1 if [ $MODE local ]; then URLhttp://localhost:11434/v1/chat/completions MODELdeepseek-r1:1.5b AUTH else URLhttps://taotoken.net/api/v1/chat/completions MODELdeepseek-r1 AUTHAuthorization: Bearer sk-你的Key fi curl -s $URL \ -H Content-Type: application/json \ ${AUTH:-H $AUTH} \ -d {\model\:\$MODEL\,\messages\:[{\role\:\user\,\content\:\ping\}]} \ | head -c 500执行bash check_model.sh local和bash check_model.sh cloud对比两边返回。这个脚本在排查“到底是本地问题还是通道问题”时特别有用。5. 常见报错排查对照5.1 401 Unauthorized这个最常见原因就三个Key 没填、Key 填错、Key 前面少了Bearer。检查请求头-H Authorization: Bearer sk-你的Key注意Bearer和 Key 之间有一个空格Key 本身不要带引号。如果用的是配置文件确认 Key 字段没有被 YAML 或 JSON 的转义规则吃掉字符。5.2 local proxy failed / connection refused这个报错说明请求根本没到 Ollama。先确认服务在跑curl http://localhost:11434/如果这条都失败说明 Ollama 没启动。如果这条成功但/v1路径失败检查 Ollama 版本低于 0.1.24 的版本没有/v1兼容层升级即可。5.3 reading choices 报错这个通常出现在流式响应解析时。如果你用stream: true返回的是一行行 SSE 数据每行以data:开头。解析时要把data:前缀去掉再 JSON.parse。非流式模式下如果还报这个错检查返回体是不是被中间层改写过比如某些代理会包一层{code, data}这时候choices就不在顶层了。5.4 OAuth 相关报错如果你用的是 Claude Code 或类似工具报 OAuth 错误通常是因为工具在尝试走它自己的登录流程而不是用你配的 API Key。这时候要确认工具是否支持自定义 Base URL以及是否把鉴权方式切到了 API Key 模式。CC Switch 这类工具需要在设置里明确选“API Key”而不是“OAuth”。5.5 模型名不匹配本地报model not found用ollama list看实际名字。云端报模型不存在去 TaoToken 的文档页确认可用的 Model ID。注意本地模型名带:1.5b这种 tag云端通常不带 tag。6. 长期编码场景的接入建议如果你只是偶尔跑一下本地模型做验证上面的配置够用了。但如果你打算把 DeepSeek-R1 接进日常编码流程比如做代码补全、Agent 任务、批量文档处理建议把统一通道的调用封装成一个客户端类本地和云端通过配置切换而不是每次改代码。TaoToken 的 Coding Plan 适合这种长期编码场景它把常用模型的调用额度打包省去每次单独充值的麻烦。接入文档里有各语言 SDK 的示例API Keys 页面管理你的 Key。模型对话页面可以快速验证某个 Model ID 是否可用不用写代码就能测。最后给一个实用技巧在项目里建一个models.yaml把本地和云端的模型配置都列进去代码启动时根据环境变量选择加载哪一组。这样换机器、换环境、切换本地和云端都只改一个环境变量不动业务代码。这个模式在团队协作里尤其省事新人拉下代码配好 Key 就能跑。