Mengoptimalkan Inferensi pada Perangkat untuk Apple Silicon

Komputasi Hibrida pada Apple silicon mengoordinasikan tugas antara kecerdasan terdepan di cloud dan model lokal di Mac. Model cloud menangani penelitian dan penalaran, sementara model lokal bekerja dengan file dan aplikasi pribadi di Mac.

Agar pembagian kerja ini terasa mulus, inferensi lokal harus mengimbangi sisa tugas lainnya. Hal itu memerlukan mesin yang dapat memproses prompt dengan cepat dan mempertahankan tingkat pembuatan token yang tinggi.

Lily, mesin inferensi lokal kami yang ringan, dibuat khusus untuk Apple silicon dan Qwen3.6-35B-A3B, dengan optimasi terpisah untuk prefill dan decode. Demo mandiri tersedia untuk umum di GitHub.

Pendahuluan

Cara umum untuk menjalankan LLM di Mac adalah dengan MLX, kerangka kerja pembelajaran mesin sumber terbuka Apple untuk Apple silicon. Pustaka pendampingnya, MLX-LM, menambahkan komponen yang diperlukan untuk memuat dan menghasilkan teks dengan berbagai macam model bahasa. Secara bersama-sama, MLX dan MLX-LM menyediakan tumpukan siap pakai tujuan umum untuk inferensi LLM lokal.

Qwen3.6-35B-A3B adalah model hibrida yang jarang (sparse): model ini menggunakan perutean mixture-of-experts (MoE) dan menggabungkan status rekuren berukuran tetap dengan atensi penuh. Pilihan arsitektur ini mengurangi jumlah komputasi yang diperlukan, tetapi juga menciptakan beban kerja yang tidak teratur. Token dialihkan ke bobot pakar yang berbeda, dan status rekuren bersifat sekuensial.

MLX-LM sudah memilih kernel yang dioptimalkan untuk fase inferensi dan bentuk beban kerja umum, tetapi operasi yang dapat digunakan kembali harus mendukung banyak arsitektur model. Mesin yang didedikasikan untuk Qwen dapat mengkhususkan diri pada tingkat model dan runtime, mengoordinasikan kernel, pergerakan data, dan penjadwalan di sekitar struktur tetap model.

Lily mengimplementasikan spesialisasi ini secara menyeluruh dalam satu proses. Runtime Rust memuat pos pemeriksaan model dan mengelola status sesi dan perulangan pembuatan, API penyelesaian obrolan yang kompatibel dengan OpenAI menerima permintaan dan mengalirkan token, dan kernel Metal kustom mengeksekusi operasi khusus Qwen. Baik PyTorch maupun MLX tidak berada di jalur eksekusi.

Perbesar

Kami mengukur performa prefill dan decode secara terpisah. Throughput prefill menangkap seberapa cepat mesin memproses prompt; throughput decode menangkap seberapa cepat mesin menghasilkan token keluaran.

Kami membandingkan Qwen3.6-35B-A3B pada satu MacBook Pro yang ditenagai M5 Max dengan GPU 40-core dan memori terpadu 128 GB. Pada sepuluh panjang prompt untuk prefill dan sepuluh panjang konteks untuk decode, dari 256 hingga 128K token (K = 1.024), engine ini rata-rata mencapai throughput prefill 1,22× milik MLX-LM dan throughput decode 1,32× milik MLX-LM. Pada prompt 4K token dan konteks decode 4K token, engine kustom ini mencapai 5.749,9 token prefill per detik dan 186,6 token decode per detik, dibandingkan dengan 4.737,5 dan 140,9 untuk MLX-LM. Di sepanjang sesi multi-turn, penghematan waktu ini terakumulasi pada setiap panggilan model tambahan.

Perbesar

