DeepSeek非官网使用：API调用与LM Studio本地部署避坑

简介：围绕DeepSeek官网调用、API接入与本地部署三种使用路径的PDF文档，面向具备一定技术背景的AI与自然语言处理开发者、研究者，以及需频繁处理文字智能解析任务的专业人士，帮助其依据响应效率、控制权限和离线需求选择合适方案。资源以1个PDF文件交付，压缩包约963KB，篇幅紧凑，便于在单文件中集中查阅平台差异、配置要点与测试记录。已有2423人学习，说明该主题在开发者群体中关注度较高。内容重点展开硅基流动与华为云平台的API密钥获取、ChatBox客户端配置及Token管理，并说明LM Studio安装、通过Hugging Face代理下载DeepSeek-R1不同版本、按硬件选择1.5B、7B或8B等模型尺寸以平衡速度与精度；同时给出1.5B与8B模型在同一问题下的推理耗时对比，附官网高峰繁忙、API无法联网及本地部署速度受限等限制条件与选型建议，便于读者快速建立可执行的调用与部署思路。

1. 网页版转圈的那个深夜：DeepSeek 非官网使用的三条落地路径

晚上十一点半，问题敲完，进度条转了四十秒，最后弹出一句服务繁忙——这种时刻，任何做过 API 调用的人都懂。DeepSeek 的能力没人质疑，但排队这件事不看你的心情。绕开官方网页版其实有三条成熟路径：一是走第三方推理托管平台做 API 调用，把模型当成一个 HTTP 接口来用；二是用 LM Studio 把 DeepSeek-R1 的蒸馏版模型下载到本机，做完全的本地部署；三是在云厂商的模型服务上开实例，账号体系和计费走云平台。三条路的共同点是：都不依赖官方网页版的排队队列，差别在于质量、速度、成本和数据出不出的问题。这篇写给已经会装软件、能看懂报错、但不想在环境上耗一整晚的开发者，也写给第一次接触自然语言处理模型、想先把链路跑通的新手。下面按“选哪条、怎么配、哪里会翻车”的顺序，把每一步拆到能照着敲。

2. 选型先算账：API 调用与 LM Studio 本地部署差在哪

很多人一上来就装 LM Studio，下完 8B 模型跑出第一句话，兴奋三分钟，然后发现回答质量跟网页版差了不止一个档。这不是软件的问题，是权重的问题。搞清楚三条链路背后跑的是什么，比装十个客户端都管用。

2.1 三条链路跑的根本不是同一个东西

官方网页版背后是完整的 671B 级模型，带联网检索、带工具调用、带一整套后处理，你在对话框里看到的答案是多段流程拼出来的结果。第三方平台的 API 调用，托管的是同一套完整权重，接口只暴露最原始的chat/completions，联网、搜索、文件解析这些能力全部没有，需要你自己外挂。本地部署跑的基本都是蒸馏版——1.5B、7B、8B、14B、32B 这些数字代表学生模型从教师模型那里学到的容量，参数量越大越接近，但没有任何一个蒸馏版能追平完整版。

这个差别决定了三件事：本地部署适合断网、隐私敏感、长期高频但问题不难的场景；API 调用适合要质量、要稳定、能接受按量计费的日常问答和批处理；官方网页版适合需要联网和复杂推理的重活。三者不是替代关系，是互补关系。我在实际项目里通常是这么分的：日常写代码和查文档走 API，涉密材料或断网环境走本地，需要查最新资料才回官方。

把三条链路摊开对比，取舍会直观很多：

表格里最容易被忽略的是最后一行。上下文长度不是想设多大就多大，它和显存是硬绑定关系，后面第 4 章会给出估算方法。

2.2 先量硬件，再谈模型尺寸

决定走本地部署之前，先把机器摸清楚。显存、内存、CPU 核心数三项决定了你能跑多大的模型、能开多长的上下文。Linux 下一条命令就能拿到：

# 查显卡型号与显存占用，没装驱动的机器这条会直接报错 nvidia-smi --query-gpu=name,memory.total,memory.used,driver_version --format=csv # 内存与 CPU 核心数，纯 CPU 推理时这两项是瓶颈 free -h && nproc

Windows 用户直接在任务管理器里看“性能”页，重点看“专用 GPU 内存”那一栏，不是“共享 GPU 内存”。共享显存走的是内存条，速度差一个数量级，靠它跑模型会慢到怀疑人生。

