目录

• 第一阶段：环境与服务的“深度重置”
• 第二阶段：向量化模型与存储优化
• 第三阶段：显存与参数调优 (5500XT 专项)
• 第四阶段：日志监控定位
• 假设你已经下载好了 bge-m3 的 gguf 文件
• 核心优化：限制 CPU 线程数为 8 或 12，避开超线程带来的性能回退
• 启用内存锁定，防止大模型在内存和虚拟内存之间来回倒腾
• 设置上下文窗口，bge-m3 最大支持 8192，但为了省资源，设 2048 足够日常 RAG 使用
• 同样限制线程数
• 关键：限制 GPU 显存占用上限（单位 MB），给 5500XT 留一点保底显存
• 如果是直接通过环境变量控制，在运行前执行：
• set OLLAMA_GPU_MAX_VRAM=3500
• 按照这个配置，你的 E5 反而能发挥出多通道内存的优势，告别检索转圈的问题。你可以先试试第一步，看看 AnythigLLM 的检索是不是立马变流畅了？

针对你 E5 + 5500XT + 64GB 环境下，使用 AnythingLLM + Llama.cpp + Ollama (bge-m3 FP16) 处理万级数据 Excel 出现的检索假死问题，现总结排查方案。
由于你处于内网环境，无法下载新模型，我们将重点放在配置优化和资源调度上。请按以下顺序操作：

第一阶段：环境与服务的“深度重置”

排除由于长时间运行导致的接口死锁或显存碎片。

1. 重启 Ollama 服务：在任务栏右下角退出 Ollama 并重新启动，确保 API 接口响应正常。
2. 重启 Llama.cpp 服务：确保启动参数中 -c (Context Size) 至少为 4096 或 8192。
3. 验证单点可用性：

4. 在 CMD 输入 ollama run bge-m3 "测试"，看是否秒回。

   • 在 AnythingLLM 中新建一个无文档工作区，提问“你好”，确保 LLM 推理通路正常。

第二阶段：向量化模型与存储优化

FP16 版本的 bge-m3 在处理 10,000+ 条数据时，检索压力巨大，极易引发假死。

1. 更换内置引擎测试：

2. 在 AnythingLLM 设置中，将 Embedding Engine 临时改为 Built-in Embedder。

   • 原理：内置引擎不走 GPU，不占用 Ollama 资源。如果改为内置后检索恢复，说明原 bge-m3 FP16 模型在处理大规模索引时与显卡驱动存在冲突。
3. 数据格式降级：

4. 将 Excel 另存为 CSV (UTF-8) 格式。

   • 原理：Excel 结构复杂，AnythingLLM 解析时可能产生冗余碎片。CSV 是纯文本，检索效率最高。
5. 重建索引：
6. 删除原有工作区，新建一个工作区，上传 CSV 并点击 Save and Embed。

第三阶段：显存与参数调优 (5500XT 专项)

5500XT 的 8GB 显存在同时运行 Qwen 9B 和 FP16 向量模型时非常吃力。

1. 腾出显存空间：
2. 降低 Llama.cpp 加载到 GPU 的层数（例如 -ngl 参数减少 5-10 层），预留至少 2GB 专用显存给向量检索任务。
3. 调整检索阈值：

4. 进入工作区设置，将 Document Similarity Threshold 设置为 0.5（不要太高）。

   • 将 Vector Search Count (K值) 限制在 3 到 5 之间。
5. 关闭全文搜索：
6. 确保工作区设置中的 "Full-text search" 已关闭，仅依靠向量检索。

第四阶段：日志监控定位

如果以上步骤仍无反应，通过日志确定“卡”在哪一步：

1. 看 Llama.cpp 黑窗口：

2. 提问后，如果黑窗口有日志滚动但没字：说明卡在 LLM 推理。

   • 如果黑窗口完全没动静：说明卡在前面的“向量检索”阶段，请求还没发出来。
3. 看 AnythingLLM 日志：

