Infrastruktur AI Dimulai dari Satu Pertanyaan: Bagaimana GPU Sampai ke Aplikasi Anda?

Percakapan tentang AI hampir selalu berhenti di lapisan yang paling terlihat: model apa yang dipakai, seberapa besar parameternya, benchmark-nya berapa. Tapi begitu sebuah perusahaan memutuskan menjalankan AI di infrastrukturnya sendiri, pertanyaan pertama yang menentukan proyek itu jalan atau mandek justru jauh lebih membosankan: bagaimana GPU yang terpasang di rak server itu sampai ke aplikasi yang membutuhkannya?

Pertanyaan itu terdengar sepele. Dalam praktiknya, jawabannya menentukan berapa banyak tim yang bisa memakai satu kartu GPU, seberapa cepat model Anda merespons, dan berapa besar sebagian aset paling mahal di data center Anda menganggur.

Tumpukan yang Jarang Digambar Utuh

Ada rantai yang perlu diluruskan lebih dulu, karena sering disederhanakan secara keliru.

Model AI, pada dasarnya, bukan program. Ia adalah kumpulan model weights: file besar berisi angka. Ia tidak melakukan apa-apa sampai ada perangkat lunak yang memuatnya ke memori dan menjalankan perhitungannya. Perangkat lunak itulah yang kita sebut runtime atau inference server, misalnya Ollama, vLLM, atau TensorRT.

Runtime tadi adalah sebuah aplikasi biasa. Aplikasi butuh sistem operasi, sistem operasi butuh mesin, dan khusus untuk AI, mesin itu butuh akselerator: GPU. Rantainya menjadi model weights, lalu runtime, lalu sistem operasi, lalu mesin, lalu silikon.

Setiap sambungan di rantai itu adalah titik keputusan arsitektur. Sambungan paling akhir, antara mesin dan silikon, adalah yang paling sering diabaikan sampai proyeknya terlanjur berjalan.

Kenapa Satu Aplikasi Satu Server Fisik Tidak Masuk Akal

Menempatkan satu aplikasi di satu server fisik adalah cara paling mahal untuk menjalankan apa pun. Sebagian besar waktu, server itu menganggur. Anda membayar listrik, ruang rak, pendinginan, dan lisensi untuk kapasitas yang tidak terpakai.

Dari sinilah lahir dua teknologi yang sering disebut dalam satu tarikan napas, padahal keduanya bekerja dengan cara yang sangat berbeda.

Virtualisasi benar-benar memecah satu mesin fisik menjadi beberapa mesin virtual. Masing-masing punya kernel sendiri, sistem operasi sendiri, dan batas yang tegas. Yang mengatur pembagian ini adalah hypervisor, misalnya KVM yang menjadi bagian dari kernel Linux.

Kontainerisasi tidak memecah mesin. Ini perbedaan yang penting dan sering salah dipahami. Semua kontainer di sebuah host berbagi satu kernel yang sama. Yang dipisahkan hanyalah pandangan setiap proses terhadap sistem: proses mana yang terlihat, file mana yang bisa diakses, berapa banyak CPU dan memori yang boleh dipakai. Kontainer adalah isolasi proses, bukan mesin baru. Untuk mengaturnya dalam jumlah besar, dipakai orkestrator seperti Kubernetes.

Perbedaan ini bukan soal istilah. Ia menentukan langsung cara GPU bisa dihubungkan ke workload Anda, karena mesin virtual dan kontainer melihat perangkat keras dengan cara yang sama sekali berbeda.

Untuk AI, Ekonominya Justru Terbalik

Virtualisasi klasik lahir dari masalah server CPU yang terlalu banyak menganggur. Konsolidasi adalah jawabannya: banyak beban kecil ditumpuk di satu mesin besar.

Pada workload AI, tekanannya berpindah. CPU dan memori jarang menjadi penghambat. Yang langka, mahal, dan sulit didapat adalah GPU. Satu data center-class GPU bisa bernilai setara beberapa server biasa, dan waktu tunggu pengadaannya sering diukur dalam bulan, bukan hari.

Konsekuensinya, pertanyaan yang benar bukan lagi "bagaimana menghemat server", melainkan "bagaimana memastikan kartu yang sudah kami beli ini benar-benar terpakai". GPU yang menganggur di malam hari karena satu tim menguasainya sepanjang waktu adalah bentuk pemborosan modal yang jauh lebih mahal daripada server CPU yang idle.

