Dilema Arsitektur: Native CUDA vs Runtime Siap Pakai

Pemilihan stack inferensi Large Language Model (LLM) menentukan efisiensi hardware, batas skalabilitas, dan kecepatan rilis produk. Pendekatan minimalis native C/CUDA (seperti arsitektur referensi markusheimerl/gpt atau llm.c) memberikan kontrol penuh terhadap alokasi memori dan eksekusi instruksi GPU. Sebaliknya, inference engine modern seperti vLLM, TensorRT-LLM, atau Triton Inference Server mengorbankan kontrol granular demi automasi penjadwalan dan throughput tinggi pada multi-tenant serving.

Keputusan teknis ini bukan sekadar preferensi bahasa pemrograman, melainkan trade-off antara optimalisasi latensi single-stream pada tingkat mikrodetik melawan skalabilitas konkurensi pada tingkat sistem.

Kontrol Kernel, Footprint VRAM, dan Runtime Overhead

Pendekatan native C/CUDA menghilangkan layer perantara runtime Python, PyTorch C++ wrapper, dan framework orchestration. Hal ini berdampak langsung pada tiga area teknis:

  • Kontrol Instruksi GPU: Menggunakan CUDA C murni memungkinkan penulisan kernel khusus yang menggabungkan operasi (kernel fusion) secara agresif—misalnya memadukan RMSNorm, Linear Projection, dan RoPE ke dalam satu launch kernel untuk meminimalkan roundtrip ke High Bandwidth Memory (HBM).
  • VRAM Footprint: Engine umum mengalokasikan ruang VRAM untuk caching internal, driver context, dan struktur data orchestration. Implementasi native hanya membutuhkan alokasi statis untuk bobot model dan buffer aktif yang dialokasikan eksplisit via cudaMalloc.
  • Overhead Runtime: Native C/CUDA meniadakan latensi launch PyTorch/Python, Global Interpreter Lock (GIL), dan overhead context-switching antar-thread runtime. Eksekusi langsung ke CUDA stream menghasilkan latensi Time-to-First-Token (TTFT) dan Inter-Token Latency (ITL) yang sangat deterministik pada batch size 1.
// Contoh alokasi memori linear statis tanpa overhead runtime framework
typedef struct {
    half* weight_qkv;
    half* weight_out;
    half* kv_cache_k;
    half* kv_cache_v;
    half* hidden_state;
} MinimalLayerState;

void forward_layer(MinimalLayerState* layer, half* input, cudaStream_t stream) {
    // Kernel fusion: RMSNorm + QKV Projection langsung ke pointer terkelola
    launch_fused_rmsnorm_qkv(input, layer->weight_qkv, layer->hidden_state, stream);
    cudaStreamSynchronize(stream);
}

Fitur Skala Kritis: Kompleksitas Membangun Sendiri

Keunggulan latensi native C/CUDA runtuh ketika beban kerja beralih dari satu pengguna (batch size = 1) ke ratusan request simultan. Inference engine modern menyertakan tiga mekanisme kompleks yang sangat sulit diimplementasikan dan diuji keandalannya dari nol:

1. PagedAttention dan Manajemen Fragmentasi KV-Cache

Pada generasi autoregresif, panjang sequence input dan output bersifat dinamis. Alokasi buffer kontigu konvensional menghasilkan fragmentasi internal hingga 60-80% dari total VRAM. vLLM memecahkan ini dengan PagedAttention, yang memetakan memori KV-cache ke dalam virtual block layaknya konsep virtual memory pada OS. Mengimplementasikan PagedAttention secara mandiri memerlukan kernel Dynamic Block Lookup, dynamic page tables di host/device, dan penanganan dereferensi pointer non-kontigu di dalam kernel attention tanpa degradasi memori akses.

2. Continuous Batching (Iteration-level Scheduling)

Batching tradisional memaksa sequence pendek menunggu sequence terpanjang selesai dieksekusi (padding overhead). Continuous batching memasukkan request baru dan menghapus request yang sudah mencapai token <|endoftext|> pada setiap iterasi langkah token forward pass. Membangun scheduler continuous batching native menuntut pipeline eksekusi asinkron, manipulasi metadata batch dinamis pada level mikrodetik, dan kernel handling untuk batch dengan panjang sequence yang heterogen.

