Mempercepat Gemma 4: inferensi lebih cepat dengan drafter prediksi multi-token

 (blog.google)
3 poin oleh GN⁺ 1 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Google mengumumkan bahwa hanya beberapa minggu setelah peluncuran Gemma 4, jumlah unduhannya telah melampaui 60 juta, dan juga merilis drafter prediksi multi-token (MTP) untuk keluarga produk Gemma 4
  • Drafter MTP adalah arsitektur speculative decoding khusus yang meningkatkan kecepatan inferensi hingga 3x tanpa menurunkan kualitas output atau logika inferensi, dan telah diuji pada perangkat keras yang menggunakan LiteRT-LM, MLX, Hugging Face Transformers, dan vLLM
  • Inferensi LLM standar menghadapi bottleneck bandwidth memori karena miliaran parameter harus dipindahkan dari VRAM ke unit komputasi untuk menghasilkan satu token, sedangkan MTP membuat drafter ringan mengusulkan beberapa token masa depan lalu model target memverifikasinya secara paralel
  • Jika model target menyetujui token draf, seluruh sekuens diterima dalam satu forward pass dan satu token tambahan juga dihasilkan, sehingga aplikasi biasanya dapat mengeluarkan sekuens draf dan token tambahan dalam waktu yang biasanya dibutuhkan untuk satu token
  • Drafter MTP berbagi aktivasi model target dan KV cache, menerapkan clustering embedder yang efisien untuk model edge E2B dan E4B, dan bobotnya tersedia di Hugging Face serta Kaggle dengan lisensi Apache 2.0

Mengapa speculative decoding diperlukan

  • Inferensi LLM standar terikat pada bandwidth memori sehingga bottleneck latensi menjadi besar
  • Prosesor menghabiskan sebagian besar waktunya memindahkan miliaran parameter dari VRAM ke unit komputasi untuk menghasilkan satu token
  • Struktur ini, terutama pada perangkat keras konsumen, membuat sumber daya komputasi tidak termanfaatkan sepenuhnya dan meningkatkan latensi
  • Speculative decoding memisahkan pembuatan token dan verifikasi
  • Model target yang berat, misalnya Gemma 4 31B, dipasangkan dengan drafter ringan yaitu model MTP untuk memprediksi beberapa token masa depan sekaligus menggunakan sumber daya komputasi yang menganggur
  • Drafter mengusulkan beberapa token dalam waktu yang lebih singkat daripada waktu yang dibutuhkan model target untuk memproses satu token, lalu model target memverifikasi token yang diusulkan secara paralel

Cara kerja MTP

  • Model bahasa besar standar menghasilkan teks secara autoregresif, tepat satu token setiap kali
  • Pendekatan ini mengalokasikan jumlah komputasi yang sama baik untuk kelanjutan mudah seperti memprediksi “words” setelah “Actions speak louder than…” maupun untuk menyelesaikan teka-teki logika yang kompleks
  • MTP mengurangi inefisiensi ini melalui speculative decoding yang diperkenalkan peneliti Google dalam Fast Inference from Transformers via Speculative Decoding
  • Jika model target menyetujui token draf, seluruh sekuens diterima dalam satu forward pass, dan model target sendiri juga menghasilkan satu token tambahan secara bersamaan
  • Aplikasi biasanya dapat mengeluarkan seluruh sekuens draf beserta satu token tambahan dalam waktu yang dibutuhkan untuk menghasilkan satu token saja

