周三下午，板子上的LED灯毫无征兆地开始闪烁。不是那种正常的呼吸灯效果，是那种带着绝望的、频率不定的乱闪，像极了老式硬盘灯在报错。我盯着调试串口刷出来的日志，一帧一帧的模型推理时间从12ms跳到了47ms，然后又跌回15ms。那一刻我就知道，我昨天晚上“优化”过的那个int8量化算子，在特定输入下触发了灾难性的cache miss风暴。做嵌入式Agent，跑端侧模型，从来不是把一个大模型用“魔法”塞进单片机就完事了。你面对的是一个随时可能因为一个数据对齐问题，就把你精心调校的实时性彻底摧毁的战场。今天这篇笔记，没有那些PPT里的漂亮曲线，只有我在这些寄存器缝隙里摸爬滚打留下的土办法和踩过的坑。先说说最要命的“内存墙”。你们在网上看到动不动就谈“算子融合”，但在嵌入式平台上，真正的瓶颈往往不是算力，是你那个可怜巴巴的几百K SRAM，甚至只有几十K的Cache。我调试过的一个语音唤醒Agent，模型结构不复杂，两个卷积加一个LSTM。问题出在LSTM的权重矩阵上。原始float32权重是200KB，板子内存勉强能塞下，但每次做矩阵乘法时，数据的读取会把Cache彻底污染。我当时干了一件蠢事，把所有权重都加了个const修饰符，想着能放到Flash里去。结果IDE提示Flash不够，又去改链接脚本。折腾一晚上，性能没提升，反而因为Flash的读取延迟比RAM高一个量级，推理时间更长了。后来才醒悟，在嵌入式端侧，模型参数的最佳归宿不是Flash也不是SRAM，而是“你希望它刚好能塞进那片永远不换出的Cache里”。我的土办法是，对LSTM的权重进行重排。标准库里的矩阵是按行存储的，我们计算W * x时，其实是权重矩阵的每一行和输入向量做点积。但如果按“