Selanjutnya, kami menjelaskan bagaimana arsitektur Qwen menciptakan peluang optimisasi khusus model pada Apple silicon. Kami kemudian membahas perubahan prefill dan decode yang dihasilkan. Kami juga mencakup bagian di mana optimisasi tambahan berhenti memberikan manfaat sebelum ditutup dengan perbandingan menyeluruh terhadap MLX-LM.

Peluang optimisasi khusus Qwen pada Apple silicon

Qwen menciptakan tiga bentuk beban kerja yang berbeda

Qwen3.6-35B-A3B berisi 35 miliar parameter tetapi hanya mengaktifkan sekitar 3 miliar untuk setiap token. Peruter menilai 256 subjaringan pakar dan memilih delapan, di samping satu pakar bersama yang memproses setiap token. Desain MoE sparse ini mengurangi komputasi tetapi menghasilkan pekerjaan yang tidak merata: pakar menerima jumlah token yang berbeda, dan setiap token memerlukan bobot dari kombinasi pakar yang berbeda.

Qwen juga menggabungkan 10 lapisan atensi penuh dengan 30 lapisan Gated DeltaNet. Kedua jenis lapisan ini mempertahankan informasi sebelumnya dengan cara yang berbeda.

Lapisan atensi menggunakan grouped-query attention (GQA). Qwen memiliki 16 kepala kueri dan dua kepala kunci–nilai (KV), dengan delapan kepala kueri berbagi setiap kepala KV. Berbagi membuat tembolok KV lebih kecil dan memungkinkan data yang dicache digunakan kembali di seluruh kepala kueri. Tembolok tersebut masih menyimpan kunci dan nilai baru untuk setiap token, sehingga setiap langkah decode membaca lebih banyak data seiring bertambahnya konteks.

Gated DeltaNet malah mengompresi informasi sebelumnya menjadi status rekuren berukuran tetap. Gate yang dipelajari mengontrol berapa banyak status yang ada untuk dipertahankan, sementara pembaruan delta memasukkan informasi dari token saat ini. Model mendefinisikan pembaruan ini secara rekuren, sehingga setiap token bergantung pada status yang dihasilkan oleh token sebelumnya. Namun, selama prefill, mesin dapat mengevaluasi komputasi yang sama dengan dua cara. Mesin dapat memindai token secara langsung sambil membawa status ke depan, atau mengatur ulang pembaruan ke dalam blok yang mengekspos lebih banyak operasi matriks dan paralelisme tingkat token. Pendekatan mana yang lebih cepat bergantung pada dimensi model, beban kerja, dan perangkat keras.

Secara bersama-sama, struktur ini menciptakan tiga pola komputasi: kelompok pakar yang tidak merata, perhatian (attention) atas tembolok yang terus bertambah, dan rekurensi berukuran tetap yang dapat dievaluasi secara langsung atau dalam blok.

Apple silicon menyediakan jalur yang berbeda untuk beban kerja yang berbeda

Prefill memproses banyak baris aktivasi token prompt sekaligus. Beban kerja lokal yang dipertimbangkan di sini biasanya mendekode satu permintaan dalam satu waktu (batch 1) dan memproses satu baris baru per langkah. Perbedaan ini mengubah cara bobot model yang sama digunakan. Prefill dapat menggunakan kembali setiap blok bobot di ratusan atau ribuan baris. Sebagian besar decode tidak bisa, karena setiap token baru membutuhkan lintasan lain melalui bobot.

Apple silicon menempatkan CPU dan GPU di belakang memori terpadu, kumpulan memori fisik tunggal yang dapat diakses oleh keduanya. Ini memungkinkan model tetap residen tanpa mempertahankan salinan GPU terpisah, tetapi tidak membuat pergerakan data menjadi gratis. Membaca bobot dan nilai menengah tetap mengonsumsi bandwidth memori, sementara register dan penyimpanan on-chip lainnya lebih cepat tetapi jauh lebih kecil.

