py-kvcache 2026: Karakterisasi Kinerja External KV Caching vLLM pada NVMe SSD, Asynchronous Direct I/O io_uring, dan Scheduler-Aware Preloading
Bedah arsitektur mendalam atas riset sistem distributed computing frontier arXiv:2609.11744 (September 2026, Joseph Kanichai, Tiziano De Matteis, Animesh Trivedi / ETH Zurich & Large-Scale Data Systems): Mengapa external KV caching pada NVMe SSD seringkali justru memperlambat inferensi LLM dibanding komputasi ulang (recomputation)? Makalah ini mengungkap paradoks Break-Even Frontier dan merumuskan py-kvcache—konektor KV Offload vLLM berbasis Linux io_uring asynchronous direct I/O, bounded CPU staging memory, serta scheduler-aware lookahead preloading. Hasil benchmark empiris membuktikan pemangkasan Time to First Token (TTFT) hingga 2.0x–2.5x lebih cepat dibanding LMCache pada 80k token, 6.02x–7.43x lebih cepat dibanding recomputation penuh di LongBench, serta delineasi tegas kapan external KV caching layak diaktifkan pada GPU kelas enterprise.

Dalam lanskap penyajian model bahasa besar (LLM Serving) modern tahun 2026, akselerasi komputasi inferensi tidak lagi semata-mata ditentukan oleh jumlah FLOPs GPU, melainkan telah bergeser menjadi masalah arsitektur rekayasa sistem penyimpanan dan hirarki memori terdistribusi. Kompleksitas self-attention pada tahap prefill yang berskala kuadratik ($O(N^2)$) membuat pengolahan konteks panjang (32k hingga 128k token) menghabiskan VRAM GPU secara instan.
Ringkasan Eksekutif & Temuan Kunci Riset arXiv:2609.11744
Studi mendalam dari Large-Scale Data & Systems Group (ETH Zurich) yang dipublikasikan pada 10 September 2026 membongkar ilusi umum rekayasa AI: "Menyimpan seluruh KV cache ke NVMe SSD tidak selalu mempercepat inferensi." Pada dokumen pendek atau GPU generasi baru berkecepatan tinggi (seperti NVIDIA H100), membaca cache dari SSD seringkali jauh lebih lambat dibanding menghitung ulang (recomputation) attention dari awal. Untuk memecahkan paradoks ini, peneliti merancang py-kvcache: konektor KV Offload vLLM berbasis Linux io_uring direct I/O, bounded CPU staging memory, scheduler-aware lookahead preloading, dan break-even admission gating yang memangkas TTFT hingga 2.0x–2.5x lebih cepat dibanding LMCache dan hingga 7.43x lebih cepat dibanding komputasi ulang penuh.
1. Dilema Prefill vs Disk Read: Paradoks Break-Even Frontier
Automatic Prefix Caching (APC) di mesin inferensi modern seperti vLLM dan SGLang bekerja dengan mengidentifikasi blok token yang identik dari awal prompt menggunakan rantai hash bertingkat (prefix hash chain). Jika prompt baru memiliki kecocokan prefix dengan request sebelumnya, state Key dan Value (KV) yang telah dihitung dapat langsung digunakan kembali tanpa perlu menghitung ulang tensor attention di layer Transformer.
Namun, kapasitas VRAM GPU High Bandwidth Memory (HBM3e) sangat terbatas dan berbiaya mahal. Solusi alami yang banyak diadopsi industri adalah melakukan tiering memori: memindahkan (offloading) KV cache yang tidak aktif ke memori RAM host (CPU) atau media penyimpanan sekunder seperti NVMe SSD (misalnya PCIe Gen5 NVMe yang mampu menyediakan throughput baca 7–14 GB/s).
Akan tetapi, riset empiris yang dipimpin oleh Joseph Kanichai, Tiziano De Matteis, dan Animesh Trivedi menemukan bahwa asumsi efisiensi ini seringkali runtuh di lingkungan produksi. Terdapat Break-Even Frontier yang sangat tajam:
Wilayah Menguntungkan (Above Break-Even)
Ketika panjang token prefix yang dapat digunakan kembali melampaui ambang batas tertentu (misal > 6.000 token pada Qwen3-4B atau > 40k–80k token pada long-document QA):
- Biaya komputasi attention kuadratik GPU mendominasi secara absolut.
- Throughput transfer stream NVMe $ ightarrow$ Host RAM $ ightarrow$ GPU VRAM jauh melampaui kecepatan prefill GPU.
- Time to First Token (TTFT) berkurang secara drastis (2x hingga 7.4x lebih cepat).
Wilayah Kerugian (Below Break-Even)
Ketika prompt berukuran pendek hingga menengah (< 2.000–6.000 token) atau saat inferensi dijalankan di atas GPU berkemampuan komputasi masif seperti NVIDIA H100 SXM:
- GPU mampu menuntaskan prefill tensor attention dalam hitungan milidetik.
- Overhead latency I/O, traversal metadata direktori POSIX, dan transfer PCIe host-to-device justru memakan waktu lebih lama daripada komputasi ulang.
- Memuat cache dari NVMe SSD memicu regresi performa (TTFT lebih lambat) dan membebani jalur PCIe bus tanpa faedah.
2. Bedah Kelemahan Arsitektur Eksisting: LMCache, llm-d, & Native Offload
Sebelum merancang py-kvcache, para peneliti menguji secara teliti tiga sistem external KV cache terkemuka dan membongkar hambatan bottleneck fundamental yang terjadi di tingkat kernel dan runtime:
A. LMCache & KV Transfer API: Bottleneck Thread Pool & Blocking I/O
High CPU ContentionLMCache mengandalkan KV Transfer API vLLM dan pool worker thread POSIX pemblokir (blocking threads) untuk mencapai konkurensi I/O. Pada transfer blok KV berukuran puluhan megabyte, puluhan thread yang berebut context switch di Linux memicu overhead CPU scheduling dan interupsi kernel yang parah. Selain itu, alokasi memori buffer perantara yang tidak dibatasi (unbounded intermediate memory) dapat menyebabkan lonjakan konsumsi RAM host yang memicu OOM (Out Of Memory) saat beban konkurensi tinggi.
B. Kegagalan Kernel-Bypass SPDK & KvikIO GPUDirect Storage
Unexpected Overhead
Eksperimen awal tim peneliti mencoba menggunakan xNVMe dengan backend SPDK (Storage Performance Development Kit) untuk melewati kernel Linux secara menyeluruh (kernel-bypass). Namun, SPDK mewajibkan SSD dilepas (detached) dari kernel driver dan diakses langsung via PCI address, sehingga mematikan kemampuan sistem file POSIX untuk berbagi prefix cache antar-instans vLLM. Lebih buruk lagi, pengujian menggunakan KvikIO (cuFile GPUDirect Storage untuk transfer langsung NVMe-ke-GPU) justru menghasilkan performa lebih lambat akibat inefisiensi overhead binding Python dan alignment memory lock pada transfer tensor non-kontigu.
C. Letak Disk Read pada Critical Path Request
Synchronous Scheduling LagPada sistem konvensional, proses pembacaan data cache dari disk baru dipicu setelah request dipilih oleh scheduler vLLM untuk dieksekusi (demand read). Akibatnya, GPU terpaksa berada dalam kondisi idle atau terhambat menunggu transfer data I/O tuntas, menempatkan seluruh durasi pembacaan SSD tepat di atas jalur kritis (critical path) TTFT.
3. Arsitektur Teknis py-kvcache: io_uring, Bounded Staging, & Preloading
Berdasarkan wawasan di atas, arsitektur py-kvcache dirancang dengan 4 pilar rekayasa inti:
1. Linux io_uring & Asynchronous Direct I/O (O_DIRECT)
py-kvcache mengadopsi io_uring melalui pustaka Python liburing. Dengan memanfaatkan Submission Queue (SQ) dan Completion Queue (CQ) berbasis ring-buffer yang dibagi antara userspace dan kernel Linux, py-kvcache dapat mengajukan ratusan operasi baca-tulis blok secara bersamaan hanya dengan satu reactor thread tunggal. Penggunaan flag O_DIRECT sepenuhnya mem-bypass Linux Page Cache, mencegah interferensi lock memori kernel dan menjaga performa baca tetap konsisten mendekati batas teoritis bandwidth perangkat NVMe (mencapai > 3.5 GB/s transfer efektif).
2. Pengelompokan Blok Agregat & Bounded Staging Memory
Alih-alih menyimpan blok individual GPU vLLM (yang standarnya hanya berukuran 16 atau 256 token), py-kvcache mengelompokkan blok-blok tersebut menjadi storage blocks berukuran besar (~28 MiB per file untuk arsitektur Llama 3.2 3B). Hal ini menghilangkan overhead metadata direktori (dapat menangani 1 juta file cache tanpa degradasi performa). Konkurensi I/O dikendalikan oleh software queue depth yang dapat dikonfigurasi, bukan oleh jumlah thread sistem, sehingga alokasi memori perantara CPU staging dapat dibatasi (bounded staging pool) untuk mencegah risiko OOM.
3. Scheduler-Aware Lookahead Preloading
Inovasi terpenting dari py-kvcache adalah sinkronisasi antara vLLM scheduler dan transfer engine. Manager membaca waiting queue (antrean request yang sedang menunggu slot eksekusi GPU). Ketika antrean I/O memiliki kapasitas longgar, py-kvcache segera memulai pembacaan blok prefix dari NVMe SSD ke CPU staging buffer secara asinkron—berjalan secara tumpang-tindih (overlapping) di background saat GPU sedang sibuk melakukan komputasi request lain. Ketika request akhirnya dijadwalkan ke GPU, seluruh blok KV sudah berada di CPU RAM, sehingga yang tersisa di jalur kritis hanyalah promosi cepat Host-to-Device (CPU $ ightarrow$ GPU)!
4. Offline-Calibrated Break-Even Admission Gate
py-kvcache tidak melakukan pemuatan cache secara membabi buta. Sebelum node inferensi dioperasikan, proses kalibrasi offline dijalankan untuk merekam kurva Pareto frontier latensi komputasi vs transfer untuk kombinasi model dan node tertentu. Hasilnya adalah konstanta ambang batas (misal: 6.203 token untuk Qwen3-4B pada node RTX 4000 Ada). Pada runtime, Manager mengevaluasi kecocokan token: jika panjang prefix berada di bawah ambang batas break-even, Manager secara deterministik menolak permintaan pemuatan cache dan menginstruksikan vLLM untuk melakukan komputasi ulang (recomputation), melindungi sistem dari regresi latensi.
4. Spesifikasi Implementasi: Arsitektur Referensi TypeScript
Berikut adalah implementasi model referensi modular yang mencerminkan pemisahan peran antara Scheduler Manager dan Worker IoReactor pada py-kvcache:
// py-kvcache High-Performance Offload Connector Architecture (TypeScript Reference Model)
// Berdasarkan Prinsip Arsitektur arXiv:2609.11744 (Kanichai, De Matteis, Trivedi / ETH Zurich, September 2026)
// Mengimplementasikan OffloadingSpec vLLM, Linux io_uring Direct I/O, Bounded Shared Staging,
// Scheduler-Aware Lookahead Preloading, dan Offline Calibrated Break-Even Admission Gating.
export interface BlockHash {
tokenHash: bigint;
parentHash: bigint;
tokenCount: number;
}
export interface OffloadBlockDescriptor {
blockId: string;
hashChain: BlockHash;
storageFilePath: string;
byteSize: number; // Contoh: ~28 MiB per 256-token block pada Llama 3.2 3B
sourceTier: 'GPU_VRAM' | 'CPU_PINNED_STAGING' | 'NVME_SSD';
}
export interface BreakEvenThresholds {
modelName: string;
hardwareTier: 'RTX_4000_ADA' | 'NVIDIA_A100' | 'NVIDIA_H100';
breakEvenTokensSSD: number; // Misal: 6,203 tokens untuk Qwen3-4B pada RTX 4000 Ada
}
export interface PreloadInstruction {
requestId: string;
prefixLength: number;
blocksToStage: OffloadBlockDescriptor[];
scheduledAdmissionEstimatedMs: number;
}
/**
* 1. Scheduler-Side Offload Manager
* Menangani lookup prefix hash, evaluasi break-even Pareto frontier, dan orchestrasi preloading
*/
export class PyKvCacheManager {
private breakEvenLimits: BreakEvenThresholds;
private pendingPreloads: Map<string, PreloadInstruction> = new Map();
constructor(thresholds: BreakEvenThresholds) {
this.breakEvenLimits = thresholds;
}
/**
* Mengevaluasi apakah pemuatan cache dari SSD NVMe layak secara ekonomis (latency-wise)
* Dibanding melakukan recomputation komputasi attention penuh pada GPU
*/
public evaluateAdmissionGate(prefixTokens: number, sourceTier: 'CPU_PINNED_STAGING' | 'NVME_SSD'): {
shouldLoadFromCache: boolean;
reason: string;
} {
if (sourceTier === 'CPU_PINNED_STAGING') {
return { shouldLoadFromCache: true, reason: 'CPU pinned memory transfer faster than GPU prefill' };
}
// Gating NVMe SSD terhadap ambang batas break-even offline
if (prefixTokens < this.breakEvenLimits.breakEvenTokensSSD) {
return {
shouldLoadFromCache: false,
reason: `Prefix length (${prefixTokens} tok) < break-even point (${this.breakEvenLimits.breakEvenTokensSSD} tok). Recomputation is faster.`,
};
}
return {
shouldLoadFromCache: true,
reason: `Prefix length exceeds break-even threshold. NVMe streaming reduces TTFT.`,
};
}
/**
* Lookahead Queue Inspection: Mengidentifikasi request yang sedang mengantre (waiting queue)
* untuk memicu background disk reads sebelum request dialokasikan ke GPU
*/
public planLookaheadPreload(waitingQueue: Array<{ requestId: string; prefixLength: number; blocks: OffloadBlockDescriptor[] }>): PreloadInstruction[] {
const dispatchList: PreloadInstruction[] = [];
for (const req of waitingQueue) {
const gate = this.evaluateAdmissionGate(req.prefixLength, 'NVME_SSD');
if (gate.shouldLoadFromCache && !this.pendingPreloads.has(req.requestId)) {
const instruction: PreloadInstruction = {
requestId: req.requestId,
prefixLength: req.prefixLength,
blocksToStage: req.blocks,
scheduledAdmissionEstimatedMs: 15.0, // Estimasi waktu tunggu di antrean
};
this.pendingPreloads.set(req.requestId, instruction);
dispatchList.push(instruction);
}
}
return dispatchList;
}
}
/**
* 2. Worker-Side Linux io_uring Storage Reactor
* Mengoperasikan Direct I/O (O_DIRECT) asinkron dengan pembatasan memori CPU staging (bounded depth)
*/
export class IoUringStorageReactor {
private maxIoDepth: number;
private currentQueueDepth: number = 0;
private pinnedStagingPoolSizeBytes: number;
private allocatedStagingBytes: number = 0;
constructor(maxIoDepth: number = 16, maxStagingMb: number = 2048) {
this.maxIoDepth = maxIoDepth;
this.pinnedStagingPoolSizeBytes = maxStagingMb * 1024 * 1024;
}
/**
* Menyerahkan pekerjaan pembacaan NVMe ke ring buffer io_uring tanpa blocking thread
*/
public async submitAsynchronousDirectRead(block: OffloadBlockDescriptor): Promise<{ blockId: string; stagingAddress: bigint; durationMs: number }> {
if (this.currentQueueDepth >= this.maxIoDepth) {
throw new Error('io_uring submission queue full: backpressure applied to bound memory');
}
if (this.allocatedStagingBytes + block.byteSize > this.pinnedStagingPoolSizeBytes) {
throw new Error('CPU Staging Pool exhausted: rejecting preload to prevent system OOM');
}
this.currentQueueDepth++;
this.allocatedStagingBytes += block.byteSize;
const start = performance.now();
try {
// Simulasi eksekusi io_uring SQE (Submission Queue Entry) dengan direct I/O bypass
// Membaca file blok teragregasi (~28 MiB) langsung ke pinned host memory
await new Promise(resolve => setTimeout(resolve, Math.max(1, Math.round(block.byteSize / (3.5 * 1024 * 1024))))); // Simulasi ~3.5 GB/s transfer NVMe
const elapsed = performance.now() - start;
return {
blockId: block.blockId,
stagingAddress: BigInt('0x7f00deadbeef'),
durationMs: Number(elapsed.toFixed(2)),
};
} finally {
this.currentQueueDepth--;
}
}
public releaseStagingBuffer(bytes: number): void {
this.allocatedStagingBytes = Math.max(0, this.allocatedStagingBytes - bytes);
}
}
5. Hasil Evaluasi Empiris & Pengujian Benchmark
Pengujian performa komparatif dijalankan pada node superkomputer Snellius (NVIDIA H100 80GB NVLink, PCIe Gen5 NVMe) dan workstation lokal (NVIDIA RTX 4000 Ada 20GB, PCIe Gen4 NVMe) menggunakan trace beban nyata dan dataset standar:
| Kondisi Pengujian & Dataset | py-kvcache (Full Preload) | LMCache (Disk Backend) | GPU Prefix Cache / Recompute | Keuntungan Margin Performa |
|---|---|---|---|---|
| Isolated Disk Test (80k Tokens, 50 req) | TTFT ~1.82 s | TTFT ~4.55 s | TTFT ~13.50 s (Recompute) | 2.50x vs LMCache (7.4x vs Recompute) |
| Preload Effect di 40k Tokens | 1.66x Faster vs No-Preload | N/A (No Preload Engine) | N/A | Disk Read Berjalan di Background |
| LongBench: Multi-Doc QA | Mean TTFT Terendah | +2.77x Lebih Lambat | +6.02x Lebih Lambat (Recompute) | Unggul 1.22x atas vLLM Native Offload |
| LongBench: Code Repo Understanding | Mean TTFT Terendah | +3.64x Lebih Lambat | +7.43x Lebih Lambat (Recompute) | Unggul 1.79x atas vLLM Native Offload |
| Alibaba Bailian Production Trace (RTX 4000) | 1.12x–1.79x Faster | 1.10x–1.25x Faster | Baseline GPU APC | Skalabilitas Memori Terjaga |
Sorotan Krusial Evaluasi Produksi:
- Isolasi Efisiensi Preloading: Pada 40k token, lookahead preloading menyumbang akselerasi 1.66x. Pada 80k token, akselerasi preload mencapai 1.34x (sedikit menurun karena waktu transfer memori Host-ke-GPU mulai mendominasi dibanding waktu pembacaan NVMe).
- Batas Manfaat pada NVIDIA H100: Pada pengujian trace nyata Alibaba Cloud Bailian di node NVIDIA H100, mayoritas prompt memiliki panjang rata-rata di bawah ambang batas break-even (6.203 token). Karena kapasitas VRAM H100 (80GB) sudah cukup menampung sebagian besar prefix aktif dan FLOPs komputasi prefill H100 sangat luar biasa cepat, mengalirkan data ke NVMe SSD tidak memberikan keuntungan latensi. Peneliti menegaskan bahwa external KV caching harus diperlakukan sebagai setup-specific admission decision, bukan fitur yang selalu diaktifkan secara buta.
6. Panduan Praktis untuk AI Systems & Infra Engineers 2026
Bagi arsitek platform AI, operator kluster inferensi vLLM, dan software engineer yang membangun infrastruktur model skala besar, temuan riset py-kvcache memberikan 4 prinsip desain utama:
Gunakan Linux io_uring dan Hindari Multi-Threaded I/O Pools
Saat menangani transfer file berukuran besar (>10 MiB) dari SSD, membuat thread pool konvensional di Python hanya memicu overhead context-switching dan perebutan Global Interpreter Lock (GIL). Gunakan io_uring dengan direct I/O (O_DIRECT) untuk mengalirkan batch pekerjaan I/O langsung ke antrean ring kernel secara asynchronous dari satu thread pengendali tunggal.
Terapkan Bounded Staging Memory Buffer
Jangan biarkan transfer I/O mengalokasikan RAM host secara tak terbatas. Terapkan batas kedalaman antrean I/O (queue depth) dan alokasi memory pool tetap (pinned memory buffer) agar kluster inferensi Anda kebal terhadap lonjakan lonjakan konkurensi (spike) yang dapat memicu Linux OOM Killer.
Eksploitasi Jendela Tunggu Antrean dengan Lookahead Preloading
Jangan menunggu hingga GPU siap mengeksekusi request baru sebelum mulai membaca disk. Manfaatkan informasi antrean scheduler untuk memuat blok prefix yang cocok ke memori CPU selama request masih mengantre di waiting queue. Tumpang-tindihkan I/O dengan komputasi request lain untuk menyingkirkan waktu tunggu I/O dari jalur kritis TTFT.
Wajibkan Kalibrasi Offline Break-Even Frontier
Lakukan profiling offline untuk memetakan titik impas antara kecepatan prefill GPU dan throughput SSD untuk setiap tipe node (misal RTX 4000 vs A100 vs H100). Pasang admission gate yang secara otomatis menolak pemuatan cache jika panjang prefix di bawah ambang batas break-even. Ingat: komputasi ulang (recomputation) seringkali jauh lebih murah dan cepat untuk konteks berukuran pendek!
7. Kesimpulan
Publikasi py-kvcache (arXiv:2609.11744) membuktikan bahwa optimasi infrastruktur AI generasi berikutnya menuntut integrasi mendalam antara kernel storage modern dan penjadwalan inferensi model. Dengan memadukan Linux io_uring direct I/O, bounded staging memory, scheduler-aware lookahead preloading, serta evaluasi break-even gate yang disiplin, py-kvcache berhasil melipatgandakan kecepatan TTFT hingga 2.5x atas LMCache pada dokumen berkonteks masif dan menetapkan standar emas baru bagi arsitektur tiered memory LLM serving tahun 2026.
Referensi & Sumber Terverifikasi
- [1]Building py-kvcache: A Performance Characterization of External KV Caching for vLLM with NVMe SSDs(arXiv:2609.11744 [cs.DC, cs.LG] — Joseph Kanichai, Tiziano De Matteis, Animesh Trivedi (Large-Scale Data & Systems Group / ETH Zurich))
- [2]py-kvcache: Python External KV Cache Engine for vLLM via io_uring (Official Repository)(GitHub / Large-Scale Data & Systems Group (atlarge-research))
- [3]vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention and KV Offloading Architecture(vLLM Project / UC Berkeley SkyLab)
- [4]LMCache: High-Performance Disaggregated KV Cache Layer for Long-Context LLMs(LMCache Project & Cloud Native LLM Serving Working Group)
- [5]io_uring and Modern Linux Storage Architecture: Zero-Copy Asynchronous Direct I/O(Kernel.org / Jens Axboe)
- [6]KVCache in the Wild: Characterizing and Optimizing KVCache at Scale in Production Cloud(USENIX Annual Technical Conference (ATC 25) / Alibaba Cloud Bailian Trace Study)
Butuh Arsitektur Web & AI Berkualitas Tinggi?
Tim engineering NEWSAINT siap membantu merancang website berkecepatan tinggi, sistem AI autonomous, dan solusi SaaS terukur untuk bisnis Anda.
Artikel Terkait Lainnya

