装好 Ollama 和 Obsidian Copilot 之后，最常见的卡点不是软件没装，而是插件里填了地址却连不上、模型列表是空的、或者能连上但回答一开口就报错。这篇按顺序走一遍：先把本地服务跑通并确认端口，再在插件里选对调用方式和模型名，最后给一份连接失败的排查清单，让笔记库里能直接问自己的资料。
装好 Ollama 和 Obsidian Copilot 之后，最常见的卡点不是软件没装，而是插件里填了地址却连不上、模型列表是空的、或者能连上但回答一开口就报错。这篇按顺序走一遍：先把本地服务跑通并确认端口，再在插件里选对调用方式和模型名，最后给一份连接失败的排查清单，让笔记库里能直接问自己的资料。
顺序很重要。很多人是先在插件里折腾半小时，发现刷不出模型，回头才去看终端，结果是模型压根没下完。反过来走一遍，每一步都能单独验证，出错时也容易定位到底是服务侧还是插件侧的问题。
先把本地 Ollama 服务确认跑起来
这一步的目标只有一个：在不碰 Obsidian 的前提下，证明本地推理链路是通的。做法是在终端里拉一个模型、跑一次对话，能正常出字就算过。如果终端里都跑不顺，插件里再改配置也没意义，后面所有报错都分不清是谁的锅。
- 拉一个模型并跑通对话先在终端完成一次完整的问答，确认本地推理没问题。模型没下完就开始配插件，是最常见的返工原因。
- 确认服务监听地址与端口默认监听本机回环地址即可满足单机使用。如果想让同一台机器以外的设备访问，需要额外改绑定地址，这一步涉及放开网络，先想清楚再动手。
- 记下要用的模型名插件里填的是模型标签而不是文件名，名字写错会表现为列表空白或调用失败。填之前先在终端列一次本地已有的模型，照着抄。
- 评估机器能不能带得动显存有限时先想好选小参数还是量化版本，别一上来就拉最大的那个。显存和参数量怎么对应，可以到 部署测算（/models/deploy） 按你的卡算一遍。
在 Copilot 里选对调用方式并填地址
插件设置里先选本地模型提供商那一档，再填 Base URL 与模型名。选错了提供商，地址填对也连不上，因为请求会按另一个协议发出去。地址要带 http 前缀和端口，末尾不要多写路径斜杠，多数连接失败其实是地址格式问题，而不是服务问题。
| 配置项 | 怎么填 | 常见错误 |
|---|---|---|
| 提供商 | 选本地模型那一档 | 选成云端提供商，地址填对也不通 |
| Base URL | 带 http 前缀和端口，末尾不加斜杠 | 漏端口、多写一层路径 |
| 模型名 | 照终端里列出的标签抄 | 写了文件名或记错大小写 |
| 多设备 | 同机用回环地址，跨机用局域网地址 | 跨机却填了回环地址 |
填完先点测试或拉一次模型列表，能刷出模型名就说明链路通了。刷不出来先去看服务端日志，别在插件里反复改参数，那样只会把变量越改越多。有多台设备时，区分本机地址与局域网地址，同一台机器上写回环地址最省事。
- 提供商、地址、模型名三项要一次性对齐，不要只改一项就重试
- 能刷出模型列表，说明网络与服务都通，问题只剩提示词和参数
- 刷不出列表，先看服务端有没有收到请求，再回头查地址
- 同一台机器上不要写局域网地址，多绕一层容易碰上防火墙
连不上时的排查顺序
按「服务在不在跑、端口通不通、地址格式对不对、模型名存在不存在」四步往下走，一次只改一个变量。这四步是固定的，顺序不要跳，跳步会让你同时怀疑好几个地方，最后哪都改一遍反而更乱。
- 服务在不在跑回到终端看服务进程是否还在，日志里有没有报错。服务挂了，插件这边怎么调都不通。
- 端口通不通确认端口号与插件里填的一致。跨设备访问时还要看系统防火墙有没有放行。
- 地址格式对不对检查前缀、端口、末尾斜杠，这是最常见的坑。把地址直接粘到浏览器或另一个客户端里试一次，能出内容说明格式没问题。
- 模型名存在不存在对照终端里列出的标签逐个核对。能在插件里看到模型列表但对话报错，多半就是模型名或上下文长度的问题，换回默认参数再试一次。
对话能出字但很慢，先判断是不是把超出显存的大模型硬塞进去，装不下会回落到内存，速度差一大截。这时候换小一点或量化版本通常比调参数更管用。本地跑不同量级模型的体验差异，可以到 速度测试（/tools/speed-test） 对照当时的数据看。
配好之后怎么用在笔记里
链路通了之后，重点从「能不能连」转到「怎么用得顺」。第一件事是在设置里限定检索范围，只让插件读你指定的文件夹，避免把整库无关内容都塞进上下文，既慢又容易答偏。
- 限定检索范围：只挂需要被问答的文件夹，不要把整个笔记库全开
- 长文档先切分再提问：整篇丢进去容易超上下文，分段落问更准
- 常用提示词存成模板：在笔记里调用一次就行，省得每次重写
- 定期对照上下文上限检查：术语和上限可以到 基础概念词典（/ai-dict/category/basics） 对一遍
这套流程适合个人和小团队的私密资料整理，本地推理数据不出机器，这是它最大的好处。但它不适合要求多人并发高吞吐的场景，那种情况要换推理框架而不是继续调插件设置。另外，本地小模型在复杂推理上确实会弱一些，如果任务本身对准确度要求高，得先想清楚是本地跑还是走云端。
下一步如果你还会同时用几个云端和中转的接口，把本地这套和外部服务放在一起比一比会更清楚；站内的中转站列表里有各家的接入方式与当前状态，可以先看一遍再决定哪些留在本地、哪些走外部。→常见问题
Obsidian Copilot 连 Ollama 时一直提示连接失败，先查什么？
先别改插件。回到终端确认模型能正常跑一轮对话，再确认服务监听地址和端口和你填的一致。然后检查地址有没有带 http 前缀、有没有多余的斜杠。最后确认模型名和列表里刷出来的一致。四步里任何一步不对都会表现成连不上，一次只改一个变量，改完重开插件。
插件里刷不出模型列表是什么原因？
多数是地址填成了别的东西，比如带上了具体接口路径，或者端口写错。也有一部分是模型还没拉下来，服务在跑但本地没有可用模型。先把地址还原成最基础的主机加端口，确认本地确实有拉好的模型，再重新点列表。如果换了绑定地址让服务对外，还要确认本机防火墙没拦。
本地模型回答质量和在线模型差不多吗，值得折腾吗？
本地跑的好处是资料不出机器、不按次计费、离线也能用；代价是回答质量取决于你选的那个模型的规模和你机器的显存，小模型在长文档归纳上会明显弱一些。如果只是整理自己的笔记、做摘要和提取要点，够用；如果要写复杂推理或长链条代码，本地小模型容易掉链子，这种任务还是用在线模型更省事。