GPU M5 juga menyediakan jalur komputasi yang berbeda. Lapisan linier prefill menggunakan perkalian matriks–matriks umum (GEMM), menerapkan matriks bobot ke banyak baris sekaligus. GEMM yang kompatibel dapat menggunakan Akselerator Neural di setiap inti GPU melalui operasi tensor Metal 4. Sebagai gantinya, decode batch-1 menggunakan perkalian matriks–vektor umum (GEMV), menerapkan bobot yang sama ke satu baris. Dengan sedikit penggunaan ulang bobot, GEMV dibatasi terutama oleh bandwidth memori dan lebih cocok untuk unit logika aritmatika (ALU) vektor GPU daripada Akselerator Neural yang dirancang untuk operasi matriks dengan penggunaan ulang data yang lebih besar.

Jalur eksekusi ini tidak hanya unik untuk Lily. MLX beroperasi di atas memori terpadu yang sama dan memilih kernel matriks dan vektor yang dioptimalkan sesuai dengan bentuk beban kerja. Implementasi Qwen MLX-LM sudah mengelompokkan pekerjaan pakar, mengevaluasi Gated DeltaNet dengan kernel Metal rekuren terfusi, dan menggunakan atensi yang sadar GQA. Kemampuan ini adalah titik awal bersama untuk inferensi Qwen yang efisien pada Apple silicon.

Strategi optimisasi

Cakupan Lily yang lebih sempit memungkinkannya mengoordinasikan jalur eksekusi bersama ini di sekitar arsitektur dan dimensi persis Qwen. Lily menggunakan jalur GPU khusus fase, memetakan beban kerja pakar, rekuren, dan atensi Qwen untuk meminimalkan pergerakan data, serta memilih kernel dan tata letak dari bentuk beban kerja yang diukur. Strategi ini memiliki tiga bagian:

1. Sesuaikan jalur GPU dengan fase inferensi. Gunakan eksekusi yang berorientasi matriks ketika prefill dapat menggunakan kembali bobot di banyak baris, dan eksekusi yang berorientasi vektor ketika decode batch-1 memproses satu baris dalam satu waktu.
2. Petakan struktur Qwen ke GPU sambil meminimalkan pergerakan data. Jaga agar bobot tetap dikompresi hingga digunakan, atur pekerjaan pakar yang diruterkan tanpa kembali ke CPU, pertahankan status Gated DeltaNet di chip melalui pemindaian rekurennya, dan gunakan kembali data KV yang dibagikan oleh atensi kueri terkelompok.
3. Sesuaikan kernel dengan bentuk beban kerja. Di setiap fase, pilih ukuran ubin, tata letak eksekusi, dan jalur atensi dari jumlah baris yang tersedia, distribusi baris di antara para pakar, dimensi operasi, dan panjang konteks saat ini.

Bagian berikut menjelaskan pilihan-pilihan ini. Untuk optimisasi yang dievaluasi dalam ablasi yang cocok pada M5 Max, kami memperkirakan efeknya dengan membandingkan konfigurasi mesin yang jika tidak identik hanya berbeda pada optimisasi yang sedang dipelajari. Karena eksperimen ini membandingkan versi mesin kami terhadap dirinya sendiri, eksperimen ini menjelaskan mekanisme alih-alih menguraikan hasil akhir terhadap MLX-LM.

Prefill: gunakan kembali bobot dan jaga perutean di GPU

Prefill mengekspos banyak baris token sekaligus, tetapi Qwen meruterkan baris tersebut secara tidak merata di antara para pakar dan memperbarui status rekuren melalui urutan tersebut. Optimisasinya terbagi menjadi tiga kelompok: mengorganisasikan pekerjaan pakar sparse di sekitar baris yang diruterkan, menjaga pemindaian Gated DeltaNet tetap di chip, dan membagi prompt panjang menjadi potongan-potongan yang dibatasi.

Perbesar

Optimalkan komputasi pakar sparse

Dikuantisasi ulang bobot selama perkalian matriks