HyperBrowseComp 2026: Benchmark Multilingual & Multimodal Stress Test untuk Autonomous Web-Browsing Agents, Evaluasi 13 Bahasa, dan Analisis Bottleneck Retrieval Harness
Analisis arsitektur sistem frontier riset evaluasi autonomous browsing agent (arXiv:2610.03574, Oktober 2026 — Alham Fikri Aji, Faiz Rizki Ramadhan, Zayd M. K. Zuhri, Seung Hun Eddie Han, Ryandito Diandaru, dkk. MBZUAI, Mila, Inception AI, Alibaba, AI Singapore): Mengapa tolok ukur browsing konvensional (GAIA, BrowseComp) mengalami saturasi parametrik dan bias monolingual. Memperkenalkan HyperBrowseComp, stress test 423 kueri faktual bernilai tunggal lintas 13 bahasa (termasuk Bahasa Indonesia 9.2% dan Jawa 8.3%) dan 8 modalitas (Video 39%, PDF/OCR 29.8%, Aritmetika 28.1%, Gambar 18.4%, Peta 9.7%). Evaluasi empiris 5 model frontier (Gemini 3.7 Flash, Gemini 3.1 Pro, GPT-5.6 Sol/Terra/Luna) lintas 3 harness retrieval (Provider Built-in, Exa Search API, OWL Browser Harness) mengungkap fenomena Harness Inversion (Exa mendongkrak GPT-5.6 Sol +7.56% namun mendegradasi Gemini 3.7 Flash -9.46%), 93 kegagalan fatal runtime tool-calling pada OWL, serta 57.68% pertanyaan tanpa solusi (shared failure) pada seluruh model frontier.

