Ask HN: ChatGPT bisa melayani 700 juta orang, jadi kenapa saya bahkan tidak bisa menjalankan satu GPT-4 secara lokal?

• Sam Altman mengumumkan bahwa ChatGPT menangani sekitar 700 juta pengguna mingguan
• Saat model setingkat GPT-4 dijalankan secara lokal, masalah kekurangan VRAM dan penurunan kecepatan menjadi sangat serius, sehingga muncul pertanyaan bagaimana OpenAI menangani penggunaan berskala besar ini dengan latensi rendah dan performa tinggi
• Ingin mengetahui teknik optimisasi model, pemrosesan terdistribusi, perangkat keras khusus, dan load balancing yang melampaui sekadar klaster GPU sederhana

---

Ringkasan komentar inti

1. Arsitektur inferensi terdistribusi skala besar

• Model sharding
  • Parameter disimpan secara terdistribusi di beberapa GPU
  • Saat permintaan masuk, tiap GPU menghitung bagian parameternya sendiri lalu hasilnya digabungkan
• Tensor parallelism
  • Operasi dalam satu layer dijalankan secara paralel oleh beberapa GPU
• Pipeline parallelism
  • Layer dibagi menjadi beberapa tahap, lalu diproses berurutan dan bersamaan seperti pipeline
• Pemrosesan paralel campuran untuk mengoptimalkan memori GPU dan beban komputasi

2. Optimisasi memori dan kecepatan

• Quantization: parameter diubah ke presisi bit yang lebih rendah untuk mengurangi penggunaan VRAM
• Layer offloading: bila perlu, sebagian layer dipindahkan ke memori CPU
• LoRA / Adapter Layers: hanya tugas tertentu yang di-fine-tune sehingga tidak perlu memuat ulang seluruh model
• KV caching: konteks digunakan ulang untuk menghilangkan perhitungan berulang

3. Perangkat keras khusus dan jaringan

• Penggunaan besar-besaran NVIDIA H100, A100, dan sebagian TPU terbaru
• Transfer data ultra-cepat melalui NVLink dan NVSwitch antar-GPU, serta Infiniband antar-klaster
• Membangun jaringan backbone global antar-datacenter untuk meminimalkan latensi

4. Distribusi geografis dan load balancing

• Menempatkan GPU farm di berbagai region di seluruh dunia
• Menghubungkan permintaan pengguna ke region terdekat dengan GeoDNS
• Menskalakan naik/turun klaster GPU secara dinamis sesuai pola lalu lintas
• Mendistribusikan ulang trafik global saat beban terkonsentrasi di region tertentu

5. Optimisasi pemrosesan permintaan

• Batch inference: menggabungkan permintaan dari banyak pengguna agar inferensi dilakukan sekaligus
• Pra-pemrosesan dengan model kecil: permintaan sederhana ditangani model kecil, hanya permintaan kompleks yang memanggil model besar
• Caching hasil: hasil untuk prompt yang sama atau permintaan serupa langsung dikembalikan dari cache
• Prompt engineering untuk mencegah pemborosan token yang tidak perlu

6. Optimisasi operasional dan biaya

• Meminimalkan sumber daya menganggur dengan pemantauan dan penjadwalan penggunaan GPU
• Meningkatkan efisiensi daya datacenter dan menerapkan pendinginan cair
• Meningkatkan kecepatan inferensi dengan optimisasi compiler dan runtime internal
• Mengoperasikan pipeline otomatis untuk pembaruan dan deployment model

Contoh alur arsitektur menyeluruh

1. Menerima permintaan pengguna → dirutekan ke region terdekat dengan GeoDNS
2. Prapemrosesan → permintaan sederhana ke model kecil, hanya permintaan kompleks yang diteruskan ke model besar
3. Pemrosesan inferensi terdistribusi
   • Menerapkan model sharding + tensor parallelism + pipeline parallelism
   • Bertukar hasil antara melalui jaringan berkecepatan tinggi antar-GPU
4. Pascapemrosesan dan caching hasil → menyimpan cache untuk permintaan yang sama atau mirip
5. Mengembalikan respons → memberikan hasil dalam 1~2 detik

[popkins]

