AI yang Jalan di Browser, Tanpa Server dan Tanpa API Key

Pada awal Oktober 2026, MicroLLM Lab dan beberapa playground sejenis berhasil menjalankan model bahasa berparameter 26 juta sampai 360 juta sepenuhnya di dalam tab browser.

Catatan status: belum terverifikasi. Klaim MicroLLM Lab dan playground sejenis di sini berasal dari materi yang dipublikasikan perusahaan, belum diuji ulang pihak ketiga. Angka ukuran unduhan di bawah juga perkiraan hitungan sendiri, bukan angka resmi. Perlakukan sebagai indikasi arah, bukan angka pasti. Tidak ada server, tidak ada API key, dan tidak perlu memasang CUDA di komputer sendiri. Modelnya dikuantisasi ke 4 bit dan dijalankan lewat WebGPU, API browser yang membuka akses komputasi GPU ke JavaScript.

Yang perlu dipahami dengan benar bukan "bisakah model sekecil ini jalan", tapi model seperti apa yang benar-benar jalan dan di mana batasnya. Kedua jawaban itu ditentukan oleh tiga mekanisme yang baru bisa bertemu bersamaan.

Tiga hal yang harus benar sekaligus

Model kecil saja tidak cukup. WebGPU saja juga tidak. Yang membuat ini mungkin adalah ketiganya bertemu:

Angka-angka itu perkiraan ukuran unduhan, bukan hasil pengukuran satu perangkat tertentu. Ukuran sebenarnya bergantung pada format berkas dan apakah sebagian bobot disimpan dalam presisi lebih tinggi.

Kenapa 4-bit tidak merusak model separuh yang seharusnya

Argumen yang sering dipakai kedengarannya berlebihan: memangkas presisi jadi seperempat harus menghapus seperempat model. Kenyataannya tidak sesederhana itu, dan alasannya ada di cara bobot dipakai.

Di layer transformer, yang terjadi pada setiap token adalah perkalian matriks. Bobot di dalam matriks itu hampir semua bernilai kecil dan berkerumun di sekitar nol. Menyimpan sebagian besar dari mereka sebagai bilangan bulat 4 bit dengan faktor skala per kelompok menghasilkan kesalahan yang sangat kecil, karena nilai yang dibulatkan memang sudah mendekati nol.

Yang benar-benar rusak justru kemampuan yang butuh representasi halus, yaitu model kecil. Model kecil tidak punya redundant; setiap bobotnya benar-benar dipakai. Model besar punya banyak jalur yang bisa saling menggantikan, dan pembulatan di satu jalur sering tertutup jalur lain.

Ukuran yang tepat terlihat di angka yang beredar: mode compact 135 juta parameter disebut "sering tidak koheren", sementara 360 juta sudah bisa dipakai untuk hal sederhana. Batasnya bukan ukuran memorinya, tapi jumlah parameter yang benar-benar dipakai model itu untuk menyimpan pengetahuan.

Batas yang tidak bisa dilewati: coherensi

Dokumentasi runtime in-browser hampir selalu memuat peringatan yang sama dan sering dilewati: model di bawah 2 miliar parameter sering mengarang fakta, dan keluarannya harus dibaca sebagai draf, bukan sebagai rujukan.

Alasannya, model kecil tidak bisa menyimpan dunia. Parameternya memang menyimpan pola bahasa, kompresi yang cukup untuk menulis kalimat yang masuk akal, tapi tidak cukup untuk menyimpan fakta yang bisa diambil kembali. Jawaban yang masuk akal tapi salah bukan bug; itu hasil yang paling mungkin terjadi ketika informasi dipaksakan melewati kapasitas yang lebih kecil.

Akibatnya, usage yang masuk akal untuk model browser bukan "tanya apa saja", melainkan tugas sempit dengan jawaban yang bisa diperiksa:

• Menggolongkan teks ke dalam kategori
• Mengambil nama, tanggal, dan angka dari teks
• Mengubah nada dan panjang jawaban
• Menerjemahkan istilah teknis dengan daftar yang kamu sediakan sendiri
• Menjalankan RAG di mana model kecil hanya menulis kueri retrie, bukan menyusun jawaban

Tugas-tugas itu punya satu ciri yang sama: keluarannya bisa diverifikasi tanpa model yang lebih besar.

Empat angka yang membantu penilaian cepat. Lima belas sampai sembilan puluh detik adalah unduhan model pertama pada koneksi sedang. Setelah itu, muat berikutnya berjalan dalam hitungan detik karena bobotnya sudah ada di cache browser.

Lima puluh sampai delapan puluh empat megabyte adalah jejak memori untuk model seratus juta parameter pada kuantisasi 4 bit dengan pengelompokan 32. Angka itu bukanmarketing; itu hasil penghitungan ukuran berkas setelah dikompresi.

Seratus lima belas token per detik tercatat untuk model 124,6 juta parameter di Apple M4 lewat Safari dan Metal. Model 135 juta parameter di perangkat yang sama mencapai 66 token per detik. Perbedaan itu bukan kebetulan: arsitektur yang lebih besar butuh lebih banyak operasi per token.

