Segmentation fault on VMware ESXi 8.0.3 with Intel Xeon Gold 6526Y (Sapphire Rapids) running Ubuntu 24.04

快速结论：该报错发生在 Ollama 在 Intel Sapphire Rapids 架构 CPU（含 AMX 指令集）上启动模型时。优先排查步骤是将 Sapphire Rapids 的后端动态库文件移至备份位置，让 Ollama 自动回退至 Ice Lake 等兼容后端。此问题在裸机环境（无 hypervisor）下同样能复现。

问题场景

用户使用 Ollama 0.31.1（后也验证在 0.32.1 复现）在 VMware ESXi 8.0.3 虚拟机中的 Ubuntu 24.04 LTS 上执行 ollama run 加载任何模型（qwen3:4b、qwen3:14b、llama3 等）。模型下载完成后，在预热（warmup）阶段立即触发 segmentation fault。

报错原文

Error: 500 Internal Server Error:
llama-server process has terminated:
signal: segmentation fault (core dumped)

在裸机复现时，内核日志也报告了通用保护错误（general protection fault），表现为 SIGSEGV：

traps: llama-server[...] general protection fault ip:... error:0

原因分析

可能原因：Ollama 为 Sapphire Rapids CPU 选择了 libggml-cpu-sapphirerapids.so 后端，该后端使用了 AMX INT8/tile 指令路径。在 Linux 上，AMX tile 状态采用惰性启用策略：权限检查可能在启动时成功，但更大的 xstate 缓冲区是在第一次执行 AMX 指令时才分配的。如果该首次使用路径在虚拟机（VMware ESXi 8.0.3）或者裸机（bare metal）上失败，则会表面化为 SIGSEGV 或 #GP（通用保护异常），导致 llama-server crash。该问题后续在裸机 Intel Xeon Gold 5412U (Sapphire Rapids) 上也被完全复现，证明 hypervisor 不是触发必要条件，问题根因在 Ollama 的 Sapphire Rapids 后端与特定 CPU/固件组合的兼容性上。

环境排查

Ollama 版本：0.31.1、0.32.1（已验证影响范围）
OS：Ubuntu 24.04 LTS
CPU：Intel Xeon Gold 6526Y (Sapphire Rapids)；裸机复现使用 Intel Xeon Gold 5412U (Sapphire Rapids)
Hypervisor（如果适用）：VMware ESXi 8.0.3 Build 24859861，VM 硬件版本 21
关键 CPU 标志（故障环境）：amx_tile amx_int8 amx_bf16 + 完整的 AVX512 系列 (AVX512F, AVX512BW, AVX512VL, AVX512_BF16, AVX512_FP16 等)
冲突后端库：/usr/local/lib/ollama/libggml-cpu-sapphirerapids.so

解决步骤

（可优先尝试）后端库重命名法：将 Sapphire Rapids 后端动态库移走，让 Ollama 自动回退到下一级 CPU 后端（如 Ice Lake）。此方法已在 VM 和裸机上验证有效：
```
sudo mv /usr/local/lib/ollama/libggml-cpu-sapphirerapids.so{,.bak}
sudo systemctl restart ollama
```
（备选方案，仅限 VMware 环境）调整虚拟机 EVC：关闭虚拟机，在 ESXi 主机或虚拟机设置中将 EVC（Enhanced vMotion Compatibility）模式设置为 Intel Ice Lake baseline。重启后，检查 /proc/cpuinfo，确认 amx_tile / amx_int8 标志消失。该操作同样可强制 Ollama 不使用 Sapphire Rapids 后端。如果此改动避免 crash，则确认问题仅限 AMX/Sapphire Rapids 后端路径。
检查内核日志：排查 crash 时刻内核日志以确认故障类型与 AMX 相关：
```
sudo dmesg -T | grep -Ei 'ollama|llama|segfault|amx|xstate|xsave|xcomp|sigsegv'
```

验证方法

执行 ollama run qwen3:4b（或其他模型），观察模型是否能正常加载并进入对话模式，不再报 segmentation fault (core dumped)。同时运行 sudo journalctl -u ollama -n 50 检查服务日志中是否仍有 segfault 记录。如果选择修改 EVC，重启后可用 grep -oE 'amx|avx512' /proc/cpuinfo | sort -u 确认相关指令标志是否消失。