用Ghidra逆向CUDA推理引擎，RTX 3090提速12%

逆向工程通常被视为安全研究或破解的工具，但一位开发者的实践表明，它同样可以用于本地AI推理引擎的性能调优。这位用户在RTX 3090上运行一个永不关机的编程模型服务，通过Ghidra读取引擎符号表，结合实际的会话访问模式，最终在解码侧实现了12%的速度提升，会话切换延迟降低了约25倍。

先读二进制，再改参数

这位开发者在调整任何配置之前，先用Ghidra 12.1.4对推理引擎Strata 0.1.44进行了静态分析。引擎运行在systemd服务下，监听8090端口，由llama-swap在8080端口代理，背后共享一个GGUF模型集合。

二进制分析揭示了不少关键信息。.text段有8.88 MiB主机代码，CUDA fatbin镜像共50.3 MiB，全部为sm_86架构编译——恰好对应RTX 3090，因此启动时不会有JIT编译的意外。符号表未被剥离，包含12,446个过程和54,524个字符串，是一个带-O3优化的NDEBUG构建。

符号名称确认了架构设计：core::Verifier::run配合AdaptGate在专家交换窗口进行验证，RemoteExpertOpt::adapt和PeerExperts::adapt实现自适应专家层，detect_cpu_topology_impl和PoolAffinity支撑7个工作线程的绑核，prefill::detail::mmq_resident_sort_rows是预填充路径。文档、符号表和STRATA_DECODE_TIMING的实时阶段计时三个角度相互印证了这一架构。

启动日志显示：专家缓存7325个槽位占用13.94 GiB显存（总计24.5 GiB），KV缓存32768行常驻加上6.19 GiB固定在内存中，命中率稳定在94-96.7%。MTP草稿头212.9 MiB，--spec-min-p从0.55自动精调到0.35，--pcie-frac固定在0.20。显存已用23.8/24.5 GiB，这意味着任何优化方案都必须塞进剩余的空间里。

关于 Ghidra 与静态逆向分析

Ghidra 是美国国家安全局（NSA）开源的一款软件逆向工程框架，支持反汇编、反编译和符号分析，能够将编译后的二进制文件还原为近似可读的 C 代码。在本场景中，开发者并未用它破解软件，而是将推理引擎的二进制当作"地图"来阅读：未剥离的符号表（包含 12,446 个过程和 54,524 个字符串）相当于一份天然的架构文档，函数名直接暴露了模块职责，例如 core::Verifier::run、RemoteExpertOpt::adapt、prefill::detail::mmq_resident_sort_rows 等。

值得注意的是，CUDA fatbin 是 NVIDIA 编译器将设备端 GPU 代码嵌入主机二进制的一种容器格式，其中包含针对特定计算能力（如 sm_86 对应 RTX 3090 的 Ampere 架构）预编译的 SASS 指令。确认 fatbin 全部为 sm_86 编译意味着引擎启动时不会触发即时编译（JIT），从而排除了因 JIT 预热导致的性能抖动，使后续测量结果更可信。-O3 NDEBUG 则表明这是一个经过高强度优化且关闭了断言的生产构建，性能已接近编译器能给出的上限，调优空间主要集中在运行时参数而非代码本身。

最重要的一次失败：跨会话前缀缓存

开发者的实际使用模式并非单一对话，而是多个会话交替——定时任务、群聊、通话、长对话之间来回切换。因此他设计的探针精确模拟了这一场景：两个对话交替进行，测量返回第一个对话时的延迟。

基线结果暴露了一个严重问题。返回第一个对话需要完整的10.4到10.8秒重新读取。每次切换都会丢弃该会话已经读取过的内容。在单个会话内部，前缀缓存已经生效——同一个会话中重复30k的提示只需0.07秒，追加轮次耗时0.07到0.32秒。但跨会话没有任何内容被保留，每次切换都要付出完整的重读代价。