拿到显存数字之后，用下面这段脚本粗算权重占用。逻辑很简单：模型权重占用的字节数约等于参数量乘以每个参数的比特数再除以 8，量化就是把比特数从 16 压到 8、4 甚至更低。

# 粗算模型权重显存占用，不含 KV Cache def weight_gb(params_b: float, bits: int) -> float: # params_b 单位为十亿参数，bits 为每参数量化位宽 return params_b * 1e9 * bits / 8 / 1024**3 * 1.08 # 1.08 是加载开销余量 for p in [1.5, 7, 8, 14, 32, 70]: print(f"{p:>4}B Q4 约 {weight_gb(p, 4):5.2f} GB Q8 约 {weight_gb(p, 8):5.2f} GB")

跑出来的数字可以直接对照：8B 的 Q4 量化权重在 4.5 GB 左右，Q8 在 9 GB 左右。注意这只是权重，还要留出 KV Cache 的空间——上下文越长、并发越多，KV Cache 涨得越快。经验值是权重之外再预留 30% 到 50% 的显存，否则一开长上下文就爆。1.5B 的 Q4 权重不到 1 GB，没有独显的笔记本也能跑，但回答质量只能算“能用”。

2.3 三个判据定方向

硬件量完，用三个问题定方向，按顺序问自己：

第一，数据能不能出本机。涉及合同、病历、内部代码这类不能外传的材料，直接排除前两条路，只能本地部署，没有讨论空间。

第二，问题难度到哪。需要多步推理、代码生成、长文档理解的，本地 8B 蒸馏版会给你似是而非的答案，返工成本比 Token 费用高得多，走 API 更划算。

第三，调用频率和预算。一天几十次问答，API 的 Token 消耗很低；一天几千次批量处理，成本就要认真算了，这时候本地部署的边际成本才显出优势。

三个问题问完，多数人会落到“API 为主、本地为辅”的组合上。这个组合的搭法很省事：客户端只装一个，两套配置并存，需要的时候切一下。下一步就按这个思路，先把 API 调用链路打通，因为它的配置项最少、见效最快。

3. API 调用落地：硅基流动密钥 + ChatBox 的三处对齐

API 调用的本质是拿一串密钥，向托管平台的接口发一个 HTTP 请求，平台在它自己的机器上跑完整模型，把结果按 Token 计价回给你。听起来简单，但真正卡住人的从来不是请求本身，而是密钥放哪、模型名怎么拼、客户端里三个下拉框怎么对齐。这一章把这三件事按顺序做一遍。

3.1 密钥：注册、创建、别贴到任何地方

第一步是注册账号。打开硅基流动的控制台，用手机号注册，注册页一般会有一个邀请码输入框，填了之后邀请方和被邀请方各自会得到一笔体验配额，不填也能正常注册，只是少一份。这笔额度的量级足够把整条链路跑通、做几十轮问答，测试阶段完全够用。

注册完成后，在侧栏找到“账户管理 - API 密钥”，点新建，系统会生成一串以sk-开头的字符串。这串东西只显示一次，关掉页面就再也看不到了，所以要么当场复制，要么重新建一个。这里有个血泪经验：新建密钥时给你的密钥起个能认出来的名字，比如“chatbox-笔记本”，等你手上有三四个密钥、其中一个泄露需要吊销的时候，命名规范能救你一次。

拿到密钥后，第一反应不要是贴进任何图形界面，而是先放进环境变量。命令行里这样设置：

# 只在当前终端会话生效，关闭窗口即失效，适合临时测试 export SF_API_KEY="sk-替换成你自己的那串" export SF_BASE_URL="https://api.siliconflow.cn/v1" # 以控制台文档页给出的为准 # 确认变量写进去了，输出应为 sk- 开头的一串 echo "${SF_API_KEY:0:8}..."

这样做的原因很实际：图形界面里的密钥是明文存在本地配置文件里的，某些客户端还会把它同步到云端；环境变量的作用域可控，泄露面小得多。长期使用的话，把这两行写进 shell 的启动脚本里，或者用系统的密钥管理工具托管，是更稳妥的做法。

提示：密钥一旦截图、贴群、提交进 Git 仓库，就当作已泄露处理，直接去控制台吊销重建，不要抱侥幸心理。

3.2 ChatBox 里必须对齐的三项

客户端选 ChatBox 的理由很朴素：全平台、免费、支持自定义模型提供方，配置界面比手写 JSON 直观。装完之后点左下角的设置图标，进入模型配置页，这三项必须逐一核对。

