Ollama本地部署：解决SillyTavern向量存储卡死与嵌入慢问题

要不要先给个关键词？谁在聊向量存储的时候绕得过数据加载慢、请求超时、索引建不起来这几座大山？

前阵子我折腾 SillyTavern 的向量存储，属实被虐了一轮。一开始图省事，接了远程嵌入接口，结果中文文本进去，界面直接卡死，日志里全是超时重试，一个二十条的文档库能等十分钟。后来换思路，改成本地部署 Ollama 跑嵌入模型，问题一下清爽了：响应稳定、速度可接受、离线可用，数据也全在本地，不再看外部服务脸色。这篇文章就专门记录这次从“卡死”到“本地部署 Ollama 跑通”的完整过程，包括为什么会卡、Ollama 怎么装、模型怎么选、SillyTavern 具体怎么配，以及我在这个过程中踩过的所有坑。如果你正好在给 SillyTavern 配置向量存储，或者想给本地大模型做知识库接入，这篇文章直接照着操作就行。

1. 先把问题说清楚：向量存储卡死的根源与 Ollama 的解法

1.1 标题里所谓的“卡死”到底是什么现象

先说现象。SillyTavern 的向量存储模块，说白了就是把角色的背景设定、世界书、聊天记录这些文本切片之后转成向量，存进一个向量数据库里，等以后提问时再做相似度检索。正常逻辑很简单，但实操起来非常容易翻车。我当时遇到的情况是这样的：

• 在 SillyTavern 的扩展面板里打开 Vector Storage，填入嵌入服务的地址和模型名，点击“创建/连接知识库”；
• 界面长时间转圈，浏览器标签页一直处于“等待”状态；
• 查看后台控制台，满屏的 timeout、connection reset、retry；
• 偶尔有一两条文本入库成功，但索引构建始终不完整，检索结果乱七八糟；
• 更头疼的是，只要知识库里的条目一多，整个页面像被按住了一样，连打字都卡。

很多人以为这是 SillyTavern 本身的问题，其实不是。卡死的根源主要在三层。

第一层是网络。如果你用的是外部在线嵌入服务，中文文本需要先把数据送到远端接口，等接口算完再把向量传回来。这个过程“往返时间”不可控，一旦服务商过载或者你的网络环境不佳，请求就会堆积，表现就是无限转圈、然后超时。

第二层是线程阻塞。SillyTavern 的扩展机制并不是完全异步的，如果嵌入请求迟迟不返回，前端会一直等着这个响应，导致后续 UI 操作全部排队，体感就是整个页面卡死。

第三层是向量库本身。SillyTavern 默认的向量存储方案是 ChromaDB，它需要在本地完成文本切块、向量写入、索引构建。如果你的嵌入模型质量差或者向量维度过高，索引构建会非常慢，小文档还能忍，文档一多直接变成“假死”。

所以，当远程嵌入服务不稳定的时候，最直接、最可靠的解法就是——把嵌入模型挪到本地。这就是标题里“本地部署 Ollama”的出发点。

1.2 为什么选 Ollama 而不是其他本地推理方案

本地跑大模型和嵌入模型的方案并不少，最主流的有 llama.cpp、Ollama、LM Studio、Text Generation WebUI。综合下来，我推荐 Ollama，原因非常直白：

• 安装简单。Ollama 有现成的安装包，Windows 和 macOS 都是双击安装，Linux 一个 curl 脚本搞定，不需要手动编译、不需要折腾 CUDA 环境；
• 接口兼容 OpenAI 格式。SillyTavern 对 OpenAI 兼容接口的支持最成熟，Ollama 原生提供/api/embeddings和/api/chat接口，配置起来几乎没有障碍；
• 模型管理方便。一条ollama pull命令就能拉模型，模型文件统一管理，不像 llama.cpp 那样需要自己去找 GGUF 文件、自己写命令行参数；
• 资源占用可控。Ollama 常驻后台时占的内存并不算夸张，而且支持按需加载模型，不用的时候可以卸载，对 16GB 内存的机器很友好。

