Menjalankan Model AI Tanpa GPU: Kekuatan Tersembunyi dari Optimasi Perangkat Lunak
Formula 'harus beli GPU untuk mulai AI' tidak selalu benar. Pelajari bagaimana optimasi matriks dapat meningkatkan kinerja dari Gflop/s ke Tflop/s, serta prinsip dasar cache locality, SIMD, dan blocking, melalui panduan praktis tim Grinda.
Menjalankan Model AI Tanpa GPU: Kekuatan Tersembunyi dari Optimasi Perangkat Lunak
Klaim 'Harus Beli H100 untuk AI' Hanya Benar Separuh
Jika tim Anda tengah memikirkan optimasi kinerja AI, Anda pasti pernah melontarkan pertanyaan, "Bisakah saya menjalankan AI tanpa GPU?" Ini adalah pertanyaan paling umum yang kami terima dalam praktik ekspor. Memang, jika melihat harga, satu unit NVIDIA H100 bisa melebihi 300 juta Rupiah, dan biaya operasional instance GPU cloud bisa menghabiskan jutaan Rupiah per bulan. Namun, saat kami memeriksa basis kode secara mendalam, kami menemukan fakta yang berbeda.
Sebagian besar bottleneck justru terletak pada level optimasi perangkat lunak, tepatnya pada cara implementasi operasi matriks. Perbedaan throughput antara kode perkalian matriks dengan loop Python sederhana dan implementasi BLAS yang dioptimalkan sesuai struktur cache bisa mencapai puluhan hingga ratusan kali lipat. Semua itu pada CPU yang sama. Kami akan membahas perbedaan antara benchmark operasi tunggal dan beban kerja pelatihan nyata secara jujur. Namun pertama-tama, mari kita pahami intuisi di balik klaim bahwa 'kinerja bisa ditingkatkan secara dramatis tanpa mengganti perangkat keras'.
Titik Awal Optimasi Inferensi LLM: Memahami Bottleneck
Apa Itu GEMM yang Mendominasi Operasi Transformer?
Struktur internal model bahasa besar seperti ChatGPT, Claude, dan Gemini didasarkan pada arsitektur Transformer. Layer Attention dan layer FFN (Feed-Forward Network) semuanya bermuara pada perkalian matriks, yaitu GEMM (General Matrix Multiply). Fakta bahwa 60-80% operasi model adalah GEMM telah berulang kali dikonfirmasi dalam berbagai studi analisis operasi deep learning. Singkatnya, seberapa efisien Anda menjalankan satu GEMM akan menentukan kecepatan inferensi dan pelatihan AI Anda secara keseluruhan.
Prinsip Utama Optimasi Kinerja AI: Mengapa Cache Miss Membuat Investasi Jutaan Rupiah untuk GPU Jadi Sia-sia
Ada tiga prinsip utama optimasi perangkat lunak low-level:
① Cache Locality: Baik CPU maupun GPU memiliki struktur memori hierarkis. Kecepatan membaca data dari cache L1 puluhan kali lebih cepat daripada memori utama (DRAM). Jika pola akses data dalam operasi matriks tidak ramah terhadap cache, perangkat keras secanggih apa pun akan menghabiskan lebih banyak waktu untuk menunggu memori. Mengubah urutan akses dengan satu baris kode dapat mengubah throughput secara signifikan.
② SIMD (Single Instruction Multiple Data): Metode pemrosesan beberapa data dengan satu instruksi. Dengan Intel AVX2, Anda dapat memproses 256 bit (8 nilai FP32) secara paralel; AVX-512 bahkan dapat memproses 512 bit. Jika digunakan dengan benar, jumlah data yang diproses dalam satu loop bisa meningkat 8 kali lipat.
③ Blocking (Tiling): Teknik memecah matriks besar menjadi blok-blok kecil yang pas di dalam cache. Daripada membaca seluruh matriks dari memori, data digunakan kembali secara berulang dalam ukuran yang sesuai dengan cache untuk memaksimalkan cache hit rate. Inilah alasan mengapa pustaka numerik berkinerja tinggi seperti OpenBLAS atau oneDNN menerapkan prinsip ini selama bertahun-tahun.
Melatih LLM dengan Swift? — Eksperimen Paradoks yang Membuktikan Pelajaran Universal
Upaya Mendobrak Stereotip 'AI = Python'
Baru-baru ini, komunitas pengembang melakukan eksperimen menarik, seperti implementasi GPT-2 dalam bahasa C via llm.c milik Andrej Karpathy atau penerapan optimasi perkalian matriks secara bertahap dalam Swift. Semua eksperimen ini menanyakan satu hal: jika kita mengubah bahasa atau kerangka kerja, seberapa besar efeknya jika prinsip optimasi low-level diterapkan dengan benar?
Gflop/s → Tflop/s: Kekuatan Prinsip Optimasi Low-level
Saat kami mereplikasi angka yang dilaporkan dalam eksperimen Swift ke dalam environment Python, arahnya sama. Dimulai dari implementasi naive (nested loop sederhana), kemudian menambahkan peningkatan cache locality → pemanfaatan SIMD → penerapan blocking, throughput melonjak drastis. Berikut hasil pengukuran kami di environment Python + NumPy:
| Tahap Optimasi | Metode Implementasi | Kinerja Relatif (vs naive) |
|---|---|---|
| naive | Nested loop Python murni | 1× (Dasar) |
| Peningkatan Cache Locality | Operasi setelah transpose | ~10× |
| Pemanfaatan BLAS | NumPy dot (via OpenBLAS) | ~200× |
| Mixed Precision | Operasi setelah konversi FP16 | ~250× |
Lebih penting dari angka mutlak adalah alur kontribusi di setiap tahap optimasi. Intinya adalah perbedaan kinerja yang luar biasa ini bisa didapat hanya melalui perubahan level kode tanpa mengganti perangkat keras.
Hal yang Perlu Diingat Sebelum Mempercayai Angka Benchmark
Mari kita jujur:
Pertama, hasil eksperimen Swift Apple Silicon mencakup karakteristik unit AMX (Apple Matrix Coprocessor) dan akselerasi Metal pada chip M1/M2/M3. Sebagian peningkatan mungkin berasal dari karakteristik perangkat keras, bukan hanya optimasi kode Swift.
Kedua, benchmark perkalian matriks tunggal berbeda dengan loop pelatihan LLM penuh. Pelatihan nyata yang melibatkan backpropagation, optimizer step, batch pipelining, dan overhead komunikasi multi-GPU tidak berarti otomatis mencapai level Tflop/s hanya dengan optimasi GEMM.
Ketiga, ekosistem ML Swift masih memiliki kesenjangan besar dibandingkan Python dalam hal diversitas pustaka, skala komunitas, dan kematangan perangkat.
Jadi, pelajaran sebenarnya bukanlah 'Swift bagus untuk AI', melainkan bahwa dalam bahasa apa pun, memahami prinsip optimasi low-level memungkinkan peningkatan kinerja yang dramatis.
Memikirkan Kembali 'Menjalankan AI Tanpa GPU' dalam Kendala Lapangan Ekspor
Ada kesenjangan antara diskusi optimasi infrastruktur AI umum dengan realitas di lapangan ekspor. Saat bekerja dengan klien, kami berulang kali menghadapi tiga kendala:
Server On-premise: Seringkali perusahaan tidak bisa menggunakan instance GPU cloud karena alasan keamanan dan kepatuhan. Jika pipeline inferensi harus dijalankan di server internal, optimasi perangkat lunak menjadi satu-satunya tuas pengungkit.
Keterbatasan SDM IT: Sebagian besar perusahaan ekspor skala menengah tidak memiliki ML Engineer khusus. Optimasi yang memiliki hambatan masuk rendah, seperti mengubah pengaturan PyTorch, jauh lebih realistis daripada tuning kernel CUDA yang kompleks.
Batasan Anggaran: Jika biaya GPU cloud mencapai jutaan Rupiah per bulan, banyak tim yang tidak mencapai ROI yang efisien. Meningkatkan throughput pada perangkat keras yang sudah ada melalui level perangkat lunak adalah jalur tercepat untuk memotong biaya.
Dengan ketiga kendala ini, urutan pendekatannya berubah. Titik awalnya bukan "GPU mana yang harus dibeli", melainkan "di mana letak bottleneck pada server yang ada saat ini".
Poin Praktis yang Bisa Segera Diterapkan untuk Optimasi Kinerja AI
Poin Optimasi Inferensi LLM di Lingkungan PyTorch/JAX
Prinsip cache locality, SIMD, dan blocking berlaku sama untuk Python + PyTorch, C++, maupun JAX. Untuk mengoptimalkan inferensi/fine-tuning AI tanpa GPU atau dengan GPU berspesifikasi rendah, ikuti checklist berikut:
- Profil terlebih dahulu. Anda tidak bisa mengoptimalkan tanpa mengukur bottleneck menggunakan
torch.profilerataupy-spy. Gunakan data, bukan perasaan. - Manfaatkan Mixed Precision. Menggunakan FP16 atau BF16 alih-alih FP32 dapat memotong penggunaan memori hingga setengahnya dan meningkatkan throughput. Bisa diterapkan hanya dengan
torch.autocastdi PyTorch. torch.compileatau XLA JIT. Sejak PyTorch 2.0,torch.compilemengoptimalkan grafik komputasi untuk meningkatkan kecepatan tanpa mengubah kode secara drastis.- Tinjau Kembali Batch Size & Layout Memori. Menyesuaikan batch size ke kelipatan dua dan memeriksa layout memori tensor (contiguous vs non-contiguous) bisa memberikan perbedaan yang berarti.
Realita Ekspektasi Kinerja Berdasarkan Lingkungan untuk Penghematan Biaya AI
Jujurnya, tanpa GPU mahal, fine-tuning model skala kecil (7B ke bawah), optimasi inferensi, dan prototyping sangat memungkinkan. Proyek open-source seperti llama.cpp yang dioptimasi untuk inferensi CPU sudah berada di level praktis. Namun, pre-training model dengan puluhan miliar parameter sulit hanya mengandalkan optimasi perangkat lunak untuk mengatasi ketergantungan perangkat keras. Membedakan hal ini adalah langkah pertama rencana penghematan biaya AI yang realistis.
Mengapa Tim Kami Begitu Terobsesi dengan Masalah Ini
Kendala terbesar penerapan AI dalam ekspor adalah biaya dan kecepatan. Begitu pertanyaan "Berapa biaya infrastruktur untuk mulai memakai AI?" muncul, banyak tim berhenti meninjau. Awalnya, kami juga mencoba menambah instance GPU cloud, namun setelah melihat pipeline-nya, bottleneck justru bukan pada model, melainkan ketidakefisienan kode pemrosesan permintaan inferensi.
Dalam pipeline pencarian pembeli kami, sebagian besar latensi inferensi justru berasal dari pra-pemrosesan data dan konfigurasi batch, bukan operasi model. Dengan beralih ke Mixed Precision dan menyesuaikan batch size, throughput pada server yang sama meningkat signifikan tanpa perlu penambahan instance GPU. Membiasakan diri memeriksa kode sebelum menambah anggaran GPU adalah langkah awal dari cara kami merancang layanan.
Saat Grinda menerapkan AI di lapangan ekspor, kami bertanya "bagaimana menjalankan operasi ini secara efisien" sebelum bertanya "di mana menyewa GPU". Teknologi hanyalah sarana; tujuannya adalah agar solusi tersebut bekerja dalam kecepatan dan biaya yang terjangkau bagi praktisi.
Kesimpulan: Jika Ingin AI Lebih Cepat, Curigai Kode Anda Terlebih Dahulu
Langkah Pertama yang Bisa Dilakukan Hari Ini
Inti dari biaya dan kecepatan pengoperasian LLM bergantung pada optimasi kinerja AI di level perangkat lunak, bukan sekadar spesifikasi perangkat keras. Prinsip cache locality, SIMD, dan blocking berlaku sama di stack apa pun. Langkah pertama Anda sebelum mengeluarkan tagihan GPU adalah menjalankan torch.profiler. Tanpa mengetahui letak bottleneck, mengganti perangkat keras ibarat mengganti ban mobil padahal mesinnya yang bermasalah.
Jika Ingin Mempelajari Lebih Dalam
Kami merekomendasikan kursus From Deep Learning Foundations to Stable Diffusion dari fast.ai atau proyek llm.c milik Andrej Karpathy untuk melihat optimasi perkalian matriks secara langsung melalui kode. Referensi ini sangat baik karena menyertakan komentar penjelasan "mengapa melakukan ini" di setiap tahap proses optimasi.
Penulis · Tim Grinda (Editor Riset Otomasi Penjualan & Pencarian Pembeli Luar Negeri)
Berdasarkan data pipeline pencarian pembeli lebih dari 200 perusahaan ekspor Korea dan pengamatan internal platform grinda.ai, kami menyunting strategi dan checklist yang dapat digunakan langsung dalam praktik ekspor.
Jika Anda penasaran dengan contoh optimasi pipeline AI untuk ekspor atau ingin berdiskusi mengenai cara mengurangi biaya inferensi di lingkungan on-premise, jangan ragu untuk menghubungi kami melalui Cek Bagaimana Grinda Mengurangi Biaya. Kita bisa meninjau poin-poin yang perlu diperiksa di level perangkat lunak sebelum memutuskan besaran anggaran GPU.
Q. Apakah LLM bisa digunakan dalam layanan nyata tanpa GPU? A. Tergantung pada ukuran model dan jumlah permintaan. Model 7B ke bawah yang dioptimasi dengan llama.cpp dapat berjalan dengan kecepatan inferensi praktis bahkan di CPU. Namun, untuk lingkungan produksi dengan permintaan konkuren yang tinggi atau memerlukan respon real-time, kemampuan pemrosesan paralel GPU tetap diperlukan. Pendekatan realistisnya bukan bertanya "bisa tanpa GPU?", melainkan "apa persyaratan minimum sesuai beban kerja saya" melalui profiling.
Q. Seberapa cepat torch.compile meningkatkan kinerja?
A. Tergantung pada struktur model dan ukuran input. Benchmark resmi PyTorch melaporkan peningkatan kecepatan inferensi 1,5–2 kali lipat pada model tertentu dengan backend Inductor. Perlu dicatat, karena adanya overhead kompilasi, efeknya lebih terasa pada lingkungan batch processing daripada lingkungan dengan permintaan singkat yang sering terjadi. Disarankan untuk mengukur beban kerja dengan torch.profiler sebelum menerapkannya.
Q. Seberapa realistis kisaran penghematan biaya 도입 AI melalui optimasi perangkat lunak? A. Berdasarkan observasi kami, tim yang sebelumnya beroperasi tanpa profiling dapat meningkatkan throughput secara signifikan pada perangkat keras yang sama setelah menerapkan batch size, mixed precision, dan kompilasi secara bertahap. Namun, tingkat penghematan bergantung pada kondisi awal.