Excel格式设置后不生效？揭秘双击才生效的底层原理与批量处理方案
2026/9/26 14:56:47
把DeepSeek跑在自己的Windows电脑上，听起来像是一件需要啃不少文档的事情，但实际操作下来，整个链路的复杂度比大多数人想象中低一个数量级。Ollama把模型下载、依赖管理和本地服务打包成了两个命令，UI可视化层有Chatbox、Open WebUI这类现成工具，个人知识库则靠RAG（检索增强生成）的思路在半小时内搭起来。这篇文章是我在Windows 10/11上完整走一遍的实录，包含Ollama下载安装、DeepSeek本地部署、界面可视化和知识库搭建四个环节，每个步骤都标注了会踩的坑和我的解决办法。
1. 本地大模型的复利：为什么这套组合值得搭
1.1 本地部署解决了什么
先聊一个很多人没想清楚的问题：官网上的DeepSeek用得好好的，为什么要费劲在本地装一套？
最直接的原因是数据不出本机。你把文档、聊天记录、私有资料喂给网页版，等于默认同意这些内容经过第三方服务器；本地部署后，模型推理全部发生在自己这台Windows电脑上，断网也能用。对于经常处理合同、论文初稿、项目纪要的人来说，这一步的意义不只是省流量，而是把“隐私边界”重新拿回自己手里。
另一个原因是摆脱限流和排队。网页端在高峰期经常出现“服务器繁忙”，而本地部署没有并发限制，你想连续问多少轮就问多少轮。加上本地模型是恒定可用的，哪怕办公室断网、出差在高铁上，模型仍然能跑。对我来说，这种“随时可用的私有计算资源”才是本地部署最大的价值。
1.2 这套方案适合哪些人
- 内容创作者：写稿、改写、润色，不用把未经发布的草稿粘贴到公网服务里。
- 程序员：把代码片段和报错日志丢给本地模型，不需要担心代码外泄。
- 研究者/学生：处理文献PDF、课堂笔记、论文资料，搭建个人知识库后检索效率成倍提升。
- 单纯想玩模型的人：Windows电脑上双击安装包就能跑，门槛已经低到不需要会Linux。
整个技术栈的分工也很清晰：Ollama负责模型的下载、启动和本地服务暴露，DeepSeek系列模型负责实际问答，UI工具把命令行变成了图形聊天窗口，知识库工具则把“聊天”升级成“基于你的文档聊天”。接下来按这个链路逐步实操。
2. Windows环境下的Ollama下载安装：从官网到环境变量
2.1 下载安装包与安装细节
去Ollama官网找到Windows版本下载入口，拿到的就是一个.exe安装包。Ollama的Windows安装包体积不大，国内网络通常也能顺利拉下来，真正慢的往往是后面下载模型那一步，这里先不展开。
双击安装包，下一步下一步就行。需要注意一点：默认安装路径是当前用户目录下的AppData\Local\Programs\Ollama，如果你不想在C盘塞系统工具，可以在安装向导里改路径。但比安装路径更重要的，是模型文件的存储位置，这个必须提前规划好。
安装完成后，系统托盘区会出现一个羊驼图标，说明Ollama已经在后台以服务方式运行。打开一个终端（PowerShell或CMD都行），输入：
ollama --version能正常输出版本号，安装环节就通过了。我遇到过不少朋友卡在这一步，多半是安装后没有重开终端，命令没刷新进PATH，重开一个窗口即可。
2.2 模型存储路径规划：最容易被忽略的一步
Ollama默认会把所有模型文件塞进C:\Users\你的用户名\.ollama\models。听着没什么，但模型文件动辄几个GB起步，7B量化模型约4.7GB，32B量化模型约20GB，全装在C盘会把系统盘塞到冒烟。
强烈建议在安装完成后立刻修改模型目录，方法是通过环境变量OLLAMA_MODELS指定新路径。
在Windows上这样操作：
- 按
Win + S，搜索“编辑系统环境变量”并打开。 - 点击“环境变量”，在用户变量区新建一个变量。
- 变量名填
OLLAMA_MODELS，变量值填你想要的位置，比如D:\ollama_models。 - 确认保存，完全退出Ollama托盘程序再重新打开（重启进程才会加载新环境变量）。
改完之后拉取模型，模型文件就会落到D盘。我见过有人模型已经下了20GB才发现路径不对，最后只能把整个.ollama目录挪走，虽然可行但白白浪费一晚上下载时间。路径环境变量这个坑，提前排掉最划算。
2.3 安装后的核心配置与环境变量
除了OLLAMA_MODELS，还有几个环境变量在实际使用中命中率很高：
OLLAMA_HOST：默认是127.0.0.1:11434，只允许本机访问。如果想让局域网里其他设备（手机、另一台电脑）也能连你的模型，就改成0.0.0.0:11434。涉及局域网开放，注意安全范围。OLLAMA_NUM_PARALLEL：控制同时处理几个请求，默认1。对多用户场景有效，单机自己玩不用动。OLLAMA_MAX_LOADED_MODELS：控制最多同时加载几个模型到内存，默认1。如果内存够且经常切换模型，可以适当调高。
设置方式跟OLLAMA_MODELS完全一样。配置完成后，浏览器打开http://localhost:11434，如果能看到Ollama is running字样，说明服务正常。
3. 拉取DeepSeek模型：命令行里的几个关键细节
3.1 模型尺寸怎么选
Ollama官方仓库里的DeepSeek模型主要是deepseek-r1系列，标签后缀对应不同参数规模。选择标准不是“越大越好”，而是“你的内存和显存扛得住哪个”。
| 模型标签 | 参数规模 | 磁盘占用（约） | 内存/显存参考 |
|---|---|---|---|
| deepseek-r1:1.5b | 1.5B | 1.1GB | 4GB可跑，速度尚可 |
| deepseek-r1:7b | 7B | 4.7GB | 8~16GB，最推荐入门 |
| deepseek-r1:14b | 14B | 9GB | 16~32GB，质量明显提升 |
| deepseek-r1:32b | 32B | 20GB | 32GB以上，建议8GB+显存 |
| deepseek-r1:70b | 70B | 43GB | 48GB以上，纯CPU会很吃力 |
第一次部署，我的建议是从deepseek-r1:7b开始。这个尺寸在普通16GB内存的Windows笔记本上可以靠CPU推理流畅跑，生成速度虽然比网页版慢，但作为本地私有服务完全可用。等整个链路跑通，再评估要不要换14B或32B。
3.2 模型下载慢：手动导入GGUF文件
执行拉取命令很简单：
ollama run deepseek-r1:7b但很多国内用户在第一步就翻车——模型文件默认从境外的模型仓库拉取，网络状况不好的时候进度条能卡在几个文件上几个小时。这时候不必硬等，有一个绕开网络瓶颈的方案：从国内模型托管平台（比如魔搭社区的DeepSeek页面）下载GGUF格式的模型文件，再手动导入Ollama。
操作流程：
- 把下载好的
.gguf文件放在一个固定目录，比如D:\models\。 - 在这个目录里新建一个文本文件，命名为
Modelfile（注意没有后缀名）。 - 在Modelfile里写一行：
FROM ./deepseek-r1-7b-Q4_K_M.gguf./后面的文件名换成你实际下载的GGUF文件名。
- 在同一个目录打开终端，执行：
ollama create deepseek-r1-7b-local -f Modelfile导入完成后，用deepseek-r1-7b-local这个名字启动模型即可：
ollama run deepseek-r1-7b-local这个办法的好处是：模型文件下载走国内平台，速度稳定；GGUF文件可以保存下来备份，以后换电脑、重装系统都不用重新下载。我自己现在所有的Ollama模型都是这么维护的，一劳永逸。
3.3 常用命令与运行观察
把模型跑起来之后，有几个命令值得记一下：
ollama list：列出本机已有的模型和占用空间。ollama ps：查看当前加载在内存里的模型，以及它们占了多少内存/显存。ollama show deepseek-r1:7b：查看模型详情，包括参数数量、上下文长度等。ollama stop deepseek-r1:7b：手动卸载正在运行的模型，释放内存。
在命令行里直接对话时，输入/bye退出。注意一点：ollama run进入交互模式后，模型是常驻内存的，即使退出对话界面，可能还占用着资源，所以ollama ps和ollama stop一定要会，否则换大模型时很容易报显存不足。
4. UI可视化：把黑底命令行变成图形界面
4.1 Chatbox：五分钟连上本地模型
命令行毕竟是程序员熟悉的东西，给非技术背景的人用，还是得有个图形界面。这里我最推荐先试Chatbox，理由只有一个：轻。
Chatbox有Windows桌面版，装好后打开设置，找到AI模型提供方，选择Ollama，在API地址栏填http://localhost:11434，然后在模型列表里选deepseek-r1:7b，完成。
整个过程不需要写任何配置代码。连上之后，平时怎么用网页版聊天就怎么用，支持流式输出、会话历史、多会话管理。Chatbox对Windows用户非常友好，适合作为“第一层可视化入口”。缺点也很明显——它本质上是通用聊天客户端，没有文档库、没有插件体系，只适合对话场景。
4.2 Open WebUI：功能完整的Web控制台
如果想把本地模型做成一个“真正能用”的服务，我推荐Open WebUI。它相当于一个完整的对话前端，支持多用户、文档上传、内置RAG、模型切换、联网搜索等功能，界面风格接近ChatGPT。
Windows下有两种安装方式：
第一种是Docker。装了Docker Desktop后，执行：
docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main等镜像启动后浏览器访问http://localhost:3000即可。
第二种是Python方式。Windows装了Python 3.11+后，执行：
pip install open-webui open-webui serve默认访问http://localhost:8080。这种方式不用装Docker，但需要自己处理Python环境。我个人更推荐Docker方式，因为更新方便、环境隔离、不会把系统Python搞乱。
首次启动后，Open WebUI会自动检查能否访问Ollama。你在设置里把Ollama地址填成http://localhost:11434，模型列表里就能看到本机的DeepSeek了。
4.3 局域网共享与连接故障排查
本地模型搭起来之后，最爽的场景是让手机、平板、办公室另一台电脑都连上来。让局域网设备访问，需要做两件事：
- 把Ollama的
OLLAMA_HOST设为0.0.0.0:11434。 - 在Open WebUI里把Ollama地址改成宿主机在局域网中的IP，比如
http://192.168.1.100:11434。
如果在Open WebUI里显示无法连接Ollama，先按这个顺序排查：
- 本机浏览器能打开
http://localhost:11434吗？不能，说明Ollama没在运行。 - 设置里填的地址带不带
http://？漏了协议头连接不上。 - Windows防火墙是否拦截了11434端口？很多时候系统会弹窗询问是否允许Ollama对外监听，没点允许就会导致局域网设备连不上。
Open WebUI的8080端口如果被占用，启动日志会直接报错，换一个映射端口，比如-p 3001:8080，问题就解决了。
5. 搭建个人知识库：让本地模型回答“你的文档”
5.1 知识库背后的RAG原理
光会聊天没有稀缺性，本地模型真正值钱的地方在于：它能回答“你文档里的问题”。
这背后的技术叫RAG（检索增强生成）。原理可以理解成：你有一堆文档，系统先把它们切分成小段，每一段转化成向量存入向量数据库；你提问时，系统先把你的问题转化成同样的向量，检索出最相关的小段，再把原文片段和问题一起塞给大模型，让模型基于检索到的内容回答。
生活化类比：你让一个刚读完全部藏书的管理员帮你查资料，先问“关于XX有什么记录”，管理员不是凭印象瞎编，而是先去书架上精准抽出来那几本，翻到对应页再念给你听。RAG做的就是这个“先检索、再回答”的过程，核心价值是让答案有依据，而不是让模型凭空生成。
5.2 用AnythingLLM把资料本地化
Windows上最容易上手的知识库工具，我推荐AnythingLLM Desktop。它支持Windows桌面版，内置完整的RAG流程，并且可以对接Ollama，非常适合作为Ollama + DeepSeek的知识库层。
搭建步骤：
- 下载安装AnythingLLM桌面版。
- 打开设置，在LLM（大模型）配置里选择
Ollama，模型选deepseek-r1:7b或你导入的本地模型。 - 在Embedder（嵌入模型）配置里同样选择
Ollama，拉取一个嵌入模型。我习惯用nomic-embed-text，体积小、启动快：
ollama pull nomic-embed-text- 创建一个新的工作区（Workspace），把需要建立索引的PDF、Word、TXT、Markdown文件拖进去。
- 系统会自动对文件进行分段、向量化和入库。完成后，在工作区里提问时勾选“引用工作区文档”，模型就会基于你的文档内容回答。
这里的关键点是：Embedder负责把文本转成向量，LLM负责生成回答，两者都需要配置，且都是本地化的。这意味着你的文档数据从头到尾不出本机，知识库本身也是私有的。
5.3 中文资料的实际调优
中文环境的坑，我帮人搭知识库时遇到不少，总结几个最常见的：
- PDF扫描件必须先OCR。没有文字层的扫描版PDF，RAG索引出来全是乱码或干脆索引不到内容，建议先用OCR工具转成带文字层的PDF再入库。
- 分段长度按内容类型调。AnythingLLM可以设置chunk size，对中文来说，300到600字的分段比较合理。太短会丢失上下文，太长检索命中率低。
- 嵌入模型的差距。
nomic-embed-text能跑，但中文语义理解一般；如果全是中文资料，可以试试bge-m3这类中文优化过的嵌入模型，检索准确率会明显上升。 - 提问方式影响很大。知识库问答不是“随便问都能答”，尽量让问题包含具体实体和限定范围，比如“根据这些技术文档，列出项目部署的前提条件”，比“部署要注意什么”命中率高得多。
如果觉得AnythingLLM不够用，可以再了解Dify和RAGFlow。Dify适合做完整的AI应用编排，RAGFlow对复杂PDF的解析非常强。但我个人建议先从AnythingLLM跑通，它做的是一站式桌面应用，没有服务端部署成本，Windows用户最友好。
6. Windows排障实录：下载慢、端口占用、启动失败
6.1 模型下载卡住的常见场景
现象是ollama run deepseek-r1:7b后进度条半天不动，或者报pulling manifest超时。本质原因是模型文件来自境外服务器，网络波动时就容易卡死。
最简单的处理方式不是反复重试，而是切到GGUF手动导入方案，也就是3.2节里写过的那套流程：国内平台下载GGUF → 写Modelfile →ollama create导入。这条路我在多台机器上实测过，比等进度条可靠得多。
另外一个小技巧：ollama pull中途如果卡住，可以按Ctrl + C取消，然后重新执行ollama pull。Ollama有断点续传机制，已经下载完的分片不会重新拉。这个机制挽回过我不少下载进度。
6.2 端口被占用的排查链路
启动Open WebUI或连接Ollama时，最常碰到的报错是address already in use。比如你想自己手动ollama serve，结果提示11434端口被占用——这通常不是坏事，而是后台已经有Ollama在跑了。
排查命令在CMD里执行：
netstat -ano | findstr 11434输出里会列出占用该端口的进程PID，然后：
tasklist | findstr PID号看一眼是什么程序，确认不是必要服务后，可以：
taskkill /PID PID号 /F但针对Ollama，我建议优先用托盘图标右键退出，而不是直接杀进程。直接杀进程偶尔会导致模型元数据写不完整，下次启动要重新校验。Open WebUI端口冲突同理，换宿主端口或换映射端口即可。
6.3 内存不足与模型切换
本地模型最典型的翻车现场：明明16GB内存，跑14B模型却提示内存不足，或者系统卡到无法操作。原因是Windows下模型加载时不仅占内存，还需要额外开销；如果模型加载到显卡，还要看显存够不够，不够就会回退到CPU，速度断崖式下跌。
解决办法遵循一个原则：先用ollama ps看清楚当前加载模型占用，再用ollama stop释放，最后再切换目标模型。观察方法在任务管理器的“性能”页签看内存/GPU显存，模型参数和你的硬件配置匹配不上，就老老实实换成小一号的模型。
还有一个容易被忽视的点：关了命令行窗口不等于模型卸载。Ollama守护进程会把模型留在内存里，方便下次快速响应。所以长期占用高、卡顿频繁时，先ollama ps再ollama stop，内存立刻就能释放出来。
7. 写在最后：从跑通到用好
我前后帮朋友在Windows机器上搭过十几套这套环境，最大的体会是：不要贪大。第一次部署老老实实选7B，跑通流程后再考虑14B或32B；知识库资料先挑三五个重要文档试，验证准确率高于追求花哨功能。
还有一个容易被忽略的习惯：模型文件下载后第一时间备份GGUF。以后换电脑、重装系统，再把模型导进去就行，不用重新熬下载时间。后续如果想继续玩，可以试试给Open WebUI接多模型路由，比如让DeepSeek负责复杂推理，再用一个小模型跑日常问答；知识库也可以接入自己的博客、笔记软件，让私有数据在更大范围内发挥作用。
这套组合拳的地基打好了，后面加什么模块都只是时间问题。