NS
NEWSAINT
ai-eng• 8 MIN READ•28 September 2026

EAServe 2026: Arsitektur Encode-Aware Disaggregated Serving pada Multimodal LLM, Reposisi Modality Encoder sebagai Control Point EPD Pipeline, Dynamic SM Partitioning, dan Eliminasi GPU Resource Imbalance

Analisis arsitektur sistemik riset frontier AI systems & distributed inference (arXiv:2609.31551, PACT 2026, 25 September 2026): Mengapa pemisahan pool Prefill dan Decode (PD disaggregation) konvensional gagal total saat diterapkan pada Multimodal Large Language Models (MLLMs). Makalah ini membongkar bottleneck struktural dari fase Encode (vision/audio/video processing) yang menjadi pintu masuk pipeline 3-tahap (Encode-Prefill-Decode / EPD) namun menyisakan idle GPU compute yang masif akibat ukuran batch kecil. Riset ini memperkenalkan EAServe, framework serving disaggregated pertama yang mereposisi Encode sebagai control point aktif dari seluruh pipeline inference. Didukung oleh dua lapisan ko-desain: Hybrid Auto Selection (HAS) yang memadukan profiling kapasitas per-tahap dengan optimasi Bayesian TPE untuk menavigasi konfigurasi alokasi GPU, batas batch B, dan rasio offload s; serta tiga mekanisme runtime adaptif: Load-Adaptive Micro-Batching berbasis aturan Poisson-gap (g = κ/λ), Rate-Controlled Partial Offload berbasis Deficit Round Robin, dan Dynamic Streaming Multiprocessor (SM) Partitioning yang mengizinkan worker prefill lokal berjalan bersamaan pada GPU encode tanpa melanggar QoS tail latency. Evaluasi empiris pada LLaVA-34B (gambar), Qwen2.5-VL-32B (video), dan Ultravox-27B (audio) membuktikan lonjakan goodput hingga 4.3x lipat dibanding NVIDIA Dynamo dan 1.7x lipat dibanding vLLM di bawah batasan SLO yang identik.

N
Ervareza Naurian Novantila
Lead Architect & Founder NEWSAINT
Fact-Checked & Verified
Ilustrasi Arsitektur Teknis 16:9 EAServe 2026: Arsitektur Encode-Aware Disaggregated Serving pada Multimodal LLM, Reposisi Modality Encoder sebagai Control Point EPD Pipeline, Dynamic SM Partitioning, dan Eliminasi GPU Resource Imbalance

Dalam infrastruktur inferensi kecerdasan buatan modern, transisi dari model bahasa berbasis teks (text-only LLM) menuju Multimodal Large Language Models (MLLM)—seperti LLaVA-1.6, Qwen2.5-VL, InternVL-2.5, dan Ultravox—menghadirkan tantangan komputasi terdistribusi yang belum pernah diantisipasi oleh sistem serving generasi pertama. Jika pada model teks disaggregasi hanya membagi siklus hidup inferensi menjadi dua fase komputasi: Prefill (yang dibatasi oleh kapasitas komputasi / compute-bound) dan Decode (yang dibatasi oleh bandwidth memori VRAM / memory-bandwidth bound), maka MLLM menambahkan fase ketiga yang sangat krusial dan heterogen: Encode.

Fase Encode bertugas memproses input non-teks mentah—seperti resolusi piksel citra visual, deretan frame video resolusi tinggi, atau spektrogram audio analog—menggunakan encoder khusus (seperti CLIP ViT, Whisper, atau multi-frame 3D convolution) dan memproyeksikannya ke ruang embedding model bahasa melalui modul connector (MLP projection atau cross-attention resampler). Penambahan fase ini melahirkan pipeline 3-tahap: Encode-Prefill-Decode (EPD).

STRUCTURAL BOTTLENECK

Mengapa Paradigma Serving Konvensional Mengalami Kegagalan Katastropik pada MLLM