Dalam kasus OpenAI, bukan hanya hardware Nvidia, tetapi AMD MI300X juga sedang digunakan untuk inferensi. Untuk pelatihan memang hanya Nvidia,
namun untuk inferensi mereka mati-matian berusaha mengamankan VRAM sebisa mungkin dibanding biaya investasinya.
Dalam kasus Microsoft juga sama, untuk inferensi mereka mencampur penggunaan Nvidia dan AMD.

[popkins]

Khususnya di region Azure Asia, porsi AMD yang digunakan OpenAI sekitar NVIDIA 8 / AMD 2

[GN⁺]

Komentar Hacker News

• Saya bekerja langsung menangani sistem seperti ini di Google (ini pendapat pribadi), dan saya bisa bilang dengan yakin bahwa orang-orang cerdas benar-benar memikirkan semua sisi masalah ini dengan serius. Saya tidak bisa membagikan lebih banyak informasi, tetapi saya ingin membagikan materi yang ditulis rekan-rekan saya. Ada penjelasan yang sangat bagus tentang arsitektur akselerator dan cara optimasi untuk mencapai kecepatan tinggi di scaling book. Khususnya jika Anda penasaran soal inferensi, bab inference akan membantu. Selain itu saya merekomendasikan panduan unsloth. Mereka menggali berbagai model secara mendalam untuk menemukan optimasi, lalu merangkum dan menyajikannya dengan baik. Selain panduan Gemma 3n, ada juga banyak panduan lain

  • Kalau dijelaskan tanpa terlalu dibungkus aura misteri, inferensi pada dasarnya adalah pekerjaan yang (sebagian besar) stateless. Jadi, tidak seperti training, kita tidak perlu memikirkan konsistensi memori antar ratusan ribu mesin atau kegagalan mesin. Kita hanya perlu mengirim sejumlah kecil data dengan baik ke mesin-mesin yang sangat besar. Mesin riset di tempat saya bekerja adalah mesin superkuat dengan 8 GPU, dan selama modelnya muat di total VRAM, hampir semua pekerjaan bisa diproses dengan baik. Bahan rahasia untuk skala besar adalah "modal dalam jumlah luar biasa besar". NVIDIA pernah mengirim mesin DGX berlapis emas ke kami, tetapi itu tidak terlalu padat dan sangat mahal. Kebanyakan perusahaan besar sudah punya sistem RPC dan orkestrasi yang andal, jadi bagian yang benar-benar sulit bukan pengiriman pesan, melainkan bagaimana menempatkan model agar sesuai dengan hardware yang memilikinya (ini bukan bidang keahlian saya)

  • Rak inferensi modern berskala besar, teknik RDMA dan jaringan latensi rendah yang sudah dikenal luas, serta optimasi MLA dan cache yang kuat tidak perlu digambarkan seolah-olah teknologi misterius. Hal-hal ini sudah dipahami dengan baik secara publik, malah kalau perusahaan terkenal melakukan sesuatu yang sangat kustom, sering kali justru jadi beban karena masalah kompatibilitas dengan masa lalu. Yang benar-benar penting adalah memiliki sistem dan proses yang matang untuk menjalankan sistem besar. Ini mencakup berbagai area, dari pengadaan perangkat, pelatihan SRE, sampai RTL untuk TPU baru. Jika ada seseorang yang unggul 10x, kita akan langsung tahu (orang dengan pengalaman inferensi skala besar selama 10 tahun di perusahaan TOP-5)

  • Soal ungkapan "kami adalah orang-orang pintar yang benar-benar memikirkan semua masalah dengan serius", sebenarnya ini bisa dipahami sebagai menjalankan sistem time-sharing bergaya mainframe tahun 1970-an

  • Saya penasaran apakah Google, berkat TPU, memiliki profitabilitas inferensi model internal yang jauh lebih tinggi dibanding menyewa kartu NVIDIA. Setahu saya OpenAI sebagian besar memperoleh GPU melalui kemitraannya dengan Microsoft. Saya membaca tautan dan bukunya dengan tertarik

  • Kalimat "bahkan model 'kecil' saat ini berjalan mendekati batas hardware" sangat membekas. Ini terdengar mirip dengan kalimat era 60-an dan 70-an bahwa "bahkan program kecil pun berjalan menyesuaikan batas hardware". Meskipun optimasi dan efisiensi dalam software engineering tampak memudar, di pengembangan LLM hal itu masih sangat hidup

