这两年AI工具铺天盖地但越是依赖云端我越觉得自己被拴着。直到有一次在客户现场做项目办公区走的是内网隔离外网全断云端AI全部哑火而我手上恰好有一批不能外传的项目资料需要快速检索整理。所以我折腾起了DODESK 本地助手 本地大模型这套组合目标就八个字数据不出门断网也能用。这篇把完整链路写下来从为什么选这套方案、怎么搭底层的 Ollama Llama 3到 DODESK 如何对接、断网实测体验如何再到后续优化方向适合有隐私要求的个人用户、中小企业 IT以及被内网环境逼过的人参考。1. 一场内网事故把云端依赖打回原形1.1 那天的真实场景所有在线AI集体失联那次是在一家做智能制造的客户厂区里办公网络是独立隔离开的厂区内部系统、产线数据全部走内网外部访问基本受限。我带笔记本连上内网 Wi-Fi 后浏览器打不开常用网页在线翻译、云端文档、在线 AI 全部连不上。临时有一个批量合同条款比对整理的任务几百页 PDF靠人工翻显然来不及。我当时的第一个念头是忍一忍回酒店再处理但客户要当天出结果。那半小时我试过的路数今天回想起来很有代表性先试手机开热点结果厂区信号像进了铁皮盒子聊胜于无再找同事电脑看有没有外网权限一样没有。最后是客户 IT 提醒了一句你们搞 AI 的不能直接在本地跑一个吗 这句话直接点醒了我的方向。1.2 数据分级意识不是所有材料都能扔给云端那批合同里既有价格条款又有供应商信息属于典型的商务敏感材料。平时在家里用云端 AI 写周报、吹水没问题但工作场合的数据尤其是涉及第三方商务条款的我给自己定了三条红线含身份信息、联系方式、银行账号等个人信息的内容不上云未公开的商务合同、报价单、技术文档不上云客户要求留在内网环境里的数据一律本地处理。这三条红线列出来后云端方案基本被排除了。剩下来的问题变成能不能在笔记本上用本地大模型跑出一个足够好用的 AI 问答和文档处理环境这个环境还要能长期维护、成本可控而不是演示完就扔。1.3 数据不出门不是洁癖是可用性兜底做这个项目之后我才想明白数据不出门这个概念表面看是保密要求底层其实是可用性要求。断网并不是极端场景内网隔离、出差、地下室、高铁隧道、偏远现场这些都随时可能让一台性能很好的笔记本变成信息孤岛。如果你的 AI 能力百分之百寄存在云端你的生产力就等于被一根网线掐着。本地化方案的真正价值在于在任何环境下都保持可用。这个兜底的意义比单纯省 API 费用重要得多。那天回到酒店后我立刻盘了一下手头机器一台 Windows 11 笔记本32GB 内存8GB 显存的 RTX 3070。跑 7B-8B 量级模型问题不大于是正式把本地 AI 化提上日程。2. DODESK 本地助手到底是什么它解决的痛点比想象中具体2.1 它不是又一个套壳网页版而是本地 AI 工作台DODESK 这个名字圈内做本地化 AI 的人应该不陌生了。简单说它是一个桌面优先的本地 AI 助手工具数据和配置都留在你自己的机器上模型接进来的是本地推理服务。和网页版 AI、云端 API 的本质区别在于整个数据链路都在本机闭环。你导入的文档、你提出的问题、模型生成的回答全程不经过第三方服务器。我见过一些人以为 DODESK 不过就是又一个聊天界面这其实低估了它。它更像一个本地 AI 工作台左侧是知识库空间右侧是对话窗口上方有模型切换下方有文档上传入口。关键的是它把喂文档、建索引、问答、引用溯源这些整合成了一个连贯流程而不是让你用脚本一步步拼。2.2 核心功能拆解知识库问答、文档处理、多轮对话我实际使用中DODESK 给我帮助最大的几个功能点本地知识库问答把 PDF、Word、TXT 批量导进去它会自动切分、向量化、建索引。之后你可以直接问这份技术手册里设备报警代码 E102 是什么意思回答会关联到具体来源段落。长文档处理上千页的 PDF 也能做摘要、关键词提取、条款比对。这一点在合同场景特别有用我后面详测。多轮对话不是一问一答就完事而是能带上下文持续聊。上下文窗口由背后接的模型决定DODESK 提供参数入口。混合检索普通关键词搜不到的内容可以靠语义检索兜底比如搜哪个供应商对付款周期有异议它能跨文档找出相关段落。全本地存储所有索引、向量库、对话记录都存在指定本地目录你不用猜数据去了哪里。2.3 和 Dify、FastGPT 这类平台的选型对比在搭这套之前我也考虑过更重的方案比如 Dify、FastGPT 这类知识库平台。这类平台本身没问题但对我的场景来说有点杀鸡用牛刀。对比维度Dify / FastGPTDODESK 这类桌面助手部署方式通常需要 Docker、服务端、数据库桌面应用装完即用适合规模团队协作、多用户、复杂工作流个人或小团队单机使用数据处理链路可通过服务端配置到底但上手成本高默认全本地路径直观模型接入支持 Ollama 等本地模型支持 Ollama、LM Studio 等本地模型使用成本维护成本偏高基本零维护成本我的结论很直接如果你的场景是个人生产力、单机知识库、内网隔离环境DODESK 这类轻量桌面工具比搭一套 Dify 舒服太多如果团队多人协作、要做审批流、要对外提供服务那再上 Dify 或 FastGPT 不迟。3. 本地大模型底座Ollama Llama 3 从零搭起来3.1 硬件门槛先想清楚显卡和内存本地大模型部署绕不开硬件。很多人上来就问什么配置能跑我的回答是先看显存再看内存最后看 CPU。显存决定你能塞下多大的模型内存决定你在推理时会不会局促。我按实际体验给一个参考梯度硬件水平可运行模型体验描述16GB 内存 无独显3B~7B 量化模型CPU 推理能用速度较慢适合轻量问答16GB 内存 6~8GB 显存7B~8B 量化模型速度可接受单问答 5~15 秒32GB 内存 12GB 以上显存14B~32B 量化模型体验明显提升多轮对话顺畅我自己的 RTX 3070 8GB 版本属于中间档跑 Llama 3 8B 量化非常舒服。如果你的机器只有 CPU也能跑但强烈建议选小参数模型别跟自己过不去。3.2 Windows 11 下安装 Ollama 并拉取 Llama 3Ollama 是目前本地跑大模型最顺手的工具之一把模型下载、运行、API 暴露都封装好了。Windows 11 下装它基本没有门槛。第一步去 ollama.com 下载 Windows 安装包一路下一步装完。装好后打开终端验证一下ollama --version看到版本号就说明主程序没问题。第二步拉取 Llama 3 模型。这里注意一下Ollama 上的模型名带有标签默认 latest 往往跟随最新版本我建议明确指定版本可控性更强# 拉取官方 Llama 3 8B 指令版 ollama pull llama3 # 也可以拉指定量化格式常常比默认精简版更稳 ollama pull llama3:8b-instruct-q5_K_M网络正常的情况下8B 量化模型大概 4~5GB 下载量看带宽等几分钟到几十分钟。第三步先跑起来试试ollama run llama3它会进入交互式对话界面随便问一句你好简单介绍下你自己只要模型正常加载到显存并开始回答底座就算通了。退出对话用/bye。3.3 验证模型可用命令行对话只是开始命令行能对话只说明模型本身可用。DODESK 要接的不是终端而是 HTTP API。Ollama 默认在本地 11434 端口提供 API其中还兼容了一部分 OpenAI 接口风格这对 DODESK 对接是很有价值的。用 curl 看下模型列表curl http://localhost:11434/v1/models能返回 JSON 列表就说明 API 服务正常。再测一个真实的对话请求curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: llama3, messages: [{role: user, content: 用一句话解释什么是 RAG}], stream: false }返回内容包含choices字段就说明 OpenAI 兼容端点也通了。这一步是 DODESK 对接的关键前提。4. DODESK 对接本地大模型配置细节与踩坑记录4.1 模型接入配置OpenAI 兼容接口是关键打开 DODESK 的设置找到模型配置入口。基本逻辑是给它填一个符合 OpenAI 风格的服务地址和模型名。Ollama 的 OpenAI 兼容端点地址是http://localhost:11434/v1。我用的配置参考{ api_base_url: http://localhost:11434/v1, model_name: llama3, api_key: ollama, temperature: 0.3, max_tokens: 2048 }注意到api_key这里Ollama 本身不校验 key但 DODESK 的接口调用逻辑往往会校验非空所以填一个任意字符串即可比如ollama。填好后先做一次连通测试DODESK 一般会有一个测试按钮也可以直接在对话窗口发一句话验证。如果提示连接失败按 4.3 的排查思路走。4.2 关键参数调优上下文、温度、超时、并发模型接进去能跑只是第一步参数不调好体验天差地别。我调得最频繁的四个参数上下文窗口num_ctxOllama 默认 2048对长文档问答不够用。在 DODESK 里如果你发现聊到一半模型失忆前后回答对不上多半是上下文被截断了。我调到 8192长文档场景调到 16384 也可以但显存占用会上升需注意。温度temperature问答、条款提取、事实型任务设 0.2~0.4避免模型自由发挥头脑风暴、写提纲这种创意任务可以到 0.7~0.8。请求超时本地模型首次加载有几秒到几十秒的延迟尤其冷启动。DODESK 里的超时时间建议设 90~120 秒不然工具会先报请求超时实际模型还在慢慢加载。并发数8GB 显存跑 8B 模型推理时显存基本占满并发超过 1 就可能 OOM 或者排队严重。DODESK 的并发设置我锁在 1宁可慢慢出结果也别把整个机器搞崩。4.3 几个典型坑端口占用、首次加载、上下文截断这套配置我前前后后踩过不少坑挑三个最典型的端口占用。Ollama 默认监听 11434但有些机器上这个端口可能被其他软件占了。启动报错时先确认端口netstat -ano | findstr 11434如果是别的进程占用可以改 Ollama 的监听地址比如 Windows 上设置环境变量OLLAMA_HOST127.0.0.1:11435再修改 DODESK 里的api_base_url保持一致即可。首次加载慢得心惊。第一次用 DODESK 发问我等了将近一分钟都没反应一度以为崩了。后来才发现模型要从磁盘加载到显存首次加载慢是正常的。解决办法就是前面说的把超时时间调长别急着杀进程。加载完之后后续问答就快多了。上下文截断导致失忆。有一回我在 DODESK 里传了一篇 40 多页的项目章程连着追问几个细节后模型开始答非所问。排查日志发现问题是默认上下文窗口太小前面的内容被挤出去了。用ollama run时可以在对话前设置参数/set parameter num_ctx 16384DODESK 层面如果暴露了上下文参数直接填更大值就行。这一步对长文档场景几乎是必须的。5. 断网实测从知识库问答到文档处理的完整验证5.1 测试环境与测试方法模型对接完成之后最重要的一步是断网实测。我当时的验证方法非常物理拔掉网线、关闭所有网络连接连系统通知栏里都看不到 Wi-Fi 图标。测试用的数据是三份合同 PDF、一份 60 页的技术手册、一份项目会议纪要导入 DODESK 建立知识库。整个测试过程里我确认了一下没有任何请求发到外网——本机防火墙配合任务管理器的网络占用曲线都看不到像样的流量。5.2 知识库问答实测我准备了几个有代表性的问题直接看效果这批合同的付款周期分布是怎么样的 模型准确列出了不同合同的天数差异并引用了对应文档页码。技术手册里提到设备在什么温度下会触发告警 回答给出了具体数值和前置条件来源指向手册第四章。会议纪要里遗留的待办事项有哪些 模型梳理出五条其中两条是我人工翻校对后才注意到的细节。整体感受是8B 模型做基于文档的事实型问答完全够用。前提是文档要先切好、索引建好且问题不能绕太远。对明确范围的信息检索它表现得很稳。5.3 本地模型的短板我也如实说客观讲断网实测也暴露了不少短板。复杂推理上本地 8B 模型和云端顶级模型有明显差距。比如让它从三份合同里找出一组不合理的价格条款并解释原因它的分析深度不够只能罗列表面差异给不出有说服力的推演。中文表达偶有瑕疵个别句子有点机翻感。但当问的是事实型内容时这个缺点不明显。还有一点多步指令容易断比如先提取所有合同编号再按合同编号排序然后输出成表格这种复合任务它经常做到一半就走偏。不过这些短板对断网可用这件事没有本质影响。我需要的不是它全能而是它能在我没有任何网络的情况下帮我处理原本必须人工翻完的文档。从这个角度看它达标了。6. 进阶优化模型升级、量化选型与日常调优6.1 从 Llama 3 到更合适的模型Llama 3 是很好的起步模型但它未必是中文场景的最优解。实际用了一段时间后我换成了更适合中文文档处理的模型组合综合问答、通用助理Qwen2.5 7B/14B中文理解比 Llama 3 更顺跑起来也稳。中文长文档摘要、条款提取Qwen2.5-14B-Instruct上下文长处理长文更从容。逻辑推理向DeepSeek-R1-Distill-Qwen-7B做条款推理、多步分析比普通指令模型强一截。企业内网归档检索也可以试试 glm4 系列中文检索和归纳表现不错。拉取方式都一样ollama pull qwen2.5:7b ollama pull qwen2.5:14b ollama pull deepseek-r1:7bDODESK 里面切换模型名称就行。想换模型的时候别忘了先ollama list看当前有哪些可用模型别填错名字。6.2 量化版本怎么选Ollama 上同一个模型常有多个量化标签很多人不知道怎么选。我说下我的经验量化格式相对体积效果适用场景q4_K_M小可用显存紧张时首选q5_K_M中等较好我的日常首选平衡体积和效果q8_0较大接近原版显存足够时用效果最接近 fp16以 8B 模型为例q4 大概 4.7GBq8 大概 7.6GB。8GB 显存跑 q5_K_M 比较舒服显存再大点直接上 q8。不要盲目追原版精度推理速度和显存余量往往比那几个点的精度差异更重要。6.3 知识库构建与日常维护知识库不是导入完就完事构建质量直接决定问答效果。我整理了几条实操原则扫描版 PDF 先 OCR。直接用 PDF 文本提取会得到一堆乱码问答自然全错。先过一遍 OCR 再导入效果天差地别。文档分块合理。500~1000 字一块、块间重叠 100~200 字这是我试下来比较稳的区间。块太大会稀释语义块太小则检索时丢上下文。定期重建索引。本地文档经常更新的话DODESK 里的索引可能不同步。建议每次批量更新文档后重新建立索引避免旧数据干扰结果。控制单库规模。我个人的习惯是一个知识库对应一个项目或一个主题别把所有文档塞进一个库检索准确率会更高。日常运维上Windows 下建议在任务计划程序里加一个开机自启项指向 Ollama。否则你每次要用之前都得手动ollama run或ollama serve。清理不用的模型用ollama rm 模型名能省不少磁盘空间。最后说点个人体会。折腾 DODESK 加本地大模型这套组合最大的感受不是替代云端 AI而是把选择权拿回自己手里。云端模型快、聪明、全面这是事实但只要有断网、有保密要求、有无限量使用需求本地这套就是不可替代的兜底方案。我现在的习惯已经固定下来日常写作和头脑风暴用云端合同处理、内部资料问答、出差在外的一切需求全部交给本地。两者互补日子好过很多。如果你也想搭一套数据不出门的 AI 环境建议从一台带有 8GB 以上显存的机器开始按这篇的顺序走一遍一个晚上基本就能跑通。