Crash in Vulkan backend on Intel Arc when using Ollama through VS Code Continue (Exception 0xe06d7363 during llama_decode)

快速结论：该问题通常出现在 Intel Arc GPU 上通过 VS Code Continue 调用 Ollama、以流式方式高频执行增量解码时，runner 在 llama_decode 阶段崩溃；应优先怀疑 Vulkan 后端与 Intel 驱动/高频小批量解码之间的兼容问题，并以此方向排查。

适用环境：Windows 11；Ollama 0.15.6；Qwen2.5-7B（Q4_K 量化）；Intel Arc 140V（16 GB 共享显存）；Intel 显卡驱动 32.0.101.8425；Vulkan 1.4.333；CPU 为 Intel Lunar Lake，内存 32 GB。Issue 中未提供 Python、CUDA 相关信息。

最快修复方案：暂无确认的一步修复方案。Issue 正文中未给出经明确验证的首选处理方法；根据讨论，可优先尝试调小 batch size 或 GPU 层数、关闭 Flash Attention，但这些操作只是降低崩溃频率，并不能完全消除崩溃。

注意事项：上述缓解措施均未得到彻底验证，只能降低频率；问题是否由 Ollama/GGML 的 Vulkan 后端、Intel Arc Vulkan 驱动或两者交互导致，Issue 中尚未确认。若需进一步定位，应按服务器日志排查。

问题场景

用户在同一台 Intel Arc 140V 的 Windows 11 机器上运行 Ollama 0.15.6，通过 ollama run qwen2.5:7b 在终端直接对话时一切正常；但把 Ollama 配置为 VS Code Continue 扩展的后端后，Continue 以流式、增量解码、多次小批量请求的方式调用模型，模型可正常加载（全部层卸载到 GPU、Flash Attention 开启、推理正常开始），崩溃却发生在首次解码步骤中的 llama_decode。runner 进程崩溃后，Ollama 返回 500 错误。

报错原文

Exception 0xe06d7363 0x19930520 0x1de98f9550 0x7ffa3647a80a signal arrived during external code execution
llama_decode → crash
wsarecv: An existing connection was forcibly closed by the remote host

Issue 标题中对应描述为：Crash in Vulkan backend on Intel Arc when using Ollama through VS Code Continue (Exception 0xe06d7363 during llama_decode)

原因分析

根据 Issue 描述，崩溃只出现在 Continue 触发的解码流程中，而终端直接运行不崩溃，且模型加载、层卸载、Flash Attention 均正常，因此问题可能原因集中在高频解码调用路径，而非模型加载阶段。Issue 列出几个可能方向：

Vulkan 后端在高频 decode 调用下存在缺陷；
批量（batch）处理方式存在问题；
流式 token 生成过程存在同步或批处理问题；
增量解码期间 CPU 与 GPU 之间同步异常；
也可能是 Intel Arc Vulkan 驱动问题，或 Ollama/GGML Vulkan 后端与驱动交互导致。

Issue 同时指出，其他 Intel Arc 用户在 GGML 类项目的高频解码负载下也报告过类似 Vulkan 崩溃，但并未确认同一根因。因此当前无法断定唯一原因，应按“可能原因”对待。

环境排查

操作系统：是否 Windows 11，与 Issue 一致。
Ollama 版本：是否为 0.15.6，或是否已升级到含相关修复的版本（Issue 未给出具体修复版本号，需以官方发布说明为准）。
显卡：是否为 Intel Arc 140V 或同系列 Arc GPU，显存是否为共享内存。
显卡驱动：Intel 驱动版本是否为 32.0.101.8425，或已尝试更新/回退驱动。
Vulkan：运行时版本是否为 1.4.333。
模型：Qwen2.5-7B，量化格式 Q4_K（日志显示 file type = Q4_K – Medium）。
调用方式：是否通过 VS Code Continue 扩展以流式方式请求 Ollama，而非终端直接 ollama run。
运行参数：GPU 层数、batch size、Flash Attention 是否开启。
日志：是否已开启并收集 Ollama 服务器日志，崩溃堆栈和 Vulkan 内存报告是否完整。

解决步骤

先确认问题可稳定复现：在 VS Code Continue 中向 Ollama 发起一次会触发流式生成的提问，观察是否在首次解码步骤附近崩溃；同时用 ollama run qwen2.5:7b 直接运行同一提示，确认终端路径是否正常。Issue 中两者表现不同，这是定位关键。
按 Ollama 官方 troubleshooting 文档开启并收集服务器日志，保留 runner 启动信息、模型加载信息、Vulkan 内存报告和崩溃堆栈，用于判断崩溃发生在 decode 还是加载阶段（Issue 讨论中要求提供服务器日志以辅助调试）。
可优先尝试降低解码压力：减小 batch size 或 GPU 层数。Issue 报告这样做可降低崩溃频率，但不能完全消除。
可优先尝试关闭 Flash Attention，观察崩溃频率是否下降；Issue 报告同样只是降低频率，不能彻底修复。
检查 Intel 显卡驱动版本，必要时更新或回退到其他驱动版本进行对比测试（Issue 未验证具体驱动版本结论，属于可能原因排查方向）。
如条件允许，关闭 Vulkan 后端、改用其他后端（如 CPU 或其他已支持后端）运行同一 Continue 流式请求，作为对照，以确认问题是否与 Vulkan 路径相关；该做法 Issue 未验证，仅作为隔离变量的排查手段。
若以上均无法解决，携带完整服务器日志、驱动版本、Vulkan 版本和复现步骤到 Ollama Issue 跟踪，并可参考 Intel GPU 社区 Issue Tracker 中同问题的记录（链接见 Issue 正文）。

验证方法

在 VS Code Continue 中使用与复现时相同的模型和提问方式发起流式生成，观察 runner 是否仍因 Exception 0xe06d7363 在 llama_decode 处崩溃、Ollama 是否仍返回 500；若多次连续请求均不再崩溃且服务器日志无相关异常堆栈，可视为缓解生效。由于 Issue 中调小 batch size、减少 GPU 层数、关闭 Flash Attention 仅被描述为降低频率，验证时建议进行多轮长输出测试，避免单次成功被误判为彻底修复。