Qwen3.5:9b concurrent call BUG

快速结论：Ollama v0.17.6 在 ARM 版 DGX Spark 上运行 Qwen3.5:9b 时，因为 qwen35 架构当前不支持并行请求，日志会强制将 Parallel 降级为 1；如果强行并发调用或加载并行图，可能在 ggml_backend_sched_reserve 阶段触发 SIGABRT 崩溃。优先排查：将 Ollama 升级到 v0.17.7 并接受该模型当前只能串行处理请求，不要尝试绕过架构安全检查。

适用环境：Ollama v0.17.6（Linux），NVIDIA DGX Spark（ARM64 / GB10），CUDA compute=12.1，驱动 13.0，统一内存 128GB（识别为 iGPU / 119.7 GiB VRAM）。Apple Silicon 上相同配置可正常工作，问题疑似 Linux-ARM64 CUDA runner 的调度/后端缺陷。

最快修复方案：暂无确认的一步修复方案。Issue 中明确验证的是：在 DGX Spark 上同时发起 4 个 curl 请求，Ollama 会按串行队列依次完成、不会崩溃；官方实验室复现正常，说明并行降级机制本身可用。因此先接受“qwen35 不支持并行”的限制，并保持默认串行调度。

注意事项：有人尝试手动移除 qwen35 的架构安全检查，但这会直接触发底层图构建错误，不是可持续的修复；不要在生产环境使用这种 hack。Qwen 3.5 全系列在 Ollama 当前版本下都表现为不支持并行，Qwen v3 则正常。

问题场景

用户在 DGX Spark 上启动 Ollama 服务后，打开多个终端同时向 /api/generate 发起 Qwen3.5:9b 的流式请求，期望获得真正的并行推理。实际行为是：日志显示模型架构不支持并行请求，Parallel 被强制设为 1，请求只能串行排队执行；在某些并发触发场景下，runner 会直接以 SIGABRT 崩溃。

报错原文

level=WARN source=sched.go:450 msg="model architecture does not currently support parallel requests" architecture=qwen35
level=INFO source=runner.go:1302 msg=load request="{Operation:fit ... Parallel:1 ... FlashAttention:Enabled KvSize:4096 ...}"

SIGABRT: abort
PC=0xfe7256047608 m=11 sigcode=18446744073709551610
signal arrived during cgo execution

goroutine 20 [syscall]:
runtime.cgocall(...)
github.com/ollama/ollama/ml/backend/ggml._Cfunc_ggml_backend_sched_reserve(0xfe71e10b9950, 0xfe6f5eceda10)
github.com/ollama/ollama/ml/backend/ggml.(*Context).Reserve(0x400043c100)
github.com/ollama/ollama/runner/ollamarunner.(*Server).reserveWorstCaseGraph(0x400024f0e0, 0x1)

level=INFO source=types.go:42 msg="inference compute" id=GPU-... library=CUDA compute=12.1 name=CUDA0 description="NVIDIA GB10" libdirs=ollama,cuda_v13 driver=13.0 pci_id=000f:01:00.0 type=iGPU total="119.7 GiB" available="61.4 GiB"

原因分析

可能原因有两层，且彼此独立：

1. 架构级限制：qwen35 架构目前未加入 Ollama 的并行请求支持列表，所以 sched.go 会直接覆盖 OLLAMA_NUM_PARALLEL 环境变量，强制 Parallel: 1。官方已确认这是当前 Ollama 集成的限制，并非模型本身不支持并行——有独立 Issue 在跟踪该功能，Qwen v3 则不受影响。

2. 后端崩溃：SIGABRT 发生在 ggml_backend_sched_reserve 阶段。官方认为该崩溃与并行限制“很可能相互独立”。有人尝试删除架构安全检查后复现崩溃，发现报错根源在底层计算图（graph）本身，而不是安全性检查遗留的视觉模型（VL）逻辑。因此 DGX Spark 特定的 Linux-ARM64 CUDA runner 可能在构建最坏情况图时存在缺陷。

环境排查

确认 Ollama 版本：是否为 v0.17.6 或 v0.17.7（后续版本是否引入修复需另行验证）。
确认硬件平台：DGX Spark（ARM64 / GB10）被识别为 iGPU，统一内存 128GB。
确认 CUDA 环境：compute=12.1、驱动 13.0、Ollama 内置 cuda_v13 库目录。
对比测试：在 Apple Silicon（macOS）上跑相同命令，看是否能正常并行——Issue 中确认相同配置在 macOS 上工作正常。
检查 OLLAMA_NUM_PARALLEL 是否被日志中的架构警告覆盖：若看到 Parallel:1 说明设置已失效。

解决步骤

先确认问题不是并发调用方式导致的：用官方实验室相同的方式（同时跑 4 个 curl）发起请求，观察是否按串行队列依次完成且不崩溃。
确认当前 Ollama 版本是否为 v0.17.6；Issue 中已提到 v0.17.7 仍存在并行问题，建议持续关注后续版本更新。
如果目标是真正的并行推理：目前没有可用的官方开关。不要试图用删除架构安全检查的方式来绕过，因为这会直接触发图构建错误。
如果崩溃频繁出现且影响使用：用 OLLAMA_DEBUG=1 ollama serve 启动服务，捕获完整崩溃日志后提交到官方 Issue，帮助定位 Linux-ARM64 runner 的调度缺陷。
临时规避：限制并发请求数量，让 Ollama 自然排队串行处理；或在客户端侧加锁，确保同一时刻只有一个请求进入模型加载阶段。

验证方法

重新发起多个并发 curl 请求，观察是否满足以下条件：不再出现 SIGABRT 崩溃；服务日志中保留 ms="model architecture does not currently support parallel requests" 警告，但请求按顺序完成；OLLAMA_NUM_PARALLEL 即使设置大于 1，实际仍为 Parallel:1。若所有请求都正常返回且无崩溃，则说明问题已规避成功。