基数树编译进了推理引擎，KV 缓存的前缀查找偏偏用 for 循环扫目录

有人把 Redis 的基数树整份搬进了一个大模型推理引擎，然后在它的四字节头上动了刀：typedef struct raxNode { uint32_t iskey:1; uint32_t isnull:1; uint32_t iscompr:1; - uint32_t size:29; /* Redis 上游：压缩串最长 5.4 亿字节 */ + uint32_t leafbitmap:13; /* ds4 从 size 里挖走的 13 个位 */ + uint32_t size:16; /* 压缩串上限就此掉到 65535 */ unsigned char data[]; } raxNode;挖走的 13 位拿去做了一张位图：第 N 位置 1，表示第 N 个子指针槽里装的是用户 value 本身，而不是子节点地址。一个只挂 value 的叶子，本来要raxNewNode(0,1)单独malloc出 16 字节、被 glibc 圆整成 32 字节的 chunk，现在直接塞进父节点那个闲着的指针槽——十万个 key 就是十万次省掉的分配。代价写在另一边：压缩串长度上限从 5.4 亿掉到 65535。能把第三方数据结构的位域拆开、把这笔账算到malloc圆整粒度的人，不会不知道什么时候该建索引。可是在整个引擎里最像“前缀匹配”的那个地方——KV 磁盘缓存的前缀查找，命中就意味着一整段 prefill 被跳过、TTFT 直接砍