Dinamika Komunikasi Distributed GPU Worker

Orkestrasi beban kerja inferensi model bahasa besar (LLM) dan model difusi menuntut karakteristik transmisi data yang berbeda dibanding beban kerja komputasi umum. Inferensi modern bersifat interaktif: model menghasilkan token secara sekuensial melalui autoregressive decoding yang harus distreaming ke klien dengan Time to First Token (TTFT) dan Inter-Token Latency (ITL) serendah mungkin. Terdapat dua paradigma dominan untuk menghubungkan edge gateway/koordinator dengan kluster GPU worker terdistribusi: koneksi dua arah Stateful WebSocket (seperti pola koneksi balik worker Talos) dan perantara Stateless Message Queue (seperti RabbitMQ, Kafka, atau NATS).

NAT Traversal dan Topologi Jaringan Heterogen

Penyedia komputasi GPU sering kali berada di lingkungan terisolasi, baik on-premise datacenter, cloud publik (AWS, GCP, RunPod), maupun mesin bare-metal. Mayoritas node ini berada di balik NAT simetris atau firewall korporat yang memblokir koneksi masuk (inbound traffic).

  • Stateful WebSocket (Outbound reverse connection): Worker menginisiasi koneksi TCP keluar (port 443) ke gateway publik. Pendekatan ini menembus NAT secara transparan tanpa konfigurasi port forwarding, VPN mesh, atau tunneling overlay (seperti WireGuard). Koneksi persisten ini kemudian bertindak sebagai saluran transmisi dupleks penuh untuk meneruskan perintah eksekusi job masuk dan mengalirkan token keluar.
  • Message Queue: Worker juga menginisiasi koneksi keluar ke broker terpusat. Pola ini menyelesaikan masalah NAT traversal secara identik pada layer transport. Namun, queue membutuhkan infrastruktur perantara terkelola yang harus dapat dijangkau oleh kedua belah pihak (gateway/API server dan worker node), memperkenalkan satu hop jaringan tambahan di setiap siklus komunikasi.

Latensi Streaming Token dan Mekanisme Backpressure

Streaming token menuntut throughput pesan kecil berfrekuensi tinggi. Jika satu model LLM menghasilkan 80 token per detik, worker memancarkan 80 payload terpisah ke klien.

Overhead Jalur Transmisi

WebSocket mengalirkan frame biner atau teks langsung melalui soket TCP yang sudah mapan (established socket) tanpa overhead routing broker. Latensi transmisi dibatasi murni oleh RTT (Round Trip Time) jaringan antara worker dan gateway.

Pada Message Queue, streaming token mengharuskan setiap pecahan respons dipublikasikan ke topic/queue terdistribusi (misalnya topic respons per-request). Broker harus memvalidasi header, menulis ke buffer memori atau disk commit-log (tergantung durabilitas), dan mendistribusikan pesan ke konsumen di sisi API gateway. Ini memperkenalkan jitter latensi kumulatif dan potensi bottlenecks pada I/O broker ketika ratusan GPU worker melakukan streaming secara bersamaan.

Penerapan Backpressure

GPU dapat menghasilkan token lebih cepat daripada kemampuan jaringan klien mengonsumsinya, atau sebaliknya, gateway dapat menerima permintaan lebih banyak daripada kapasitas antrean GPU VRAM.

# WebSocket flow control via application-level credit or windowing
class BackpressureController:
    def __init__(self, high_watermark=50, low_watermark=10):
        self.pending_acks = 0
        self.high_watermark = high_watermark
        self.low_watermark = low_watermark
        self.pause_event = asyncio.Event()
        self.pause_event.set()

    async def emit_token(self, ws, token):
        await self.pause_event.wait()
        await ws.send_json({"type": "token", "data": token})
        self.pending_acks += 1
        if self.pending_acks >= self.high_watermark:
            self.pause_event.clear()

    def handle_ack(self):
        self.pending_acks = max(0, self.pending_acks - 1)
        if self.pending_acks <= self.low_watermark:
            self.pause_event.set()

Pada Message Queue, backpressure worker-to-gateway ditangani secara native melalui QoS/prefetch limit (misalnya prefetch_count=1 pada protokol AMQP). GPU worker hanya mengambil pesan baru ketika batch inferensi sebelumnya selesai dihitung, mencegah saturasi VRAM tanpa logika koordinasi manual.

