DSH+Ollama本地部署大模型实战：免费对话大肥鱼

为什么要在本地跑大模型？

用云端 API 和大模型对话固然方便，但 token 消耗是实打实的成本。B 站 UP 主「尾巴长」在视频里提到，他折腾本地部署的初衷很简单：和大肥鱼聊天时想少花点 token，于是尝试把对话请求转到本地模型上。这个需求其实很普遍——隐私敏感、高频调用、离线场景，都指向同一个方向：把模型搬到自己的机器上。

不过本地部署并不是「下载完就能用」那么简单。UP 主实测了多个模型，既有能顺利跑通的，也有因为显存不足而卡住的。这篇文章结合他的操作录屏，把整个流程和踩过的坑梳理一遍，重点放在「怎么装、怎么配、怎么选模型」上。

实测：不同模型在 8G 显存笔记本上的表现

UP 主的硬件是 RTX 4060 笔记本显卡，8G 显存。这个配置在消费级里算中端，跑小参数模型没问题，但遇到大模型就吃力。他测试的模型包括千问 3.5 系列（2B、4B、8B 等规格）、DeepSeek^广告 系列，以及从魔搭（ModelScope）下载的开源模型。

从录屏能看出明显差异：千问 3.5 2B 拿到一个表情输入后，只输出了思考过程，没有给出实际回应；千问 3.5 4B 则好很多，能调用工具、图文并茂地回复，体验接近可用状态。而参数更大的千问 3.5 8B 虽然回复质量更好，但在 8G 显存上运行时间明显拉长，UP 主的原话是「用时很久才能进行回复」。

Gemma 4 12B 也能出结果，但速度比千问 3.5 4B 更慢。UP 主的建议很直接：如果不那么追求速度，千问 3.5 4B 是平衡性不错的选择；具体选哪个，看自己显卡大小来定。至于 DeepSeek 的 API 方案，响应只要两秒左右，如果对本地部署没有执念，直接调 API 反而更省心。

这个对比其实揭示了一个现实：本地部署的核心矛盾是「模型能力」和「硬件上限」的拉扯。参数越大越聪明，但显存和算力跟不上，等待时间就会消磨掉使用意愿。

显存与模型参数的关系：大模型的权重需要全部或部分加载到显存中才能推理，参数越多，占用的显存越大。粗略估算，FP16 精度下每 10 亿参数约需 2GB 显存，而通过量化（如 4-bit）可压缩到约 0.5-1GB/10 亿参数。8G 显存实际可用约 6-7G，因此 4B 模型在 4-bit 量化下能流畅运行，8B 模型则接近上限，需要部分卸载到内存，导致速度骤降。文章里 8B 模型“用时很久”正是显存不足触发内存交换的典型表现。

Ollama 安装：绕开慢速下载的坑

UP 主用的是 Ollama 做本地模型服务。它的好处是配置简单、模型库丰富，装完之后在聊天界面就能直接拉取模型。

安装过程中唯一需要留意的是下载速度。Ollama 官网的安装包走外网，UP 主实测可能要一个小时左右，取决于网络状况。他的解决办法是复制下载链接，丢进迅雷里下，一分钟左右就能完成。安装本身是一路「下一步」，没有复杂选项。

装完后进设置，默认模型存储路径在 C 盘。如果 C 盘空间紧张，可以在设置里改到其他盘——这一步建议在下载模型之前就改好，避免后期迁移。

在 Ollama 里拉取和运行模型

进入聊天界面后，Ollama 提供了不少模型可以直接下载，千问 3.5 4B、Gemma 4 2B、千问 3.5 8B、千问 3.5 2B 都在列表里。操作方式很轻量：输入模型名，选中对应条目就能开始下载，不用额外配置。

如果内置列表不够用，可以去魔搭（ModelScope）找开源模型。UP 主以 DeepSeek 为例演示了流程：进入模型文件页面，注意选择框架时优先选 GGUF 格式，然后下载模型文件，另存到本地模型目录。

关键一步是创建 Modelfile。UP 主强调要在当前路径下新建一个 txt 文件，命名为 Modelfile，内容按官方给的模板写。保存时要注意去掉 .txt 后缀——他的做法是另存为时删掉后缀、加个空格保存，确保文件名就是 Modelfile 而不是 Modelfile.txt。

文件就位后，在文件路径栏输入 cmd 回车打开命令行，按顺序执行命令，把模型导入 Ollama 能读取的格式。UP 主现场重新演示了一遍：空格、模型文件名、再空格、粘贴路径，执行完模型就被 Ollama 接管了。

GGUF 格式是什么：GGUF 是 llama.cpp 项目推出的模型文件格式，专门为在消费级硬件上高效推理而设计。它把模型权重、分词器配置和量化信息打包在一个二进制文件里，支持 2-bit 到 8-bit 等多种量化级别，能在 CPU 或 GPU 上直接加载，无需额外的转换步骤。Ollama 底层正是基于 llama.cpp，因此原生支持 GGUF。从魔搭下载模型时优先选 GGUF，意味着文件可以直接被 Ollama 读取，省去格式转换的麻烦。

接入 DSH：自定义模型与 API 地址配置

模型跑起来之后，最后一步是让 DSH（DeepSig Highlights）能调用它。进入 DSH 设置，找到模型配置，选择「自定义模型」，输入一个自定义名称，API 地址填 Ollama 的本地服务地址。

这里有个容易忽略的细节：地址后面必须带上 /v1 路径，这是 Ollama 兼容 OpenAI 接口的约定。填好后点「获取可用模型」，之前下载的模型就会列出来，选中并添加即可。

添加供应商 ID 时，UP 主提醒 ID 要以小写字母开头。之后在「更多」里可以调整输入类型等参数，其余配置和默认模型基本一致。完成这些，DSH 就能把对话请求转发到本地 Ollama，实现免费对话。

Modelfile 与 /v1 接口约定：Modelfile 是 Ollama 用来定义模型运行参数的配置文件，类似 Dockerfile，里面可以指定基础模型路径、对话模板、温度等参数。导入自定义模型时，Ollama 会读取 Modelfile 并生成内部模型条目。而 /v1 路径来源于 OpenAI 的 API 规范——/v1/chat/completions 等端点。Ollama 为了兼容大量现成工具，在本地服务端口（默认 11434）上模拟了这套接口，所以任何支持 OpenAI API 的客户端（包括 DSH）只要把地址指向 http://localhost:11434/v1 就能直接调用本地模型，无需额外适配。

本地部署还是调 API？

把整个流程走下来，能看出本地部署的门槛主要在两头：一是下载和安装的耐心，二是硬件能不能撑住模型。Ollama 已经把操作简化到「选模型、点下载、填地址」的程度，真正的瓶颈在显存。

UP 主自己的结论也偏向务实：如果觉得本地跑一分钟还是太久，不如花点钱走 DeepSeek API，响应两秒左右，成本并不高。本地部署适合那些对隐私、离线、零调用成本有明确需求的人；如果只是偶尔对话，云端方案的综合体验反而更好。

对于手里有 8G 显存显卡的用户，千问 3.5 4B 是当前比较稳妥的起点。想再往上探，就得接受等待时间变长，或者考虑升级硬件。