第一项，模型提供方。下拉列表里选SILICONFLOW API，不要选成通用的 OpenAI 兼容项，虽然底层协议一样，但预置项的模型列表是平台维护的，选对了省去手填模型名的麻烦。如果列表里没有这一项，就走通用自定义，手动填 Base URL。

第二项，API 密钥。把刚才那串sk-开头的字符串粘进去。粘贴完检查一下首尾有没有带空格，这是最常见的低级错误——多一个空格，请求就会被服务端判成鉴权失败，而客户端往往只弹一句“请求失败”，不给具体原因。

第三项，模型。这是最容易翻车的地方。平台返回的模型列表里通常同时挂着好几个 DeepSeek 相关条目：完整版叫deepseek-ai/DeepSeek-R1，还有各种蒸馏版、加速版、带后缀的变体。项目原文里提到的“R1 满血加速版”指的就是完整权重那个，选的时候认准带DeepSeek-R1且没有distill、没有小参数量后缀的那一条。选错了不报错，只是回答质量莫名其妙地差，很多人会误以为是平台降智。

三项填完点保存，左下角的模型指示器会显示当前模型名。到这里配置就算完成了一半，剩下的一半要靠实际请求验证。

3.3 用 curl 和 Python 各打一发，确认链路通

图形界面能聊不代表链路没问题，它可能只是把错误吞了。用命令行单独发一次请求，能看到完整的响应结构和错误码，这是排查问题的唯一可靠入口。

先来一条 curl，最原始也最直观：

curl -s "${SF_BASE_URL}/chat/completions" \ -H "Authorization: Bearer ${SF_API_KEY}" \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-ai/DeepSeek-R1", "messages": [{"role": "user", "content": "用三句话说明什么是注意力机制"}], "max_tokens": 1024, "stream": false }' | head -c 2000

-s关掉进度条，head -c截断输出避免刷屏。返回的是一个 JSON，重点看三块：choices[0].message.content是最终答案，choices[0].message.reasoning_content是推理模型的思考过程，usage里是这次调用实际消耗的 Token 数。如果返回的是{"code": 20012, "message": "..."}这类结构，说明鉴权或参数出错，message字段会写明原因，直接照着改。

Python 版本更适合放进项目里长期用，注意几个参数的含义：

import os import json import requests BASE = os.environ["SF_BASE_URL"].rstrip("/") KEY = os.environ["SF_API_KEY"] MODEL = "deepseek-ai/DeepSeek-R1" # 完整版，别漏命名空间前缀 def ask(prompt: str, temperature: float = 0.6, max_tokens: int = 2048) -> dict: payload = { "model": MODEL, "messages": [{"role": "user", "content": prompt}], "temperature": temperature, # 越低越确定，代码类任务建议 0.2~0.4 "max_tokens": max_tokens, # 含思考过程的长度，别设太小 "stream": False, # True 时按 SSE 逐块返回，适合前端打字机效果 } resp = requests.post( f"{BASE}/chat/completions", headers={"Authorization": f"Bearer {KEY}", "Content-Type": "application/json"}, json=payload, timeout=180, # 长思考任务要给足超时，默认值会让你误判为失败 ) resp.raise_for_status() # 4xx/5xx 直接抛异常，别静默吞掉 return resp.json() if __name__ == "__main__": data = ask("给一个 Python 判断字符串是否为回文的函数，要求含边界处理") msg = data["choices"][0]["message"] print("[思考]", (msg.get("reasoning_content") or "")[:300]) print("[回答]", msg["content"]) print("[用量]", json.dumps(data["usage"], ensure_ascii=False))

几个参数值得单独说。temperature控制随机性，写代码、做抽取这类要稳定的任务调到 0.2 到 0.4，创意类保持 0.6 以上。max_tokens要包含思考过程的长度，R1 这类推理模型在输出正文之前会先吐一大段思考，设成 512 很可能思考完就没配额了，正文是空的——这个坑第 5 章会细讲。timeout别用默认值，复杂问题单次调用几十秒很正常。stream设成True的时候返回的不是完整 JSON 而是 SSE 数据流，解析方式完全不同，客户端要相应改造。

3.4 Token 计量与成本控制

usage字段里通常有三个数：prompt_tokens、completion_tokens、total_tokens。前两个的比例决定了你的成本结构——输入便宜、输出贵，所以长文档问答的实际花费往往比想象中低，而让模型写长文的花费会高得多。