Arsitektur serving generasi saat ini—baik framework terdisaggregasi seperti NVIDIA Dynamo dan Splitwise, maupun runtime agregat monolitik seperti vLLM—mengalami ketimpangan sumber daya struktural (structural resource imbalance) yang parah:

  • Encode Gates Downstream Stages: Setiap request wajib menyelesaikan fase Encode sebelum token embedding dapat ditransfer ke node Prefill dan Decode. Kegagalan atau penundaan sekecil apa pun pada worker Encode langsung menyebabkan kelaparan komputasi (worker starvation) pada seluruh cluster GPU downstream.
  • Severe GPU Underutilization pada Encode Worker: Berbeda dengan Prefill yang dapat memproses ribuan token teks dalam matriks GEMM raksasa, forward pass vision encoder pada batch kecil sangat didominasi oleh latensi peluncuran kernel CUDA (kernel-launch overhead). Hasil profiling empiris membuktikan bahwa GPU khusus Encode sering kali hanya beroperasi pada pemanfaatan komputasi di bawah 30% dan pemanfaatan memori HBM di bawah 25%, bahkan saat sistem berada di bawah beban traffic tinggi.
  • Lack of Downstream Flow Regulation: Framework yang mengekspos Encode sebagai layanan mikro independen (misalnya deployment Triton Inference Server terpisah) memperlakukan Encode hanya sebagai pass-through pipe tanpa sinkronisasi beban. Akibatnya, ledakan request Encode membanjiri antrean Prefill, melipatgandakan Time-to-First-Token (TTFT) hingga melanggar batas Service Level Objective (SLO).

Terobosan radikal untuk memecahkan dilema ini diperkenalkan oleh tim peneliti Georgia Institute of Technology dan University of Georgia melalui publikasi riset teranyar mereka di PACT 2026 (arXiv:2609.31551, 25 September 2026) berjudul "EAServe: Encode-Aware Disaggregated Serving for Multimodal Large Language Models". Riset ini memperkenalkan paradigma baru: mereposisi fase Encode sebagai control point aktif dari seluruh pipeline inferensi EPD.

1. Reposisi Encode sebagai Control Point Pipeline EPD Tiga Dimensi

Alih-alih membiarkan worker Encode menjadi entitas statis yang pasif, EAServe memanfaatkan posisi unik Encode di gerbang utama pipeline untuk mengontrol tiga dimensi komputasi yang saling terhubung erat:

Dimensi Temporal

When Work Enters

Mengatur waktu keberangkatan (dispatch) micro-batch Encode secara adaptif berdasarkan hukum probabilitas celah Poisson, menyeimbangkan saturasi komputasi GPU vs penalti waktu tunggu antrean.

Dimensi Spasial

Where Prefill Runs

Menentukan rute eksekusi Prefill: mengeksekusi sebagian embedding langsung di GPU Encode yang sama (co-resident local prefill) vs melakukan offload jaringan ke remote Prefill GPU pool melalui parameter rasio $s in [0, 1]$.

Dimensi Alokasi Hardware

How GPU Is Shared

Membagi fisik Streaming Multiprocessor (SM) pada GPU Encode secara dinamis antara worker Encode dan worker local Prefill dengan isolasi spasial guna melindungi latency budget tanpa pemborosan VRAM.

2. Hybrid Auto Selection (HAS): Pemangkasan Asimetris & Optimasi Bayesian

Menentukan konfigurasi optimal pada sistem serving MLLM terdisaggregasi adalah problem kombinatorial yang sangat kompleks. Konfigurasi deployment target didefinisikan sebagai tripel:

$$PC = ( ext{alloc}, B, s)$$

di mana $ ext{alloc} = (n_E, n_P, n_D)$ adalah alokasi jumlah GPU untuk masing-masing pool Encode, Prefill, dan Decode dari total anggaran GPU $G$; $B$ adalah batas kapasitas micro-batch Encode; dan $s in [0, 1]$ adalah rasio offload Prefill ke remote pool.

Pada cluster 8 GPU saja, terdapat ratusan kemungkinan konfigurasi yang valid. Melakukan pencarian exhaustive grid search di lingkungan produksi adalah hal yang mustahil, karena setiap uji coba deployment membutuhkan waktu beberapa menit pengukuran stabil, yang berujung pada hitungan jam atau hari untuk satu jenis beban kerja.

ALGORITMA DUA TAHAP HAS

Eksploitasi Asimetri Internal Ruang Konfigurasi

