[Hotstorage-chairs] [HotStorage 2026] Rejected, but invited as poster, submission #95 "Position: TokenStore: Towards..."

[HotStorage 2026 HotCRP]

Dear authors,

The program committee for the 2026 ACM Workshop on Hot Topics in Storage 
and File Systems (HotStorage 2026) regrets to inform you that your 
submission 95 was rejected to appear in the proceedings of the workshop.

However, your work incited exciting discussion among the program 
committee members, and we would like to invite you to present your work 
during the poster session. Please let us know by August 12, 2026 
(Wednesday) whether or not you accept or decline the poster invitation.

* Title: Position: TokenStore: Towards Token-Native Video Storage for 
  Visual AI Agents
* Site: https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fhotstorage26.hotcrp.com%2fpaper%2f95&c=E,1,QXLyuRxO0O4hgi99YURlBnfDx0DlvNcpPsXJuxvLL-d5IFqmKGcUjU4w8crxztCVn-UPrplUPHZc7LwVKiOMNz0Y09VvT_capF1VnnoGeeCKym530NYVum-t4Q,,&typo=1

23 of 78 submissions were accepted.

Visit the submission site for reviews, comments, and related 
information. Reviews and comments are also included below.

Contact chairs26 at hotstorage.org with any questions or concerns.

Sincerely,
Young-ri Choi and Bryan S. Kim
HotStorage 2026 Program Co-Chairs

Review #95A
===========================================================================

Overall merit
-------------
3. Weak accept

Reviewer expertise
------------------
3. Knowledgeable

Paper summary
-------------
This paper proposes Token Native Storage (TNS), which stores and reuses vision tokens to reduce the cost of repeated vision token generation in VLM workloads. By eliminating the expensive vision encoding stage, the approach significantly improves latency while further reducing storage overhead through quantization and pruning. Experimental results show that TNS consistently outperforms both a naïve baseline and KV-cache reuse in terms of cost, energy consumption, and TTFT, while the storage overhead of maintaining the vision token store remains substantially smaller than storing the original video content.

Comments for authors
--------------------
Strengths
- Provides a comprehensive analysis of the cost and energy implications of vision token quantization and storage, complementing prior work that primarily focused on latency and accuracy.
- Introduces multiple token renditions with different pruning levels and demonstrates workload-aware routing, providing a promising direction for future optimization research.
- Clearly motivates the problem by quantifying that vision encoding accounts for an increasingly dominant portion of TTFT (up to 80%) as pruning becomes more aggressive.
- Highlights that vision token size is independent of the LLM backbone, making the storage advantage over KV cache increasingly significant as LLMs scale.

Weaknesses
- The evaluation is limited to a single compression configuration (PQ128 with 25% token retention), leaving important trade-offs such as different compression ratios, dequantization overhead, and storage overhead for multiple token renditions unexplored.
- The paper combines several existing techniques, making it difficult to clearly identify the novelty of the proposed approach.
- The key assumption that the same video is queried repeatedly in real deployments is not sufficiently justified with workload evidence.
- Most experimental results are reported under a fixed configuration (25% retention, PQ128, and 50% KV hit ratio), and the rationale for selecting this operating point is insufficient. Moreover, the chosen retention ratio appears inconsistent with the accuracy degradation observed in Fig. 3(a).

Detailed Comments

First of all, thank you for your submission to HotStorage 2026. I found the paper interesting and enjoyed reading it. However, I have several concerns that should be addressed, either in a revision or as part of future work

This paper primarily advocates a new perspective—treating vision tokens as reusable first-class storage objects—rather than introducing a fully developed system or a fundamentally new algorithm. This perspective is timely given the growing importance of visual AI agents and effectively highlights the computational cost of repeated vision encoding. In particular, the observation that vision token size is determined solely by the vision encoder, and is therefore independent of the LLM backbone, is an insightful contribution. As LLMs continue to scale, the storage advantage over KV caches is expected to become even more pronounced.