控制成本有三招，都是实操里攒出来的。一是把不必要的历史对话裁掉，多轮对话每一轮都会把前面所有消息重发一遍，聊到二十轮之后输入 Token 会滚雪球。二是对固定任务用短提示词，少写客套话，提示词里的每一个字都在计费。三是批量任务别用流式，流式对计费没影响但会增加连接管理的复杂度，脚本里没必要。

到这一步，API 调用链路已经完整走通：密钥有了、客户端配好了、命令行验证过了、成本能算了。需要审视的是它解决不了的问题——断网、涉密、以及某些平台在高峰期依然会出现的排队。

4. 本地部署落地：LM Studio 里把 DeepSeek-R1 蒸馏版跑起来

本地部署的核心价值只有两个词：离线、可控。代价同样明确：你跑的是蒸馏版，质量会下降，速度取决于硬件。接受这个前提之后，LM Studio 是目前上手成本最低的选择——图形界面、内置模型仓库、一键加载、还能起一个 OpenAI 兼容的本地服务端口。这一章按装、搜、配、验四步走完。

4.1 装完之后先动的两个开关

去 LM Studio 官网下载对应平台的安装包，Windows、macOS、Linux 都有，装完直接启动，没有复杂的初始化流程。

第一个开关是语言。右下角的齿轮图标进设置，找到 Language，切成中文。这里要提醒一句：社区里对中文汉化的评价普遍一般，部分术语翻译得比较生硬，如果你已经熟悉英文界面，保持英文反而更顺手，菜单就那么几个词，不影响使用。

第二个开关是模型下载通道，这个必须开。设置里的 General 页面有一个Use LM Studio's Hugging Face Proxy选项，默认是关的。不勾选的情况下去 Discover 页搜索，能搜到的模型条目很有限，大多是官方精选的几个；勾上之后，社区上传的量化版本才会出现在结果里——判断方法很直观，勾选前后搜索结果里会多出一批带黄色图标的条目，那些就是社区量化的 GGUF 模型。不开这个开关，你大概率会得出“LM Studio 模型太少”的结论，这是最常见的误判之一。

注意：代理开关只影响模型检索与下载通道，跟运行推理没有任何关系，下载完之后关掉也能正常用。

4.2 搜模型、认名字、挑量化：别把蒸馏版当满血版

点左侧的放大镜进入 Discover，搜索框输入DeepSeek R1。结果列表里会混着好几种东西，名字长得很像，必须逐字看。

DeepSeek-R1本身是 671B 的完整模型，标称几百 GB，个人机器跑不动，看到体积就该绕道。带Distill字样的才是蒸馏版，形如DeepSeek-R1-Distill-Qwen-7B、DeepSeek-R1-Distill-Llama-8B，这里的 7B、8B 就是参数量，是你要找的目标。同一行里还会带量化标记，比如Q4_K_M、Q5_K_M、Q8_0，含义是每个参数的比特数：Q4 大约每参数 4 比特，Q8 是 8 比特，比特数越低体积越小、质量损失越大。Q4_K_M 是社区验证过的性价比档位，绝大多数场景够用。

体积那一列是下载文件大小，直接对应硬盘占用和加载后的显存占用，参考关系是 8B 的 Q4 大约 5 GB，7B 的 Q4 大约 4.5 GB。硬盘空间要留出下载临时文件的两倍余量，别卡着剩余空间下载。

模型尺寸怎么选，给一张按硬件分档的参考表：

表格里没有 671B 那一档，是因为它在个人设备上没有实际意义，即便内存够，纯 CPU 推理的吞吐也会低到无法交互。

4.3 加载参数：上下文长度、GPU Offload 与线程数

模型下载完之后，回到对话页，顶部有一个模型选择器，选中刚下的那个。选中后右侧会展开一个参数面板，这里的每一项都会实际影响速度和质量。

上下文长度是最关键的一项。它决定模型一次能记住多少内容，也直接决定 KV Cache 占用多少显存。把这一项拉到最大是新手最常见的错误——8B 模型开到 32K 上下文，KV Cache 能吃掉好几个 G，显存直接见底，系统开始往内存里换页，速度断崖式下降。实用的做法是从 4096 或 8192 起步，只在你确实要喂长文档时才往上调，调完立刻观察速度变化。