Pos pemeriksaan Qwen3.6-35B-A3B menggunakan kuantisasi afinitas berbasis kelompok 4-bit. Setiap bobot disimpan sebagai kode bilangan bulat 4-bit, sementara setiap kelompok yang terdiri dari 64 bobot berbagi skala dan bias bfloat16 yang digunakan untuk merekonstruksi nilainya. Ini mengurangi model dengan 35 miliar parameter dari sekitar 70 GB bobot bfloat16 menjadi pos pemeriksaan 19.4 GB, menjadikannya praktis untuk menjaga model tetap residen di Mac.

Operasi tensor Metal 4 yang digunakan untuk perkalian matriks menggunakan operan bfloat16 alih-alih representasi 4-bit yang dipadatkan. Sebelum perkalian, GPU harus merekonstruksi bobot dalam bfloat16. GEMM terkelompok yang dioptimalkan di Lily melakukan konversi ini satu ubin bobot kecil dalam satu waktu dan menyimpan hasilnya di memori threadgroup on-chip hanya cukup lama untuk mengalikannya dengan baris aktivasi yang diruterkan. Akumulasi menggunakan titik mengambang 32-bit, dan keluarannya ditulis dalam bfloat16. Susunan bobot yang diperluas sepenuhnya tidak pernah dibuat di memori terpadu.

Dalam ablasi, dekuantisasi berjalan sebagai operasi terpisah: dekuantisasi memperluas bobot 4-bit menjadi susunan bfloat16 di memori terpadu, setelah itu kernel matriks membaca kembali susunan tersebut. Pada prompt 512-token, memindahkan dekuantisasi ke dalam GEMM terkelompok meningkatkan throughput prefill menyeluruh sebesar 77,4% dengan menghilangkan penulisan dan pembacaan menengah ini.

Tetap jalankan perutean pakar di GPU

GEMM terkelompok membutuhkan baris aktivasi yang ditetapkan ke setiap pakar untuk disimpan bersama. Setelah memilih delapan pakar per token, histogram menghitung berapa banyak penugasan yang masuk ke setiap pakar. Pemindaian prefiks mengubah hitungan tersebut menjadi offset awal, langkah sebar menempatkan baris ke dalam kelompok pakar mereka, dan peta blok mencantumkan blok matriks berukuran tetap yang harus diproses oleh GEMM terkelompok.

Jalur yang dioptimalkan menjaga seluruh urutan ini dalam satu penyangga perintah (command buffer), kumpulan operasi GPU yang diurutkan, untuk setiap bagian prompt. Sebagai gantinya, ablasi berhenti sejenak sehingga CPU dapat memeriksa zat antara perutean dan mengirimkan operasi berikutnya. Menjaga histogram dan pemindaian prefiks pada GPU menambahkan dua kernel tetapi menghilangkan sinkronisasi CPU–GPU di dalam setiap lapisan MoE.

Pada prompt 512-token, mengaktifkan perutean residen-GPU meningkatkan prefill menyeluruh sebesar 89%. Ini juga menunjukkan mengapa jumlah kernel saja bisa menyesatkan: rute yang lebih cepat meluncurkan lebih banyak kernel tetapi tidak pernah menunggu CPU di dalam lapisan.

Sesuaikan ukuran ubin dengan beban pakar

Pada prompt 2K-token, meruterkan setiap token ke delapan dari 256 pakar menghasilkan 16.384 penugasan token–pakar, atau rata-rata 64 baris aktivasi per pakar. Distribusi aktualnya tidak merata: beberapa pakar menerima banyak baris, sementara yang lain menerima sedikit.

GEMM terkelompok membagi keluaran setiap pakar menjadi ubin, yang merupakan blok persegi panjang kecil dari keluaran perkalian matriks. Setiap ubin ditetapkan ke satu threadgroup GPU. Pada GPU Apple silicon, threadgroup berisi satu atau lebih simdgroup, masing-masing terdiri dari 32 utas yang mengeksekusi instruksi secara bersamaan (lockstep).

