Windows本地部署Qwen3.8实战：LM Studio、Cherry Studio、远程API与Token鉴权

前言

云端AI用起来方便，但我最容易被两个问题卡住：一是高峰期响应速度和额度并不完全由自己控制，二是遇到内部文档、未公开代码或私人资料时，我并不总想把内容交给外部模型服务。真正想长期使用，我更希望把模型放在自己的电脑上，需要时直接调用本机显卡。

这次我用Windows上的LM Studio部署Qwen3.8，重点测试27B和9B两个体量，分别看聊天、识图和代码生成表现，同时记录不同显卡环境下的生成速度差异。

本地聊天跑通以后，再开启LM Studio自带的OpenAI兼容API，用Cherry Studio连接本机模型，把"只能在LM Studio里聊天"变成"其他客户端也能调用"。

最后再把12345端口通过cpolar提供给外部设备使用，并补上LM Studio的Token鉴权。

这样整条链才真正完整：**本地模型 → OpenAI兼容API → Cherry Studio → 远程访问 → Token保护。**重点不是单纯把模型装上，而是让家里的GPU真正变成自己可以长期调用的个人AI节点。

这套方案还有一个很现实的价值：高性能台式机可以留在家里长期跑模型，外出时不需要再带一台厚重游戏本。轻薄本和手机只负责发请求、看结果，真正吃显存和算力的工作仍然交给家里的主机。

1 这篇真正要解决的，不只是"本地跑模型"

本地部署大模型最直观的好处，是推理工作落在自己的电脑上。

但如果只做到"LM Studio里能聊天"，实际使用范围还是比较窄。

我更关心的是后面几件事：

能不能在Windows上稳定加载模型；
27B和9B在我的硬件上分别是什么速度；
图片理解和代码生成是否能正常用；
能不能把模型开放成OpenAI兼容API；
Cherry Studio能不能直接接入；
出门以后还能不能调用家里电脑的GPU；
公网调用以后有没有鉴权。

整篇就按这条链往下走。

2 先看Qwen3.8这次重点关注什么

这次主要使用Qwen3.8系列，并重点测试27B和9B两个体量。

模型信息页面：

27B更偏能力优先。

9B则更适合显存相对有限、希望提高响应速度的机器。

真正选择时，不建议只看参数量，而要同时看：

模型能力、显存占用、生成速度。

3 代码能力先看实际输出

这次先测试代码生成。

27B在复杂代码任务里可以连续输出比较完整的页面和交互逻辑。

4 图片理解也直接放进实操里看

Qwen3.8这次也用于图片理解测试。

5 长上下文更适合代码库和长文档场景

这次模型资料里还强调了长上下文能力。

对应页面：

对实际使用来说，它的意义不是"数字越大越好"，而是面对：

大段代码；
长文档；
项目说明；
长篇文本；

时，可以减少频繁拆分输入的次数。

6 Agent能力适合继续往自动化扩展

Agent相关能力展示：

如果以后继续往自动化、工具调用、浏览器操作等方向扩展，本地模型不一定只停留在"问一句答一句"。

这部分先不展开，本文仍然把重点放在：

部署、API、远程调用。

7 开源协议和本地运行，是我选择它的重要原因之一

8 显存不够时，不要硬上最大模型

硬件提示：

27B能力更强，但显存压力也更大。

如果机器资源有限，9B或者更合适的量化版本往往更实际。

我的判断标准很简单：

能稳定加载 + 速度能接受，比单纯追求参数量更重要。

9 LM Studio不只是聊天窗口

LM Studio最有价值的一点，是它除了图形界面，还能直接提供OpenAI兼容API。

接口相关页面：

也就是说，模型加载完成以后，不一定只能在LM Studio里聊天。

后面还可以让：

Cherry Studio；
其他兼容OpenAI接口的客户端；
本地脚本；
开发工具；

继续调用同一个本地模型。

10 Windows安装LM Studio

这次实操环境是Windows。

安装完成后进入主界面：

整个过程不需要先写启动脚本，也不需要手动拼一长串模型参数。

对于第一次接触本地大模型的人来说，这种图形界面更容易先把流程跑通。

11 先把界面切成中文

进入设置后切换语言：

到这里，LM Studio基础环境准备完成。

下一步开始下载模型。

12 搜索Qwen3.8

进入模型搜索页面，输入：

Qwen3.8

