简介：《DeepSeek 非官网使用方法》配套PDF面向具备一定技术背景的AI开发者、自然语言处理学习者及需频繁处理文本解析任务的专业人士，聚焦官网之外的API调用与本地部署两条路径，帮助读者按响应效率、联网能力、成本和控制权限完成选型。文档共1个PDF文件，约963KB，以平台对比、配置要点和实测记录为主线，涵盖硅基流动、华为云与ChatBox的API接入思路，以及LM Studio结合Hugging Face代理下载DeepSeek-R1不同规模模型的部署方案。其价值在于把官网调用、API调用和本地部署的特点与限制置于同一框架比较，说明Token管理、模型尺寸与硬件配置之间的权衡，并通过1.5B与8B模型的测试呈现推理速度差异，附有总结建议，便于读者结合自身环境评估实施方案。已有2423人学习，适合希望系统了解DeepSeek多种使用方式、快速定位合适方案的技术读者。
1. 官网排队到 401：我把 DeepSeek 拆成两条链路来装
上个月帮一位开发者收拾开发机，白天他在官网页面排队等回复，晚上换成 API 调用，结果密钥多粘了一个空格，报了一整晚 401。这件事让我把「DeepSeek 非官网使用方法」重新捋了一遍，最后落成两条互不干扰的链路：一条是 API 调用，硅基流动拿密钥、ChatBox 当客户端；另一条是本地部署，LM Studio 拉 DeepSeek-R1 蒸馏模型离线跑。两条链路的环境要求、失败点、验证手段完全不一样，混在一起讲最容易翻车。这篇写给真要动手装的人：装什么、参数怎么填、跑不动时先看哪一行日志。新手照着能走通，熟手能看清版本和量化位数的取舍。
2. 先把环境账算清：API 调用与本地部署各要什么
装之前最怕的不是命令不会敲，是装到一半才发现硬件不够、账号没注册、客户端版本对不上。这一章不写操作，只把「我这台机器该走哪条路」定下来，后面的章节才有意义。两条链路的核心差别在于算力归谁：API 调用把推理压到远端，你只负责网络和密钥；本地部署把推理压回自己的 CPU/GPU，模型文件、上下文长度、显存占用全要自己兜。
2.1 两条链路的能力边界对比
先看一张对照表，这张表是我自己装机时贴在便签上的版本，后面所有取舍都从这里推。
| 维度 | API 调用（硅基流动 + ChatBox） | 本地部署（LM Studio） |
|---|---|---|
| 算力来源 | 远端推理集群 | 本机 CPU / GPU |
| 联网能力 | 模型本身不联网，只做推理 | 完全离线，断网可用 |
| 首屏准备成本 | 注册账号 + 装客户端，十分钟级 | 下载模型文件，几 GB 到几十 GB |
| 主要瓶颈 | 密钥鉴权、Token 配额、并发限流 | 显存、内存带宽、上下文长度 |
| 效果上限 | 满血版 DeepSeek-R1 | 蒸馏小模型，参数量决定上限 |
| 典型失败 | 401、429、模型 ID 写错 | 加载转圈、爆内存、输出重复 |
表里最容易被忽略的是「典型失败」那一列。很多人以为本地部署更难，其实从排错成本看，API 侧的 401 反而更磨人，因为报错信息只有一行Unauthorized，看不出是密钥错了、前缀漏了还是账户配额空了。本地侧的报错虽然吓人，但基本都能对应到一个具体资源：内存、显存、上下文。
2.2 模型规模与硬件配置对照
本地部署这一侧，装机前必须先确定模型规模。DeepSeek-R1 官方完整模型是 671B 参数，个人机器基本不用考虑；日常能跑的是蒸馏版，常见的有 1.5B、7B、8B、14B、32B 这几档。参数量越大，模型的完整度和回答准确性越好，但推理耗时和硬件门槛同步上涨。
下面这张表按 Q4 量化（4 bit 左右）估算文件体积，实际下载时以 LM Studio 里显示的 Download 大小为准：
| 模型规模 | 量化后文件体积（约） | 内存 / 显存建议 | 适用场景 |
|---|---|---|---|
| 1.5B | 1 GB 出头 | 8 GB 内存，纯 CPU 可跑 | 无独显的轻薄本，验证流程用 |
| 7B / 8B | 4.5 ~ 5 GB | 16 GB 内存，6 ~ 8 GB 显存 | 主力档，日常问答与草稿 |
| 14B | 9 GB 左右 | 32 GB 内存，12 GB 以上显存 | 需要更稳的长回答 |
| 32B | 20 GB 左右 | 64 GB 内存，24 GB 显存 | 工作站级别，速度换质量 |
| 671B | 数百 GB | 个人设备不具备条件 | 不推荐个人尝试 |
提示：表里的显存数字是「模型全部放进显存」的估算。显存放不下时 LM Studio 会把部分层留在 CPU 上跑，能启动，但出字速度会掉一个数量级，这是后面第 4 章要调的参数。
2.3 装之前要准备好的三样东西
第一样是账号。硅基流动注册只需要手机号，注册完成后在侧栏「账户管理 - API 密钥」里新建一把密钥，新用户会有一笔赠送额度，够把链路跑通很久。密钥只在创建时完整显示一次，复制走之后页面就只剩掩码，这一点和大多数云平台一致。
第二样是客户端安装包。ChatBox 在官网按平台下载，Windows、macOS、Linux 都有对应安装包，装完是图形界面，不需要命令行；LM Studio 同样按平台下载，安装过程基本一路下一步。两边的版本都以官网当前稳定版为准，这类客户端迭代快，不建议从第三方镜像站拿旧包。
第三样是磁盘空间。LM Studio 的模型默认落在用户目录下的隐藏文件夹里，一个 8B 模型加缓存大约 6 GB，如果你打算把 1.5B 和 8B 都拉下来做对比测试，预留 20 GB 比较稳妥。C 盘紧张的话，先在设置里把模型目录改到大盘，再开始下载，别等下到一半再迁。
3. API 调用落地：硅基流动密钥配 ChatBox 的三处对齐
这条链路的本质是把 ChatBox 当成一个「壳」，真正的推理发生在硅基流动那一侧。所以装的过程就是三件事的对齐：提供方选对、密钥填对、模型 ID 写对。任何一处错位，表现都是「发出去没反应」或者「401」，而不会告诉你具体错在哪。
3.1 在 SiliconCloud 建一把能用的密钥
注册流程没什么可讲的，手机号、验证码、登录，侧栏进「账户管理」，找到「API 密钥」，点新建。名称随便起，比如chatbox-daily，方便以后按用途区分和吊销。创建后立刻复制，粘到一个临时文本里，别直接粘进聊天窗口。
有几条经验是踩出来的。一是密钥不要提交到任何代码仓库，哪怕是私有仓库，.env也要进.gitignore；二是一把密钥只给一个客户端用，ChatBox 一把、脚本一把，出问题能快速定位是哪一端在打；三是别在浏览器里反复刷新密钥列表页面，有些平台的掩码展示逻辑会让人误以为密钥变了，实际只是显示截断。
拿到密钥后，先在终端里用环境变量接住，别硬编码在命令里：
# 把密钥放进当前 shell 的临时环境变量，避免出现在命令历史里 export SILICON_API_KEY="sk-替换成你自己的密钥" # 确认长度和前缀，正常是 sk- 开头的一长串 echo "${#SILICON_API_KEY}"export只在当前终端会话有效，关掉窗口就没了，这是刻意的：它不会写进~/.bash_history以外的任何文件。第二行打印的是字符串长度，如果输出明显偏短（比如只有 3），说明引号没配对或者变量名打错了，这时候再去配客户端只会把错误放大。
3.2 ChatBox 里把提供方、密钥、模型三件事配对
打开 ChatBox，左下角进设置，找到模型提供方一栏。这里的关键是选对提供方条目：要选硅基流动对应的那一项（界面上显示为 SILICONFLOW API 之类的名称），而不是通用的 OpenAI 兼容项。选对之后，密钥输入框才会和它背后的接口地址绑定，省掉手填 Base URL 的麻烦。
填完密钥，往下找模型选择。列表里会有多个 DeepSeek 相关条目，选deepseek-ai/DeepSeek-R1这一个，也就是满血加速版。R1 和普通的 chat 模型在行为上差别不小：它会先输出一段思考过程再给结论，所以第一次用会觉得「怎么半天不出字」，这是正常的，不是卡住了。
保存设置，回到主界面，左侧新建对话，确认对话窗口顶部显示的模型名和刚才选的一致。这一步很多人跳过，结果新建对话时客户端回退到默认模型，答出来的东西完全不是 R1 的风格，还以为是平台降级了。
3.3 用 curl 和 Python 各验一次链路
客户端配好只是「看起来能用」，真正要确认链路通，还是得绕开 GUI 直接打接口。先用 curl 打一发，把变量都显式写出来：
curl -s https://api.siliconflow.cn/v1/chat/completions \ -H "Authorization: Bearer ${SILICON_API_KEY}" \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-ai/DeepSeek-R1", "messages": [{"role": "user", "content": "用一句话说明温度参数的作用"}], "temperature": 0.6, "max_tokens": 512, "stream": false }'Authorization这一行是重灾区：Bearer和密钥之间必须有一个空格，少这个空格就是 401，而且报错不会提示你少了空格。model必须和平台上的模型 ID 逐字符一致，大小写、连字符都不能改。max_tokens限制的是输出长度，不包含输入；R1 会先思考再回答，这个值设太小会出现「思考到一半被截断」的现象，512 是验证用的保守值。stream设成false是为了让返回一次性打印完整，方便肉眼检查；生产里一般开true走流式。
Python 侧用官方 SDK 更省事，base_url指向同一个地址即可：
from openai import OpenAI client = OpenAI( api_key="sk-替换成你自己的密钥", base_url="https://api.siliconflow.cn/v1", # 只到 /v1，不要再拼 /chat/completions timeout=120, # R1 思考时间长，超时要放大 ) resp = client.chat.completions.create( model="deepseek-ai/DeepSeek-R1", messages=[{"role": "user", "content": "把这段中文翻译成英文：环境已就绪"}], temperature=0.6, max_tokens=1024, ) print(resp.choices[0].message.content) print(resp.usage) # 看 prompt_tokens 和 completion_tokens 的消耗base_url写成完整的/v1/chat/completions是最常见的错误，SDK 会自己拼路径，多写一段就变成 404。timeout默认值对普通模型够用，但 R1 的思考过程会拉长响应时间，我一般直接给到 120 秒，避免长问题被客户端提前掐断。最后打印usage是为了心里有数：输出 token 消耗和输入 token 消耗是分开计费的，长对话里上下文会不断累积，跑一天下来额度掉得比想象中快。
4. 本地部署第一步：LM Studio 装好、代理打开、模型拉下来
本地这条链路和 API 侧最大的不同是：装完客户端只是空壳，模型文件要自己下。而模型能不能搜到、下得动，取决于一个很多人不会注意的开关。
4.1 安装与首次启动要改的三个设置
从官网下对应平台的安装包，双击装完直接启动。首次打开界面是英文的，右下角齿轮进设置，Language里可以切中文，但汉化完整度一般，术语翻译有时反而看不懂，我一般保持英文，看参数名更准。
真正要动的是第二个开关。在设置的General页里，有一项Use LM Studio's Hugging Face Proxy，把它勾上。这个选项控制的是模型检索走哪条通道：不勾的时候，Discover 里只能搜到官方自带的少量模型，选择面很窄；勾上之后能检索到社区上传的量化版本，界面上会多出一批带黄色图标的条目。原文里说的「不勾选的情况下搜索到的模型都是官方提供的」就是这个意思。勾完建议重启一次客户端，让配置生效。
第三个设置是模型存储目录。默认在用户目录下，模型多了会吃掉几十 GB。建议在General里先把路径改到空间充裕的盘，再开始下载，避免后面迁移时重新校验文件。
4.2 在 Discover 里搜 DeepSeek R1 并挑量化版本
右侧点放大镜进 Discover，搜索栏输入DeepSeek R1。列表里会出现一堆名字相近的条目：有带distill的蒸馏版，有不同参数规模，还有不同的量化后缀。挑的时候按三件事看：
第一看参数量，也就是名字里的 1.5B、7B、8B、14B、32B，对应第 2 章那张表；第二看量化后缀，常见的是Q4_K_M、Q5_K_M、Q8_0，数字越大精度越高、文件越大、速度越慢，Q4_K_M 是速度和质量比较平衡的档；第三看条目右侧的 Download 大小，这个数字才是你磁盘上真正要腾出来的空间。
注意：带黄色图标的条目是社区上传的模型，可用但不由官方维护。下载前看一眼更新时间，太老的版本可能和新版推理引擎不兼容。
下载是后台进行的，可以在下载列表里看进度。8B 的 Q4 版本大约 5 GB，家用带宽下要等一会儿。下载完成后不用手动解压，LM Studio 会把它放进模型库，在顶部的模型选择器里直接出现。
4.3 加载模型后的四个运行参数
选中模型不等于能跑得动，加载之后右侧（或顶部）会有一个运行参数面板，这四个值决定了你是「流畅出字」还是「转圈到怀疑人生」。
| 参数 | 作用 | 我的常用值 |
|---|---|---|
| Context Length | 上下文窗口，能记住多少 token | 4096 起步，显存够再往上 |
| GPU Offload | 有多少层模型放进显存 | 显存够就拉满，不够就减半 |
| CPU Threads | 留给 CPU 推理的线程数 | 物理核心数左右 |
| Keep in Memory | 切换模型时是否常驻内存 | 常驻，避免反复加载 |
Context Length 是最容易设大的一个。它直接吃显存，4096 已经能覆盖大部分单轮问答；一上来设 32768，模型加载时就可能直接失败或者把系统拖进交换分区。GPU Offload 的滑块决定层数分配，全给 GPU 速度最快，显存溢出时会自动往 CPU 回退，但那个回退是静默的，你只会感觉「怎么这么慢」。把 GPU 层数设成 0 就是纯 CPU 推理，用来验证模型本身能不能跑，速度会很慢，但至少排除了显卡驱动的问题。
改完参数记得点重新加载。有些版本改参数后不会自动重载，界面上看着是新的，实际跑的还是旧配置，这个坑我踩过一次，调了半小时参数发现根本没生效。
5. 装完必看：五类翻车现场与对应救法
这一章是我自己和小圈子里攒下来的问题清单，按「现象 → 原因 → 解决」写。装环境这件事，能一次装通是运气，知道坏了怎么救才是本事。
5.1 密钥类：401 与「模型不存在」
现象：ChatBox 里发消息一直转圈后报错，或者 curl 返回401 Unauthorized；另一种是返回「model not found」，但模型名看着没错。
原因：401 绝大多数是密钥本身的问题——复制时带了首尾空格、密钥已被删除重建、或者账户额度耗尽。第二种「模型不存在」通常是模型 ID 拼写不一致，比如把deepseek-ai/DeepSeek-R1写成了deepseek-r1，平台侧是精确匹配，不做模糊纠错。
解决：先用第 3.3 节那条echo "${#SILICON_API_KEY}"确认长度，再回平台上重新建一把密钥对比。模型 ID 直接从平台的模型列表页复制，不要手打。如果两边都对还是 401，去看账户的余额和配额页面，有些平台的赠送额度有有效期。
5.2 检索类：Discover 里搜不到带黄色图标的模型
现象：在 LM Studio 的 Discover 里搜DeepSeek R1，结果只有寥寥几条，全是官方条目，没有社区量化版。
原因：Use LM Studio's Hugging Face Proxy没勾，或者勾了但没重启客户端。也有一种情况是网络环境导致检索请求超时，界面表现为「搜完了但结果为空」，不报错。
解决：回设置里确认开关状态，重启客户端再搜。如果仍然为空，换一个更短的关键词，比如只搜deepseek，再看列表里有没有 R1 相关的条目。搜到了但下载卡在 0%，一般是临时网络问题，暂停再继续通常能接上，不必删了重下。
5.3 加载类：模型加载到一半失败或系统假死
现象：点加载后进度条走到某个百分比停住，客户端无响应，任务管理器里内存占用飙到 90% 以上，风扇狂转。
原因：Context Length 设得过大，或者 GPU Offload 层数超过显存容量，触发大量内存与显存之间的换入换出。也有可能是模型文件下载不完整，校验不过。
解决：先把 Context Length 降到 4096，GPU Offload 调到 0，用纯 CPU 加载一次，能起来就说明是资源分配问题，再逐级往上加。如果纯 CPU 也起不来，去模型目录看文件大小是否和页面显示的 Download 大小一致，差得多就删掉重下。
5.4 输出类：答非所问、重复、乱码
现象：模型能出字，但回答驴唇不对马嘴，或者一句话反复重复，或者夹杂奇怪的符号。
原因：三个方向。一是温度参数过高，采样过于随机；二是模型的对话模板（chat template）没被正确识别，蒸馏版模型对模板比较敏感；三是量化精度太低，Q2、Q3 这类极限量化会明显损伤语言能力。
解决：温度先降到 0.6 以下再试；确认 LM Studio 里加载的模型条目和你以为的是同一个（同名不同量化的条目很多）；把量化档从 Q2 换到 Q4_K_M 以上。这三步走完还不行，就换一个参数规模更大的模型对比，排除是模型本身能力不足。
5.5 速度类：能跑但慢得没法用
现象：一句话要等一两分钟，任务管理器显示 GPU 利用率很低，CPU 却跑满。
原因：GPU Offload 层数为 0 或者设得太低，全部推理压在 CPU 上；也可能是显存不够，模型被静默拆到了内存里。
解决：先看显存占用，如果远低于显卡容量，说明层数没给够，往上调；如果显存已经满了还在往上涨，说明 Context Length 吃多了，往下压。还有一个常被忽略的点是 CPU 线程数，设成逻辑核心数反而会因超线程争抢变慢，设成物理核心数通常更稳。
6. 验证跑通：三步确认这套环境真的能用
装完不等于跑通，我习惯用三个动作做终检，全程不到十分钟，但能挡掉后面 80% 的「明明装好了却用不了」。
第一步，API 侧做一次固定输入比对。用同一句提示词，分别走 ChatBox 和第 3.3 节的 curl，看两边的回答结构是否一致——都应该是先一段思考、再一段结论。如果 ChatBox 出来的没有思考段，说明对话窗口的模型选错了，回 3.2 节重选。
第二步，本地侧看吞吐而不是看「能不能出字」。在 LM Studio 里发一个两百字左右的问题，回答完成后界面会显示本次的 tokens/s 和耗时。把这个数字记下来，作为你这台机器的基线：
| 配置 | 8B Q4 的参考吞吐 | 判断 |
|---|---|---|
| 纯 CPU、16 GB 内存 | 3 ~ 8 tokens/s | 能用，但长文吃力 |
| 8 GB 显存、GPU 全量加载 | 25 tokens/s 以上 | 正常水位 |
| 显存不足、部分回退 CPU | 5 ~ 10 tokens/s | 去调 GPU Offload |
数字明显低于表格区间，就回第 5.5 节查资源分配，别急着换模型。
第三步，探一次本地服务端口。LM Studio 可以在开发者页把模型暴露成 OpenAI 兼容接口，默认监听本机 1234 端口，这样脚本和客户端就能共用同一个模型：
# 先确认端口在监听，再发一条最小请求 curl -s http://127.0.0.1:1234/v1/models curl -s http://127.0.0.1:1234/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "本地模型列表里显示的名称", "messages": [{"role": "user", "content": "报一下你的模型名"}], "temperature": 0.6, "max_tokens": -1, "stream": false }'第一条请求返回的是当前已加载的模型清单，model字段要照抄这里的名字，不要自己猜。max_tokens设成-1表示不限制输出长度，本地推理不按 token 计费，限制它没有意义，反而容易把长回答截断。端口通了但请求超时，通常是模型还在加载，等加载完成再发。
从那以后我每次装完这套环境，都会强制走一遍这三个动作：固定输入比对、吞吐打点、端口探活。少走一步，后面就会在某个深夜被一个说不清来源的 401 或者「怎么这么慢」拖住。环境这东西，装的时候多花十分钟验证，用的时候少花十小时排查。希望帮到你。
本文还有配套的精品资源，点击获取