另外还要说一句，Ollama 不只是能跑嵌入模型，它同时也能跑对话模型。这意味着你可以把 SillyTavern 的聊天模型和嵌入模型全部指向本地，整套链路不依赖任何外部服务。隐私性和稳定性都大幅提升，也彻底避免“服务商改接口导致功能失效”的风险。

2. 本地部署 Ollama：安装、模型选择与关键参数

2.1 Ollama 安装的完整过程与下载慢的应对方法

Ollama 的官方安装方式很简单，去官网下载对应平台的安装包，Windows 用户直接跑 OllamaSetup.exe，一路下一步就行。macOS 用户得到的是一个压缩包，把 Ollama.app 拖进 Applications 文件夹即可。

但这里有一个国内用户几乎都会遇到的问题：官方下载速度非常不稳定，经常几十 KB/s 的蜗牛速度，一个几百 MB 的安装包能下半小时。如果你卡在这一步，别死磕官网，可以试试以下几种方式：

• 通过代理镜像站下载安装包，注意选择可信的第三方镜像;
• 去 GitHub Releases 页面找对应版本的安装包，有时候 GitHub 的 CDN 速度反而比官网快；
• 用夸克网盘、百度网盘这类分享渠道，很多社区用户会定期搬运最新安装包，搜索“Ollama 安装包 + 版本号”通常能找到。

下载慢的问题解决之后，安装本身没什么难度，安装完打开终端执行：

ollama --version

能正常输出版本号，就说明安装成功了。Windows 上如果提示找不到命令，多半是安装时没有把 Ollama 加入 PATH，去“系统环境变量”里手动加一下C:\Users\你的用户名\AppData\Local\Programs\Ollama就行。

Ollama 安装后默认会注册成后台服务，开机自启。这个行为我觉得非常贴心，因为 SillyTavern 需要调用嵌入接口时，Ollama 必须处于运行状态，如果每次都要手动启动，那体验会大打折扣。

提示：如果你对开机自启有顾虑，可以在 Windows 的服务管理器里把 Ollama 服务改成“手动”，需要用的时候再启动。但对于绝大多数用户，保持默认自动启动反而是最省心的。

2.2 嵌入模型与对话模型的选择：尺寸、维度与中文能力

安装好 Ollama 之后，下一步是拉取模型。这里必须先搞清楚一个概念：嵌入模型和对话模型是两类完全不同的模型。

嵌入模型的作用是“把文本变成向量”，它不生成文字，而是把一句话映射成一个固定维度的数值数组。SillyTavern 的向量存储就是要用这个向量来做相似度计算。常见的嵌入模型有：

• nomic-embed-text：768 维，轻量，英文表现好，中文一般；
• bge-m3：1024 维，多语言能力强，中文表现非常出色，是我个人最推荐在 SillyTavern 里用的嵌入模型；
• snowflake-arctic-embed：不同版本维度不同，整体中规中矩。

对话模型的作用是“理解上下文并生成回复”，SilLyTavern 里配置聊天接口时用到的就是它。如果你之前没有本地对话模型，常用的选择有：

• qwen2.5系列：中文能力扎实，体积从 0.5B 到 72B 不等，16GB 内存的机器跑 7B 或 14B 比较合适；
• llama3.1系列：英文能力强，中文能凑合用，胜在生态好；
• gemma2：中规中矩，胜在体积小、速度快。

拉取嵌入模型的命令：

ollama pull bge-m3

拉取对话模型的命令：

ollama pull qwen2.5:7b

这里特别提醒一个容易犯的错误：嵌入模型和对话模型不能混用。你不能用qwen2.5去生成向量，也不能用bge-m3去聊天。SillyTavern 的配置里有一个是“嵌入模型”选项，一个是“聊天模型”选项，两者要分别指定，别填混。

另外，模型拉取同样可能遇到下载慢的问题。Ollama 的模型默认从官方仓库拉取，国内网络环境下经常卡在 50% 左右不动。应对办法有两个思路：

一是改环境变量，把模型下载地址指向国内可访问的镜像仓库，具体配置方法在网上搜索“Ollama 国内镜像”就能找到，基本就是设置OLLAMA_MODELS和镜像地址这两个变量，然后重启 Ollama 服务；