Di situlah virtualisasi berubah peran. Ia bukan lagi alat penghematan, melainkan alat alokasi: cara membagi sumber daya termahal Anda secara adil, terukur, dan bisa ditagihkan.

Dua Cara GPU Sampai ke Mesin Virtual

Ada dua mekanisme yang matang secara industri, dan keduanya menjawab kebutuhan yang berbeda.

PCI passthrough memberikan seluruh kartu fisik kepada satu mesin virtual. Hypervisor melepaskan kartu itu dari host dan menyerahkannya utuh kepada guest, sehingga sistem operasi di dalam VM berbicara langsung ke silikon. Performanya mendekati bare metal. Syaratnya, prosesor dan motherboard harus mendukung IOMMU, yaitu Intel VT-d atau AMD-Vi, dan fitur itu harus diaktifkan di BIOS maupun di parameter kernel.

vGPU, atau mediated device, memecah satu kartu enterprise menjadi beberapa GPU virtual. Sebuah Tesla T4 berkapasitas 16 GB, misalnya, dapat di-slice menjadi delapan vGPU berukuran 2 GB untuk delapan mesin virtual sekaligus. Ini membutuhkan driver khusus di host dan lisensi dari vendor GPU.

	PCI Passthrough	vGPU (Mediated Device)
Pembagian	Satu kartu untuk satu VM	Satu kartu untuk banyak VM
Performa	Mendekati bare metal	Sesuai porsi slice
Paling cocok untuk	Training, fine-tuning, beban berat berkelanjutan	Inference, pengembangan, demo, banyak pengguna
Kebutuhan lisensi	Tidak ada	Lisensi vGPU dari vendor
Perangkat keras	GPU umum, asalkan IOMMU aktif	Umumnya data center-class GPU

Ada tiga batasan teknis yang sebaiknya diketahui sejak awal, karena sering ditemukan terlambat saat implementasi.

Pertama, satu kartu tidak bisa melayani keduanya pada saat bersamaan. Ketika sebuah GPU sudah terikat ke driver passthrough, ia tidak bisa menyediakan slice vGPU, dan sebaliknya. Kedua, vGPU tidak mendukung hot-plug: menambah atau melepas slice mengharuskan mesin virtual dimatikan lebih dulu. Ketiga, pada GPU generasi Ampere ke atas, virtual function SR-IOV harus diaktifkan di host sebelum profil vGPU muncul sama sekali.

Lalu di Mana Posisi Kontainer?

Karena kontainer berbagi kernel dengan host, ia tidak menerima GPU lewat passthrough. Kontainer memakai driver yang sudah terpasang di host, lalu runtime kontainer menyuntikkan akses perangkat itu ke dalamnya.

Pada platform Awanio hari ini, jalur GPU yang tersedia berada di lapisan mesin virtual, baik di CEP maupun di Vapor. Ini bukan keterbatasan yang menghalangi pemakaian kontainer, karena polanya justru sudah umum dipakai di banyak lingkungan produksi: mesin virtual diberi GPU, lalu kontainer dijalankan di dalam mesin virtual tersebut. Anda tetap mendapat portabilitas kontainer, sekaligus batas isolasi yang lebih tegas antar tim atau antar tenant, yang justru penting ketika satu kartu dipakai bersama.

Bagaimana Awanio Mengerjakannya

Dua lini produk Awanio menjawab kebutuhan ini dari dua sisi skala yang berbeda.

CEP (Cloud Enabler Platform) menjalankan mesin virtual di atas Kubernetes. GPU dilekatkan ke VM saat pembuatan, dan mode pemasangannya mengikuti jenis perangkat yang dipilih: kartu yang ditandai dapat dibagi akan disajikan sebagai vGPU, sementara kartu yang tidak dapat dibagi diberikan utuh sebagai passthrough. Karena CEP juga membawa IAM dan manajemen penagihan, alokasi GPU bisa diperlakukan sebagai layanan yang punya pemilik dan biaya, bukan sekadar perangkat yang kebetulan menempel di suatu server.

Video berikut menunjukkan alurnya secara utuh, dari menyiapkan compute ber-vGPU sampai Ollama benar-benar melayani model di dalamnya.