Mitigasi Reconnect Storm saat Gateway Failover

Tantangan terbesar arsitektur stateful WebSocket adalah kerapuhan state koneksi saat gateway restart, rolling deployment, atau mengalami network partition. Ketika satu edge gateway menangani 10.000 soket worker dan mengalami crash, 10.000 node akan serempak mencoba menginisiasi koneksi ulang (thundering herd problem atau reconnect storm), yang berisiko menumbangkan gateway baru melalui TCP SYN flooding dan load spike pada layer TLS termination.

Strategi mitigasi wajib pada worker mencakup Truncated Exponential Backoff dengan Full Jitter:

import random
import time

def calculate_backoff(attempt: int, base_delay: float = 1.0, max_delay: float = 60.0) -> float:
    # Truncated exponential backoff with full jitter
    temp = min(max_delay, base_delay * (2 ** attempt))
    sleep_duration = random.uniform(0, temp)
    return sleep_duration

Sebaliknya, pada Message Queue, broker decoupling memisahkan siklus hidup gateway dari worker. Kegagalan pada API gateway tidak memengaruhi koneksi worker ke broker; job tetap tersimpan dalam antrean persisten, dan worker terus beroperasi tanpa perlu re-autentikasi atau re-handshake TLS.

State Tracking, Idempotensi, dan Operasional Biaya

State Tracking dan Ephemeral Liveness

WebSocket membutuhkan gateway yang stateful. Gateway harus memelihara tabel in-memory pemetaan connection ID, worker ID, kapasitas spesifikasi GPU (kapasitas VRAM tersisa, model yang ter-load), dan status idle/busy. Jika gateway crash, seluruh snapshot state tersebut hilang kecuali disinkronisasi ke shared memory external seperti Redis, yang menambahkan kompleksitas konsistensi terdistribusi.

Pada Message Queue, status worker bersifat stateless dari perspektif gateway. Koordinasi kerja dialihkan pada status kepemilikan pesan (message visibility timeout / lease). Jika worker mendadak mati (kernel panic, CUDA Out of Memory), pesan akan mengalami lease timeout dan secara otomatis didistribusikan ulang ke worker lain tanpa orkestrasi eksternal.

Komparasi Biaya Operasional (TCO)

  • Resource Footprint Gateway WebSocket: Mempertahankan ribuan koneksi persisten menuntut alokasi file descriptor (ulimit -n), memori kernel TCP socket buffer (rmem, wmem), serta penanganan session stickiness. Namun, arsitektur ini memangkas biaya perantara data karena tidak ada disk store terpusat.
  • Infrastruktur Broker Message Queue: Mengoperasikan kluster Kafka/RabbitMQ berskala tinggi membutuhkan node komputasi dengan bandwidth disk tinggi untuk commit-log, retensi pesan, serta overhead cluster consensus (etcd/Zookeeper/KRaft), yang meningkatkan total biaya infrastruktur.

Matriks Keputusan: Kriteria Pemilihan Pola

Gunakan kriteria berikut untuk menentukan arsitektur sistem orkestrasi inferensi:

  1. Pilih Stateful WebSocket jika:
    • Sistem mengutamakan TTFT dan latensi end-to-end terendah untuk model LLM interaktif (chat, agentic workflows).
    • Topologi worker tersebar luas di berbagai penyedia infrastruktur pihak ketiga (decentralized / multi-cloud compute) di balik NAT tertutup tanpa integrasi VPN.
    • Data payload streaming tidak memerlukan durabilitas tinggi; jika jaringan terputus, sesi inferensi pengguna dapat dibatalkan secara instan tanpa perlu re-queue.
  2. Pilih Stateless Message Queue jika:
    • Beban kerja didominasi oleh inferensi batch (offline transcription, embedding generation, batch image generation) di mana latensi per-token bukan metrik utama.
    • Keandalan mutlak dan eksekusi at-least-once dibutuhkan secara deterministik; kegagalan node harus ditoleransi otomatis oleh broker via Dead Letter Queues (DLQ).
    • Tim menginginkan pemisahan operasional (decoupled lifecycle) yang bersih antara tim model serving dan tim backend engineering.