Arsitektur Hybrid Auto Selection (HAS) memecahkan dilema pencarian ini dengan mengeksploitasi asimetri struktural sistem:

  1. Stage 1 — Analytical Feasibility Pruning: Pengaruh $ ext{alloc}$ bersifat monotonik dan dapat diprediksi dari profil kapasitas per-tahap secara terisolasi. Jika alokasi GPU pada salah satu tahap tidak mampu menampung target arrival rate $Lambda$, konfigurasi tersebut pasti bottleneck terlepas dari bagaimana $B$ dan $s$ dipilih. HAS melakukan profiling throughput per-worker secara independen dan langsung memangkas konfigurasi yang infeasible tanpa pernah men-deploy-nya ke cluster penuh, hanya mempertahankan $K$ kandidat alokasi GPU terbaik.
  2. Stage 2 — Empirical TPE Bayesian Optimization: Interaksi non-linear antara ukuran batch $B$ dan rasio offload $s$ dalam subset alokasi feasible dinavigasi menggunakan Tree-structured Parzen Estimator (TPE). HAS mengeksplorasi pasangan $(B, s)$ melalui evaluasi end-to-end terarah, mencapai konfigurasi goodput optimal 5.8x lebih cepat dibandingkan pencarian Bayesian murni atau random search.

3. Tiga Mekanisme Runtime EAServe: Presisi Temporal, Spasial, dan Hardware

Setelah konfigurasi $PC^star$ ditentukan secara offline oleh HAS, lapisan runtime EAServe mengeksekusinya secara online melalui 3 mekanisme ko-desain:

A. Load-Adaptive Micro-Batching via Poisson-Gap Rule

Bagaimana scheduler menentukan kapan harus meluncurkan batch Encode jika jumlah request yang terkumpul belum mencapai batas $B$? Dispatcher konvensional yang mengandalkan timeout statis atau batas panjang antrean kaku akan mengalami misalignment saat laju kedatangan request berfluktuasi.

EAServe merumuskan aturan batas celah kedatangan (arrival gap threshold) $g$ langsung dari sifat stokastik proses Poisson dengan laju per-worker $lambda = Lambda / n_E$ dan target probabilitas pengisian batch $p in (0, 1)$:

$$kappa := -lnleft(1 - p^{ rac{1}{B-1}} ight), qquad g := rac{kappa}{lambda}$$

Formula ini memberikan sifat krusial: $g propto 1/lambda$. Saat beban traffic melonjak tinggi, threshold $g$ mengetat secara otomatis sehingga batch segera meluncur tanpa latensi antrean yang tidak perlu. Sebaliknya, saat beban rendah, threshold melonggar secara anggun, memungkinkan akumulasi request untuk efisiensi komputasi.

B. Rate-Controlled Partial Offload via Deficit Round Robin

Untuk mengeksekusi rasio offload target $s in [0, 1]$, pendekatan acak (probabilistic coin toss) menghasilkan variansi tinggi pada rentang waktu pendek, sementara pendekatan sliding window membutuhkan parameter ukuran window $W$ yang sensitif terhadap beban.

EAServe mengadopsi skema Deficit-Controlled Routing yang diadaptasi dari algoritma antrean jaringan teruji Deficit Round Robin (DRR):

// Invarian Routing EAServe
Setiap kedatangan request k:
  d_k = d_{k-1} + s
  JIKA d_k ≥ 1.0 MAKA:
    Rute ke REMOTE_PREFILL_POOL
    d_k = d_k - 1.0
  LAINNYA:
    Rute ke LOCAL_PREFILL_WORKER (co-resident pada GPU Encode)

Skema ini membuktikan secara analitis bahwa deviasi kumulatif terhadap rasio ideal $s$ selalu terbatas ketat $|c_k - k cdot s| < 1$, mengeliminasi getaran antrean (queue jitter) dan menjaga beban Prefill lokal dan remote tetap seimbang secara deterministik.

C. Dynamic SM Partitioning dengan Perlindungan QoS Latensi

Ketika worker Prefill lokal dijalankan pada GPU Encode yang sama, keduanya berisiko mengalami interferensi komputasi yang parah jika hanya mengandalkan time-slicing standar CUDA atau hint advisory pada CUDA MPS.

EAServe memanfaatkan partisi fisik Streaming Multiprocessor (SM). Berdasarkan karakterisasi kurva latensi Encode vs persentase SM pada arsitektur GPU Ada Lovelace dan Hopper, latensi Encode turun tajam dari 500 ms pada 10% SM ke 280 ms pada 30% SM, kemudian melandai datar pada rentang 50%-90% SM. EAServe menetapkan latency degradation budget maksimal 20% sebagai batas aman QoS:

$$ ext{SM}_{ ext{encode}}(B) = min left{ sigma in Sigma mid ext{Latency}( ext{Encode}, B, sigma) le 1.20 imes ext{Latency}_{ ext{isolated}}(B) ight}$$

