改了什么，以及为什么改

已适配的芯片不再误报「这颗芯片还没人验证过」

天玑 9500、8300/8350、8400、9400+ 平板都已经跑通并在云端标了「已验证」，但模型库照样弹提示，让人以为跑不了。

上一版没修干净：那段判断读的不是界面状态，云端信息拉回来之后界面根本不会刷新，于是永远停在「还没拉到」那一刻的结论上。现在改成拉到之前不下任何判断。

连续迭代

这一段是芯片适配推进最密集的时候，十九个构建在不到一天里发完，改动零散、当天就推， 没有留下逐版的发布说明。这里如实标注，不做事后补写。

找到 rc=6 的真因：冷编译的内存峰值是各图之和

决定性证据来自同一台平板的对照 —— 自检逐张编、编完就放，五张图（含 VAE）在可用 6095 MB 下全部通过； 真装载时 DiT 四张过、VAE 挂，而那一刻只剩 3782 MB。同机、同图、同运行时，差别只有「编这张的时候还剩多少」。

这也意味着前几轮「算子种类 / 操作数个数 / 常量字节都排除了」的推论底座是脏的： 自检一趟要编几十次，驱动内存不随对象释放，越往后可用越低 —— 所谓「前 44 个过、前 45 个挂」不是内容更难，是它们跑得晚。

• 装载改成两趟：第 0 趟只编译并写缓存，每编完一张立刻整张释放；第 1 趟才真装载（全部命中缓存）。冷编峰值从各图之和降到单张最大值。热机不付代价。
• VAE 从「解码前才第一次编」挪到 DiT 之前编，编完立刻释放。平板就是死在旧顺序上。
• rc=6 不再当场判死：整张放掉、等 1.5 秒重试两次；文案也改成「内存不够」，并说清这不是芯片不支持。

拿到天玑 9500 的关键对照

VAE（277 算子 / 25 MB）编得过，四张 DiT（3398–3846 算子 / 444 MB）全 rc=6。 而算子种类、操作数个数、常量字节三个维度当时都被否掉了 —— 前 44 个算子过、前 45 个挂， 而带 12.61 MB 常量的另一个窗口反而过。于是不再从这些数字里找规律，改问一个直接的问题：一张图放几个块能编得过。

天玑 9400+ 平板：DiT 四张全过，只有 VAE 挂

这条推翻了「图太大 / 算子太多」整条线 —— DiT 444 MB、3398 个算子过了，VAE 才 25 MB、277 个算子。 自检以前只探 DiT，VAE 一次没测过；从这一版起每张图都探，慢的前缀扫描只在第 0 张跑。

修掉探针自身的错误

• 切出来的子图带着 6–14 个悬空出口（整图是干净的 0 个），测的其实是「编译器容不容忍悬空」。现在段内产出而段内无人消费的一律声明为图输出。
• 扫描点是 1 / 106 / 212…，1 过、106 挂，中间一个都没测，却一直在 868 那边打转。改成倍增扫小端 + 真二分。
• 自检的键从「算子类型」改成「算子类型 × 输入维数 × 输出维数」—— 图里有 30 种组合，只按类型取首次出现只覆盖了 12 种，漏掉的恰是最可疑的那些。

下载前就说清跑不跑得了

逐算子探针的结果是：12 种算子用真实形状和真实类型（含逐通道量化权重）单独全部编得过，整图仍 rc=6。远程排查到此为止，不再让人跑第六遍。

改成云端可以把某颗芯片标为 failing，模型库在下载前就说清楚，别让人下完 8 GB 才发现。

天玑 9500 跑通：加载的一直是错的那个库

目录扫描找到真凶 —— 那台机器的 /system_ext/lib64 里有两个 adapter， 我们一直加载不带版本号的那个（兼容壳：自报 8.2.26、枚举出 0 个设备、连 fp32 最小加法都 rc=6）， 而它的 /vendor/lib64 里是 libneuron_runtime.9.so，实际上是 Neuron 9.x。

• 候选库表加上带版本号的 .9 / .10 变体，并同步进清单声明（不声明就 dlopen 不了）。
• 设备节点检查改成扫 /dev 和 /proc，不再用猜的固定名单。
• 修复生效后：9500 上设备 2 个、Neuron 9.2.0、3398 个算子 0 个不支持、四种张量类型全通过。

「3300 个算子不支持」其实是没有设备可映射

9500 的自检报告显示 APU 设备 0 个，于是 3398 个算子里 3300 个「不支持」—— 连加法和形状变换都在内。 那不是缺算子，是没有设备。

随后拿到天玑 8350 的对照：同一个库、同一个 Neuron 版本，8350 枚举出 3 个设备、0 个算子不支持。 于是自检一次写全：系统里有哪些 NPU 库（扫目录，不猜名字）、APU 设备节点存不存在及能否打开（区分「没有」和「没权限」）、关键符号是否齐全、张量类型逐个探针、特性位、磁盘剩余。

加了设置页

• 芯片检测：本机是哪颗天玑。
• 缓存状态：本机哪些档位已有编译缓存，云端哪些「芯片 × 档位」已经有人传过。
• 一键上传本机编译缓存 —— 同款芯片的下一个人就能直接命中。
• 芯片兼容性自检。
• 下载源切换移进来。
• 「上次装载没走完」的落盘记号与报告框。

步数滑块只有 12 一档、拖不动

根因是下载只拉了当前那一档的调制表。工作台的滑块只列「本地已有表」的步数，于是只剩一个刻度， 物理上就拖不动，6–11 全不见了。现在七张表全下（合计约 65 MB，是总量的 0.8%），并给已装好的机器自动补齐。

这类问题的共同点是：自己 adb push 过全套资产的机器上永远看不出来，只有全新安装才踩得到。

非 9400 家族不再误命中别人的编译缓存

缓存 token 里不含芯片型号，异构机型会命中我们在 MT6991 上编的 MDLA 二进制并返回 rc=6。 103 改成不再下载；104 发现光「不下载」不够 —— 从旧版升上来的机器缓存早在本地了，于是改成装载前主动删掉。

错误报告同时补上构建号和缓存文件数（原来只有显示名，长期是 0.1.0，分不出报告来自哪个构建）。

下载源换到魔搭

从自建服务器切到 ModelScope（HTTPS + CDN，实测单连接 18.8 MB/s，自建那边是全体共享的 5 MB/s），并加了换源重试。

同时撤掉 768×1024 的 fp16 档：它配的是 W8A16 的 int16 位置编码表，喂进 FLOAT16 槽位必然出纯色平图。 两份文件字节数完全相同，大小校验拦不住，日志也一切正常 —— 只有看图才发现。

装 App，点下载，出图

第一次做到不需要 root、不需要电脑、不需要等编译：把在开发机上编好的 NPU 产物随模型一起下发，别人下完直接命中。

在此之前，出一张图要先在电脑上用 adb 把几个 GB 的资产推进去，再在设备上等四张图各编译四分钟。