二是手动下载模型文件。先去模型仓库页面找到对应模型的 GGUF 文件，下载后放到本地模型的指定目录，再用ollama create命令导入。这个方法稍微繁琐，但胜在速度可控。

2.3 Ollama 服务配置与环境变量调优

Ollama 安装好并拉完模型之后，正常情况下已经可以直接用了。但为了让它在SilLyTavern 的场景下更稳，我建议做两项调优。

第一项是确认服务监听地址。Ollama 默认监听127.0.0.1:11434，这个配置对“只在本机使用”的场景完全够用。如果你打算让局域网内的其他设备也能访问 Ollama，可以设置环境变量：

OLLAMA_HOST=0.0.0.0

然后重启 Ollama 服务。注意，改成 0.0.0.0 意味着局域网内所有设备都能调用你的模型服务，不需要的时候尽量别开，避免被蹭算力。

第二项是并发参数。SillyTavern 在构建索引的时候，会一次性向嵌入接口发送很多文本切片，如果 Ollama 处理不过来，请求就会排队，表现为索引构建非常慢。通过环境变量可以调大 Ollama 的并发处理数量：

OLLAMA_NUM_PARALLEL=4 OLLAMA_MAX_LOADED_MODELS=2

这两个变量的作用分别是“同时处理的请求数”和“最多同时加载的模型数”。设置之后重启 Ollama，索引构建的速度通常会有明显改善。

如果 Ollama 所在机器同时还要跑对话模型，建议给系统预留足够的内存。以 16GB 内存的机器为例，同时加载 7B 对话模型和 bge-m3 嵌入模型，内存占用大概在 6~8GB 左右，还没到无法接受的程度。但如果你的机器只有 8GB 内存，同时跑两个模型会比较吃力，这时候建议关闭掉不用的模型，或者选择更小体积的嵌入模型，比如nomic-embed-text。

3. SillyTavern 向量存储配置全流程

3.1 确认前置条件与扩展模块

在开始配置之前，先确认你手里的 SillyTavern 版本。向量存储功能不是所有历史版本都有，建议直接用最新版 release，避免遇到功能缺失或者 UI 对不上的问题。

然后是扩展模块。SillyTavern 的向量存储功能不是主程序自带的，它通过扩展市场安装。打开 SillyTavern 面板，点击顶部的扩展管理图标（拼图块形状），在“Available” 列表里找到以下两个扩展装好：

• SillyTavern-vector-storage：向量存储的核心扩展，负责管理知识库、索引和检索；
• SillyTavern-chromadb：ChromaDB 的适配器，负责连接本地向量数据库。

安装扩展之后，最好重启一次 SillyTavern，让扩展正确加载。重启后左侧栏会出现一个新的“Vector Storage”面板，看到这个面板就说明扩展装成功了。

注意：有些人会漏装 ChromaDB 适配器，结果向量存储面板永远报“无法连接数据库”。这两个扩展是配合使用的，缺一不可。

3.2 配置向量数据库连接参数

进入 Vector Storage 面板后，首先要配置的是数据库连接。SillyTavern 的向量存储扩展支持多种后端，但默认和兼容性最好的是 ChromaDB。

ChromaDB 是一个轻量级的向量数据库，它可以内嵌在 SillyTavern 进程中运行，也可以作为独立服务运行。对于普通用户，我建议直接用内嵌模式，省去单独启动服务的麻烦。也就是说，SillyTavern 会在你创建知识库时，自动在本机启动一个 ChromaDB 实例。

在面板里，你只需要确认一下数据库地址和端口设置。内嵌模式下，SillyTavern 自己管理 ChromaDB 的生命周期，你不需要额外启动任何东西。如果你选择独立模式，需要先安装chromadbPython 依赖，然后手动启动服务，再把地址填进去。

我推荐内嵌模式的原因很简单：少一个环节就少一个坑。独立服务虽然灵活，但需要额外维护进程，而且端口冲突、依赖版本不兼容的问题很容易让人头疼。

3.3 嵌入服务地址与模型的正确填写方式