• Satu H100 berharga $20.000 dan punya VRAM 80GB. Bisa dibayangkan satu server rak 2U berisi kartu senilai $100.000 seperti ini. Jika perangkat seperti ini memenuhi satu rak penuh, lalu ditambah CPU, RAM, dan pendinginan, biayanya bisa mencapai sekitar $1 juta per rak (belum termasuk biaya operasional dan personel pemeliharaan). Bahkan untuk perangkat yang dianggap "murah", satuan hitungnya tetap sangat besar. Saya berharap saat bubble AI mereda, kita bisa menjalankan model lokal yang bagus secara realistis. Dalam 10 tahun, mungkin server seharga $100.000 seperti ini akan dijual seharga $3.000 di eBay, dan para teknisi listrik akan menerima permintaan untuk memasang daya 240V di garasi atau ruang server dadakan

  • Tidak perlu menunggu 10 tahun, Anda sudah bisa membeli DGX-1 di eBay sekarang dengan harga di bawah $10.000. Dapat 256GB VRAM (HBM2), NVLink, RAM 512GB, CPU 40-core, SSD 8TB, dan HBA 100Gbit. Produk non-NVIDIA-brand bahkan bisa dibeli seharga $6.000. Hanya saja, perangkat ini sangat berat, jauh lebih berisik dari yang dibayangkan, dan satu unit hampir menghabiskan seluruh sirkuit 240V 16A. Pada saat yang sama, ia juga menghasilkan panas 13.000 BTU per jam

  • Bahkan jika bubble AI tidak pecah, kemungkinan besar server-server itu tetap akan membanjiri eBay 10 tahun dari sekarang. Pusat data akan meng-upgrade hardware dan menjual perangkat bekas ke pihak ketiga

  • Secara pribadi, saya curiga model-model terbuka menggunakan komputasi jauh lebih sedikit daripada yang kita kira. Pada model Mixture of Experts terbaru, berkat top-k sampling, yaitu struktur yang hanya mengaktifkan sebagian expert (parameter) untuk dievaluasi, bahkan model SOTA pun tidak memerlukan komputasi jauh lebih besar daripada model non-MoE 70-80B

  • Dalam AI serving tingkat perusahaan, pertanyaan sebenarnya bukan "bagaimana melayani pengguna", melainkan bahwa investor pada akhirnya mengharapkan ROI. Infrastruktur sebanyak apa pun yang dibutuhkan pada dasarnya bisa dibangun selama ada investasi. Bahkan tanpa optimasi, kalau perlu ya tinggal bangun gudang dan rak sebanyak yang dibutuhkan untuk melayani beban itu

  • Saya bukan orang Amerika, jadi bagian tentang 240V itu terasa lucu

• Anda punya beberapa ribu dolar, mereka punya puluhan miliar dolar. Selisih skalanya 1.000 vs 10.000.000.000. Efisiensi yang mereka miliki juga mungkin satu atau dua orde magnitudo lebih baik berkat skala. Selain itu, bahkan di MacBook (RAM 24GB), Anda bisa menjalankan model lokal yang performanya setara dengan masa awal rilis GPT-4. Tautan perbandingan performa

  • Jika 700 juta pengguna itu tersebar pemakaiannya sepanjang hari atau minggu, kenyataannya mungkin hanya sekitar 10 juta sesi yang aktif bersamaan. Pengguna individu tidak bisa menabung resource komputasi selama seminggu lalu memakainya sekaligus, tetapi penyedia layanan hanya perlu melakukan scale-out horizontal untuk memenuhi puncak beban. Karena itu, untuk kebutuhan performa yang sama, lingkungan lokal akan memerlukan hardware jauh lebih banyak

• Bahkan satu node GPU saja bisa memberikan FLOPs dan bandwidth memori yang sangat tinggi. Saat menangani sedikit request, GPU sering kali lebih banyak menunggu data bobot di-stream dari RAM ke unit komputasi. Jika request digabung dan diproses sebagai batch, satu kumpulan bobot bisa dibaca sekali lalu dipakai untuk banyak request secara paralel, sehingga efisiensi menjadi maksimal. Selain itu, model bisa dikompresi ke 8-bit atau format yang lebih rendah untuk mengurangi jumlah data yang harus di-stream, dan GPU modern mendukung komputasi 8-bit/4-bit. Model Mixture of Experts hanya memakai sebagian parameter untuk setiap token, sehingga lebih sedikit bobot yang perlu dimuat. Teknik speculative decoding memakai model kecil untuk memprediksi beberapa token lebih dulu, lalu model utama hanya menerima yang memang cocok. Semua optimasi ini jika digabungkan menghasilkan efisiensi yang luar biasa (berdasarkan pengalaman sebagai direktur tim inferensi Databricks)

