RW-TTT：为带请求自有状态的测试时训练模型提供批量服务，吞吐量提升9.31倍
一组研究者在arXiv发布RW-TTT系统，通过为解码步骤标记所有者和读写效应，实现了对带快权重等请求自有状态的模型的安全批量推理，使吞吐量达到串行执行的9.31倍。
AI解读：这篇论文解决的是：当大模型在生成过程中需要为每个请求单独更新状态（比如快权重）时，传统的批量推理会失效——因为批量推理假设所有请求共用一套固定的模型权重，而每个请求的状态更新会相互污染。RW-TTT的做法是给每个解码步骤打上“属于哪个请求、哪个版本、是读还是写”的标签，只合并那些互不冲突的阶段，并且只在更新完成后写回给对应的请求。这样既能保持批量推理的速度，又不会破坏每个请求的状态。结果是，在同一块GPU上服务8个需要快权重的请求时，RW-TTT能达到每秒27.4万多个token，比一个一个串行执行快9.31倍，比每个请求单独复制一份模型（在相同内存下）快3.44倍。如果你是在部署TTT类模型的推理服务，这项技术意味着可以用更少的GPU处理同等规模的请求，或者在相同GPU上支持更多并发用户。不过需要注意的是，这只是论文报告的数据，实际部署效果可能因模型和硬件不同而有差异，而且系统目前主要针对内存受限的单GPU场景。
来自Meta、哈佛大学和微软的研究者近日在arXiv发表论文《RW-TTT: Batched Serving for Request-Owned Test-Time Training State》，提出一种名为RW-TTT的系统，允许对具备请求自有状态（request-owned state）的测试时训练（TTT）模型进行批量推理，解决了TTT模型因状态隔离需求而难以批量处理的问题。
论文指出，标准LLM推理服务依赖“共享静态权重”的假设，而TTT模型在生成过程中会读写每个请求独有的状态，比如快权重、低秩增量或流式学习状态。若串行执行虽然正确但速度慢，若简单批量处理则可能破坏请求状态。
RW-TTT的核心机制是为每个解码步骤打上所有者（owner）、版本（version）和读写（READ/WRITE）效应的标签，只批量处理兼容阶段，并且只将更新提交给对应的请求所有者。
在单块GPU上运行8条使用快权重的InPlace-TTT流时，RW-TTT达到了274.61 token/s的聚合吞吐量，相比串行处理提升9.31倍，相比同内存预算下每流独立复制模型的方式提升3.44倍。论文还称，在长文本基准RULER上的行为保持一致，并顺利通过了所有者和版本检查。