VenusRL 2026: Arsitektur Disaggregated Agentic RL dengan Priority-Aware Scheduling, Akselerasi Training 4.24x, dan Pangkas 89% Biaya Sandbox

Gambar 1: Visualisasi Konseptual Arsitektur VenusRL—Pemisahan menyeluruh antara alur orkestrasi data (Data Coordinator), penjadwalan aksi berbasis prioritas (Rollout Worker), preservasi KV Cache (Trajectory-Aware Radix Cache), dan pooling sandbox microVM elastis. arXiv:2610.03286

1. Paradoks Agentic RL: Mengapa Utilisasi GPU Tinggi Tidak Menjamin Kecepatan Pelatihan?

Dalam pelatihan LLM tradisional (single-turn reasoning atau pre-training), komputasi bersifat deterministik: setiap request menghasilkan token hingga batas akhir tertentu tanpa jeda eksternal. Namun, dalam Agentic RL, agen berulang kali mengeksekusi pola aksi: menghasilkan tool call, menunggu lingkungan merespons, memproses observasi baru, lalu melanjutkan rantai penalaran hingga 300 putaran interaksi.

Arsitektur generasi sebelumnya (seperti RollFlash) memperkenalkan penjadwalan level-aksi (action-level scheduling) untuk menutupi gelembung latensi alat (tool execution bubble). Saat satu agen menunggu eksekusi terminal bash, slot GPU dialihkan untuk melayani token generasi agen lain. Sekilas, metrik GPU utilization terlihat mencapai 95-99%. Namun, para insinyur menemukan paradoks yang membingungkan di kluster produksi: kecepatan pelatihan end-to-end justru macet parah.

Penyebab utamanya terletak pada formulasi matematika optimasi grup GRPO/PPO:

Di sini, $B$ adalah ukuran batch micro-step trainer. Satu kelompok sampel $g = {r_{g,1}, dots, r_{g,K}}$ baru dapat dikirim ke worker training setelah seluruh $K$ lintasan dalam kelompok tersebut selesai. Jika penjadwal mendistribusikan slot komputasi secara merata ke puluhan kelompok baru tanpa memprioritaskan kelompok yang hampir selesai, waktu tunggu batch berikutnya ($T_{ ext{next}}$) membengkak tajam. Lebih buruk lagi, membuka terlalu banyak lintasan aktif secara bersamaan memicu perebutan memori KV Cache, menyebabkan eviksi paksa dan overhead re-prefill yang masif.

Gambar 2: Alur Kerja Sistem Terdisagregasi VenusRL (arXiv:2610.03286 Fig. 4)—Data Coordinator bertindak sebagai bidang kendali terpusat, berinteraksi asinkron dengan Rollout Workers (SGLang), Environment Resource Manager (Firecracker/E2B), Reward Workers, dan Actor Workers. Fig. 4 Overall Design

2. Priority-Aware Action Scheduler: Mengurai Hambatan Straggler Group

VenusRL memecahkan dilema penjadwalan ini melalui mekanisme Priority-Aware Action Scheduler yang beroperasi pada tiga dimensi komputasi:

Gambar 3: Arsitektur Penjadwalan Berbasis Prioritas (arXiv:2610.03286 Fig. 6)—Memadukan length prediction heuristics, penataan antrean preemptif, dan integrasi erat dengan status eksekusi sandbox. Fig. 6 Action Scheduler

3. Trajectory-Aware Radix Cache: Eliminasi Eviksi Paksa pada Siklus Multi-Turn

Pada sistem serving standar seperti SGLang, mekanisme RadixAttention mengelola cache KV menggunakan pohon radix berbasis LRU (Least Recently Used). Namun, pada pelatihan agentic RL, asumsi LRU runtuh: lintasan yang sedang menunggu respons dari lingkungan (bisa memakan waktu 2–10 detik) memiliki akses timestamp yang tua. Akibatnya, cache KV lintasan tersebut sering kali dieviksi oleh request baru yang tiba.

Saat respons alat akhirnya kembali, rollout worker terpaksa menghitung ulang seluruh prefix KV dari awal (re-prefill penalty), yang membuang puluhan teraflops komputasi GPU.

VenusRL merevolusi ini dengan Trajectory-Aware Radix Cache. Pohon radix kini melacak keterikatan kelompok (group membership) dan skor prioritas lintasan. Node cache milik lintasan prioritas tinggi diberi pin residensi khusus (retention guard), melindunginya dari algoritma eviksi selama jeda interaksi lingkungan berlangsung.

Gambar 4: Trajectory-Aware Radix Cache (arXiv:2610.03286 Fig. 7)—Node prefix mempertahankan reference count aktif dan bobot prioritas grup, mencegah eviksi prematur saat menunggu feedback tool. Fig. 7 Radix Cache

4. Environment Resource Manager: Lompatan Densitas Sandbox hingga 905%

