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

[Jaehong Kim]

Dear Program Co-Chairs,

Thank you for the invitation. We appreciate the opportunity, but we would
like to decline the poster invitation.

Best,
Jaehong

2026년 7월 25일 (토) 오후 12:03, HotStorage 2026 HotCRP <
noreply-hotstorage26 at hotcrp.com>님이 작성:

> 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,L5x3YmXIH0JPMusJnixRSsJ8ZFVm6OdIbjuVteXndb2crmxN7re1rgtnmaofbO9w3xHh5KxQ7yaYKWENXwmClJnGUZS8uhcs3TBTB7GDLXhys6aQlHYTrvsKGaiU&typo=1
> <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fl.jumpto.es%2fl%2f3c1ba5c81db798e37a07d9fb3292f4bb639c7af1%3fu%3d14417039&c=E,1,V0uaMkQ1_PIxvmXTqLWrZm2vb68XDPBbdGEv6ZR1EBNaxpcLNKNPQEG4ojZZbA4jPo1bDkRCiq9aLqR0JnwyShWs8iNF5N7nrIDbX_-UFAXlorhorn0,&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.
>
>

-- 
Jaehong Kim
Assistant Professor, Department of Artificial Intelligence
Inha University, Republic of Korea
Web: *https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fjaykim305.github.io%2f&c=E,1,VioswpF3A0K3pYYZeK-0SOZFezzaeTY_-aXguYKF4Zzh4IvPYKZS3ZIuhKA1GORbpHs2BuxkkzzA0nKEO0BjuVnVTVdzYE2UWHHdmRP8TA,,&typo=1
<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fl.jumpto.es%2fl%2f2ab5ce5c1bea4af4337898a671d26825968f16c8%3fu%3d14417039&c=E,1,n7jX3hVa6rRLlum4uY8wAxt93XyHC_YM5qCQcXP7j7_Vmfu5t25HviM0MQSM6ZyLQLgeNXgSBFcoVsBpJMNFCsKniQ19pRHE9rW1PVm0fJw6G4LpCg,,&typo=1>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fsl.cs.sunysb.edu/pipermail/hotstorage-chairs/attachments/20260813/59639e5a/attachment-0001.htm>