列表：

这里会看到不同参数量和不同量化版本。

选模型时，LM Studio给出的硬件占用提示很重要。

13 27B和9B怎么选

这次实际准备了两条路线。

能力优先：27B Q4

适合显存更充足的机器。

速度优先：9B Q8_0

适合希望降低显存压力、提高响应速度的环境。

选择页面：

量化级别越低，通常体积和资源占用越小；量化越高，对硬件要求也会更高。

最终还是以自己机器能稳定运行的版本为准。

14 第一组实测：RTX 5060 Ti 16GB跑27B

模型加载以后直接对话。

在这次RTX 5060 Ti 16GB环境里，27B Q4实测大约：

3---4 token/s

页面：

这个速度可以完成对话，但如果一次生成很长的内容，等待感会比较明显。

15 多卡环境下27B速度明显提高

换到多卡机器以后，同一个27B模型速度明显上升。

实测页面：

这次多卡环境达到：

40+ token/s

同一个模型在不同硬件上的体验差异非常直接。

所以本地模型部署很难脱离硬件单独谈"快不快"。

16 第二组实测：图片理解

把图片直接放进聊天框：

这次截图、图片都可以直接用于分析。

对于开发和办公场景，我更看重这类能力能不能处理：

报错截图；
页面截图；
表格；
图片文字；
界面结构。

17 第三组实测：27B生成登录页

我先让27B生成一个完整登录页面。

结果：

页面中包含较多交互细节。

这类测试更容易看出大模型在连续代码输出上的完整度。

18 再换9B做同类任务

9B版本继续生成类似页面：

相比27B，细节丰富度有所不同，但日常前端辅助仍然可以使用。

如果主要追求响应速度，9B会更轻松。

19 再把任务提高到完整FPS单页

继续让27B生成Three.js第一人称FPS单HTML。

结果：

测试要求里包含：

WASD移动；
跳跃；
枪械逻辑；
后坐力；
敌人AI；
HUD；
场景元素。

这里主要验证的是长代码连续输出能力。

20 开启LM Studio本地API

本地聊天跑通以后，进入：

开发者 / Server Settings

默认端口可以使用1234。

这次为了后面配置，示例改成：

12345

页面：

21 启动LM Studio服务

从任务栏启动服务：

看到服务正常运行以后，下一步用Cherry Studio接入。

22 Cherry Studio连接本机模型

打开Cherry Studio。

添加服务商，选择OpenAI兼容类型。

API地址填写：

http://localhost:12345

初次本地测试时，API密钥使用示例值：

1

配置页面：

保存以后获取模型列表。

23 本地API调用成功

选择已经下载好的Qwen模型，发送消息测试。

结果：

如果能够正常回答，就说明：

Cherry Studio → localhost:12345 → LM Studio → Qwen3.8

已经跑通。

这一步之后，家里的模型才真正具备被第三方客户端调用的基础。

24 本地能调用，出门以后还不够

当前这套API仍然只在本机或局域网环境里使用。

离开家里的网络以后，就会遇到新的问题：

真正缺的不是模型能力，而是：

外部设备如何访问家里电脑上的12345端口。

25 远程调用的思路很简单

家里的电脑负责：

加载模型；
占用GPU；
完成推理。

外面的轻薄本、手机或其他客户端负责：

发请求；
接收结果。

也就是把高性能机器留在家里，把算力通过API提供给自己的其他设备使用。

示意：

26 Windows安装cpolar

先安装Windows版cpolar：

安装完成以后，在浏览器访问：

http://localhost:9200

进入本地Web UI：

后面的隧道都从这里配置。

27 创建LM Studio API隧道

进入创建隧道页面。

本地地址填写：

12345

隧道名称可以使用：

LM-Studio

临时测试可以先用随机域名。

配置页面：

28 长期使用再保留固定二级子域名

如果只是确认链路，随机地址已经够用。

如果准备长期从外面调用，再去预留固定二级子域名。

页面：

保留完成后，把固定子域名填回隧道配置。

29 查看LM Studio公网地址

创建完成以后进入在线隧道列表：

这时已经可以看到LM Studio API对应的公网地址。

30 Cherry Studio切换为公网地址

回到Cherry Studio。

把原来的：

http://localhost:12345

替换成cpolar生成的公网地址。

重新获取模型列表：

如果能够正常读取模型，说明：