这是整个配置中最重要的部分，也是最容易出错的地方。SillyTavern 的向量存储面板里，嵌入模型配置有几个关键字段：

Embedding Endpoint指的是嵌入服务的 API 地址。如果你用的是 Ollama，这个地址填：

http://127.0.0.1:11434/api/embeddings

注意api/embeddings这个路径是 Ollama 的标准嵌入接口，不要漏掉。

Embedding Model指的是嵌入模型的名字。这里填你通过ollama pull拉取的嵌入模型名称，我用的是bge-m3，所以你填：

bge-m3

Chat/Completion Endpoint和Chat Model如果之前配置过对话接口，可以保留原来的配置。如果还没有配置过，只需要暂时忽略即可，向量存储的正常工作不依赖对话接口。但后续如果想实现“根据知识库内容生成回答”，就需要把对话接口也配好。

配置完这两项之后，点击测试按钮。如果一切正常，你会看到类似“Connected to Ollama at ...”的提示。如果测试失败，检查一下 Ollama 服务是否在运行，以及 URL 拼写是否正确。

3.4 知识库创建、文本导入与索引构建

连接配置通过后，就可以创建知识库了。

在 Vector Storage 面板里，给知识库起一个名字，点“Create”按钮，SillyTavern 会调用 ChromaDB 创建一个 collection。创建完成后，把角色设定、世界观文档、聊天记录等文本粘贴到文本输入框，点击“Add”或“Import”按钮。

此时 SillyTavern 会把这些文本切成多个 chunk，然后逐个调用你配置的嵌入接口，把每个 chunk 转化成向量，再写入 ChromaDB。整个过程的耗时取决于文本长度和嵌入模型的速度。

以我自己的实测为例：一段一万字的中文背景设定，切成约 30 个 chunk，使用 bge-m3 模型在本地 CPU 上跑，大概需要 1~2 分钟完成索引构建。如果使用独立显卡做 GPU 加速，这个时间还能大幅缩短。

索引构建完成后，面板上会显示“N vectors stored”之类的信息，同时会出现一个可检索的搜索框。你可以直接输入一句测试问题，点搜索，看看能不能从知识库中召回相关内容。召回结果里会列出相关的文本片段和相似度分数，分数越高代表匹配度越好。

如果搜索结果为空或者相关度很低，大概率是嵌入模型选得不对。把嵌入模型换成bge-m3这类多语言模型，通常能明显改善中文知识库的召回效果。

3.5 将知识库接入角色对话：向量存储的终极目标

配置好知识库之后，最后一个问题就是：怎么让角色在聊天时用上这些知识？

SillyTavern 的向量存储扩展提供了两种接入方式。

第一种是手动检索。在聊天时，打开 Vector Storage 面板，输入当前话题相关的关键词，点击搜索，把检索到的文本插入到对话上下文中。这种方式比较手动，但胜在完全可控。

第二种是自动注入。在扩展设置里开启“自动检索”功能，设定一个触发机制，比如每次聊天前自动用最新的几条消息作为查询条件，在知识库中检索相关内容并注入到上下文。这种方式更智能，但要注意限制注入的文本量，避免把上下文撑爆。

我个人的建议是先用手动检索跑通整个流程，确认知识库里的内容能被正确召回，再开启自动注入。一上来就开自动，万一知识库内容质量不高，反而会给角色注入一堆错误信息，导致对话质量下降。

4. 常见问题与排查技巧实录

4.1 从“卡死”到“跑通”的完整排查记录

按时间来还原一下我当时从卡死到跑通的完整排查过程，这个过程本身就是一个很好的案例，希望对你有参考价值。

第一步，我先确认了“卡死”是不是SillyTavern主程序本身的问题。换了浏览器、重启了 SillyTavern，问题依旧。然后我打开浏览器的开发者工具，切到 Network 标签页，刷新页面重新触发索引构建，观察请求列表。结果发现大量请求都卡在同一个外部接口地址上，等待时间全部显示为“Pending”。这就锁定了问题：卡死不是主程序崩溃，而是外部嵌入接口的请求迟迟不响应，把前端线程拖死了。