Ubin yang lebih besar menyebarkan biaya penyiapan ke lebih banyak baris dan mengekspos lebih banyak pekerjaan paralel, tetapi sebagian dari ubin besar tetap menganggur ketika seorang pakar hanya menerima beberapa baris. Oleh karena itu, ukuran ubin dan jumlah simdgroup digabungkan.

Sebuah ablasi menetapkan ubin pada 16 baris. Terhadap kontrol tersebut, mengaktifkan ubin 32-baris dengan empat simdgroup meningkatkan prefill menyeluruh sebesar 13,2% pada 2K token.

Tetap jaga status rekuren di chip

Selama prefill, setiap lapisan Gated DeltaNet memindai prompt secara berurutan sambil membawa status rekurennya ke depan. Dengan residensi register dinonaktifkan, ablasi menggunakan pemindaian berbasis blok. Pada prompt 2K-token, jalur tersebut memindahkan 256 MiB (mebibit) status per lapisan dan secara berulang menghentikan utas yang bekerja sama di pembatas (barriers), titik sinkronisasi di mana semua utas yang berpartisipasi harus menunggu satu sama lain.

Status rekuren adalah sebuah matriks. Kernel yang dioptimalkan menetapkan setiap kolom ke satu simdgroup. Simdgroup membagi kolom di antara utas-utasnya, memuat kolom ke dalam register mereka sekali, dan membawa status melalui seluruh pemindaian. Utas-utas tersebut bertukar hasil menengah melalui operasi simdgroup alih-alih memori threadgroup, penyimpanan on-chip yang dibagikan di seluruh threadgroup. Status yang telah selesai ditulis kembali hanya setelah pemindaian.

Status dan gatenya menggunakan format titik mengambang (floating-point) 32-bit karena kesalahan pembulatan kecil terakumulasi di seluruh pembaruan sekuensial. Aktivasi kueri dan kunci tetap dalam bfloat16.

Pada prompt 2K-token, mengaktifkan pemindaian residen-register meningkatkan prefill menyeluruh sebesar 5,6%. GEMM pakar menyumbang sekitar 90% dari waktu prefill. Pemindaian sekuensial tidak mengekspos cukup banyak pekerjaan matriks yang dapat digunakan kembali untuk mendapatkan keuntungan dari Akselerator Neural.

Batasi memori sementara dengan pemotongan prompt

Runtime memproses prompt panjang sebagai urutan potongan yang dibatasi alih-alih menyimpan data sementara untuk setiap token prompt di memori sekaligus. Bobot model tetap residen di memori terpadu, sementara status rekuren dan tembolok KV membawa konteks dari satu potongan ke potongan berikutnya. Tidak ada konteks sebelumnya yang dibuang.

Tanpa pemotongan, susunan aktivasi sementara tumbuh bersama prompt penuh dan bersaing dengan bobot model, status rekuren, dan tembolok KV untuk memori terpadu. Pemotongan hanya menjaga nilai sementara satu segmen tetap aktif dalam satu waktu, lalu merilis atau menggunakan kembali penyimpanan tersebut sebelum memproses segmen berikutnya. Ini membatasi memori kerja puncak dan memungkinkan mesin memproses prompt yang lebih panjang tanpa mengubah keluaran model.

Prefill terpangkas (chunked prefill) populer di banyak mesin and sangat penting untuk menyajikan lintasan multi-putaran yang panjang di lingkungan yang terbatas memori ini. Total waktu prefill untuk lapisan atensi tetap kuadratik pada panjang prompt, dengan beberapa tambahan overhead dari pemuatan KV yang berulang dari potongan sebelumnya.

Decode: minimalkan bita yang dipindahkan per token