Vapor mengambil sisi yang berbeda: satu host, dikelola langsung. Vapor bekerja di atas KVM, QEMU, dan libvirt, dan menyediakan kedua mekanisme tadi. Passthrough dipasang sebagai perangkat PCI, sedangkan vGPU dipasang sebagai mediated device. Yang membedakannya dalam praktik adalah pekerjaan penyiapan yang biasanya paling merepotkan sudah dijadikan alur terpandu: unggah paket driver vGPU Manager dari vendor, lalu Vapor menjalankan sembilan pemeriksaan kesiapan sebelum instalasi, mulai dari keberadaan GPU, status IOMMU, ketersediaan kernel header dan toolchain, kondisi Secure Boot, sampai memastikan driver bawaan tidak sedang memegang kartu tersebut. Dukungan vGPU ini masuk sejak Vapor versi 3.0.0 pada Juli 2026.

Yang perlu digarisbawahi, keduanya tidak menggantikan GPU, dan tidak mengurangi kebutuhan Anda akan driver maupun lisensi dari vendor. Yang keduanya kerjakan adalah menghilangkan jarak antara "kartu sudah terpasang di server" dan "workload sudah bisa memakainya", jarak yang biasanya diisi pekerjaan manual yang rawan salah.

Yang Dilihat Investor dari Lapisan Ini

Bagi investor, ada tiga hal yang membuat lapisan ini layak diperhatikan, dan ketiganya bertumpu pada satu kenyataan yang sama: perangkat kerasnya mahal dan langka.

Pertama, utilisasi adalah pengungkit imbal hasil yang paling langsung. Belanja modal GPU sudah terjadi di awal, sementara nilainya baru muncul dari jam pemakaian. Platform yang memungkinkan satu kartu melayani banyak workload secara aman mengubah aset yang sebelumnya terkunci pada satu tim menjadi kapasitas yang bisa dijual berulang kali.

Kedua, di sinilah letak peluang bagi penyedia infrastruktur lokal. Kebutuhan komputasi AI di dalam negeri tumbuh lebih cepat daripada kemampuan sebagian besar perusahaan untuk membangun dan mengoperasikan sendiri kluster GPU. Penyedia cloud lokal yang mampu menawarkan GPU sebagai layanan, dengan kontrak yang tunduk pada hukum Indonesia dan data yang tetap berada di yurisdiksi Indonesia, menjawab dua kebutuhan sekaligus: kapasitas komputasi dan kepastian kendali.

Ketiga, keunggulan yang bertahan lama di lapisan ini bukan pada modelnya. Model berganti setiap beberapa bulan. Yang bertahan adalah kemampuan mengalokasikan, mengukur, menagih, dan mengamankan pemakaian akselerator, karena kemampuan itu tetap relevan berapa kali pun modelnya diganti.

Langkah yang Bisa Dijadwalkan Pekan Ini

Kalau perusahaan Anda sedang mempertimbangkan menjalankan AI di infrastruktur sendiri, empat langkah berikut sudah cukup untuk mengubah wacana menjadi keputusan yang berdasar.

Mulai dengan memeriksa kesiapan perangkat keras Anda: apakah IOMMU sudah aktif, dan apakah GPU yang dimiliki termasuk kelas yang mendukung pembagian vGPU. Lalu kelompokkan workload Anda, karena training dan inference menuntut perlakuan yang berbeda. Dari situ, pilihan antara memberikan kartu utuh atau membaginya menjadi beberapa vGPU akan menjawab dirinya sendiri. Terakhir, jalankan satu workload nyata, bukan sekadar benchmark sintetis, dan ukur berapa persen kapasitas GPU yang benar-benar terpakai.

Angka terakhir itu biasanya yang paling membuka mata, dan hampir selalu menjadi dasar pembicaraan anggaran yang jauh lebih sehat.

Menjalankan AI di infrastruktur sendiri pada akhirnya adalah keputusan tentang kendali, sama seperti keputusan infrastruktur lain yang pernah kami bahas sebelumnya. Bedanya, pada AI, taruhannya lebih terlihat: bukan hanya di mana data Anda disimpan, melainkan siapa yang menentukan kapan Anda boleh menghitungnya.

---

Versi visual dan interaktifnya, berupa penjelajahan tujuh wilayah dari pertanyaan pembuka sampai langkah nyata, bisa dilihat di presentasi sinematik Infrastruktur AI.