Biaya non-GPU dalam pelatihan agentic RL sering kali diabaikan, padahal menjalankan puluhan ribu instans sandbox per hari menelan biaya infrastruktur cloud yang luar biasa. Kerangka kerja seperti E2B dan Firecracker menggunakan Linux userfaultfd untuk mengisi halaman memori dari snapshot secara lazy. Artinya, halaman fisik hanya dialokasikan saat pertama kali disentuh oleh proses guest.

Meskipun deklarasi memori virtual per sandbox disetel ke 4GB, penggunaan fisik sebenarnya sering kali hanya 200–400MB. Namun, alokasi konvensional bersifat konservatif: pada node server dengan 400GB RAM, sistem menolak instansiasi baru setelah mencapai 100 sandbox (karena batas 100 x 4GB = 400GB tercapai), menyebabkan 80–90% RAM fisik menganggur (stranded memory).

VenusRL menerapkan solusi tingkat kernel yang elegan:

1. Dynamic Admission Threshold Adaptation (Algoritma 1): Node menerima sandbox baru berdasarkan footprint fisik aktual ditambah estimasi laju pertumbuhan memori aktif, bukan kuota virtual. Sistem dilengkapi mekanisme fallback sandbox migration jika terjadi lonjakan memori tak terduga.
2. Intra-Group Page Sharing: Karena seluruh $K$ lintasan dalam satu grup GRPO diluncurkan dari prompt dan template lingkungan yang sama, proses inisialisasi mengeksekusi kode setup, import pustaka Python, dan dependensi OS yang identik. VenusRL memisahkan kepemilikan alamat virtual dari residensi halaman fisik melalui write-protected Page Table Entry (PTE) aliasing. Seluruh sandbox membaca dari frame fisik memori yang sama; pemisahan halaman fisik hanya terjadi saat ada modifikasi lokal melalui Copy-on-Write (CoW).

Gambar 5: Arsitektur Page Sharing (arXiv:2610.03286 Fig. 9)—Mengaitkan page table virtual beberapa sandbox ke frame fisik bersama, mereduksi footprint duplikasi hingga lebih dari 80%. Fig. 9 Page Sharing

5. Hasil Evaluasi Empiris: Tolok Ukur Kecepatan Pelatihan dan Penghematan Biaya

VenusRL diimplementasikan dengan 24.000 baris kode gabungan Python, Rust, dan Golang, diuji secara komprehensif pada kluster 32 GPU NVIDIA Hopper (16 GPU dialokasikan untuk rollout inferensi dan 16 GPU untuk pelatihan bobot model) yang saling terhubung melalui 900 GB/s NVLink dan 400 Gb/s Mellanox InfiniBand. Model yang dievaluasi mencakup Qwen3-4B dan Qwen3-32B pada dataset SWE-agent OpenSWE yang memuat 45.320 lingkungan Docker executable dengan batas 128K context window dan 300 putaran per lintasan.

Gambar 6: Heatmap Versi Bobot (arXiv:2610.03286 Fig. 12)—VenusRL menekan dispersi versi bobot pada lintasan rollout secara signifikan, memastikan bahwa sampel yang dihasilkan selalu selaras dengan kebijakan model teranyar (on-policy alignment). Fig. 12 Staleness Heatmap

6. Implementasi Arsitektur Sistem: Scheduler & Memory Manager

Berikut adalah implementasi referensi modul TypeScript untuk mengintegrasikan logika penjadwalan grup kritis dan manajemen page-sharing sandbox ke dalam pipeline orchestrator agen berskala besar:

// Production Architecture: VenusRL Priority-Aware Scheduler & Page-Sharing Sandbox Manager
// Berdasarkan Arsitektur Sistem VenusRL (arXiv:2610.03286 - Oktober 2026)
//
// Karakteristik Inti:
// 1. Critical Group Identification: Memprioritaskan grup sampel yang paling cepat membuka batch trainer berikutnya.
// 2. Trajectory-Aware Radix Cache: Menahan entri KV Cache dari lintasan prioritas tinggi agar tidak tereviction saat eksekusi tool.
// 3. Dynamic Admission Threshold: Mencegah memory stranding sandbox dengan admission berbasis footprint fisik nyata.
// 4. Intra-Group Page Sharing: Meng-alias page table entry (PTE) write-protected antar-sandbox dalam grup template yang sama.

export interface SampleTrajectory {
  id: string;
  groupId: string;
  promptId: string;
  currentTurn: number;
  tokensGenerated: number;
  predictedRemainingTokens: number;
  state: 'ROLLOUT_PENDING' | 'ROLLOUT_RUNNING' | 'TOOL_WAITING' | 'COMPLETED';
  lastActiveTimestamp: number;
}