Decode Batch-1 memproses satu baris baru dalam satu waktu. Dengan sedikit penggunaan ulang bobot, throughput-nya terutama bergantung pada berapa banyak bita yang dipindahkan mesin untuk setiap token. Perubahan decode terbagi menjadi empat kelompok: mengoptimalkan jalur bobot satu baris, menjaga setiap langkah di GPU, mengurangi lalu lintas menengah dan status, serta membaca tembolok atensi secara efisien.

Perbesar

Optimalkan jalur bobot satu baris

MLX sudah mendistribusikan pekerjaan satu baris ke kernel matriks–vektor khusus. Karena Lily tidak menggunakan MLX, runtime kustom harus menyediakan strategi dasar yang sama. GEMV paralel-baris kami dirancang untuk satu baris aktivasi. Simdgroup bekerja sama pada keluaran sambil membaca berbagai bagian matriks bobot secara paralel.

Tetap jalankan setiap langkah decode di GPU

Jaga penyerahan token tetap di GPU

Setiap langkah decode diakhiri dengan memilih token berikutnya; langkah berikutnya dimulai dengan token tersebut sebagai input. Mengirimkan pilihan ke CPU lalu kembali ke GPU menambahkan titik sinkronisasi ke setiap token. Sebagai gantinya, runtime kami bergantian antara dua penyangga perintah dan dua slot token residen-GPU. GPU memilih token dengan skor tertinggi dan menulis ID token-nya langsung ke slot input untuk langkah decode berikutnya, sementara CPU menyiapkan pekerjaan berikutnya.

Tumpang tindihkan pekerjaan GPU independen

Dalam satu langkah decode batch-1 yang tercatat, menghasilkan token meluncurkan 795 kernel GPU. Dependensi mereka membentuk 555 tahap sekuensial, membuat beberapa kernel bebas berjalan secara bersamaan. Meskipun demikian, mode eksekusi serial Metal menjalankan setiap kernel secara berurutan.

Jalur decode yang dioptimalkan mencatat dependensi data aktual dalam pass Metal konkuren. Peluncuran kernel independen dapat berjalan secara bersamaan ketika sumber daya GPU mengizinkan. Penghalang dimasukkan hanya ketika pekerjaan selanjutnya memerlukan hasil sebelumnya.

Kurangi lalu lintas menengah dan status

Kernel terpisah sering kali mewujudkan zat antara: satu kernel menulis hasil sementara ke memori, dan kernel berikutnya membaca kembali hasilnya. Jalur decode yang dioptimalkan memadukan empat rantai: dua proyeksi input pakar dengan aktivasi ber-gate mereka; proyeksi keluaran pakar dengan skor peruteannya dan hasil pakar bersama; persiapan kueri dan kunci sebelum atensi; serta pembaruan rekuren dengan normalisasinya. Setiap kernel terfusi menjaga nilai sementara tetap di register alih-alih mengirimkannya melalui memori.

Fusi juga memperpendek grafik dependensi: ketika penulisan menengah hilang, penghalang yang melindungi konsumennya juga hilang.

Baca tembolok atensi secara efisien

Gabungkan pembacaan tembolok atensi

Atensi membaca kunci dan nilai dari tembolok KV selama setiap langkah decode. Dalam ablasi, utas GPU yang bertetangga tidak selalu meminta bita yang bertetangga, memaksa sistem memori untuk melayani lebih banyak transaksi terpisah. Mengaktifkan muatan tergabung membuat utas yang berdekatan meminta bita yang berdekatan sehingga perangkat keras dapat menggabungkan pembacaan mereka.

Pada konfigurasi bfloat16, penggabungan (coalescing) meningkatkan bandwidth kunci dari 33,8 menjadi 47,9 GB/s, meningkatkan bandwidth nilai dari 42,0 menjadi 61,8 GB/s, dan meningkatkan decode menyeluruh sebesar 2,1% pada konteks 3.840-token.

Padatkan kepala kueri untuk menggunakan kembali baris KV

