每年HPCA上最吸引我的，永远是那类敢于把系统栈切开来重新缝合的工作。V-Rex就是一篇典型的软硬件协同设计论文，目标非常明确：让流式视频理解这种重负载LLM推理任务，在边缘端设备上真正做到实时。如果你一直在做LLM推理优化、边缘端部署，或者对KV Cache的硬件加速感兴趣，这篇值得认真读几遍。
先说清楚V-Rex解决的痛点。流式视频LLM推理，不是一次性把整段视频塞进模型，而是视频帧持续进入、模型持续输出理解结果。这种场景下，KV Cache的体量随视频时长远超文本对话，同时每一帧新增的视觉Token让KV Cache不断增长，显存占用和带宽压力特别大。边缘端设备本身计算和显存受限，通常还和CPU共用一块存储带宽，稍微处理不好延迟就会飙升。
V-Rex的核心思路，是把KV Cache的检索和调度做成一个软件、硬件协同设计的系统。软件层面负责策略和预测，硬件模块负责快速检索和淘汰，两者配合，让流式视频推理过程中KV Cache的增长和清理变得足够便宜，从而在边缘端保持低延迟。这篇文章我会拆开讲几个核心维度：这个问题为什么难、V-Rex怎么设计、软硬件接口怎么处理，以及我尝试复现这个思路时踩过的一些坑。
1. 为什么流式视频LLM在边缘端这么难跑
1.1 边缘端的“三堵墙”
边缘端做流式视频LLM推理，先撞上三堵墙：算力墙、显存墙和带宽墙。算力墙大家都熟，边缘端的NPU或者低功耗GPU，算力上限比数据中心差一个数量级。显存墙更直接，视频帧转换为Token之后，每帧在KV Cache里占据的空间远大于输入本身，几分钟的视频就可能让KV Cache膨胀到数千甚至数万个Token的规模，边缘设备那几GB统一内存根本不够塞。带宽墙则是很多人容易忽视的，边缘端芯片的内存带宽普遍在几十GB/s的量级，比数据中心的HBM带宽低一个量级，KV Cache一旦过大，每一轮Decode都要反复搬运KV数据，这部分时间很快超过计算时间。
举个例子，假设一个视频每一帧产生128个视觉Token，每秒处理5帧，一分钟的视频就会产生38400个Token的KV Cache。按每Token 0.5KB的KV大小估算，一分钟视频的KV Cache就有大约19MB。这个数字看起来不大，但如果同时多层多头累积，加上文本部分，以及交互历史，几分钟的持续会话就能把边缘端的显存吃满了。而如果KV Cache被换到CPU内存，每一轮Decode都要把相关KV从系统内存搬到加速器里，这种搬运延迟是灾难性的。
1.2 KV Cache膨胀与动态性
文本对话场景里，KV Cache的增长是可预测的，大概按对话轮次线性增长。流式视频场景不一样，视觉信息的到达是不间断的，模型还要频繁引用早期帧内容来做时空理解。也就是说，KV Cache不仅膨胀快，而且大部分旧内容都不能简单丢弃——你删掉那一帧的KV，模型就没法对后来的事件建立时空关联。
这带来一个很棘手的问题：流式视频推理需要“动态KV Cache检索”。模型不是顺序把整个KV Cache读一遍，而是需要根据当前帧内容，快速找到之前保存的、相关视频片段对应的KV，把它们拉回缓存参与Attention计算。这个检索动作如果桩桩件件走通用内存访问，那边缘端的延迟完全扛不住。硬件的检索单元和软件调度策略，必须围绕这种“长期存储+按需召回”的访问模式重新设计。
1.3 为什么需要软硬件协同
纯软件方案行不行？可以做，但代价很大。常见做法是定期把旧KV写回CPU内存，需要时再拷回加速器。但每一次拷贝都涉及驱动、DMA和同步开销，而且软件没法精确预测硬件缓存行被替换的时间点，很多拷贝实际是白做的。纯硬件方案也不行，没有软件策略的硬件加速器只会机械地按淘汰算法清理缓存，无法感知视频内容的重要性差异。
V-Rex的价值就在这里：软件决定“什么重要、什么时候取”，硬件负责“便宜地完成取和放”。软硬件的明确分工让系统既能适应视频内容动态变化，又能把检索和淘汰的开销压到极低。边缘端设备本来就没有数据中心那么强的通用算力，这类专用协同设计反而是更合理的路线。
2. V-Rex的核心设计：动态KV Cache检索
2.1 从“缓存”到“检索”的思路转变
一般提到KV Cache优化，大家第一反应是量化、剪枝、或分页管理，本质上是把KV Cache当成一块需要省着用的存储。V-Rex换了一个角度：既然视频推理有明确的时间局部性和内容局部性，真正该做的是让系统像搜索引擎一样，能从大块历史KV里快速找出当前计算需要的那一部分。
这种设计思路的转变，对边缘端特别有意义。如果设备可以高效地只加载“相关帧”的KV参与Attention，那KV Cache整体放在更慢的大容量存储里也问题不大。检索的精准度和速度成为新的性能瓶颈。V-Rex把检索相关工作从CPU/GPU打出去，用专用硬件模块处理，让检索成本趋近于查表，而不是真正的搜索。
2.2 三条设计主线
第一条主线是分层的KV存储。加速器片上留一小块最近使用的KV，片外内存放中间层，CPU系统内存作为长期存储。软件维护一个跨层的逻辑索引，记录哪些Token的KV在哪一层、属于哪一帧。第二条主线是专门的硬件检索单元，扫描索引结构并预取下一轮可能用到的KV，硬件单元能够识别视频帧之间的相似性，不只是按地址连续读取。第三条主线是软件层的动态一致性协议，因为剪裁、淘汰KV会对模型推理结果产生影响，软件必须决定什么时候允许淘汰、淘汰哪些帧，而硬件负责执行。
这三条主线缺一不可。没有分层，放不下；没有硬件检索，取不快；没有一致性协议，代码跑几次结果都对不上。
2.3 与通用KV淘汰策略的差异
现有KV缺少管理工具，像H2O、StreamingLLM的思路，大部分靠注意力分数观察决定哪些KV可以丢。这类方法在文本场景好使，但视频场景却会失效。视频的理解经常依赖“看到某个物体后来运动发生变化”这种跨帧引用，单看注意力分数最高的片段未必是未来最需要的。
V-Rex不是用注意力分数做淘汰依据，而是靠时间窗口、内容显著性以及用户交互的引用模式来综合判断。这样更贴合视频流的特征。硬件检索单元还会进一步修正软件决策，如果发现某一帧的KV被连续频繁访问，会自动提升该帧的存储优先级，阻止软件过早淘汰它。这种双层决策机制比纯软件方案稳很多。
3. 硬件模块与调度策略：从设计到实现
3.1 存储分层与检索硬件加速
V-Rex的硬件层面可以理解成三部分：KV预取引擎、索引扫描器和优先级标记器。KV预取引擎观察Attention模块正在读取哪些帧的KV，并预测下一轮会读取哪些邻近帧的KV，提前搬到片上缓存。索引扫描器遍历帧级索引表，逐帧判断是否有需要加载到片上缓存的条目。优先级标记器跟踪每个KV Cache行的命中频率和最近使用时间，动态调整淘汰顺序。
这三个硬件模块都不需要高精度浮点运算，只是地址计算和比较操作，所以占用的芯片面积和功耗都很低。特别适合边缘端，不需要为了这套机制增加几十瓦功耗。实现时，RTL设计大概控制在几个平方米毫米级别，比一块NPU核心小得多。
3.2 软件调度：卷帘式策略和过期驱逐
V-Rex的软件调套路，我印象深刻的是把视频推理当成一个滑动的卷帘窗口处理。当前处理帧在窗口中心，窗口内的KV全部保留在片上，窗口外的KV按淘汰策略降级到片外或系统内存。窗口大小由硬件容量实时决定，如果片上缓存吃紧，调度器会压缩窗口并提前触发淘汰。
过期驱逐策略也很有意思。不是所有旧KV都必须删，而是依据“这一帧是否还会被后续内容引用”来做判断。比如场景检测发现镜头切换了，那么前一镜头的KV会被标记为可驱逐；如果后续再次出现相似背景，预取引擎可以重新从长期存储中拉回这些帧的KV。
这些策略如果用纯软件实现，每次Attention都要在后台遍历查找表，开销大得离谱。V-Rex把决策放在软件、执行放在硬件的做法，其实是在工程效率和灵活性之间找到了一种不错的平衡。
3.3 一个边缘端流式视频会话的数据流
假设边缘设备正在跑一个实时摄像头分析任务，每秒输入5帧。第1步，NPU接受解码后的帧输入，视觉编码器抽出Token，Attention模块开始计算。此时KV预取引擎提前从系统内存里把之前10帧的KV预取到片上缓存。第2步，Attention计算过程中，索引扫描器发现当前帧与第40帧的背景高度相似，于是将第40帧的KV列入下一次预取队列。第3步，当前窗口处理完毕，滑动到下一帧，过期驱逐逻辑把最早几帧的KV写出到片外缓存，空间空出来给新帧使用。第四步，如果需要生成文本理解结果，生成阶段再次利用片上保留的当前窗口KV配合预取的历史相关帧KV，完成交叉Attention。
整个过程中，NVMe/DRAM访问都被硬件调度得井井有条，NPU几乎不会因为等到KV数据而空转。
4. 软硬件接口与实现细节
4.1 缓存行粒度的KV管理
KV Cache管理的一点，粒度选择很关键。如果按整个张量或按整个帧的粒度管理，调度不灵活——某帧只有部分Token被高频引用，整帧保留反而浪费空间。如果按单个Token粒度管理，元数据开销又太大，特别是视频Token数量动辄上万。
V-Rex采用的是缓存行粒度的管理，以KV Cache的固定尺寸块为最小单位，512字节或1KB。这样预取、淘汰、索引都围绕这些缓存行进行，既能精细控制，又不像Token粒度那样代价高昂。处理时，硬件把KV Cache组织成一组组固定大小的行，每个行记录所属帧号、Token号和当前层级。预取引擎读取这些行，判断时效。
4.2 与算子融合和调度器的协作
KV检索涉及的内存移动，如果每次移动都穿透到CUDA或OpenCL API，边缘端延迟根本受不了。V-Rex选择把预取操作直接编译进算子图里，让调度器在生成计算任务的同时下发预取指令。
具体来说，调度器看到模型结构里包含Attention层时，会在任务前插入一组KV移动指令，这些指令由硬件检索单元直接执行，不走通用驱动路径。这种方式听起来简单，实际对编译器前端要求很高，需要对模型计算图做依赖分析，确保预取不会覆盖当前正在计算的数据。实现时常见做法是把算子图转成中间表示，再单独做一轮KV访问分析，把所有Attention节点涉及到的KV范围提炼出来。
4.3 精度与可复现性
很多时候，为了性能做KV淘汰会影响模型精度。V-Rex并没有直接声称“无损”，而是通过设计保证“可复现的损失可控”。做法是通过索引记录每次淘汰的KV范围，结合验证集上统计的注意力分布，给每个淘汰决策打一个重要性分，只有在重要性低于阈值时才允许硬件真正丢弃。
如果你拿来在自己模型上做实验，建议多做几组视频输入，统计真正被淘汰的KV占总KV的比例。如果比例超过5%，模型输出大概率已经肉眼可见地漂移了。软件调参时，优先调整的是窗口大小而不是淘汰阈值，窗口太小会导致大量频繁召回，反而把预取引擎打满。
5. 实测效果与踩坑经验
5.1 性能预期和瓶颈
V-Rex论文里给出的数据，如果复现条件到位，效果确实明显。延迟降低，得益于KV预取消除了Attention阶段的大量等待。吞吐提升，因为片上缓存命中率提高了，片外带宽占用降低。功耗表现也不错，专用硬件模块省去了软件反复搬运的代价。
但有个瓶颈要特别注意：索引扫描器的扫描速度受限于帧索引表的规模。当会话时长超过半小时，索引表膨胀到一定规模时，扫描本身成为瓶颈。作者的做法是按时间分桶，只扫描最近若干个桶的索引，再靠长期索引兜底。
5.2 我复现和评估时踩过的坑
第一次复现这个设计思路时，我栽在硬件预取和软件淘汰的同步问题上。软件调度器如果提前淘汰了一部分KV，预取引擎还傻等它被读回来，预取队列会积压。后来在实现里加了版本号机制，每次淘汰都递增版本号，预取引擎发现版本不匹配就自动丢弃预取任务。
另一个坑是边缘端的内存分配器通常不支持大块连续内存，KV Cache分散在多个不连续区域。V-Rex的硬件索引模块需要的是连续地址扫描，这就导致大量地址解析开销。我的建议是，如果做FPGA验证，先把内存池化成固定大小的物理块，再用二级页表映射成连续的虚拟地址空间，这样硬件扫描逻辑能简化很多。
5.3 部署建议：什么场景值得用它
据我个人经验，如果只是做10秒以内短视频的分类任务，V-Rex这套设计是杀鸡用牛刀，纯软件KV Cache管理就够用。但如果你的场景是长时间的流式交互视频理解，比如AR眼镜辅助、智能监控流分析、车载多模态助手，那么V-Rex的设计思路很值得认真评估。
评估时先看三件事：你的KV Cache是否经常超过片上缓存的容量？Attention计算时间是否频繁低于数据搬运时间？你的交互端是否能容忍提前淘汰带来的一些偶发精度损失？这三个问题只要有一个是肯定的，就说明你需要类似软硬件协同的动态KV检索方案。
我在实际实现中最想提醒的一点，是别把硬件部分想得太复杂。KV预取、索引扫描和优先级标记，本质上都是地址运算，完全可以用简单的Verilog逻辑实现。真正的复杂度在软件和硬件之间的接口协议设计上，这一步没有做好，后续性能调试会非常痛苦。先把淘汰决策的全部语义在软件侧定义清楚，再让硬件做无脑执行，系统会稳定得多。
最后再分享一个小技巧：如果只是想验证V-Rex的软件策略部分对模型精度的影响，不需要写硬件。用普通PyTorch代码模拟分层存储，每一层之间用手动拷贝代替硬件预取，就能观察出不同窗口大小、不同淘汰策略下的精度曲线。有了这条曲线，再做硬件设计，你会对每个模块的意义理解得更清楚。
