AI inference membuat memory dan storage jadi keputusan arsitektur
Oleh Zai · Let's Make It Easy
Dipublikasikan 2026-09-05
Mengapa workload AI inference membuat memory, storage, dan data movement ikut menentukan performa sistem.
Saat membahas infrastruktur AI, perhatian sering langsung tertuju pada GPU. Artikel “Architecting memory and storage in the AI era” dari MIT Technology Review Insights memakai sudut pandang berbeda: ketika inference berjalan terus menerus, memory, storage, dan perpindahan data ikut menentukan latency serta biaya operasi.
1. Apa yang berubah pada workload inference?
Training biasanya dibahas sebagai pekerjaan besar yang berjalan dalam fase tertentu. Inference lebih dekat dengan layanan produksi: request datang terus, data harus diambil, diproses, lalu dikirim ke model dengan jeda yang kecil. Sistem bisa tersebar di beberapa lokasi dan melayani kebutuhan yang berbeda.
Artikel tersebut menyebut beberapa bagian yang saling terkait, termasuk memory bandwidth, storage throughput, networking, latency, dan performance per watt. Jika satu bagian tertinggal, peningkatan pada bagian lain belum tentu memperbaiki pengalaman pengguna.
2. Mengapa RAG sensitif terhadap data movement?
Retrieval augmented generation mengambil konteks dari sumber eksternal sebelum model menyusun jawaban. Pipeline seperti ini perlu membaca database atau index, melakukan retrieval, memindahkan hasil ke proses inference, dan sering kali melakukan caching. Jadi waktu respons tidak hanya ditentukan oleh token generation.
Untuk operator, ini berarti tracing perlu mencakup request ke vector store, database, cache, dan network. Mengukur latency model tanpa mengukur retrieval bisa membuat sumber lambat terlihat seolah olah ada di model.
3. Sponsored analysis tetap perlu dibaca kritis
Artikel MIT Technology Review Insights ini dibuat dalam partnership dengan Micron. IBM menjelaskan AI infrastructure dari sudut pandang yang lebih umum, tetapi tidak memverifikasi angka atau rekomendasi vendor yang ada di artikel utama. Karena itu, tulisan ini tidak boleh dipakai sebagai benchmark universal.
Poin yang masih berguna adalah cara memecah masalah: mulai dari karakter workload, lalu lihat bagaimana data diambil, disimpan, dipindahkan, dan di-cache. Desain yang cocok untuk batch inference belum tentu cocok untuk agent yang perlu merespons secara interaktif.
4. Checklist praktis
Sebelum membeli hardware, ukur porsi waktu yang dihabiskan pada model, retrieval, storage, serialization, dan network. Catat ukuran context, pola cache, concurrency, serta perubahan latency saat data bertambah. Dengan begitu, tim tidak otomatis mengatasi semua masalah dengan menambah GPU.
5. Cara menguji bottleneck
Mulai dari trace end to end pada satu request. Ukur waktu retrieval, serialisasi, transfer, cache lookup, dan inference secara terpisah. Lalu ulangi dengan concurrency serta ukuran context yang berbeda. Data ini membantu membedakan masalah kapasitas dari masalah arsitektur. Jika cache hit sudah tinggi tetapi latency tetap besar, perhatian bisa bergeser ke network atau serving layer, bukan langsung menambah memory.
Referensi: https://www.technologyreview.com/2026/09/04/1140872/architecting-memory-and-storage-in-the-ai-era/