Atensi kueri terkelompok (grouped-query attention) memungkinkan delapan kepala kueri berbagi satu kepala KV. Dalam ablasi, setiap kepala kueri berjalan di simdgroup terpisah, sehingga kedelapannya secara independen meminta baris KV tersendek yang sama. Kernel yang dioptimalkan memadatkan empat kepala kueri ke dalam satu threadgroup, yang memuat setiap baris KV satu kali dan menggunakannya kembali di empat kalkulasi atensi. Threadgroup kedua menangani empat kepala yang tersisa.

Teknik ini, yang umumnya disebut pemadatan GQA, melakukan aritmatika yang sama dan menghasilkan bita keluaran yang identik sambil mengurangi delapan permintaan KV independen menjadi dua muatan bersama. Terhadap ablasi yang tidak dipadatkan, teknik ini meningkatkan throughput decode menyeluruh sebesar 23,8% pada konteks 32K-token.

Alihkan tata letak atensi pada konteks panjang

Setiap langkah decode pada lapisan atensi penuh memindai tembolok KV yang ada. Tata letak blok-tetap membagi tembolok tersebut menjadi bagian-bagian yang sama yang dapat diproses oleh GPU secara paralel. Penjadwalan tambahannya tidak layak saat tembolok berukuran kecil, tetapi tata letak blok-tetap menyeimbangkan pekerjaan secara lebih merata seiring berkembangnya konteks.

Untuk model ini, runtime menjaga jalur atensi umum di bawah 32K token dan menggunakan jalur blok-tetap pada 32K atau lebih lama. Peralihan berlaku ketika setiap kepala memiliki 256 nilai dan delapan kepala kueri berbagi kepala KV; bentuk lain tetap pada jalur umum. Ablasi menonaktifkan peralihan ini dan selalu menggunakan jalur umum. Mengaktifkan rute blok-tetap meningkatkan decode menyeluruh sebesar 7,7% pada 32K, 27,4% pada 64K, dan 40,2% pada 128K.

Batas optimisasi lebih lanjut

Beberapa perubahan meningkatkan operasi terisolasi tetapi tidak meningkatkan inferensi menyeluruh.

Speculative decoding, yang menggunakan model yang lebih kecil untuk mengusulkan token agar model penuh memverifikasinya, membuat decode batch-1 menjadi 18% lebih lambat. Verifikasi memproses kelompok berisi dua hingga lima baris, bentuk yang tidak efisien untuk perangkat keras ini, dan baris-baris tersebut sering memilih pakar yang berbeda, sehingga meningkatkan jumlah data bobot pakar yang dibaca. Mengurangi kosakata keluaran drafter meningkatkan throughput drafter sebesar 4,7–5,1%, tetapi tidak membuat loop speculative yang lengkap menjadi lebih cepat. Hasil ini bergantung pada beban kerja: deployment Qwen kami di Blackwell yang dibatch menggunakan speculative decoding dalam kondisi yang berbeda.

Eksperimen lain termasuk mengurangi peluncuran GPU, menumpangtindihkan seluruh fase, menggunakan ubin prefill yang lebih besar, menerapkan fusi yang lebih luas, mempercepat peruter, dan menggabungkan proyeksi keluaran dengan pemilihan token. Tidak ada yang meningkatkan perulangan inferensi yang lengkap.

Pengukuran batas perangkat keras juga menunjukkan sedikit sisa headroom dalam operasi prefill dan decode utama. GEMM dan GEMV MoE mencapai 97,9% dan 90,3% dari tingkat baca-bobot berkelanjutan tercepat untuk pola aksesnya. Menghilangkan aritmatika dari GEMV yang jarang hanya mengubah throughput sebesar 0,2%, yang mengonfirmasi bahwa pembacaan bobot alih-alih komputasi adalah sumber yang membatasi. Perkalian matriks prefill secara serupa mencapai 93% dari batas matriks teoretis secara terisolasi dan 80–86% di dalam model yang diuji.

Performa menyeluruh

