jev在amd显卡上未调用gpu因rocm驱动未装、用户组权限未生效或gpu架构不匹配；性能低下主因是统一内存访问nvme盘或state字段膨胀；崩溃于illegal instruction系pytorch_rocm_arch与实际gfx架构不符。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Jev模型在AMD显卡上运行时设备识别失败
启动Jev服务后，日志里完全不出现GPU相关初始化信息，【进程始终只占用CPU和内存，显卡利用率长期为0%】，任务管理器或rocm-smi里都看不到任何计算负载。这说明Jev根本没尝试调用GPU——不是性能差，是压根没连上。
先验证底层是否具备基础条件：执行rocm-smi。如果命令未找到，说明ROCm驱动根本没装；如果报错Permission denied，大概率是当前用户没加入video和render组，且【未重启系统】，组权限不会生效。
确认rocm-smi能正常输出GPU温度、显存使用率后，再运行rocminfo | grep gfx，记下类似gfx942的架构代码。这个值必须和后续Jev编译或运行时指定的GPU架构严格一致，否则会静默回退到CPU。
Jev推理速度远低于预期
显卡被识别了，日志里也出现了Using HIP backend，但吞吐量只有标称值的1/3甚至更低，生成一个token要等好几秒。问题往往出在内存带宽瓶颈上。
检查Jev启动参数是否强制启用了统一内存模式：如果模型权重加载路径指向的是普通NVMe盘而非RAM盘，每次访存都要跨PCIe总线，延迟飙升。应把--model-path指向/dev/shm下的软链接，或用tmpfs挂载大容量内存盘。
更隐蔽的坑是state字段膨胀。Jev对输入上下文长度敏感，若业务侧传入的state平均字符数从2000涨到8000，显存中张量尺寸呈平方级增长，HIP kernel launch延迟直接翻倍。用ollama ps观察显存占用是否随请求变长而线性暴涨，就能快速定位。
Jev服务启动即崩溃，报illegal instruction
日志末尾只有一行Illegal instruction (core dumped)，无其他线索。这是典型的架构指令集不匹配——编译Jev时用的PYTORCH_ROCM_ARCH和你显卡实际架构对不上。
方法一：用rocminfo重新确认真实架构代码，例如输出为Name: gfx942，但编译时却设了export PYTORCH_ROCM_ARCH="gfx90a"，MI300系列卡跑MI250的二进制就会触发非法指令。
方法二：跳过源码编译，改用Ollama官方预编译的Jev镜像。它内置了多架构fat binary，启动时自动选择匹配指令集，省去手动指定环节。执行OLLAMA_VULKAN=1 ollama run jev可强制走Vulkan后端，兼容性更好，尤其适合Radeon消费级显卡。