3. Multi-GPU Parallelism (Tensor Parallelism via NCCL)

Model berukuran di atas puluhan miliar parameter melampaui kapasitas satu GPU, sehingga membutuhkan Tensor Parallelism (TP) atau Pipeline Parallelism (PP). Inference engine telah mengintegrasikan komunikasi primitive NCCL (seperti ncclAllReduce) yang dioptimasi secara mendalam untuk topologi NVLink. Mengelola sinkronisasi multi-GPU secara mandiri menimbulkan risiko race conditions, deadlocks, dan penanganan kegagalan node.

Analisis Biaya: Compute GPU vs Engineering Hours

Pertimbangan arsitektur harus mengkalkulasi total biaya kepemilikan (Total Cost of Ownership):

  • Custom CUDA Runtime: Menuntut spesialis insinyur sistem CUDA berkemampuan tinggi. Pengembangan dan pemeliharaan kernel custom, backward compatibility antar-generasi GPU (misal Hopper FP8 Transformer Engine vs Ada Lovelace vs Blackwell), serta debugging race conditions membutuhkan ribuan jam rekayasa. Biaya rekayasa perangkat lunak ini sering kali melampaui penghematan hardware server, kecuali skala kluster melebihi ratusan node GPU.
  • Inference Engine Off-the-Shelf: Menghemat waktu deployment dari hitungan bulan menjadi hitungan hari. vLLM atau Triton siap digunakan melalui container standar, mendukung berbagai model architecture secara out-of-the-box, serta secara rutin menerima patch performa dan dukungan hardware baru dari komunitas open-source.

Matriks Keputusan Arsitektur

Tabel berikut membandingkan karakteristik teknis antara Custom CUDA native dan Inference Engine modern:

  • Kontrol Hardware Granular: Custom CUDA (Sangat Tinggi / Manual) | vLLM / Triton (Tinggi / Melalui Konfigurasi)
  • Throughput Multi-User: Custom CUDA (Rendah, kecuali dibangun scheduler mandiri) | vLLM / Triton (Sangat Tinggi via Continuous Batching)
  • Deterministic Latency (Batch = 1): Custom CUDA (Superior, minimal jitter) | vLLM / Triton (Baik, namun ada overhead middleware)
  • Dependensi Eksternal: Custom CUDA (Nol / C++ Compiler & CUDA Driver) | vLLM / Triton (Python, PyTorch/C++, Ray, Triton Server C++ libs)
  • Waktu Implementasi: Custom CUDA (Bulan ke Tahun) | vLLM / Triton (Jam ke Hari)

Kapan Memilih Custom CUDA Runtime?

  1. Sistem Hard Real-Time / Edge AI: Sistem embedded (seperti robotika, alutsista, atau platform otomotif berbasis NVIDIA Jetson) yang mewajibkan latensi sub-milidetik, toleransi jitter nol, determinisme tinggi, dan tidak memiliki dependensi Python.
  2. Single-Stream Inference: Beban kerja batch size = 1 murni tanpa kebutuhan antrean multi-tenant, di mana VRAM cukup untuk menampung seluruh context window statis.
  3. Kebutuhan Kernel Eksperimental: Modifikasi arsitektur model baru yang belum didukung oleh engine komersial (misal jenis kuantisasi non-standar atau modifikasi layer linear proprietary).

Kapan Memilih Inference Engine Modern?

  1. SaaS dan Enterprise Serving: Infrastruktur cloud yang melayani banyak user secara bersamaan dengan panjang prompt dinamis. Continuous batching dan PagedAttention memberikan throughput per dollar (tokens/sec/$) jauh lebih tinggi.
  2. Model Lifecycles Cepat: Organisasi yang sering mengganti bobot model (Llama, Mistral, Qwen, DeepSeek) tanpa ingin menulis ulang implementasi forward-pass di level C++/CUDA.
  3. Distribusi Multi-GPU: Kebutuhan menjalankan model 70B+ di kluster multi-GPU yang membutuhkan optimasi NCCL out-of-the-box tanpa alokasi tim khusus untuk pemeliharaan infrastruktur low-level.