Dampak performa bagi developer

  • Bagi developer, kecepatan inferensi sering menjadi bottleneck utama dalam deployment produksi
  • Pada agen otonom yang membutuhkan perencanaan multi-langkah cepat, coding assistant, dan aplikasi mobile responsif yang berjalan sepenuhnya on-device, latensi hingga tingkat milidetik pun penting
  • Dengan menggunakan model Gemma 4 bersama drafter ini, efek berikut dapat diperoleh

  • Responsivitas meningkat

    • Latensi untuk chat nyaris real-time, aplikasi suara imersif, dan workflow agentic dapat berkurang secara signifikan

  • Pengembangan lokal dipercepat

    • Menjalankan model 26B MoE dan 31B Dense lebih cepat di komputer pribadi dan GPU konsumen untuk mendukung coding offline yang kompleks dan workflow agentic

  • Performa on-device meningkat

    • Membantu model E2B dan E4B menghasilkan output lebih cepat di perangkat edge, sehingga dapat mengurangi penggunaan baterai perangkat

  • Tanpa penurunan kualitas

    • Karena model dasar Gemma 4 tetap melakukan verifikasi akhir, tingkat penalaran dan akurasi yang sama dapat diberikan jauh lebih cepat
    • Contoh Gemma 4 26B yang dijalankan di NVIDIA RTX PRO 6000 membandingkan perbedaan token per detik antara inferensi standar dan drafter MTP, serta menunjukkan bahwa latensinya sekitar setengahnya pada kualitas output yang sama
    • Video perbandingan dapat diunduh

Optimasi internal drafter MTP

  • Berbagai peningkatan arsitektur diterapkan agar drafter MTP cepat dan akurat
  • Model draf secara alami memanfaatkan aktivasi model target dan berbagi KV cache model target
  • Berkat berbagi KV cache, model besar tidak membuang waktu untuk menghitung ulang konteks yang sudah diproses
  • Pada model edge E2B dan E4B, perhitungan logit akhir menjadi bottleneck besar, sehingga teknik clustering yang efisien diimplementasikan pada embedder untuk mempercepat generasi
  • Optimasi per perangkat keras juga dianalisis
  • Pada Apple Silicon, model mixture-of-experts 26B memiliki tantangan routing tersendiri saat batch size 1, tetapi ketika beberapa permintaan diproses bersamaan, peningkatan kecepatan lokal hingga sekitar 2,2x dapat diperoleh
  • Contoh batch size adalah 4~8, dan peningkatan serupa juga terlihat pada NVIDIA A100 ketika batch size ditingkatkan
  • Arsitektur visual, berbagi KV cache, dan cara kerja embedder efisien dapat dilihat pada penjelasan teknis mendalam

Cara penggunaan dan lokasi ketersediaan

  • Drafter MTP untuk keluarga produk Gemma 4 disediakan dengan lisensi open source Apache 2.0 yang sama seperti Gemma 4
  • Cara menggunakan MTP bersama Gemma 4 dapat dilihat di dokumentasi
  • Bobot model dapat diunduh dari Hugging Face dan Kaggle
  • Inferensi yang lebih cepat dapat diuji melalui transformers, MLX, vLLM, SGLang, Ollama
  • Bisa langsung dicoba di Google AI Edge Gallery pada Android atau iOS
  • Google berharap peningkatan kecepatan ini dapat mempercepat pengembangan di ekosistem Gemma, Gemmaverse

Bacaan terkait