However, the paper relies on two important assumptions that are not sufficiently supported. First, its economic benefit depends on the assumption that the same video is queried repeatedly in practical deployments, yet the paper provides little evidence regarding real-world access patterns or query frequency. Second, nearly all evaluations are conducted under a fixed configuration (25% token retention, PQ128, and 50% KV hit ratio). The rationale for selecting this operating point is unclear, and the chosen retention ratio appears inconsistent with the paper's own Fig. 3(a), where the accuracy of the count task drops significantly. As a result, the reported headline improvements appear to reflect a favorable operating point rather than representative performance across a broad design space. Furthermore, the evaluation does not quantify practical overheads such as compression/decompression costs or token transfer overhead.

>From a novelty perspective, the two primary building blocks of the proposed approach substantially overlap with existing work. First, caching and reusing vision tokens across requests has already been explored in systems such as vLLM and LMCache. Second, the observation that a single fixed pruning ratio is not optimal across all inputs is also well established. For example, SmartTrim showed that applying a uniform token pruning ratio causes significant accuracy degradation on difficult inputs and proposed adaptive pruning strategies accordingly.

I acknowledge that this work offers a novel perspective from the standpoint of storage systems. However, this key novelty is not sufficiently highlighted in the current manuscript. I therefore encourage the authors to strengthen the discussion of related work, clearly articulate how their approach differs from existing solutions, and more explicitly emphasize the originality and unique contributions of their work.


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


Review #95B
===========================================================================

Overall merit
-------------
3. Weak accept

Reviewer expertise
------------------
3. Knowledgeable

Paper summary
-------------
The paper proposes TokenStore, a token-native storage layer for visual AI agents. It proposes a dedicated caching layer for video, storing vision tokens, thus reducing re-computation.

Comments for authors
--------------------
The paper makes the right hypothesis that there is a point where caching "knowledge" in a format understood by the accelerator is better than recomputing it. This can be caching in memory or storage. This is a real improvement, and it is good that more research is done, on top of industrial deployment of existing KV$ systems.

However, I do not understand how caching vision tokens are significantly different or better than existing work on KV$s. While there is an argument to be made that vision tokens can operate cross-model, there is no evidence in the paper that this is achieved. In my opinion, the authors need to (i) articulate how vision tokens are different or more relevant than storing the KV$, and (ii) explain why if KV$s are not good enough (e.g., model-dependent), the research cannot be focused on improving them.

Besides the above, the proposal is purely architectural and there is no experimentation. While HotStorage is a good place to positioning papers, I believe that a small POC is important to have a first experimental validation of the idea.


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


Review #95C
===========================================================================

Overall merit
-------------
2. Weak reject

Reviewer expertise
------------------
3. Knowledgeable

Paper summary
-------------
This paper proposes TOKENSTORE, a token-native storage layer situated beneath the KV cache that persists vision tokens materialized from videos as durable, reusable artifacts. By storing compressed and quantized vision tokens in remote object storage, the system aims to bypass the recurring GPU-intensive vision encoding stage during repetitive queries of the same video, significantly reducing Time-to-First-Token (TTFT) and total serving cost.

Comments for authors
--------------------
Dear Authors,

Thank you for your submission to HotStorage 2026. We appreciate your focus on the intersection of multimodal model serving and video storage architectures, particularly around optimizing visual AI agent workloads.

### Strengths and Weaknesses

**Strengths:**
* **Timely Domain:** Addressing the compute bottleneck of video-language model (VLM) prefilling is a highly relevant problem for high-concurrency visual agent systems.
* **Detailed Trade-off Analysis:** The paper provides a systematic comparison between storing raw video, full KV caches, and intermediate vision tokens.
* **Effective Compression Approach:** Employing product quantization (PQ) and attention-based pruning enables highly compact token representations.

**Weaknesses:**
* **Lack of Architectural Novelty as a Storage System:** The paper proposes a separate "storage system" abstraction, but the design resembles a localized software library layer built on top of standard object storage (like AWS S3) rather than a distinct storage engine.
* **Unrealistic TCO Assumptions:** The Total Cost of Ownership (TCO) calculations assume that storing tokens replaces storing raw video. In practice, platform providers must almost certainly retain the raw video anyway for human playbacks, compliance, or token re-generation when models change.

