快速结论：该报错通常发生在 Windows 上使用 Ollama 调用 embedding 模型且单次请求文本过长、超出模型上下文窗口时，底层 llama.cpp 在断言失败后强制关闭了本地 runner 连接，导致 Ollama 收到 embedding generation failed. wsarecv: An existing connection was forcibly closed by the remote host.。优先排查输入长度是否超过模型窗口，以及 Ollama 版本是否处于 0.3.14 / 0.4.0-rc3。
适用环境：Ollama 0.3.14 与 0.4.0-rc3（报告问题）；Ollama 0.3.13 与 0.3.10（报告正常）；操作系统为 Windows（多台 Windows 系统均复现）；涉及 embedding 模型如 viosay/conan-embedding-v1、893379029/piccolo-large-zh-v2；Issue 中未确认 Python、CUDA、PyTorch 或具体显卡型号。
最快修复方案：暂无确认的一步修复方案。Issue 中未给出已验证的配置修改或升级版本，讨论最终指向 llama.cpp 应更优雅地处理超长输入，而非客户端侧的一步修复。
注意事项：在客户端将长文本切分为小于模型上下文窗口的片段，是 Issue 中被讨论的规避思路，但并未被作者确认为已验证修复；且该问题在新旧版本间行为不一致，说明仅靠切分可能无法覆盖所有情况。是否已在新版本中修复，Issue 中没有明确结论。
问题场景
用户在 Windows 上运行 Ollama，并通过 /api/embed 接口请求 embedding 模型。提交单个短片段时响应正常，提交多个片段或单段超长文本时触发异常。该问题在 Ollama 0.3.14 与 0.4.0-rc3 上出现，而在 0.3.13 与 0.3.10 上工作正常。用户测试了多个 embedding 模型，包括 893379029/piccolo-large-zh-v2、viosay/conan-embedding-v1，均出现相同问题；而 shaw/dmeta-embedding-zh 未出现该问题。
报错原文
[GIN] 2024/10/21 - 16:00:29 | 200 | 722.8624ms | 192.168.7.100 | POST "/api/embed"
ggml.c:13343: GGML_ASSERT(i01 >= 0 && i01 < ne01) failed
ggml.c:13343: GGML_ASSERT(i01 >= 0 && i01 < ne01) failed
time=2024-10-21T16:00:36.434+08:00 level=ERROR source=routes.go:434 msg="embedding generation failed" error="do embedding request: Post \"http://127.0.0.1:64075/embedding\": read tcp 127.0.0.1:64078->127.0.0.1:64075: wsarecv: An existing connection was forcibly closed by the remote host."
[GIN] 2024/10/21 - 16:00:36 | 500 | 6.5660285s | 192.168.7.100 | POST "/api/embed"原因分析
最可能的原因是输入文本长度超过了 embedding 模型的上下文窗口。Issue 中维护者指出：viosay/conan-embedding-v1 的 embedding length 为 1024，而示例文本为 1905 bytes，已经超出窗口，导致底层 llama.cpp 触发 GGML_ASSERT(i01 >= 0 && i01 < ne01) failed。断言失败后，本地 runner 进程/连接被强制关闭，Ollama 侧收到 wsarecv: An existing connection was forcibly closed by the remote host.。
另一个可能因素是版本回归：用户明确表示该问题在 0.3.14 之前不存在，0.3.13 与 0.3.10 正常，说明 0.3.14 与 0.4.0-rc3 可能在超长输入的处理上出现了行为变化。但 Issue 中没有给出对应的代码变更或补丁验证，因此“版本回归”只能作为可能原因。
此外，模型差异也可能影响触发条件：shaw/dmeta-embedding-zh 的 embedding length 为 768，在该用户的测试中新旧版本均正常，说明是否触发与模型窗口、输入长度及版本实现均有关联。
环境排查
- 确认 Ollama 版本：
ollama --version，对比 0.3.14 / 0.4.0-rc3 与 0.3.13 / 0.3.10 的行为差异。 - 确认操作系统：Issue 明确为 Windows，且在多台 Windows 系统上复现。
- 确认 embedding 模型及其 embedding length / 上下文窗口，例如
viosay/conan-embedding-v1为 1024，shaw/dmeta-embedding-zh为 768。 - 检查请求输入长度：单段文本的字节数是否接近或超过模型窗口；多片段请求时每个片段的长度是否超限。
- 查看 Ollama 日志中是否出现
GGML_ASSERT(i01 >= 0 && i01 < ne01) failed，该断言是判断是否因超窗口触发崩溃的关键线索。 - Issue 未确认 Python、CUDA、PyTorch、显卡驱动或显存细节，无需作为首要排查项。
解决步骤
- 先复现并确认触发条件：用短文本请求
/api/embed，再用 Issue 中的长文本请求，观察是否只在长文本时出现 500 与wsarecv错误。 - 计算输入文本长度与模型 embedding length / 上下文窗口的关系。Issue 中示例长文本为 1905 bytes，模型 embedding length 为 1024，已超出窗口。
- 可优先尝试在客户端侧对长文本进行切分，使每个片段长度小于模型的上下文窗口，再分别请求 embedding。Issue 中维护者建议客户端应切分文本，否则返回的 embedding 会缺失语义内容。
- 如果切分后问题消失，说明触发路径与超长输入相关；如果仍然复现，需要记录具体模型、输入长度、Ollama 版本和完整日志。
- 回退到 Issue 中报告正常的版本（0.3.13 或 0.3.10）可作为临时规避手段，但需注意这并非长期修复，且 Issue 未确认该回退在所有模型上都有效。
- 关注 Ollama / llama.cpp 后续版本对超长输入的错误处理改进，因为 Issue 讨论最终指向 llama.cpp 应更优雅地处理该情况，而非仅靠客户端规避。
验证方法
使用与报错时相同的模型和长文本重新请求 /api/embed：如果切分后每个片段都能正常返回 embedding，且日志中不再出现 GGML_ASSERT(i01 >= 0 && i01 < ne01) failed 和 wsarecv: An existing connection was forcibly closed by the remote host.，说明问题与输入长度相关并已被规避。若仍出现相同报错，则需进一步确认是否为版本回归或其他未识别因素。
参考来源
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
这个方案解决了吗？
可以继续搜索完整报错，或查看同一工具的其他排查指南。