解决方案是三个参数：--prompt-cache 3 --conversation-cache-mib 4096 --conversation-cache-slots 4。启用后，停驻的对话在交替切换中得以保留，同样的测试从10.8秒降到0.4秒。一个意外的副作用是，跨会话的共享前缀命中了相同的系统提示根检查点，冷启动的定时任务几乎零成本返回，parktest后的30k读取从10.3秒降到5.3秒。

但代价随之而来。在4096 MiB和4个槽位配置下，会话内的小读取从干净的0.07秒增加到每轮多出0.15到0.35秒。Agent循环恰恰是持续的小读取场景。降到3072 MiB和3个槽位后，偶发的尾部延迟恢复到接近原始水平。最终配置比最初能工作的配置更小——代价就是原因。

关于前缀缓存与 KV 缓存

理解这一节的关键在于区分两个层级：KV 缓存和前缀缓存。KV 缓存（键值缓存）是 Transformer 推理的核心机制——每生成一个 token，模型都需要之前所有 token 的注意力键值对，缓存它们可避免重复计算，但内存占用随上下文长度线性增长。文中 32768 行 KV 缓存常驻、6.19 GiB 固定在内存，即为此。

前缀缓存则作用在更上层：当新请求的开头部分与之前某次请求完全相同时，引擎可以直接复用那段前缀对应的 KV 状态，跳过整段预填充（prefill）。但传统实现通常只保留"最近一次"请求的前缀，一旦切换到另一个会话，原有前缀就被覆盖。开发者启用的 --conversation-cache-slots 4 本质上是让引擎为多个会话分别保留独立的前缀快照（停驻的对话），这正是跨会话切换从 10.8 秒降到 0.4 秒的原因。

代价在于显存：每个槽位都要占用一份 KV 状态，而 24.5 GiB 显存已被专家缓存（13.94 GiB）、KV 常驻、MTP 草稿头等瓜分殆尽，因此槽位和 MiB 数必须精细权衡——降到 3072 MiB/3 槽位后，会话内小读取的额外开销才回到可接受范围。

贪婪采样的陷阱

第二个失败来自请求形态。开发者的Agent栈在向本地提供商发送请求时不带采样参数，而引擎在没有收到采样参数时使用默认的贪婪解码。贪婪模式在IQ1_M量化的编程模型上会产生循环——同一个token序列反复重复。

修复方法是在服务JSON中添加采样配置块：temperature 0.6、top_p 0.95、top_k 20。runconfig.py第20-24行确认这些键被正确接收。解码速度保持在探针范围内，这里获得的是正确性而非性能。

关于贪婪解码与 IQ1_M 量化

贪婪解码（greedy decoding）指每一步都选择概率最高的 token，不引入任何随机性。它看似"最准确"，但在低比特量化模型上极易陷入退化循环：由于权重量化损失了大量数值精度，模型对某些 token 序列的评分会出现病态的高峰值，导致同一段文字被反复输出，无法自行跳出。

temperature、top_p、top_k 正是打破这种确定性的三个旋钮。temperature 0.6 将 logits 除以温度后再做 softmax，使分布更平坦；top_p 0.95（核采样）只保留累积概率前 95% 的候选；top_k 20 进一步限制候选数量。三者叠加使采样具备适度随机性，从而绕开量化模型的高分陷阱。

IQ1_M 是 llama.cpp 系列中一种约 1 bit 级的极限量化格式（"M"表示混合精度），专为在有限显存中塞下大参数模型而设计，代价是输出质量下降和上述的循环风险。这也解释了为何开发者强调这一修复"获得的是正确性而非性能"——解码速度并未改变，只是让模型停止自我重复。

专家交换窗口的重叠优化

一次解码窗口的测量显示了18.76毫秒的总耗时，其中路由加计划加bell占2.36毫秒，VRAM命中2.29毫秒，等待约1.1毫秒，头部0.93毫秒。专家层在窗口之间交换槽位，这意味着每个窗口中交换都是纯粹的等待时间。