GPU Offload 是第二项。它控制有多少层计算交给显卡。数值拉满表示全部走 GPU，速度最快；设成 0 就是纯 CPU 推理，项目原文里提到的“将 GPU 设为 0 将会使用纯 CPU 进行推理，推理速度会降低很多”说的就是这一项。中间档位只在显存不足时才有意义——把一部分层放 GPU、一部分留给 CPU，能跑起来但速度介于两者之间。如果你的机器显存刚好差一点点，调低这个值比换小模型更划算。

剩下几项属于微调范围。CPU 线程数一般设为物理核心数，超线程核心加上去收益不大。Keep in Memory决定切换模型时是否保留在内存里，只有一个模型就没必要开。Flash Attention 在支持的硬件上开了会快一些，遇到输出异常再关掉排查。

加载完成后，界面上会显示模型的加载状态和实际占用。如果加载直接失败或者卡在加载中超过一分钟，八成是显存不够，回退到更小的量化档位或者更短的上下文。

4.4 不开图形界面也能测：本地 OpenAI 兼容接口

LM Studio 有一个很实用的能力：它可以起一个本地 HTTP 服务，接口格式和 OpenAI 兼容。这意味着你写好的 API 调用代码，只要把 Base URL 换成http://localhost:1234/v1、密钥随便填一个非空字符串，就能直接打到本地模型上，不需要改一行业务逻辑。

在左侧栏找到本地服务（Local Server）标签页，点启动，默认端口是 1234。然后验证：

# 本地服务不需要真实密钥，但多数客户端要求该字段非空 curl -s http://localhost:1234/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer local" \ -d '{ "model": "local-model", "messages": [{"role": "user", "content": "解释一下什么是量化"}], "max_tokens": 512, "temperature": 0.3 }'

model字段在本地服务里通常不校验，填什么都能过，真正生效的是你在界面上加载的那个模型。这一点和云端 API 不同，云端模型名写错会直接报错，本地不会——这也埋下了一个坑，切回云端时忘了改模型名，就会收到 400。

接口通了之后，本地部署的工程价值才真正体现出来：你可以把同一份调用代码指向云端或本地，用配置切换，做 A/B 对比、做降级兜底。断网时切本地，联网时切云端，这套结构在真实项目里比单纯“能跑”有用得多。

5. 避坑清单：五类翻车现场的现象、成因与处置

配置能跑通只是及格线，真正拉开差距的是出错时能不能三分钟内定位。下面这五条都是我在调试这条链路时实打实撞过的，按“看到什么、为什么、怎么办”写，遇到时可以直接对号入座。

5.1 现象：客户端只提示“请求失败”，没有任何细节

原因几乎总是鉴权。三个高频来源：密钥复制时带了首尾空格或换行；密钥已经被吊销但本地还留着旧的；请求头里Bearer和密钥之间少了空格，或者把Authorization拼成了Authorisation。

解决方法是绕开客户端，用第 3 章那条 curl 直接打一次。命令行会返回明确的错误码和 message，鉴权类错误通常是 401 或平台自定义的码值。定位到是密钥问题后，去控制台重新生成一个，用echo确认环境变量里没有多余字符，再回填客户端。养成习惯：任何图形界面报错，第一反应都是回到命令行复现，图形界面是黑匣子，命令行才是仪表盘。

5.2 现象：返回 400，提示 model not found

原因在模型名。云端 API 的模型 ID 是带命名空间前缀的完整字符串，少一段就找不到。另一种情况是名字对但指向了别的版本——平台的模型列表里同时有完整版和各种蒸馏版，从别处抄来的名字可能对应蒸馏版，调用不报错但质量差一截。

解决办法是把模型列表拉下来看，用GET {BASE_URL}/models拿到平台当前挂载的全部模型 ID，逐字比对，复制粘贴而不是手敲。还有一个隐蔽的变体：从本地服务切回云端时忘了改model字段，本地服务不校验模型名所以一切正常，切回云端立刻 400。我的做法是在配置里把model和base_url绑成一组，切换环境时整组替换，不给单独改一个字段留机会。

5.3 现象：本地模型加载失败，或加载后系统卡死

原因是显存超配。两种情况最常见：上下文长度设得太大，KV Cache 把剩余显存吃光；或者量化档位选高了，Q8 的 8B 模型权重接近 9 GB，加上 KV Cache 直接超过 8 GB 显卡的容量。

解决顺序是这样：先把上下文降到 4096 再加载，能起来就说明是 KV Cache 的问题，按需往上加；还起不来就把量化换成 Q4_K_M，体积能砍掉近一半；仍然不行就调低 GPU Offload，让一部分层走 CPU，速度慢但能跑。要强调的是，显存不够时系统不会给你一个漂亮的错误提示，它的表现是卡顿、加载转圈、甚至整个桌面失去响应，别等，直接强退重来。留足 30% 的显存余量是常识，不是保守。