Sisa kuota SM (misalnya 70% atau 60%) dialokasikan penuh secara eksklusif ke local prefill worker. Ketika ukuran batch Encode berubah secara dinamis, alokasi SM bergeser secara mulus di antara partisi fisik yang terisolasi, mengeliminasi kontensi eksekusi kernel tanpa mengorbankan SLA p99.

4. Evaluasi Empiris: Kinerja Goodput vs vLLM dan NVIDIA Dynamo

Evaluasi mendalam dilakukan pada kluster 8 GPU NVIDIA RTX 6000 Ada (48GB VRAM) dan A100 SXM4 (80GB VRAM) dengan interkoneksi NIXL/NVLink berkecepatan tinggi, mencakup tiga modalitas input representatif:

  • Modalitas Citra (Image): LLaVA-v1.6-34B (CLIP ViT-L/14 @ 336px)
  • Modalitas Video (Multi-Frame): Qwen2.5-VL-32B (Dynamic Resolution ViT 3D Conv)
  • Modalitas Suara (Audio): Ultravox-v0.6-27B (Whisper-large-v3 Audio Encoder)
Arsitektur Serving Image Goodput (LLaVA-34B) Video Goodput (Qwen2.5-VL) Audio Goodput (Ultravox-27B) GPU Utilization
vLLM v0.14.1 (Monolithic Continuous Batching) 1.82 req/s 1.24 req/s 2.41 req/s 54% (Compute Imbalance)
NVIDIA Dynamo v0.9.0 (Static EPD Disaggregation) 1.15 req/s 1.38 req/s 0.98 req/s 41% (Encode Bottleneck)
EAServe (s = 1.0, No Local Prefill) 2.45 req/s 1.62 req/s 3.12 req/s 72% (Micro-Batch Gain)
EAServe (HAS-Tuned + Dynamic SM Partitioning) 3.10 req/s (+70% vs vLLM) 2.11 req/s (+53% vs Dynamo) 4.18 req/s (4.3x vs Dynamo) 89% (Balanced Pipeline)

Hasil pengujian membuktikan bahwa EAServe mencapai peningkatan goodput yang konsisten di semua modalitas. Lonjakan performa paling masif terjadi pada modalitas audio (4.3x lebih tinggi dibanding Dynamo), di mana encoder audio yang relatif ringan sebelumnya menyia-nyiakan kapasitas GPU secara ekstrem pada arsitektur terdisaggregasi statis. Dengan mengaktifkan local prefill melalui partisi dinamis SM, utilisasi GPU melonjak dari 41% menjadi 89%.

5. Spesifikasi Teknis: Implementasi TypeScript EAServe Orchestration Engine

Berikut adalah implementasi referensi berstandar enterprise dalam TypeScript modern yang mengabstraksikan modul PoissonGapMicroBatcher, DeficitCounterRouter, dan DynamicSMPartitioner untuk integrasi gateway inferensi MLLM:

lib/mllm-serving/easerve-orchestrator.ts PRODUCTION SPEC / TYPESCRIPT
// EAServe Production Engine: Encode-Aware Disaggregated MLLM Serving
// Berdasarkan Arsitektur PACT 2026 / arXiv:2609.31551 (Zhu et al. - September 2026)
//
// Komponen Inti:
// 1. PoissonGapMicroBatcher: Dynamic threshold g = κ / λ dengan κ = -ln(1 - p^(1/(B-1)))
// 2. DeficitCounterRouter: Deficit-controlled routing untuk rasio offload s ∈ [0, 1] dengan batas deviasi terbukti
// 3. DynamicSMPartitioner: QoS-guarded spatial SM allocation antara Encode dan Co-resident Local Prefill
// 4. HASConfigManager: Hybrid Auto Selection configuration resolver

export interface RequestEnvelope {
  requestId: string;
  modality: 'image' | 'video' | 'audio';
  rawPayloadSize: number; // Bytes or token equivalent
  arrivedAt: number; // High-precision timestamp ms
  targetSloMs: number;
}

export interface DeploymentConfiguration {
  gpuBudget: number; // e.g. 8 GPUs
  encodeWorkers: number; // n_E
  remotePrefillWorkers: number; // n_P
  decodeWorkers: number; // n_D
  batchBoundB: number; // Encode batch ceiling
  offloadRatioS: number; // s ∈ [0, 1]
  targetArrivalRateLambda: number; // req/s
}