启用STRATA_ADAPT_OVERLAP=1后，交换在解码过程中完成。变更后的日志显示“130个窗口中交换仍在落位，总共等待0.11毫秒”，窗口时间从18.76毫秒降到17.73毫秒，解码中位数从91.9-92.6提升到95.6。另一个方案--adapt-async 1的中位数为92.6，两者存在冲突，因此重叠方案胜出，异步方案当天就被放弃了。

关于专家交换与计算重叠

文中引擎采用自适应专家层（RemoteExpertOpt::adapt、PeerExperts::adapt）架构，可类比 MoE（混合专家）思路：不同输入激活不同专家子集。当所需专家不在显存中时，必须在解码窗口之间从主机内存或对端交换槽位。传统串行流程中，这一交换发生在一个窗口结束、下一个窗口开始之前，GPU 只能空等，实测约 1.1 毫秒纯等待。

STRATA_ADAPT_OVERLAP=1 的作用是把交换操作搬到解码计算进行的同时（即用 CUDA 流或异步拷贝与计算内核并发），让 PCIe 传输和 GPU 算力互相掩盖。日志中"130 个窗口中交换仍在落位，总共等待 0.11 毫秒"正是重叠生效的证据——原本每窗口必付的固定等待被压缩到近乎为零。

作者还对比了 --adapt-async 1，其解码中位数为 92.6 而重叠方案为 95.6，说明异步方案虽也试图并行化，但调度粒度或同步点不同，反而引入了额外开销，因此被放弃。这一案例表明，并发优化的收益高度依赖具体实现路径，必须用实测数据而非直觉来选型。

两个工程陷阱

serve/server.py使用缓存的参数启动引擎，因此编辑JSON文件不会有任何效果，直到服务重启。磁盘上的文件看起来正确，但运行中的引擎参数不同。一次重启需要18-19秒，然后轮询/v1/models并进行真实的对话探测才能确认。

calibrate命令会启动自己的引擎实例并独占显存，因此必须先停止服务。开发者第一次运行校准时，工作线程和自适应专家层的分支全部启动失败，因为刚停止的引擎仍持有显卡。那次运行的每一个数字都是无效的。

测试后放弃的方案

开发者还测试了六个看似合理但没有效果的参数，每个都有数据记录：

• KV预取：成功激活并记录了层前缀，66k预填充前后都是18.0秒。在PCIe 4上完全没有效果。
• 融合int8预填充内核：成功激活，30k预填充从10.44秒变成10.53秒。在IQ1_M量化上毫无作用。
• --prefill-head-alias：需要关闭短读取，每次提示读取都要付出0.3-0.6秒的头部重载代价。Agent循环是持续的小读取场景，净负面，分析后跳过。
• 大页内存：引擎需要11992个2 MiB的映射，内核只返回11170个，碎片化严重，MAP_HUGETLB始终不可用，预留会白白消耗22G内存。回退到零。
• 拒绝引导速度预测：每token成本0.2-0.4%，但会改变模型行为。放弃。
• 上游0.1.44.1版本：11个提交的修复，没有性能相关改动。跳过以避免风险。

最终数据与经验总结

在相同的探针、交叉执行、相同会话条件下，短解码从108.7 tok/s提升到121.5 tok/s，提升12%。预填充从2998 tok/s到3004 tok/s基本持平——所有收益都在解码侧。会话交替从10.4-10.8秒降到0.2-0.5秒，约25倍提升。同时启用了持久化模式（nvidia-smi -pm 1），该设置原本是关闭的，且不会在重启后保留。

开发者给出了两条核心经验。第一，先测量访问模式再调参数——25倍的提升来自会话交替的方式，与引擎本身无关，一个永远保持单一对话的探针永远不会发现这个问题。第二，死胡同本身就是交付物——六个看似可行的参数各自附带了数据，让下一个人不必再花一天重新测试。

硬件配置为Ryzen 7 5800X、64G DDR4、RTX 3090 24G，PCIe 4.0实测主机到设备带宽25.9 GB/s。测试使用IQ1_M编程量化模型，冷缓存探针。