VenusRL 2026: Arsitektur Disaggregated Agentic RL dengan Priority-Aware Scheduling, Akselerasi Training 4.24x, dan Pangkas 89% Biaya Sandbox
Analisis arsitektur sistem frontier riset Agentic RL (arXiv:2610.03286, Mingjun Zhang, Yucheng Li, Menghao Zhang, Shuyong Zhu, Ping Zhang — Oktober 2026): Mengapa sistem pelatihan RL agen multi-turn konvensional (Slime, RollFlash) mengalami bottleneck sistemik fatal akibat barrier penyelesaian grup GRPO/PPO dan alokasi statis memori sandbox microVM. Memperkenalkan VenusRL, sistem agentic RL terdisagregasi penuh pertama yang memadukan Priority-Aware Action Scheduler dan Environment Resource Manager. Melalui heuristik prediksi panjang lintasan, Trajectory-Aware Radix Cache, alokasi memori dinamis adaptif, serta intra-group page sharing berbasis aliasing page table entry (PTE) dan copy-on-write, VenusRL meraih akselerasi training throughput hingga 4.24x, meningkatkan densitas sandbox per node hingga 905% (dari 100 ke 905 sandbox pada node 400GB), dan memangkas biaya infrastruktur non-GPU hingga 89% pada pengujian kluster 32 GPU Hopper dengan Qwen3-32B di SWE-agent OpenSWE.

ActKV 2026: Arsitektur Action-Guided KV Cache Management pada Agentic LLM Inference, Pangkas 74% Memori dengan 98.5% Akurasi, dan Akselerasi Throughput hingga 3.97x
Analisis mendalam arsitektur sistem operasi frontier agent inference (arXiv:2609.31395, University of Science and Technology of China - USTC): Mengapa kompresi KV cache konvensional (StreamingLLM, SnapKV, R-KV) gagal total pada agen otonom karena menyamaratakan seluruh token. Memperkenalkan ActKV, framework kompresi KV cache pertama yang dirancang khusus untuk agentic LLM inference. Melalui tiga inovasi arsitektural—Action-Oriented Eviction berbasis attention-aware LRFU, Confidence-Driven Adaptive Budget Allocation berbasis sinyal intrinsik LLM & trend detection, serta Page-Aware In-Place Compaction Kernel tanpa alokasi workspace ekstra—ActKV mempertahankan 98.53% akurasi FullKV dengan hanya 25.98% peak memory, serta melejitkan token throughput hingga 3.97x dan task throughput hingga 3.58x pada model Qwen3-30B, Qwen3-235B, GPT-OSS-20B, dan GPT-OSS-120B.