5.4 现象：content字段是空的，只有reasoning_content有内容

原因是被max_tokens截断了。推理模型在输出正文前会先写一大段思考过程，这段也算 Token。max_tokens设成 512 的时候，思考可能就吃掉 480，正文还没开始就被掐断，finish_reason会是length。

解决办法分两步。短期把max_tokens调到 2048 以上，复杂任务给到 4096。长期则在代码里判finish_reason，等于length就说明输出被截，要么加大配额重试，要么把问题拆小。另外，如果业务只关心结论不关心思考过程，读content就好，别把reasoning_content直接展示给终端用户，那段文字的逻辑是跳跃的，看着像自言自语。

5.5 现象：Discover 里搜不到量化模型，或者搜出来的都是几十 GB 的大文件

原因是 Hugging Face 代理开关没勾。不勾选时搜索结果被限制在官方精选范围内，社区上传的 GGUF 量化版本不会出现，你看到的多是原始权重仓库，体积巨大且格式未必能直接加载。

解决办法是回到设置里的 General 页，勾上代理选项，重启 Discover 页面重新搜索。勾上之后结果里会多出带黄色图标的条目，那些是社区量化版，按 4.2 节的命名规则挑Distill+ 参数量 +Q4_K_M的组合即可。要是勾了还是搜不到，换关键词，从DeepSeek R1改成DeepSeek-R1-Distill，搜索结果对连字符和空格敏感。

6. 同一组题跑两遍：把 API 与本地模型的差异拉成一张可比表

配置跑通之后，多数人就此停手，凭感觉觉得“本地慢一点但能用”。这种模糊判断在需要做技术选型时会害人——你以为的“慢一点”可能是十倍，你以为的“差一点”可能是答非所问。稳妥的做法是自己造一个小测试集，同一组问题、同一套评分口径，把两条链路各跑一遍，把结果落成数字。

测试集不用大，八到十道题就够，但要覆盖三种类型：事实型（考察知识准确性）、推理型（考察多步推导）、生成型（考察代码或结构化输出）。每条记录四个指标：首字延迟、总耗时、输出 Token 数、人工质量评分（1 到 5 分）。脚本大致这样：

import time, json, requests QUESTIONS = [ "用一句话说明 TCP 三次握手的目的", "一个列表里有重复元素，写出保留首次出现顺序的去重函数并说明复杂度", "解释什么是 KV Cache，以及它为什么和上下文长度成正比", # 其余题目按事实/推理/生成三类补齐 ] def bench(base, key, model, tag): rows = [] for q in QUESTIONS: t0 = time.time() r = requests.post(f"{base}/chat/completions", headers={"Authorization": f"Bearer {key}", "Content-Type": "application/json"}, json={"model": model, "messages": [{"role": "user", "content": q}], "max_tokens": 2048, "temperature": 0.3}, timeout=300) cost = time.time() - t0 d = r.json() rows.append({"tag": tag, "q": q[:20], "sec": round(cost, 2), "completion": d["usage"]["completion_tokens"]}) return rows # 云端与本地各跑一遍，输出后直接贴进表格对比 result = bench("http://localhost:1234/v1", "local", "local-model", "local-8b") print(json.dumps(result, ensure_ascii=False, indent=2))

跑完把数字填进表里，差距会很刺眼：

这张表的价值不在数字本身，而在于它能替你回答“本地能不能顶上”这个问题。我的经验是：本地 8B 在事实问答和简单改写上够用，在需要多步推理和严格语法的代码生成上，返工成本远高于省下的 Token 费用，这种情况下本地部署只适合当断网兜底，不适合当主力。

还有两个容易忽略的验收细节。一是测长上下文，把一份两万字的文档塞进去问细节，蒸馏版经常在中间段落开始丢信息，这个用短问题测不出来。二是测并发，本地服务默认单请求串行，两个请求同时打进去，第二个的延迟会翻倍，做批量任务时要么加队列，要么接受这个事实，别以为是代码写错了。

从那以后我每次接一个新模型，不管是云端的还是本地的，都强制先跑一遍这个十题小测试，把数字记进项目笔记，再决定把它放在链路的哪个位置——不测就上生产，翻车只是时间问题。希望这套流程能帮你少走几个晚上的弯路。

本文还有配套的精品资源，点击获取