/**
 * 1. Poisson-Gap Micro-Batcher
 * Menghitung waktu tunggu dinamis g = κ / λ berdasarkan laju kedatangan riil,
 * memperketat threshold saat beban tinggi dan melonggarkannya saat idle.
 */
export class PoissonGapMicroBatcher {
  private batchBoundB: number;
  private targetP: number; // Default: 0.6 (titik optimal trade-off latency vs throughput)
  private currentArrivalRateLambda: number;
  private kappa: number;
  private gapThresholdMs: number;
  private queue: RequestEnvelope[] = [];
  private lastArrivalTimestamp: number = 0;

  constructor(batchBoundB: number, initialArrivalRateLambda: number, targetP: number = 0.6) {
    this.batchBoundB = batchBoundB;
    this.targetP = targetP;
    this.currentArrivalRateLambda = initialArrivalRateLambda;
    this.kappa = -Math.log(1 - Math.pow(this.targetP, 1 / (this.batchBoundB - 1)));
    this.gapThresholdMs = (this.kappa / this.currentArrivalRateLambda) * 1000;
  }

  public updateArrivalRate(measuredLambda: number): void {
    if (measuredLambda <= 0.01) return;
    this.currentArrivalRateLambda = measuredLambda;
    this.gapThresholdMs = (this.kappa / this.currentArrivalRateLambda) * 1000;
  }

  public enqueue(req: RequestEnvelope): { shouldDispatch: boolean; batch: RequestEnvelope[]; reason: string } {
    const now = performance.now();
    this.queue.push(req);
    this.lastArrivalTimestamp = now;

    // Kondisi 1: Batch penuh mencapai batas B
    if (this.queue.length >= this.batchBoundB) {
      const batchToDispatch = this.queue.splice(0, this.batchBoundB);
      return { shouldDispatch: true, batch: batchToDispatch, reason: 'BATCH_BOUND_REACHED' };
    }

    return { shouldDispatch: false, batch: [], reason: 'QUEUED' };
  }

  public checkGapTimeout(currentTime: number): { shouldDispatch: boolean; batch: RequestEnvelope[]; reason: string } {
    if (this.queue.length === 0) {
      return { shouldDispatch: false, batch: [], reason: 'EMPTY_QUEUE' };
    }

    const elapsedGap = currentTime - this.lastArrivalTimestamp;
    if (elapsedGap >= this.gapThresholdMs) {
      const batchToDispatch = [...this.queue];
      this.queue = [];
      return { shouldDispatch: true, batch: batchToDispatch, reason: 'POISSON_GAP_EXPIRED' };
    }

    return { shouldDispatch: false, batch: [], reason: 'WAITING_FOR_GAP' };
  }
}

/**
 * 2. Deficit-Counter Router
 * Mengatur rute prefill (lokal vs remote) menggunakan akumulator Deficit Round Robin (DRR).
 * Menjamin deviasi rute maksimal bounded |c_k - k*s| < 1 tanpa fluktuasi acak.
 */
export class DeficitCounterRouter {
  private offloadRatioS: number; // s ∈ [0, 1]
  private deficitAccumulator: number = 0;
  private totalLocalDispatched: number = 0;
  private totalRemoteDispatched: number = 0;

  constructor(offloadRatioS: number) {
    this.offloadRatioS = Math.max(0, Math.min(1, offloadRatioS));
  }

  public routeRequest(req: RequestEnvelope): 'LOCAL_PREFILL' | 'REMOTE_PREFILL' {
    this.deficitAccumulator += this.offloadRatioS;

    if (this.deficitAccumulator >= 1.0) {
      this.deficitAccumulator -= 1.0;
      this.totalRemoteDispatched++;
      return 'REMOTE_PREFILL';
    } else {
      this.totalLocalDispatched++;
      return 'LOCAL_PREFILL';
    }
  }

  public getStats() {
    const total = this.totalLocalDispatched + this.totalRemoteDispatched;
    const empiricalS = total > 0 ? this.totalRemoteDispatched / total : 0;
    return {
      targetS: this.offloadRatioS,
      empiricalS: Number(empiricalS.toFixed(4)),
      localCount: this.totalLocalDispatched,
      remoteCount: this.totalRemoteDispatched,
      currentDeficit: Number(this.deficitAccumulator.toFixed(4)),
    };
  }
}