export interface SampleGroup {
  groupId: string;
  promptId: string;
  groupSize: number; // K sampel per prompt (e.g. K=8 untuk GRPO)
  completedCount: number;
  trajectories: SampleTrajectory[];
}

export class VenusPriorityScheduler {
  private activeGroups: Map = new Map();
  private batchSizeThreshold: number; // Jumlah grup selesai yang dibutuhkan untuk 1 trainer micro-batch

  constructor(batchSizeThreshold: number = 16) {
    this.batchSizeThreshold = batchSizeThreshold;
  }

  /**
   * Mengestimasi sisa waktu penyelesaian grup berdasarkan sampel terlambat (straggler)
   * T_remain(g) = max_{r in g} (predicted_remaining_tokens / generation_speed + tool_latency)
   */
  public calculateGroupEstimatedRemainingTime(group: SampleGroup): number {
    let maxRemaining = 0;
    for (const traj of group.trajectories) {
      if (traj.state !== 'COMPLETED') {
        const estTime = traj.predictedRemainingTokens * 0.02 + 0.5; // heuristik latensi
        if (estTime > maxRemaining) {
          maxRemaining = estTime;
        }
      }
    }
    return maxRemaining;
  }

  /**
   * Menyeleksi critical groups untuk meminimalisir waktu rilis batch trainer (T_next)
   */
  public selectCriticalGroups(limit: number): Set {
    const sortedGroups = Array.from(this.activeGroups.values())
      .filter((g) => g.completedCount < g.groupSize)
      .sort((a, b) => {
        // Prioritaskan grup yang hampir selesai (completion ratio tertinggi dan sisa waktu terpendek)
        const aProgress = a.completedCount / a.groupSize;
        const bProgress = b.completedCount / b.groupSize;
        if (bProgress !== aProgress) return bProgress - aProgress;
        return this.calculateGroupEstimatedRemainingTime(a) - this.calculateGroupEstimatedRemainingTime(b);
      });

    const criticalSet = new Set();
    for (let i = 0; i  = new Map();

  constructor(totalMemoryGb: number = 400) {
    this.totalPhysicalMemoryBytes = totalMemoryGb * 1024 * 1024 * 1024;
    this.admissionThresholdBytes = this.totalPhysicalMemoryBytes * 0.85; // 85% safety bound
  }

  /**
   * Algoritma 1: Dynamic Admission Threshold Adaptation
   * Memeriksa apakah kandidat sandbox dapat diterima berdasarkan prediksi pertumbuhan memori aktif
   */
  public admitSandbox(estimatedFootprintBytes: number): boolean {
    if (this.currentUsedMemoryBytes + estimatedFootprintBytes > this.admissionThresholdBytes) {
      return false; // Tolak / migrasi untuk menghindari risiko OOM
    }
    this.currentUsedMemoryBytes += estimatedFootprintBytes;
    return true;
  }

  /**
   * Mekanisme Intra-Group Page Sharing:
   * Mengaitkan virtual page address ke shared physical frame dengan flag Write-Protected
   */
  public mapSharedPage(templateKey: string, pageOffset: number): { physicalFrameId: number; isCow: boolean } {
    const key = `${templateKey}:${pageOffset}`;
    let entry = this.pageSharingPool.get(key);
    if (!entry) {
      entry = { physicalFrameId: Math.floor(Math.random() * 1000000), refCount: 1 };
      this.pageSharingPool.set(key, entry);
    } else {
      entry.refCount++;
    }
    return { physicalFrameId: entry.physicalFrameId, isCow: true };
  }
}

7. Implikasi Arsitektural bagi Rekayasa AI Skala Industri 2026

Riset VenusRL membuktikan bahwa peralihan dari model fondasi teks pasif menuju agen otonom interaktif menuntut perombakan total pada arsitektur sistem komputasi terdistribusi:

• Penjadwalan Sadar Konvergensi (Convergence-Aware Scheduling): Mengoptimalkan sistem komputasi tidak lagi cukup hanya dengan memantau saturasi FLOPs GPU. Bidang kendali harus memahami dependensi struktural algoritma RL (seperti group barrier GRPO) agar setiap watt daya komputasi langsung berkontribusi pada penurunan waktu iterasi pelatihan.
• Sinergi Co-Design OS dan AI Runtime: Isolasi lingkungan eksekusi agen tidak boleh diperlakukan sebagai kotak hitam terisolasi. Melalui kolaborasi antara runtime inferensi (SGLang) dan primitif kernel OS (Copy-on-Write, virtual memory aliasing), pemborosan memori dapat dieliminasi hingga level minimal.
• Demokratisasi Pelatihan Model Coding Skala Besar: Dengan memangkas 89% biaya lingkungan dan mempercepat throughput 4x lipat, kluster komputasi yang sebelumnya hanya mampu melatih model kecil kini memiliki kapasitas untuk mengeksekusi long-horizon reinforcement learning pada repository kode dunia nyata berskala enterprise.