論文の概要: LayoutBench: Performance Benchmarking of Cloud Storage Layouts for Multimedia Data
- arxiv url: http://arxiv.org/abs/2607.28880v1
- Date: Thu, 30 Jul 2026 22:49:54 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-08-03 14:29:40.513577
- Title: LayoutBench: Performance Benchmarking of Cloud Storage Layouts for Multimedia Data
- Title（参考訳）: LayoutBench: マルチメディアデータのためのクラウドストレージレイアウトのパフォーマンスベンチマーク
- Authors: Debopam Sanyal, Hongjie Chen, Alexey Tumanov, Joshua Kimball,
- Abstract要約: ストレージで物理的に整理されたデータセットは、どれだけ素早く安価に検索できるかに影響を及ぼす。
マルチメディアデータ検索において,ストレージのレイアウトがどう機能するかを評価するための最初のベンチマークを提示する。
ImageNet上では,検索時間,データ転送量,金銭コストを,それぞれ異なる結果セットの11のクエリを用いて測定する。
- 参考スコア（独自算出の注目度）: 3.923411972744016
- License: http://creativecommons.org/licenses/by/4.0/
- Abstract: Modern multimedia machine learning workloads increasingly store large-scale datasets in cloud object storage services such as AWS S3. How these samples are physically organized in storage (i.e.,storage layout) directly affects how quickly and cheaply they can be retrieved. Yet the benchmarks used to guide storage decisions today focus on database engines and query processing, and none systematically evaluates how different storage layouts perform for multimedia data retrieval. We present LayoutBench, the first benchmark designed to fill this gap. It evaluates three representative layout strategies: storing each sample as an individual object (L1), sequentially packing samples into tar archives (L2), and organizing samples as columns in Parquet files (L3). We measure retrieval time, data transferred, and monetary cost using 11 queries of varying result-set sizes on ImageNet across six AWS EC2 instance configurations that span different network bandwidth and memory tiers. Our experiments reveal that L2 achieves lower latency than L1 and L3 through connection reuse, but loses this advantage as retrieval sizes become very large. L3 is the fastest for very large retrievals but transfers substantially more data across all query sizes due to row-group granularity, and requires significantly more memory. Across all layouts, data transfer cost dominates total expenditure, with L3 costing an order of magnitude more than L1 or L2.
- Abstract（参考訳）: 現代のマルチメディア機械学習ワークロードは、AWS S3のようなクラウドオブジェクトストレージサービスに大規模なデータセットを格納する傾向にある。
これらのサンプルがどのように物理的にストレージに整理されているか(すなわちストレージのレイアウト)は、どのようにして素早く安価に回収できるかに直接影響を及ぼす。
しかし、今日のストレージ決定を導くために使用されたベンチマークは、データベースエンジンとクエリ処理に重点を置いており、マルチメディアデータ検索に異なるストレージレイアウトがどのように機能するかを体系的に評価するものではない。
このギャップを埋めるために設計された最初のベンチマークであるLayoutBenchを紹介します。
各サンプルを個々のオブジェクト(L1)として保存し、サンプルをtarアーカイブ(L2)に順次パッケージ化し、サンプルをParquetファイル(L3)で列として整理する。
私たちは、異なるネットワーク帯域とメモリ層にまたがる6つのAWS EC2インスタンス構成に対して、ImageNet上のさまざまな結果セットサイズの11のクエリを使用して、検索時間、データ転送、金銭的コストを測定します。
実験の結果,L2は接続再利用によってL1やL3よりも低レイテンシを実現するが,検索サイズが大きくなるにつれてこの優位性は失われることがわかった。
L3は、非常に大規模な検索では最速だが、行グループの粒度のため、クエリサイズ全体のデータ転送が大幅に増加し、メモリも大幅に増加している。
すべてのレイアウトにおいて、データ転送コストが総支出を上回り、L3はL1やL2よりも桁違いにコストがかかる。
関連論文リスト
- Filesystem-Based Memory for LLM Agents: Organization, Evolution, and Sustainability [49.415740364852105]
デプロイされたエージェントは、エージェント自身がジェネリックファイルツールを通じて読み込み、書き込み、再編成するマークダウンファイルのディレクトリツリーとして、長期記憶をますます保持する。
以前のシステムではメモリ表現を設計し、それらを検索し、デフォルトの2つの動作仮定を未検証のまま残した。
LLMエージェントのためのチャンクベースメモリの最初の体系的探索を行う。
論文 参考訳（メタデータ） (2026-07-29T08:59:43Z) - Memory as a Controlled Process: Learned Adaptive Memory Management for LLM Agents [72.3752981234916]
大きな言語モデル(LLM)エージェントは、タスク間の経験を蓄積するために、外部メモリシステムに依存している。
メモリ操作をマルコフ決定プロセスとしてモデル化するフレームワークである制御プロセス(MemCon)としてメモリを提示する。
MemConは、複数のメモリベースラインのタスク成功率を最大15.2ポイント上回り、トークン消費量を5-20%削減している。
論文 参考訳（メタデータ） (2026-07-15T08:32:40Z) - BitNet Text Embeddings [104.29781473344813]
BITEMBEDは,符号化効率とベクトル記憶を両立させるLLMベースのテキスト埋め込みのための極低ビットフレームワークである。
BITEMBEDは、トレーニング済みのLLMバックボーンを3次重み、量子化アクティベーション、軽量な正規化改善を備えたBitNetスタイルの埋め込みエンコーダに変換する。
Qwen3-0.6B と Gemma703-2M を用いた MMTEB (eng) の実験では、BITEMBED は完全精度の教師埋め込み器とほぼ同等であることが示された。
論文 参考訳（メタデータ） (2026-06-24T10:37:01Z) - Rethinking RAG in Long Videos: What to Retrieve and How to Use It? [56.38819694781005]
V-RAGBenchは$langle$query, evidence chunk, answer$rangle$三重項のベンチマークで、検索と生成を忠実に分離した評価を可能にする。
また、CARVEは、コンフィグレーションにまたがって並列レトリバーを動作させ、チャンク毎に入賞構成を識別するためにチャンク適応リランクを用いる手法である。
論文 参考訳（メタデータ） (2026-06-11T10:05:49Z) - Scaling Teams or Scaling Time? Memory Enabled Lifelong Learning in LLM Multi-Agent Systems [36.7638915908205]
大規模言語モデル(LLM)マルチエージェントシステムは、2つの異なる次元に沿ってスケールすることができる。
チームサイズと生涯学習能力を共同で検討するマルチエージェントシステムの概念的スケールビューを導入する。
フレキシブルメモリトポロジに基づくLLMマルチエージェントシステムのための生涯メモリフレームワークである textbfLLMA-Mem を提案する。
論文 参考訳（メタデータ） (2026-03-27T19:34:23Z) - Larger than memory image processing [0.7161783472741748]
本報告では、1.4PBの電子顕微鏡ボリュームや150TBのヒト臓器のアトラスなどのペタスケールデータセットのメモリ画像解析について述べる。
ストリーミングがデータを通過するときの構造化分析が重要であることを示す。
3Dボリュームでは、2Dスライス(ディレクトリやマルチページTIFFなど)のスタックと3Dチャンクレイアウト(Zarr/HDF5など)の2つの表現が人気である。
ディスクI/Oを最小限に抑える方法で、スライスベースのストリーミングアーキテクチャをどちらの画像表現の上に構築する方法を示す。
論文 参考訳（メタデータ） (2026-01-26T12:02:41Z) - REIS: A High-Performance and Energy-Efficient Retrieval System with In-Storage Processing [8.574396262432522]
大きな言語モデル(LLM)は固有の課題に直面します。
Retrieval-Augmented Generation (RAG)は、LLMの静的トレーニングに基づく知識を外部知識リポジトリで補完する。
本稿では,これらの制約を3つのキーメカニズムで処理するRAG用に設計された最初のISPシステムであるREISを提案する。
論文 参考訳（メタデータ） (2025-06-19T16:26:51Z) - Tuning LLMs by RAG Principles: Towards LLM-native Memory [27.236930156936356]
メモリを生成プロセスに組み込む2つの主要なソリューションは、長文LLMと検索拡張生成(RAG)である。
本稿では,3つの更新/更新データセットに対して,これらの2種類の解を系統的に比較する。
本稿では,RAG法則に従って生成されたデータを用いて,相対的に小さい (例えば7B) LLM を微調整するRAG-Tuned-LLMを提案する。
論文 参考訳（メタデータ） (2025-03-20T12:04:40Z) - NumS: Scalable Array Programming for the Cloud [82.827921577004]
タスクベース分散システム上でNumPyのような表現を最適化する配列プログラミングライブラリであるNumSを提案する。
これはLoad Simulated Hierarchical Scheduling (LSHS)と呼ばれる新しいスケジューラによって実現される。
LSHSは、ネットワーク負荷を2倍減らし、メモリを4倍減らし、ロジスティック回帰問題において実行時間を10倍減らし、Rayの性能を向上させる。
論文 参考訳（メタデータ） (2022-06-28T20:13:40Z) - MeMOT: Multi-Object Tracking with Memory [97.48960039220823]
私たちのモデルはMeMOTと呼ばれ、トランスフォーマーベースの3つの主要モジュールで構成されています。
MeMOTは広く採用されているMOTデータセット上で非常に競争力のあるパフォーマンスを観測する。
論文 参考訳（メタデータ） (2022-03-31T02:33:20Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。