Sedangkan di sisi lain, satu model frontier di server biasanya menjawab pada 30 sampai 60 token per detik. Artinya model kecil di browser tidak selalu lebih lambat dari model besar di pusat data -- untuk model 100 sampai 400 juta parameter, di perangkat yang punya GPU, ia justru bisa lebih cepat karena tidak ada perjalanan bolak-balik ke server.

Itu poin yang jarang disebut: sebagian besar disadvantage model lokal berasal dari jaringan dan antrean, bukan dari komputasi. Menghilangkan perjalanan itu restoring sebagian besar disadvantages itu.

Sejarah singkat: dari plugin ke API standar

Menjalankan AI di browser punya sejarah panjang yang penuh kegagalan. Yang pertama adalah WebGL, API yang sudah ada puluhan tahun di mana-mana, tapi hanya bisa menghitung di atas shader. Shader terlalu terbatas untuk attention: satu lapis attention butuh menyimpan matriks untuk seluruh konteks, dan WebGL tidak punya cara menulis dan membaca buffer itu secepat yang dibutuhkan transformer.

Percobaan berikutnya memakai WebAssembly plus worker terpisah. WebAssembly mengompilasi kode ke instruksi mesin asli, jadi jauh lebih cepat daripada JavaScript. Tapi WebAssembly tidak punya akses GPU. Hasilnya model tetap jalan, tetapi di CPU, dan itu terlalu lambat untuk interaksi.

WebGPU menutup dua celah sekaligus. Browser sekarang bisa menulis shader komputasi, dan yang lebih penting punya kontrol eksplisit atas memori. Shader terpisah bisa mengerjakan attention sementara buffer konteks tetap tinggal di memori video. Itulah yang membuat model 1,5 miliar parameter bisa jalan di laptop tanpa server.

Perubahan dari WebGL ke WebGPU bukan cuma soal kecepatan, tapi soal paradigm. WebGL dianggap aplikasi grafis yang kebetulan bisa menghitung. WebGPU dirancang sebagai API komputasi umum dengan akses GPU yang eksplisit, mirip CUDA yang terbuka untuk browser.

Analisis: apakah ini akan menggantikan API

Tidak untuk semua kasus, dan alasannya struktural, bukan teknis.

Pemisahannya jelas. Model lokal menang di mana privasi dan biaya marginal menentukan, dan model API menang di mana pengetahuan luas menentukan. Klasifikasi, ekstraksi, dan ringkasan pendek berada di sisi pertama. Analisis dokumen panjang dan penulisan kreatif berada di sisi kedua.

Yang benar-benar berubah beberapa tahun terakhir bukan modelnya, tapi titik temu. Karena model lokal jadi murah, pola retrieve-lokal-lalu-generate-di-server menjadi masuk akal: pencarian dan penyaringan berjalan lokal, dan hanya langkah terakhir yang memanggil model besar.

Yang perlu dipantau

Tiga hal. Pertama, apakah WebGPU merambah ke browser yang belum mendukungnya. Selama Firefox masih di balik flag, banyak pembaca Indonesia yang memakai Firefox akan tertinggal.

Kedua, apakah kuantisasi 4 bit bertahan atau tergantikan 3 bit dan 2 bit. Setiap pengurangan presisi berikutnya memberi penghematan memori yang lebih kecil dan penurunan kualitas yang lebih besar, dan akan ada titik di mana hubungannya berbalik.

Ketiga, apakah memori browser cukup. Batas saat ini bukan compute, tapi ketersediaan RAM. Model 3 miliar parameter butuh unduhan sekitar 2 GB, dan itu sudah melewati yang bisa diterima sebagian besar perangkat tanpa membuat halaman terasa lambat.

Apa artinya buat pembaca di Indonesia

.Combine Ini bukan berita kecil untuk sitenya, karena cara kerja Loonix sudah sama persis dengan yang dilakukan runtime in-browser ini: tool diproses di perangkat, tidak ada file yang dikirim ke server.

Tiga implikasi nyata. Pertama, privat data bisa dipakai tanpa bersih-bersih policies karena tidak pernah meninggalkan perangkat. Kedua, biaya tambahan nol — tidak ada tagihan per token, karena tidak ada token yang dikirim ke mana pun. Ketiga, batasan perangkat keras nyata: sebagian besar ponsel punya memori 4 GB, dan model 360 juta parameter sudah memakai sebagian davon.

Kalau kamu sedang membangun tool yang selama ini memanggil API berbayar, ada langkah antara yang jarang dicoba: pindahkan bagian yang paling sering jalan — penggolongan, ekstraksi, ringkasan pendek — ke model kecil lokal, dan sisakan panggilan API untuk kasus yang benar-benar butuh pengetahuan luas.

Yang perlu dicek sebelum berharap banyak:

• Dukungan WebGPU. Chrome dan Edge 113 ke atas, Safari 18 ke atas, dan Firefox masih di balik flag. Tanpa itu, fallback ke WebAssembly jauh lebih lambat.
• Memori, bukan hanya GPU. Mesin dengan GPU terintegrasi sering kehabisan memori sebelum kehabisan daya komputasi.
• Kualitas keluaran di bahasa sendiri. Semua pengukuran di atas berasal dari pengujian berbahasa Inggris.