4. 打开路径 %APPDATA%\anythingllm-desktop\logs。

   • 搜索关键字 Error、Timeout 或 Fetch Failed。
     你这台机器的组合非常经典：E5大内存保障吞吐，但单核性能偏弱；RX 5500 XT 只有 4GB 显存，属于典型的“亮机卡”。

在这种配置下跑 AnythingLLM，最容易踩的坑就是“线程数给太多，导致 CPU 在高频短任务中疯狂争抢资源，最终死锁假死”。外接应用发起检索时，一旦卡死，通常就是后端线程池崩了。

我们来针对性地给这两个模型做个“减法”优化，直接用代码说话：

第一步：重构 bge-m3 的 Modelfile（解决检索卡死）

对于 12 核的老架构 E5，24 个线程不仅不能提速，反而会互相踩踏。建议将 bge-m3 的线程锁死在 8~12 个，并强制锁定内存防止被系统换出。

创建一个新的
"Modelfile"（比如命名为
"bge-m3-fix"）：

假设你已经下载好了 bge-m3 的 gguf 文件

FROM ./bge-m3-q4_k_m.gguf

核心优化：限制 CPU 线程数为 8 或 12，避开超线程带来的性能回退

PARAMETER num_thread 8

启用内存锁定，防止大模型在内存和虚拟内存之间来回倒腾

PARAMETER use_mlock 1

设置上下文窗口，bge-m3 最大支持 8192，但为了省资源，设 2048 足够日常 RAG 使用

PARAMETER num_ctx 2048

保存后，在终端执行重建：

ollama create bge-m3-fix -f Modelfile

然后在 AnythingLLM 的设置里，将 Embedder 切换到这个新模型。

第二步：优化 Qwen2.5 的启动参数（防止后台默默崩溃）

RX 5500 XT 只有 4G 显存，而 Qwen2.5 7B 即使量化后也需要约 3.5G~4G 显存。如果 KV Cache 也塞进显存，极易触发显存溢出（OOM），导致 llama.cpp 在后台静默崩溃，前端就会一直转圈没反应。

建议在启动 Qwen 的 Modelfile 中加入显存限制（如果你是用 Ollama 跑 Qwen）：

FROM ./qwen2.5-7b-instruct-q4_k_m.gguf

同样限制线程数

PARAMETER num_thread 12

关键：限制 GPU 显存占用上限（单位 MB），给 5500XT 留一点保底显存

PARAMETER gpu_layers 99

如果是直接通过环境变量控制，在运行前执行：

set OLLAMA_GPU_MAX_VRAM=3500

第三步：Windows 系统级的“降压”设置

在 Windows 下，llama.cpp 对 AMD 显卡的支持不如 N卡完善，加上 E5 的老架构，必须通过环境变量强行接管线程分配。

请在启动 Ollama 服务的终端（或系统的环境变量设置里）加入这两行，这是最关键的一步：

set OMP_NUM_THREADS=12
set OLLAMA_NUM_PARALLEL=1

• "OMP_NUM_THREADS=12"：告诉底层计算库，只用 12 个核心干活，避免 24 线程打结。
• "OLLAMA_NUM_PARALLEL=1"：AnythingLLM 在检索时会瞬间发起大量短请求，设为 1 可以让 CPU 排队处理，彻底告别死锁。

总结排查顺序

先改 bge-m3 的 Modelfile 并重建模型 ➡️ 然后加上 系统环境变量 ➡️ 最后重启 Ollama 服务。

按照这个配置，你的 E5 反而能发挥出多通道内存的优势，告别检索转圈的问题。你可以先试试第一步，看看 AnythigLLM 的检索是不是立马变流畅了？

核心建议：
最先尝试“CSV 格式 + 内置 Embedder”。如果这个组合能跑通，说明你的硬件跑不动 FP16 版的 bge-m3 处理一万条数据的余弦计算。
如果你完成了以上步骤，检索速度是否有提升？