---

### Detailed Comments

The paper pitches TOKENSTORE as a novel, token-native storage system. However, the described ingestion, manifest cataloging, and retrieval mechanisms do not seem to require a dedicated, custom storage engine. A general-purpose object store (such as Amazon S3) integrated with a lightweight, client-side Python/Go SDK could easily handle manifest serialization, token compression, and object mapping. 

* **Question 1:** Why is a specific-purpose storage engine needed here? Why can't this be fully implemented as a specialized software library wrapping a standard object store client? Please clarify the unique system-level or network-level primitives that TOKENSTORE provides which a library cannot.

The paper's use of a "queries per year" metric to demonstrate a low break-even point (e.g., $N^* \approx 4.4 \text{ to } 7.1$ queries/year) is mathematically sound. It highlights an important property of token-native storage: the physical storage overhead of quantized tokens is exceptionally cheap (\$0.12/year) compared to GPU re-encoding costs (~\$0.11/query). This proves that even for extremely cold, long-tail video access patterns, persisting tokens is economically viable in a vacuum.However, the practical limitation of this TCO model is that it assumes token-native storage allows the system to substitute or discard the raw video. In production environments (e.g., surveillance, compliance, smart cities), the raw video must be archived regardless. When the raw video must be kept, the token storage cost becomes strictly additive rather than substitutional.

* **Question 2:** If a platform is legally or operationally required to retain the raw video, how does the additive cost of maintaining both representations affect your break-even calculations?
* **Suggestion:** Please provide a secondary cost curve that factors in raw video retention as a constant baseline, showing the true marginal cost of adding a token-storage layer.


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


Review #95D
===========================================================================

Overall merit
-------------
2. Weak reject

Reviewer expertise
------------------
2. Some familiarity

Paper summary
-------------
The paper presents an interesting and valid idea. The initiation of the idea is simple: storing video tokens can save the initial processing step for an additional storage cost. The authors show that the cost breakeven point is when 4-7 queries use the same video input. For the performance, the proposed approach improves TTFT and lowers resource utilization. This indicates that there is always a benefit for using the proposed approach, and there are cost benefits if there is a lot of sharing.

Comments for authors
--------------------
One point that weakens the paper's argument is that while the KV cache is model-specific, the vision tokens are encoder-specific. Changing an encoder or upgrading the encoder will make the tokens not shareable between queries. So I am not sure if there is a case for wide sharing of video over a short period of time, such that all sharing uses the same encoder.

Related to the point above, different queries need different sampling and tokenization of the video. Queries that ask detailed questions need higher-resolution videos compared to queries that only ask about the general story. You may end up encoding every video at the highest level of accuracy, which may cost you more.

I feel the paper leaves a critical aspect of the design vague. Figure 3 shows that in some cases, it is sensitive to the level of pruning. Consequently, the author's statement “selecting the appropriate one based on model, query, and access pattern.” Is not a trivial nor obvious task. If you cannot select the correct pruning level, you will process 100% of the tokens, reducing the benefits of the proposed approach.

No sure why every video is encoded and the tokens are stored. This seems to impose a fixed cost even for videos that are not used or shared. Maybe a middle ground to decide when tokens need to be stored. Maybe store tokens after the first use or the second use to capture videos that are used or capture videos that are potentially shared. This will change your analysis.

It will be interesting to see the performance of the KV cache only with different hit ratios.


Comment @A1 by Reviewer A
---------------------------------------------------------------------------
The PC members carefully discussed this paper but ultimately decided not to accept it due to concerns regarding insufficient differentiation from prior work, questionable system contribution, unrealistic deployment assumptions, and limited experimental validation. That said, we appreciate the paper's attempt to introduce Token-Native Storage for reusing vision tokens, which we believe is a promising direction. We hope the reviewers' feedback will help strengthen the paper for a future submission.