/**
 * 3. Dynamic SM Partitioner
 * Mengalokasikan streaming multiprocessor secara dinamis antara modality encoder
 * dan local prefill worker. Menjamin degradasi latensi Encode <= 20% (QoS preservation).
 */
export class DynamicSMPartitioner {
  // Mapping batch size Encode ke alokasi persentase SM yang menjaga QoS
  private smAllocationTable: Map = new Map([
    [1, { encodeSmPct: 20, localPrefillSmPct: 80 }],
    [2, { encodeSmPct: 30, localPrefillSmPct: 70 }],
    [4, { encodeSmPct: 40, localPrefillSmPct: 60 }],
    [6, { encodeSmPct: 60, localPrefillSmPct: 40 }],
    [8, { encodeSmPct: 75, localPrefillSmPct: 25 }],
  ]);

  public resolveSMPartition(currentEncodeBatchSize: number): { encodeSm: number; localPrefillSm: number } {
    let bestKey = 1;
    for (const key of Array.from(this.smAllocationTable.keys()).sort((a, b) => a - b)) {
      if (currentEncodeBatchSize >= key) {
        bestKey = key;
      }
    }
    const partition = this.smAllocationTable.get(bestKey) || { encodeSmPct: 50, localPrefillSmPct: 50 };
    return {
      encodeSm: partition.encodeSmPct,
      localPrefillSm: partition.localPrefillSmPct,
    };
  }
}

/**
 * 4. Orchestration Harness: EAServe Coordination Node
 */
export class EAServeCoordinationNode {
  private config: DeploymentConfiguration;
  private batcher: PoissonGapMicroBatcher;
  private router: DeficitCounterRouter;
  private smPartitioner: DynamicSMPartitioner;

  constructor(config: DeploymentConfiguration) {
    this.config = config;
    this.batcher = new PoissonGapMicroBatcher(config.batchBoundB, config.targetArrivalRateLambda);
    this.router = new DeficitCounterRouter(config.offloadRatioS);
    this.smPartitioner = new DynamicSMPartitioner();
  }

  public handleIncomingRequest(req: RequestEnvelope) {
    const enqueueResult = this.batcher.enqueue(req);
    if (enqueueResult.shouldDispatch) {
      return this.dispatchEncodeBatch(enqueueResult.batch);
    }
    return { dispatched: false, reason: enqueueResult.reason };
  }

  public dispatchEncodeBatch(batch: RequestEnvelope[]) {
    const smSplit = this.smPartitioner.resolveSMPartition(batch.length);
    const routedBatch = batch.map((r) => ({
      request: r,
      targetStage: this.router.routeRequest(r),
    }));

    return {
      dispatched: true,
      batchSize: batch.length,
      smAllocation: smSplit,
      routingDetails: routedBatch,
      timestamp: performance.now(),
    };
  }
}

6. Panduan Implementasi bagi AI Platform & Infrastructure Engineers

Bagi organisasi enterprise yang mengoperasikan kluster inferensi MLLM mandiri atau merancang arsitektur serving generasi baru:

  1. Jangan Mengisolasi Encode sebagai Microservice Terpisah Tanpa Backpressure: Memisahkan encoder citra/video ke layanan Triton atau vLLM terpisah tanpa koordinasi rate-limiting dengan downstream Prefill/Decode hanya akan menciptakan penumpukan antrean liar dan lonjakan ekor TTFT.
  2. Terapkan Ko-lokasi Local Prefill pada Node Encode: Karena encoder visual menyisakan lebih dari 60% komputasi SM pada kondisi operasi normal, manfaatkan kapasitas sisa ini untuk memproses tahap awal prompt text-embedding menggunakan partisi SM perangkat keras (NVIDIA MPS atau MIG).
  3. Gunakan Aturan Celah Poisson untuk Micro-Batching Dinamis: Tinggalkan timeout statis 10ms atau 50ms yang rentan rusak saat volume query berubah. Turunkan nilai batas waktu tunggu $g$ secara proporsional terhadap estimasi laju kedatangan real-time $lambda$.

Referensi & Sumber Terverifikasi

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

Ilustrasi Arsitektur Teknis 16:9 HyperBrowseComp 2026: Benchmark Multilingual & Multimodal Stress Test untuk Autonomous Web-Browsing Agents, Evaluasi 13 Bahasa, dan Analisis Bottleneck Retrieval Harness

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.

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

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.

Ilustrasi Arsitektur Teknis 16:9 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

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.