第二步，排查外部接口为什么慢。我尝试在终端里直接向这个接口发送一条测试文本，结果等了 30 秒才返回结果，而同样的文本在本地模型上不到 1 秒就能完成向量化。这个差距实在太悬殊了。更关键的是，外部接口是公有服务，高峰期的响应速度完全不可控。

第三步，决定切换成本地方案。我在本地装好 Ollama，拉取 bge-m3，然后回到 SillyTavern 把嵌入接口从远程改为http://127.0.0.1:11434/api/embeddings，模型名改为bge-m3，重新测试连接——通过。

第四步，重新创建知识库并导入之前的文本。这次索引构建速度明显提升，一万字的文档十几秒搞定，面板不再卡死。

第五步，验证检索效果。输入“角色的隐藏身份是什么”，能准确召回设定中对应段落，相似度超过 0.35。整个流程跑通。

这一步一步过来，我的体会是：遇到“卡死”类问题，先定性再解决，优先判断是不是网络请求堵塞导致的。把链路中的网络环节去掉（本地化），很多奇奇怪怪的问题自然就消失了。

4.2 常见问题速查表

4.3 几个容易忽略的高级注意点

除了上面的速查表，还有几个不太容易发现、但影响非常大的细节，值得单独说。

第一，向量维度不一致是隐藏炸弹。如果你之前用远程接口（比如 OpenAI 的 text-embedding-ada-002，1536 维）建过一个知识库，现在改成本地 bge-m3（1024 维），再往同一个知识库里写新文本，ChromaDB 会报错或者静默失败，因为同一个 collection 里的向量维度必须一致。解决办法是：换模型之后，把旧知识库删掉重建。

第二，文本 chunk 的大小会影响检索效果。SillyTavern 向量存储扩展允许你设置 chunk size（每个切片的字数）。chunk 太小，语义容易被截断；chunk 太大，检索精度下降。我测试下来，中文场景下 chunk size 设置在 500~800 字左右比较合适，overlap 控制在 50~100 字。

第三，本地 Ollama 加载模型需要时间。第一次调用嵌入接口时，Ollama 需要把模型从磁盘加载进内存，这个过程可能要等 5~15 秒。这是正常现象，不是卡死。建议在正式使用前先手动向 Ollama 发送一次请求，让模型“热”起来，后面就快了。

第四，Windows 环境下要注意防火墙。有时候 Ollama 服务和 SillyTavern 都在本机，但 Windows 防火墙会拦截本地回环地址的请求。如果排除了其他原因仍然连接失败，检查一下 Windows 防火墙对 Ollama 进程的入站规则，放行本地回环流量。

5. 一些个人体会与后话

折腾完这一轮，我最大的体会是“凡事优先考虑本地化”。SillyTavern 的向量存储本身是一个非常好的功能，但对外部服务的依赖让它变得脆弱。换成 Ollama 本地部署之后，整套系统不仅稳定，还多了一层可控性——我知道模型在本地跑，数据在本地存，不依赖任何人的服务器。这种“自己的东西自己掌控”的感觉，是用外部服务永远给不了的。

另外，说实话，Ollama 这个工具大大降低了本地跑模型的门槛。前几年想在本机跑嵌入模型，要自己编译 llama.cpp、找 GGUF 文件、写 API 服务，光是环境配置就能劝退一堆人。现在一条命令拉模型、一条命令起服务，SillyTavern 这边填个地址就能用。

如果你也跟着配了一遍，从卡死走到了跑通，那恭喜你，你已经掌握了目前 SillyTavern 知识库方案里最稳定的一套架构。后面你可以继续扩展：把更多角色设定丢进知识库、尝试换不同嵌入模型看检索质量差异、甚至把对话模型也换成本地部署，彻底脱离外部接口。这套流程跑顺之后，SillyTavern 基本就是一个完全离线可用的个人 AI 角色扮演平台了。

最后再给一个小技巧：换嵌入模型或者重建知识库之前，先去 SillyTavern 的存储目录里把旧的知识库文件夹备份一下。别问我为什么知道要备份，问就是曾经手滑删掉过一套精心整理的角色设定，当时的心情只能用“心如刀绞”来形容。