Infrastruktur AI yang dimiliki, dibagi, dan dikendalikan sendiri.

NUSAPOD mengubah server GPU menjadi kapasitas AI yang bisa dialokasikan ke banyak unit kerja — lengkap dengan endpoint, kontrol siklus hidup, dan pengawasannya.

Konteks

Kebutuhan AI datang dari seluruh unit kerja. Jalur yang tersedia belum memadai.

Setiap instansi kini menghadapi permintaan yang sama dari berbagai unit. Hanya ada dua jalur yang lazim ditempuh, dan keduanya menyisakan persoalan.

Yang belum tersedia bukan perangkatnya. GPU dapat dibeli. Yang belum ada adalah lapisan yang mengubah GPU menjadi kapasitas yang dapat dibagi, dijamin, dan diawasi.

Pola yang terulang

Apa yang virtualisasi lakukan untuk server, NUSAPOD lakukan untuk GPU.

Pusat data pernah melewati persoalan yang sama persis. Hanya sumber dayanya yang berbeda.

Instansi tidak kekurangan GPU. Yang belum ada adalah lapisan yang mengubahnya menjadi kapasitas AI yang dapat dibagi ke banyak unit kerja — persis peran yang dimainkan virtualisasi pada era server.

Definisi

Layer orkestrasi antara GPU dan layanan AI Anda.

NUSAPOD berjalan di atas server GPU yang telah dimiliki instansi. Operator meminta kapasitas dalam GB — bukan dalam jumlah GPU — lalu men-deploy model di atasnya.

Satu dashboard untuk model directory, alokasi VRAM per GPU, pod yang sedang berjalan, dan monitoring — tanpa database terpisah, seluruh state berada di cluster.

Kemampuan inti

Satu GPU, dibagi sesuai kebutuhan nyata.

Kapasitas diminta dalam satuan GB. Setiap pod memperoleh hard limit VRAM: apabila workload meminta melebihi jatahnya, alokasi ditolak di level driver — tanpa berdampak pada pod lain di GPU yang sama.

Pembeda teknis

Time-slicing atau resource partitioning? Keduanya — di sumbu berbeda.

Pertanyaan yang selalu muncul dari tim teknis. Jawabannya bukan salah satu di antaranya: VRAM dipartisi keras, compute dibagi waktu. Kombinasi inilah yang membedakan NUSAPOD dari GPU sharing pada umumnya.

Dua sumbu, dua kebijakan. VRAM selalu dibatasi ketat, karena melebihi batas VRAM berarti proses gagal. Compute dibiarkan mengalir secara default agar pod yang sedang tidak aktif tidak menahan kapasitas yang tidak digunakannya — dan apabila sebuah lembaga memerlukan jaminan porsi compute, batas per pod dapat diaktifkan.

Dampak ekonomi

GPU yang sama, beberapa workload sekaligus.

Tanpa NUSAPOD setiap request mengunci GPU secara utuh — sisa VRAM menjadi fragmented dan terbuang. Dengan NUSAPOD workload berbagi GPU sesuai kebutuhan VRAM masing-masing, dan GPU yang tersisa tetap tersedia untuk unit berikutnya.

Multi-organisasi

Satu fleet GPU, dipakai banyak lembaga.

Dua topologi deployment, dipilih sesuai tingkat pemisahan yang diminta tata kelola Anda.

Skenario penerapan

Kapasitas dibagi sesuai kebutuhan, sisanya siap dipakai.

Ilustrasi satu server dengan dua GPU H100 80 GB: setiap unit kerja memperoleh VRAM sebesar kebutuhannya, dan kapasitas yang belum terpakai tetap tersedia.

Alur end-to-end

Dari server kosong ke endpoint aktif.

Empat langkah, seluruhnya dari dashboard. Tidak ada YAML yang perlu ditulis manual.

Operasi harian

Integrasi

Kompatibel dengan SDK OpenAI yang sudah dipakai tim Anda.

Tidak diperlukan SDK khusus. Cukup ubah base URL dan API key — aplikasi yang telah ada langsung berjalan di atas model internal.

# Endpoint per deployment, otomatis aktif saat pod running
curl https://ai.instansi.go.id/m/dep-9b67e5b7/v1/chat/completions \
  -H "Authorization: Bearer np_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4-12b",
    "messages": [
      {"role":"user","content":"Ringkas notulen rapat ini."}
    ]
  }'

Monitoring

Angka yang menjawab pertanyaan operator, bukan sekadar grafik.

Kedaulatan & deployment

Kesimpulan

Satu GPU. Banyak layanan. Kendali penuh di tangan instansi.

VRAM slicing·Multi-GPU placement·Model directory·Endpoint OpenAI-compatible·API key ber-scope·Telemetri & alert·RBAC·Audit log