• Salah satu saus rahasia OpenAI adalah kerugian bernilai miliaran dolar. Pada 2024 mereka rugi $5 miliar. Artikel terkait

  • Belakangan ini pendekatan agentic muncul dan banyak mengubah keadaan. Dulu 1 request berarti 1 proses, sekarang satu tugas bisa memicu ratusan proses sekaligus. Karena pemrosesan paralel seperti ini dimungkinkan, OAI/Azure punya keunggulan dibanding model lokal

  • Jika R&D dihentikan dan hanya melayani model yang sudah ada, sepertinya mereka bisa mencapai titik impas

  • Ini tepat mengenai intinya. Investasi Microsoft hingga $10 miliar menutup pretraining, R&D, dan biaya inferensi, tetapi mereka tetap rugi miliaran dolar. Ini struktur kapitalisme bergaya VC yang berorientasi pertumbuhan

• Dalam inferensi skala besar, menggabungkan request menjadi batch dan memprosesnya sekaligus jauh lebih efisien daripada pendekatan alokasi GPU per pengguna seperti di lingkungan pribadi. Jika ingin tahu trik engineering tingkat menengah, Anda bisa melihat tulisan tim kami di blog Fin AI. (OpenAI dan lainnya mungkin juga memakai teknik tertutup yang tidak dibahas di sini) Posting terkait

  • Ini jawaban inti yang sebenarnya. Dibanding berbagai hal lain yang dibahas di atas, batching-lah cara yang benar-benar memangkas biaya besar-besaran. Misalnya kalau memproses satu request butuh $50.000, berkat batching Anda bisa memproses 100 request sekaligus hampir tanpa kerugian tambahan dengan $50.000 yang sama. Saya tidak tahu pasti berapa banyak pengguna yang bisa dilayani satu hardware, tapi saya menduga skala ratusan. Artinya biaya bisa turun efektif dari $50.000 menjadi $500 (saat ada cukup banyak pengguna). Bottleneck pemrosesan LLM pada umumnya adalah waktu untuk memuat bobot ke GPU, jadi alih-alih memproses setiap request satu per satu, efisiensi dimaksimalkan dengan memproses komputasi dari banyak request bersama-sama. Misalnya, anggap ada 3 set bobot (A, B, C) yang masuk ke cache GPU, dan ada 2 request (1, 2). Pendekatan biasa memuat dan memakai bobot untuk tiap request secara terpisah, sedangkan pendekatan batching memuat bobot sekali lalu menggunakannya untuk banyak request. Jika membandingkan waktu memuat bobot dan waktu komputasi, perbedaan kecepatan sebelum dan sesudah batching menjadi sangat jelas. Dalam dunia nyata, memuat bobot jauh lebih lambat daripada komputasi, sehingga makin banyak pengguna, makin besar selisihnya. Dalam praktiknya, memori untuk status aktif juga dibutuhkan agar lebih banyak pengguna bisa dilayani, jadi perlu menyeimbangkan berapa banyak pengguna per cluster GPU. Kesimpulannya, hardware untuk LLM serving memang sangat mahal, tetapi jika sudah dimiliki, Anda bisa melayani ratusan pengguna sekaligus hampir tanpa penurunan performa

