Step Edge 装完却加载不了模型，多数时候不是“装没装上”的问题，而是加载链路里断了一条：权重文件能不能被加载器识别、进程有没有足够内存把它读进来、路径和权限对不对。判断顺序建议反过来做——先抓日志第一条错误行，再核对文件格式，最后才看内存。因为格式不符和路径错误也会让加载器在中途分配内存失败，表现和内存不足很像，一上来就换档位容易白改一轮。

Step Edge 加载失败先按日志首条错误行分类：报 magic、字段或版本不一致的按格式处理；报文件不存在、权限拒绝的按路径处理；进程无明显异常却中途消失、日志停在分配阶段的，再查内存。建议先跑一个只做“指定路径—加载—打印”的最小脚本，再用 /proc/<pid>/status 的 VmRSS、VmHWM 对比加载前后变化，确认是否被系统回收。三类问题分别对应换量化档位、转格式、改路径，每轮只改一处再复测。

在日志里定位第一条与加载相关的错误行

加载失败的日志通常“一错带多错”：首条错误之后，运行时会继续抛出参数非法、张量形状不匹配、初始化超时等派生信息，这些都不是根因。做法是按进程名过滤，并把时间窗口收窄到触发加载前后的十几秒。

Android 设备上用 adb logcat，先清缓冲再触发一次加载，只保留这一轮产生的行：

adb logcat -c
# 触发一次加载后
adb logcat -v threadtime | grep -iE 'step|edge|your_process_name' | tail -n 200

桌面或服务器上如果进程由 systemd 托管，改用 journalctl，或者直接看进程自己写的日志文件：

journalctl -u your_service `--since` '5 min ago' `--no-pager` | head -n 50
tail -n 100 /var/log/your_app.log

过滤的关键是限定时间窗口：先清一次日志，再触发加载，只看这一轮。找到第一条形如 XxxException、error、failed to 的行，把原文完整抄下来，包括它提到的文件名、字段名和期望值。后面所有报错先当成噪声，不要拿来当判断依据。

核对权重文件格式与加载器要求的格式是否一致

先确认文件是不是你以为的那个东西。看文件头和实际大小，比看扩展名可靠。

ls -l model.bin
head -c 32 model.bin | xxd
file model.bin

常见情况有三种：扩展名被改过、下载中断留下截断文件、导出时选了加载器不支持的数据类型。文件头里一般能看到魔数或 JSON 起始符；如果是断档文件，大小会和预期差出一截，这时先重新获取完整文件，别急着改配置。

再用加载器自带的探测能力对一次要求。不同运行时的接口名不一样，但思路一致：让它只解析、不推理，看它声明的格式标识、版本号和字段名。

# 伪代码骨架，替换成你自己运行时的探测接口
info = loader.inspect(path)
print(info.format, info.version, info.dtype, info.tensor_names[:5])

如果报格式标识不符、字段缺失或版本过旧，通用方向是按加载器声明的容器格式和数据类型做一次转换，例如把高精度权重转成运行时支持的低位量化档位，或把量化权重转回浮点。具体转换命令行取决于运行时版本，需要结合你实际使用的加载器确认。另外注意量化权重和浮点权重不能混用：加载器声明要量化档位时，喂浮点文件同样会报字段不符。

用最小脚本单独加载权重

业务代码里有预处理、并发和后处理，报错会被掩盖。写一个只做三件事的脚本：指定路径、加载、打印结果。

# minimal_load.py —— 只做 指定路径 -> 加载 -> 打印结果
import os, sys, time

MODEL_PATH = '/path/to/model.bin'   # 唯一需要改的地方

def main():
    print('path exists:', os.path.exists(MODEL_PATH))
    print('size:', os.path.getsize(MODEL_PATH))
    t0 = time.time()
    handle = load_model(MODEL_PATH)   # 换成自身运行时的加载调用
    print('loaded in', round(time.time() - t0, 2), 's')
    print('handle:', handle)          # 只打印，不做推理
    return 0

if __name__ == '__main__':
    sys.exit(main())

判定条件要写清楚，避免“看起来跑完了”的误判：

• 成功：进程退出码为 0；日志里出现加载耗时且没有 error 级记录；handle 非空，再打印一次权重名或输入张量名能拿到值。
• 失败：退出码非 0；或进程被信号终止（退出码 137 一般与内存回收有关，需结合系统日志确认）；或中途无任何输出直接消失，这类优先怀疑内存，而不是格式。

同一个路径先用正式权重跑一次，再用一个极小的样例权重跑一次。小权重能过、正式权重不过，通常说明格式没问题，瓶颈在内存或文件完整性。

对比加载前后的进程内存变化

先拿到进程号，在触发加载前后各读一次内存字段。

grep -E 'VmPeak|VmSize|VmHWM|VmRSS' /proc/$(pidof your_process_name)/status
# 触发加载后再读一次同样的字段

关注三个字段：VmRSS 是当前占用，VmHWM 是历史峰值，VmSize 是虚拟地址空间。判断方式很直接——加载开始后 VmRSS 持续上升、VmHWM 逼近设备可用上限，然后进程消失，基本可以归到内存不足；如果 VmRSS 几乎没动就退出了，往格式和路径方向查。

确认是否被系统回收，看这几处记录：

• 内核日志：dmesg | grep -iE 'oom|killed process'，或 journalctl -k | grep -i oom。
• Android 设备：adb logcat | grep -iE 'lowmemorykiller|lmkd|kill'，以及 adb shell dumpsys meminfo your_pkg 看当前占用与阈值。
• 容器环境：docker inspect 查内存上限，配合 docker events 观察是否有 OOM 事件。

需要提醒：临时打开 swap 或调大缓存只能把被杀的时间往后推，不是性能改善手段，它改变的是“什么时候被杀”，不改变峰值需求。真正的处理路径还是回到档位调整。

按错误类型分别给出改配置或换档位的处理路径

三类问题的动作不通用，选错了会浪费一轮排查。

• 内存不足（首条错误指向分配失败，或 dmesg 有 oom、退出码 137）：动作是换量化档位，把浮点权重换成运行时支持的低位档位，或减小上下文长度、批大小、输入分辨率这类一次性载入量。改完用同一份最小脚本复测，确认 VmHWM 峰值低于设备可用上限再回业务代码。
• 格式不符（首条错误报 magic、字段缺失、版本不支持、dtype 不匹配）：动作是转格式。按加载器声明的容器格式与数据类型转换一次，转换后先用小样例权重验证解析通过，再替换正式文件；不要同时改量化档位，否则出问题分不清是哪一步导致的。
• 路径错误（首条错误是文件不存在、权限拒绝、路径长度或符号链接问题）：动作是改路径。确认配置文件里写的是绝对路径、运行进程的用户对该目录有读权限、挂载点或存储介质已就绪；容器里还要确认宿主机目录是否已映射进去。

每轮只改一处，改完固定跑“最小脚本 → 看退出码 → 读 VmHWM → 回看首条错误行”这四步。如果改完配置首条错误原文没变，说明改动没生效或改错了配置文件，先确认进程读的是哪一份配置，再继续调。