1 komentar

 
GN⁺ 1 jam lalu
Komentar Hacker News

  • Gemma dan Gemini menggunakan jauh lebih sedikit token output dibanding model lain, tetapi performanya tetap cukup mendekati benchmark papan atas
    Jika membandingkan Gemma dan Qwen, Qwen memang sedikit lebih baik, tetapi sering kali menghabiskan 22 menit untuk sebuah tugas, sementara Gemma menyelesaikan prompt yang sama hanya dalam 4 menit meski kadang salah merapikan tombol
    Secara tampak, performa Gemma mungkin 5~10% di bawah model open terdepan, tetapi waktu yang dipakai hanya 1/10

    • Secara pengalaman, dengan paket dasar Gemini seharga $15 per bulan, saya bisa ngoding seharian tanpa menyentuh batas pemakaian
      Saya juga tidak pernah merasa perlu upgrade seperti orang-orang lain yang memakai paket $100 per bulan di Claude atau Codex
      Namun, performa Gemini sempat turun beberapa kali selama setahun terakhir, dan rate limit-nya juga makin ketat, jadi belum tentu ke depannya akan tetap sebagus ini
    • Di podcast Dwarkesh, Dylan Patel dari SemiAnalysis mengatakan bahwa Google mampu menangani model yang lebih besar daripada para pesaingnya berkat sumber daya komputasi yang jauh lebih besar dan akses ke TPU
      Karena model besar biasanya memakai lebih sedikit token untuk tingkat kecerdasan yang sama, ini tampaknya bisa menjelaskan perbedaan penggunaan token tersebut
    • Karena Gemma cepat, model ini bisa dijalankan bahkan di GPU yang awalnya terasa kekecilan
      Saya mencobanya di 4070, dan meski output-nya tidak super cepat, tetap cukup layak dipakai
      Saya belum mencobanya untuk tugas yang rumit, jadi mungkin hasilnya akan berbeda di situ
    • Saat ini Claude memang sangat populer, tetapi saya belum pernah mengalami masalah saat memakai Gemini atau merasa perlu pindah
      Setelah Google I/O, mungkin lebih banyak orang akan sadar seberapa bagusnya Gemini
    • Itu benar, tetapi agar adil kita perlu menjumlahkan total token output kumulatif
      Kalau ada masalah alignment, kita harus memakai token input dan output sekali lagi untuk memperbaikinya

  • Dukungan MTP sedang ditambahkan ke llama.cpp, dan setidaknya untuk model Qwen pengerjaannya sudah berjalan (https://github.com/ggml-org/llama.cpp/pull/20533)
    Gemma 4 tampaknya akan segera menyusul
    Peningkatan kualitas dan kecepatan model lokal/self-hosted dalam beberapa bulan terakhir benar-benar luar biasa

    • Ada PR yang lebih baru dan sepertinya akan segera di-merge: https://github.com/ggml-org/llama.cpp/pull/22673
    • Beberapa hari lalu saya kembali beralih dari Qwen3.6 ke Gemma 4 untuk penggunaan pribadi, dan versi 26B dari yang belakangan menunjukkan performa rata-rata lebih baik daripada 27B yang pertama
      Buat orang yang sudah lama menjalankan model lokal, ini benar-benar masa yang menarik
    • Minat terhadap integrasi DFlash juga makin besar: https://github.com/ggml-org/llama.cpp/issues/21978
      Saya tidak sabar melihat bagaimana perbandingannya dengan MTP
    • Saya juga ingin melihat ini di oMLX
      Itu alat yang cukup bagus
    • Saya tidak terlalu yakin MTP inference masuk di bagian mana dalam stack inference, tetapi kalau ada yang tahu apakah ini bisa diimplementasikan di ekosistem MLX, saya penasaran

  • Google nyaris sendirian menopang model open-source di dunia Barat
    Gemma 4 31B luar biasa
    Namun, agar versi terbaiknya muat di VRAM 24GB, termasuk kemampuan vision dan drafter yang akan segera hadir, rasanya cukup menyakitkan
    Build saya tidak bisa ditambah GPU lagi, dan untuk performa terbaik sepertinya saya harus beli satu 4090 lagi yang terlalu mahal, atau mengganti semuanya sekalian

    • Di llama.cpp, kalau memakai --no-mmproj-offload, Anda bisa menaruh multimodal projector, yaitu bagian pemahaman audio, gambar, dan PDF, di RAM sistem
      Tentu GPU acceleration jadi tidak aktif, tetapi VRAM bisa dihemat
    • Meski begitu, saya tetap menganggap Qwen lebih baik daripada Gemma
      Selain itu, model tersebut bisa lebih disetel per tugas, jadi kita bisa memilih mau memprioritaskan penalaran dan akurasi atau kecepatan inferensi

  • Melihat komputer menulis mengingatkan saya pada masa dulu terhubung ke BBS lewat modem
    Ini terasa seperti naik dari modem 300 baud ke 1200 baud, jadi memang peningkatan besar, tetapi tetap masih cukup lambat, dan suatu hari nanti kita mungkin akan heran bagaimana kita dulu tahan memakainya seperti ini

    • Kondisinya sekarang benar-benar terasa seperti era dial-up, dan saya terus membayangkan seperti apa “era broadband” nanti
      Melihat token mengalir keluar terasa seperti melihat JPEG dimuat beberapa baris piksel demi beberapa baris piksel, dan juga mengingatkan pada berbagai animasi loading/koneksi yang dulu dibuat masing-masing aplikasi sebelum kecepatan menjadi cukup tinggi
      Pekerjaan yang dilakukan Cerebras atau Taalas adalah petunjuk menarik tentang apa yang mungkin ke arah sana
      Menarik juga membayangkan apa yang mungkin dilakukan jika bahkan model tercanggih saat ini bisa memakai sejuta token per detik dengan biaya yang sangat rendah
    • Benar bahwa ini mengingatkan pada era dial-up, tetapi bukan 300 ke 1200, melainkan lebih dekat ke 4800 baud
      Perbandingan modem versus Claude yang dihitung Claude adalah seperti ini: untuk 2368 karakter, 300 = 1 menit 19 detik, 1200 = 19,7 detik, 2400 = 9,9 detik, 14.4K = 1,6 detik, 33.6K = 705ms, 56K = 447ms, Claude = 7,9 detik
    • Ada startup yang pernah muncul di sini yang membuat hardware khusus agar AI bisa merespons seketika
      Kecepatannya ada di kisaran ribuan token per detik

  • Strategi Google tampaknya sedikit berbeda dari penyedia frontier lainnya
    Mereka kelihatannya lebih fokus pada efisiensi performa terhadap komputasi daripada performa mentah, dan mungkin itulah sebabnya Gemini tampak tertinggal secara kasat mata
    Penyedia lain sedang menabrak batas kapasitas dan juga batas subsidi biaya inferensi
    Strategi Google tampaknya lebih ke menskalakan dan mendistribusikan model-model ini ke miliaran pengguna yang sudah ada

    • Saya tidak menganggap Gemini tertinggal
      Justru rasanya seperti jenis kecerdasan yang berbeda dari GPT-5 terbaru dan keluarga Claude
      Yang belakangan makin fokus pada produktivitas dan otomasi kerja, serta dioptimalkan untuk loop penalaran koreksi-diri yang panjang dan agentic
      Gemini terasa seperti model dasar yang jauh lebih pintar, terutama dalam mode Deep Think, di mana intuisinya terasa jauh lebih dalam, tetapi tidak sebaik itu untuk loop agen koreksi-diri jarak panjang
      Selama beberapa bulan, alur kerja saya adalah memakai Gemini untuk lompatan kreatif dan insight, lalu lebih memilih Codex, Claude, dan GPT-5.5 Pro untuk tugas yang berulang atau presisi
    • Rasanya strategi semua orang memang sedang berubah ke arah itu

  • Setelah cukup lama tidak memakai model lokal, baru-baru ini saya mengatur model 26B A4B di RTX 3090 dengan vLLM 4-bit, dan saya benar-benar terkejut oleh kecepatan dan kualitas yang bisa didapat dengan investasi di bawah $1000
    Awalnya saya mencoba Qwen, tetapi model itu tidak stabil, dan jejak penalarannya absurd panjang

    • Sebagian quantization awal qwen3.6 memang rusak
      Sampai sekarang masih agak rewel, tetapi dengan sedikit sentuhan hasilnya benar-benar luar biasa
      Model lokal adalah masa depan, dan itu keren
    • Jika memakai turboquant / Q4, model ini bahkan muat di 3060, dan menghasilkan 40T/s yang cukup layak dari kartu sekitar $200
    • Model A4B sangat cepat dan sangat bagus untuk query umum
      Untuk tugas coding memang jelas kalah dari Qwen 3.6, tetapi itu justru lebih berarti bahwa model Qwen memang luar biasa
    • 31B juga sangat cepat untuk ukuran model dense
      Di komputer saya, dibanding model 30B lain, tg setidaknya dua kali lebih cepat dari perkiraan, mungkin berkat hybrid attention
      Hanya saja, sisi pemrosesan input sedikit lebih lambat

  • Saya penasaran apakah ada yang berhasil menjalankan ini di LM Studio
    Opsi itu ada di UI, tetapi sepertinya tidak benar-benar aktif

    • Ini belum diimplementasikan di mlx[1] atau llama.cpp[2], jadi mungkin perlu waktu
      [1] https://github.com/ml-explore/mlx-lm/pull/990
      [2] https://github.com/ggml-org/llama.cpp/pull/22673
    • Bisa
      Karena tidak ada model kecil, Anda perlu memastikan bahwa Anda tidak sedang memakai model sparse Gemma
      Dan saya juga menghapus semua model image dari workspace
    • Biasanya LM Studio tidak suka kalau di dalam folder ada file mmproj
      Kadang file-file itu akan muncul kalau dihapus
      File-file ini entah bagaimana terhubung ke fitur vision dan tampaknya menghalangi speculative decoding, tapi jangan tanya alasannya
      Untuk Gemma, saya lebih berhasil memakai speculative decoding lewat jalur llama-server daripada LM Studio
    • Saya pernah membuatnya berjalan dengan model lain
      Biasanya provider, quantization, dan sebagainya harus benar-benar cocok satu sama lain
      Mencari set pasangan yang pas mungkin butuh waktu

  • Dalam pengujian saya, model Gemma 4 31B menunjukkan peningkatan kecepatan terbesar pada tugas coding saat memakai MLX runner milik Ollama, kira-kira 2x lebih cepat
    Namun, quantization sangat menurunkan acceptance rate, jadi perlu Mac yang cukup kuat
    Tiga model lain yang lebih kecil tidak sebaik itu karena waktu verifikasi draft model memakan hampir seluruh peningkatan performa
    Saya masih menyetel-nyetel apakah performanya bisa dibuat lebih baik
    Anda bisa mengujinya di Ollama 0.23.1 dengan menjalankan ollama run gemma4:31b-coding-mtp-bf16

  • Begitu ini di-merge ke llama.cpp, saya benar-benar ingin cepat mencobanya
    Di lingkungan saya, Gemma 4 26B-A4B sekitar 3x lebih cepat daripada Qwen3.6-35B-A3B, jadi membayangkan ada tambahan akselerasi 1,5x saja sudah sangat menarik
    Saya juga mencoba draft model, tetapi hasilnya terbatas, dan draft model 3B yang lebih kecil serta model dense Ministral 14B sudah menambah terlalu banyak overhead

    • Di vLLM dengan 5090, memakai quantization awq 4-bit dan MTP speculative decoding menghasilkan 120~180TPS
      Gemma4 26B menembus 200TPS dengan quantization yang sama
      Penting juga dicatat bahwa efisiensi inferensi Qwen sangat rendah
      Rata-rata rantai penalarannya sekitar 3x lebih panjang daripada Gemma

  • Saya jadi bertanya-tanya apakah ini mirip prediksi percabangan di sistem operasi
    Hanya saja, karena probabilitasnya tertanam di model itu sendiri, bentuknya jadi jauh lebih bisa diandalkan

    • Idenya mirip, tetapi cara gagalnya lebih baik
      Kegagalan prediksi percabangan membuang siklus, sedangkan di sini tebakan yang buruk biasanya hanya berarti kita tidak mendapat bonus token
      https://arxiv.org/abs/2211.17192