外部设备 → 公网地址 → 家里电脑12345 → LM Studio

已经打通。

31 公网能访问以后，必须补API鉴权

远程链路跑通以后，不能停在"能访问"。

如果12345接口没有鉴权，别人拿到地址以后也可能调用模型，占用家里的GPU资源。

所以接下来开启：

Require Authentication

页面：

打开以后，所有API请求都需要携带Token。

32 创建LM Studio Token

进入：

Manage Tokens

创建新Token。

名称示例：

cherrystudio

MCP权限保持：

Deny

页面：

33 Token生成以后立刻保存

生成页面：

完整Token只显示一次，所以需要当场保存。

长期使用时也不要把Token：

发到群聊；
放到公开仓库；
截图公开；
写进对外分享的配置文件。

34 Cherry Studio改用真实Token

回到Cherry Studio，把之前的测试密钥替换成刚刚生成的Token。

配置页面：

可以做一个简单验证：

清空API密钥；
获取模型列表失败；
填入正确Token；
模型列表恢复正常。

这样才能确认：

没有凭证的请求确实被拦截。

35 最终远程调用链跑通

最终状态：

整条链现在变成：

外部Cherry Studio

↓

cpolar公网地址

↓

LM Studio API

↓

Token鉴权

↓

Qwen3.8

↓

家里GPU完成推理

36 本地部署不等于"绝对隐私"

这套方案的核心优势，是模型推理运行在自己的电脑上。

在不额外接入云端模型服务的前提下，很多资料可以直接交给本地模型处理，不必为了推理本身上传给第三方云模型。

但长期使用仍然要看整条数据路径：

Cherry Studio是否启用其他云服务；
插件是否访问外部接口；
MCP是否联网；
公网API是否有鉴权；
Token是否妥善保存。

所以更准确的说法是：

本地部署让数据路径更可控，而不是自动等于绝对安全。

37 27B和9B应该怎么选

这次实测以后，选择逻辑反而更清楚。

如果更重视：

复杂代码；
输出完整度；
更高模型能力；

优先考虑27B。

如果更重视：

响应速度；
显存占用；
日常聊天；
普通开发辅助；

9B会更轻松。

真正适合自己的模型，是能力、速度和硬件之间的平衡。

38 这套方案更适合哪些人

比较适合：

家里有性能不错的台式机；
外出只带轻薄本；
经常使用Cherry Studio；
想减少对云端模型额度的依赖；
有些资料不方便交给云端模型处理；
想把家里的GPU长期作为个人AI节点。

前提是家里的电脑、LM Studio和网络入口需要保持运行。

39 最后把完整技术链重新看一遍

模型：

Qwen3.8-27B / 9B

运行：

Windows → LM Studio

本地聊天：

LM Studio → Qwen3.8

API：

localhost:12345 → OpenAI兼容接口

本地客户端：

Cherry Studio → localhost:12345

远程：

Cherry Studio → cpolar公网地址 → 12345

鉴权：

Require Authentication → Token

实际完成：

LM Studio安装；
Qwen3.8下载；
27B和9B实测；
对话；
图片理解；
代码生成；
OpenAI兼容API；
Cherry Studio本地接入；
cpolar公网入口；
固定二级子域名；
LM Studio Token鉴权；
Cherry Studio远程调用。

这样家里的高性能电脑才真正从"本地跑模型"变成一台可以被自己远程调用的个人AI节点。

总结

这次真正跑通的是一条完整的本地大模型使用链：先在Windows上通过LM Studio加载Qwen3.8，实际测试27B和9B在聊天、图片理解和代码生成上的表现，再根据显存和速度选择更适合自己的模型体量。

比本地聊天更重要的一步，是把LM Studio的OpenAI兼容API打开。Cherry Studio能够通过localhost:12345获取模型并正常对话以后，这台电脑就不再只是一个"聊天窗口"，而是具备了被其他客户端调用的能力。

远程部分则把这条API继续延伸到局域网之外。cpolar负责提供网络入口，LM Studio的Token鉴权负责拦住没有凭证的请求，两层职责应该分开理解。

如果家里本身就有一台高性能台式机，这种方式可以把GPU算力长期留在家里，让外面的轻薄本、手机或其他设备只负责发请求和看结果。真正值得长期保留的，不只是某一个模型，而是"本地推理 + 标准API + 远程访问 + 鉴权"这一整套使用方式。