问题描述：
我在 K3 上测试 AI 模型并发运行时，发现 llama.cpp-spacemit 启动的 GGUF 对话模型，与 ONNX Runtime SpaceMITExecutionProvider 启动的 ONNX 模型同时运行后，会出现 TCM buffer 相关错误。
现象是：ONNX 测试运行一段时间后自动异常退出，同时正在运行的 llama-server 也会中断。随后 8090 端口消失，llama-server 进程不存在。此后重新启动其他 GGUF 模型也会失败，需要重启 K3 后才能恢复正常。
测试环境：
设备：K3
系统：Bianbu OS
llama：llama.cpp / llama-server spacemit 版本
ONNX Runtime：1.24.2+spacemit.a1
ONNX Provider：SpaceMITExecutionProvider
已确认 ONNX Provider 可用：
python3 - <<‘PY’
import onnxruntime as ort
import spacemit_ort
print(ort.version)
print(ort.get_available_providers())
PY
输出：
1.24.2+spacemit.a1
[‘SpaceMITExecutionProvider’, ‘CPUExecutionProvider’]
复现步骤：
- 启动 llama-server 运行 GGUF 模型，例如 Qwen2.5-1.5B / 3B / 4B / 30B 模型。
- llama-server 正常运行后，再启动 ONNX YOLO 测试，并使用 SpaceMITExecutionProvider。
- ONNX 测试运行一段时间后报错退出。
- llama-server 同时出现 TCM buffer 相关错误并中断。
- 执行 ps / ss / curl 检查，发现 llama-server 已退出，8090 端口不存在。
- 之后重新启动模型失败，需要重启系统恢复。
ONNX 侧报错：
terminate called after throwing an instance of ‘std::runtime_error’
what(): tcm buffer acquire failed for core id 0
llama-server 侧报错：
wait tcm buffer failed for cpu_id: 2
wait tcm buffer failed for cpu_id: 1
wait tcm buffer failed for cpu_id: 6
wait tcm buffer failed for cpu_id: 7
随后出现：
ggml_abort
检查模型服务状态：
ps -ef | grep llama | grep -v grep
ss -lntp | grep 8090
curl http://127.0.0.1:8090/health
curl http://127.0.0.1:8090/v1/models
结果：无 llama-server 进程，8090 端口无监听，curl 无法连接。
问题影响：
如果应用中同时使用 GGUF 对话模型和 ONNX 视觉模型，例如一个功能使用 llama.cpp 运行对话模型，另一个功能使用 ONNX Runtime SpaceMITExecutionProvider 运行图片识别/AI相册模型，就可能触发 AI 加速资源冲突。一旦触发，模型服务会中断，并且后续模型无法正常重新启动，需要重启设备恢复。
想确认的问题：
请问 K3 当前是否支持 llama.cpp-spacemit 与 ONNX Runtime SpaceMITExecutionProvider 同时使用 AI 核/A100？
如果不支持并发，请问是否属于当前已知限制？
如果理论上支持并发，请问 tcm buffer acquire failed / wait tcm buffer failed 是否属于驱动或 runtime 层面的异常？
是否有推荐的规避方式，例如互斥调用、任务排队、释放资源命令，或者需要升级某个 runtime / driver / llama.cpp / onnxruntime 版本？