Perbandingan menyeluruh memuat bita pos pemeriksaan 4-bit yang identik di kedua mesin dan menjalankan satu permintaan dalam satu waktu pada satu M5 Max 40-inti, 128 GB. Dalam setiap putaran, kedua mesin berjalan dalam urutan bergantian untuk mengurangi bias dari beban latar belakang dan perubahan suhu cip. Kami membandingkan terhadap jalur pembuatan langsung tercepat MLX-LM, bukan servernya, sehingga pengukuran berfokus pada eksekusi model alih-alih overhead penyajian.

Penyapuan (sweep) mencakup sepuluh panjang prompt untuk prefill dan sepuluh panjang konteks untuk decode, dari 256 hingga 128K token. Throughput prefill pertama-tama meningkat seiring mesin menyebarkan biaya penyiapan tetap ke lebih banyak token. Prefill memuncak sekitar prompt 4K-token, kemudian turun karena sepuluh lapisan atensi penuh melakukan lebih banyak pekerjaan seiring bertambahnya prompt. Decode tetap hampir datar pada konteks pendek dan menurun begitu membaca tembolok KV yang bertumbuh menjadi signifikan. Mesin kustom lebih cepat pada setiap panjang yang tercatat.

Karena eksekusi khusus dapat mengubah urutan operasi titik mengambang, kami juga memeriksa konsistensi numerik terhadap MLX-LM. Dalam perbandingan teacher-forced, kedua mesin memprediksi token berikutnya dari prefiks referensi yang sama di masing-masing dari 192 posisi, mencegah perbedaan sebelumnya memengaruhi masukan selanjutnya. Perplexity Lily hanya 0,04% lebih tinggi, dan Lily memilih token dengan peringkat teratas yang sama di 96,35% posisi yang diuji.

Perbesar

Dibangun untuk platform lokal

Apple silicon bukanlah GPU pusat data yang lebih kecil. Ini adalah platform inferensi lokal yang lengkap dengan karakteristik perangkat keras dan perangkat lunaknya sendiri. Memori terpadu memberi satu node batas atas yang sangat tinggi mengenai berapa banyak model dan status yang dapat ditampungnya. Akselerator Neural M5 menyerap pekerjaan matriks padat dalam prefill. ALU vektor menangani sisa yang terikat bandwidth dan minim penggunaan kembali dalam decode.

Qwen menambahkan peluang lebih lanjut untuk spesialisasi: menjaga perutean pakar dan status rekuren di GPU, menghilangkan zat antara yang tidak perlu, menumpangtindihkan pekerjaan independen, menggunakan kembali data KV bersama, dan menyesuaikan kernel dengan bentuk beban kerja.

Dengan optimisasi khusus model dan platform, satu Mac dapat menjalankan model sparse besar secara efisien. Pekerjaan di masa mendatang akan memperluas cakupan di seluruh model, cip, dan beban kerja penyajian, dan mengubah mekanisme yang divalidasi di sini pada satu konfigurasi menjadi kebijakan runtime yang lebih umum.

Prinsip yang lebih luas adalah mencocokkan mesin dengan arsitektur model dan jalur komputasi serta memori khusus dari perangkat keras. Seiring berkembangnya model bobot-terbuka terdepan dan perangkat keras, inferensi lokal berkinerja tinggi akan semakin bergantung pada mesin yang disesuaikan untuk keduanya daripada mesin yang mengabstraksi perbedaan mereka.

Sitasi

@online{perplexity2026OptimizingOnDeviceInferenceForAppleSilicon,
  author = {{Perplexity} and Yibo Wu and Lequn Chen and Kevin Hu and Phi Hoang and Claire Beamer and Jeremy Yang and Denis Yarats},
  title = {{Optimizing on-device inference for Apple Silicon}},
  date = {2026-09-01},
  url = {https://www.perplexity.ai/hub/blog/optimizing-on-device-inference-for-apple-silicon}
}