• Memiliki 700 juta pengguna per minggu tidak banyak menjelaskan seperti apa beban nyatanya. Bahkan jika sebagian besar pengguna ChatGPT memakainya satu jam per hari sepanjang minggu, 96% waktunya tetap idle. Banyak orang juga hanya memakai model yang kurang kompleks. Fakta bahwa mereka sengaja menyebut "pengguna mingguan" berarti bahkan di antara pengguna aktif harian pun hanya sedikit yang memakainya sekali sehari. Tantangan intinya adalah 1) membuat server yang bisa memuat model di memori dan memproses token cukup cepat, 2) menyediakan cukup banyak server untuk memenuhi throughput token total pada saat puncak, 3) mendistribusikan semua request ke server secara efisien. Ada detail-detail lain juga, tetapi tugas terakhir itu sebenarnya terasa mirip dengan menjalankan mesin pencari. Semua state ada di riwayat percakapan chat, jadi tidak perlu server yang sama selalu menangani chat yang sama. Saat Anda melihat pesan "Thinking...", tidak terlihat apakah model benar-benar sedang menghitung atau hanya sedang menunggu server tersedia dalam antrean

• Salah satu kunci terbesar mengapa LLM berjalan baik dalam skala besar adalah "ukuran batch". LLM modern kebanyakan memakai arsitektur "Mixture of Experts", yang hanya mengaktifkan sebagian parameter total pada satu waktu. Karena itu, pemrosesan batch besar menjadi jauh lebih efisien. Jika Anda menjalankan GPT-4 di rumah, Anda harus bisa menaruh seluruh model di VRAM, sehingga butuh beberapa GPU seperti H100 (sekitar $40.000 per kartu). Tetapi dengan tingkat pemakaian pribadi, kartu-kartu itu tidak akan termanfaatkan dengan baik. Ini mirip seperti bertanya, “mengapa Apple bisa membuat iPhone untuk miliaran orang, tetapi saya bahkan tidak bisa membuat satu pun di garasi?”

  • Ringkasnya, beban inferensi tersebar dengan baik ke banyak pengguna sehingga bisa berjalan efisien

  • Kalau begitu, saya penasaran apakah mungkin membuat struktur yang menaruh bagian yang jarang dipakai di main memory, dan bagian yang sering dipakai di VRAM

  • Analogi yang sangat tepat

• Satu trik yang juga bisa diterapkan di rumah dan berperan penting dalam performa Cerebras adalah speculative decoding. Dengan cara ini, model draft yang jauh lebih kecil memprediksi token dengan komputasi dan memori yang jauh lebih sedikit, lalu model utama menerima token-token yang memang kemungkinan akan dipilihnya. Pada konfigurasi yang baik, ini bisa memberi peningkatan kecepatan hingga 3x. Untuk structured output, bisa juga diterapkan "fast forwarding" yang melewati token-token yang bisa diprediksi, misalnya dengan mengisi dulu format awal JSON, sehingga kecepatan bisa naik sampai 3x

  • Di LM Studio Anda bisa mencoba speculative drafting dengan menggabungkan gpt-oss-120b dan gpt-oss-20b. Namun rasanya peningkatan performanya tidak terlalu terasa

• Inti inferensi LLM adalah perkalian matriks-vektor. Saat harus menangani banyak query sekaligus, vektor dari tiap query bisa dikumpulkan menjadi matrix, lalu dihitung bersama lewat perkalian matriks-matriks. Dari sudut pandang hardware, daripada menghabiskan waktu melakukan perkalian matriks-vektor berulang kali, satu kali perkalian matriks-matriks jauh lebih efisien. Inilah batching. Trik kedua adalah speculative decoding. Inferensi terdiri dari dua tahap, pemrosesan prompt dan generasi token, dan keduanya pada dasarnya memakai struktur yang sama yaitu 'forward pass'. Pemrosesan prompt bisa diparalelkan lewat perkalian matriks-matriks, dan hanya hasil terakhir yang dipakai untuk memulai generasi token. Namun karena token masa depan belum diketahui, biasanya tahap ini tidak bisa diparalelkan. Karena itu, model draft yang cepat digunakan untuk memprediksi N token ke depan, lalu token-token itu dimasukkan ke prompt input dan forward pass paralel dijalankan di model utama. Dari N token yang dihasilkan, semua token hingga token pertama yang cocok bisa langsung dianggap valid. Secara teori, ini bisa meningkatkan kecepatan inferensi 2~4x. Saya sendiri tidak mengimplementasikan ini langsung dalam pekerjaan, tetapi saya menduga tambahan lain seperti pengelompokan paralel berdasarkan panjang query atau load balancing real-time juga akan diterapkan (karena tidak semua request punya panjang yang sama, dan ini diperlukan agar ketimpangan resource bisa dicegah)