K1 / Bianbu v2.3 上 spacemit-onnxruntime 2.0.3 跑官方 yolov8n.q.onnx 报：
tcm buffer acquire failed for core id 0。
请问是否有 spacemit-onnxruntime 2.0.5 的 riscv64 deb 包？
需要 spacemit-onnxruntime、python3-spacemit-ort、spacemit-tcm 一整套。
这个报错我们刚在 K1 上做了系统的最小复现和根因定位，确认是 EP 2.0.3 的 TCM 缓冲区分配 bug，2.0.5 已修复。先讲清楚根因，再回答你的 deb 问题。
根因
spacemit_ort（SpaceMIT EP）推理时要把算子的权重和中间缓冲放进 AI 核的 TCM（Tightly-Coupled Memory，紧耦合内存），启动 EP session 编译模型时会按模型需求向 TCM 申请缓冲。2.0.3 的分配策略有缺陷：
- 失败被放大成进程崩溃：申请失败时 EP 直接抛
std::runtime_error("tcm buffer acquire failed for core id N")，异常没有被接住，进程以 abort（核心已转储）终止；有些路径则表现为段错误（SIGSEGV）。我们实测同一问题两种表现形式都出现过。 - 触发阈值不稳定：不是模型大才会崩——我们构造的最小模型（[6,48] 的纯 MatMul，几十 KB）也能稳定触发；而更小的内置示例模型偶尔能过。也就是说 2.0.3 在 TCM block（K1 上 block size 为 128KB）的划分/记账上有问题，与模型"该不该放得下"无关。
- 你跑的 yolov8n.q int8 是典型受害者：量化模型编译期 EP 要为算子批量申请 TCM 缓冲，正好踩中。
验证方式：import spacemit_ort 后建 SpaceMIT EP session，用 faulthandler 抓到的真实异常就是上面这条；换 2.0.5 后同样的模型全部通过，且分配失败时会打 warning 并优雅回退 CPU，不再砸进程。
回答你的 deb 问题：2.0.5 的 deb 目前不存在
刚核对了 Bianbu v2.3-updates 源：spacemit-onnxruntime / python3-spacemit-ort 最高 2.0.3-bpo1，spacemit-tcm 最高 3.0.0-bpo1+2——apt 路径到 2.0.3 就到头了。楼上贴的 GitHub Release 2.0.5 存在，但资产是 SDK 整包 spacemit-ort.riscv64.2.0.5.tar.gz（含 C/C++ 头文件、samples、bin 工具，Python 部分是 python/spacemit_ort-2.0.5-...whl）——里面同样没有 deb。
不等 deb 的可用路径：私有 PyPI 的 whl（国内直连，不用翻 GitHub）：
pip3 download spacemit-ort==2.0.5 --no-deps \
--index-url https://git.spacemit.com/api/v4/projects/33/packages/pypi/simple
unzip spacemit_ort-2.0.5-*.whl -d ~/ep205 # whl 就是 zip，内含 libspacemit_ep.so.2.0.5
export PYTHONPATH=$HOME/ep205 # 覆盖系统 2.0.3
配套的 spacemit-tcm 用你源里现成的 3.0.0 就行，不用另装。
一个重要的版本坑（2.0.5+ 和 2.0.3 相反）：import 顺序必须改成先 import onnxruntime 再 import spacemit_ort。沿用 2.0.3 时代的顺序会直接 OSError: undefined symbol: _ZTIN11onnxruntime18IExecutionProviderE——别误判成装错了版本。
修复有效性已实测：同款 K1 上 6 个最小模型对照，EP 2.0.3 下全部触发本 bug（段错误/中止），换 2.0.5 后全部通过——yolov8n.q 这类量化模型正是典型受害者。
如果想上更新的 2.0.7：私有 PyPI 也有，但额外依赖 libspert.so.1（spine-runtime 发布包里才有），多一步；2.0.5 无此依赖。另外 GitHub Release 的 v2.0.8 配 xslim 2.1.2 修了 rank-5 算错（参考 t/1696），可以关注进源情况。
抛砖引玉，多交流