写了个quadlet文件用systemd管理一个ollama-rocm容器服务，英语太渣平时拿ollama配合其他本地模型来翻译文档和手册（感觉比以前的机翻强太多）。
偶然看到phoronix的一篇文章评论里提到llama.cpp用vulkan后端比ollama-rcom更快，拉取了llama.cpp server vulkan后端的容器镜像试了试跑qwen3 30b a3b q4量化能跑到62.00 tokens/s,问同一个问题的情况下ollama-rocm才28.61tokens/s，虽然跑两个模型的时候都是爆显存状态（不过运行前的空闲显存应该基本一致），还有上下文长度之类的其他参数可能会影响不过这个差距也太大了Orz。
可惜按llama.cpp项目的文档创建的llama.cpp server容器切换模型不方便，一个容器只能跑一个模型，而且一运行容器就马上占用显存，不像ollama那样子只有有对话的时候才激活模型，超时会自动卸载模型释放显存，还得继续用ollama了。
我的笔记本用 CPU 后端比 Vulkan 后端快……
搞个反代来自动启动和停止 llama-server 呗。
对于甚至还不清楚什么是反向代理的家伙而言难度过高（悲，甚至不会写bash脚本_(:3 」∠ )_
我的笔记本也是，intel xe 核显用 vulkan 后端比 CPU 还慢。不过用 intel 自己的 ipex-llm 就很快。
我又测了一下llama.cpp-vulkan和llama.cpp-hip，前者快20%以上，并且后者加载很慢。
噫，llama的Vulkan后端居然真的比ROCm快
应该是PyTorch的overhead太大了吧。另外llama.cpp使用的模型是量化过的（Q8_0）。
哦对，我还尝试过llama.cpp-hip，要比llama.cpp-vulkan慢一点。另外我还试了PyTorch的Vulkan支持，但报错说Vulkan不支持指定的数据类型。
Qwen3的模型是ROCm比较快，大约快一倍。
好像弄错了：使用OpenBLAS和x86-64-v3编译的话，Vulkan会比ROCm快一些。
另外ggml的HIP好像ROCm架构的支持有问题，即使指定了多个架构（-DAMDGPU_TARGETS=gfx1032,gfx1030），whisper.cpp还是在HSA_OVERRIDE_GFX_VERSION=10.3.0时使用gfx1032的从而报错（但是不设置这个环境变量的话rocblas又会报找不到那个什么文件）。
惊了，大佬最近在折腾LLM么，感觉做了很多测试
是啊。我还在archlinuxcn里试图打包它们来着。
