Laya di Apple Silicon: Apa yang Ditawarkan Port MLX kepada Anda, dan Apa yang Tidak

Laya adalah model keputusan yang tidak pernah menulis satu kalimat pun. Convai Innovations meletakkan bobotnya di Hugging Face pada 2026-09-18, dan keesokan harinya seorang pengembang bernama mizorewww merilis Laya-MLX — port independen yang menjalankan ketiga checkpoint Laya secara native di Apple Silicon melalui MLX, tanpa PyTorch, tanpa runtime Transformers, dan tanpa panggilan cloud. Port tersebut melaporkan median 13,42 ms untuk satu pertanyaan singkat berbahasa Inggris pada checkpoint 421M, 7,39 ms pada checkpoint multibahasa 322M, dan nol token keluaran, pada M3 Max. Sementara itu Kev, keluarga terbuka lain yang mengejar gagasan keputusan bertipe yang sama, dibangun di atas Qwen3.5-4B-Base dan membutuhkan backend kedua yang utuh sebelum dapat digunakan di Mac, karena PyTorch tidak memiliki kernel untuk lapisan DeltaNet-nya di GPU Apple. Dua proyek, minggu yang sama, tujuan yang sama, dan hanya satu di antaranya yang diporting dengan mulus. Perbedaan itulah ceritanya, dan ini adalah cerita runtime, bukan cerita model.

Alasan ini layak menjadi artikel hari ini bukan karena Laya baru. Alasannya adalah bahwa sampai 2026-09-19 tidak ada cara untuk menjalankan model keputusan bertipe di Mac tanpa turut membawa serta tumpukan PyTorch, dan pertanyaan yang sebenarnya dimiliki pembaca — dapatkah saya menjalankan ini di laptop saya, dan apa yang harus saya korbankan — akhirnya memiliki jawaban yang terukur. Jadi tulisan ini membahas jalur penyajian, angka-angka di baliknya, dan titik-titik ketika angka-angka itu berhenti bermakna seperti tampilannya.

Pertama, apa yang bukan Laya

Laya bukan LLM. Laya bersifat non-autoregresif: satu forward pass dua arah atas state ditambah pertanyaan Anda, dan keluarannya adalah jawaban bertipe. Tidak ada decoding token demi token, tidak ada rantai pemikiran, tidak ada JSON yang dihasilkan untuk diurai, dan tidak ada token keluaran yang ditagih. Tiga primitif jawaban adalah choice (pilih satu dari N opsi bernama), score (tingkat rubrik ordinal) dan noul (probabilitas terkalibrasi bahwa sesuatu itu benar).

Itu penting untuk cara Anda membaca setiap angka dalam artikel ini. Ketika port melaporkan 13,42 ms, yang dilaporkannya bukan 13,42 ms untuk menghasilkan beberapa ratus token seperti yang akan dilakukan tolok ukur generasi. Yang dilaporkannya adalah keseluruhan operasi. Membandingkan latensi model keputusan dengan token per detik LLM berarti membandingkan dua pekerjaan yang berbeda, dan artikel apa pun yang melakukannya — termasuk pos viral "50x lebih cepat daripada Jev" yang beredar setelah peluncuran — membuat klaim yang tidak didukung oleh pekerjaan yang mendasarinya.

Apa yang sebenarnya diukur oleh port

Angka-angka ini milik penulis port sendiri, diambil pada mesin yang dinyatakan, dan harus dibaca dengan mesin serta metode yang disertakan. Laya-MLX mengukurnya pada M3 Max dengan 40 inti GPU dan 128 GiB memori terpadu, pada FP16, dengan pemuatan model dikecualikan.

• Satu pertanyaan singkat, P50 — 13,42 ms pada checkpoint bahasa Inggris 421M, 7,39 ms pada checkpoint multibahasa 322M.

• Satu pertanyaan singkat, P95 — masing-masing 13,92 ms dan 7,79 ms.

• Throughput 50 pertanyaan — 146.8 pertanyaan per detik dan 395.0 pertanyaan per detik.

• Alokasi puncak MLX — 943,6 MiB dan 687,6 MiB.

Batas waktu adalah bagian yang perlu dibaca dua kali. Ini mencakup persiapan prompt, tokenisasi, konstruksi tensor, inferensi tersinkronisasi, kalibrasi, dan pemformatan hasil. Ini tidak mencakup pemuatan model. Uji throughput 50 pertanyaan menggunakan batch_size=64, sedangkan API secara default menggunakan 16, sehingga pasangan angka itu menggambarkan beban kerja yang sengaja dibatch, bukan biaya dari satu panggilan interaktif. Panjang input yang berbeda, jumlah pertanyaan yang berbeda, dan kondisi runtime yang berbeda semuanya mengubah hasil. Catatan-catatan itu adalah pembeda antara sebuah angka dan sebuah benchmark, dan port itu menyatakannya sendiri.

Batas bawah memori adalah angka yang paling akan ditindaklanjuti oleh sebagian besar pembaca, dan angka itu yang paling tidak ambigu di antara semuanya: di bawah satu gigabita alokasi puncak MLX untuk satu pertanyaan singkat, pada kedua checkpoint. Itu bukan klaim tentang total jejak Mac Anda — OS, terminal Anda, dan proses Python semuanya berada di sampingnya — tetapi itu adalah batas bawah yang sesungguhnya, dan kira-kira tiga orde besaran di bawah apa yang dibutuhkan untuk menjalankan model generatif berukuran sedang secara lokal.

Pemeriksaan fidelitas adalah hasil yang lebih menarik

Port yang cepat tetapi menjawab berbeda dari model yang di-port olehnya tidak ada gunanya, dan di sinilah proyek mengerjakan pekerjaan yang penting. Ketiga checkpoint cocok dengan jawaban terpilih upstream pada 63 dari 63 pertanyaan validasi baik dalam FP32 maupun FP16 — 378 dari 378 perbandingan. Setiap konfigurasi juga menjalankan 100 panggilan berulang yang deterministik tanpa pertumbuhan memori aktif yang terukur, dan semua 36 file bobot yang dipublikasikan lulus verifikasi checksum remote yang ketat.

Bacalah cakupannya secara jujur: itu mengukur kesetiaan pada fixture tersebut, bukan akurasi pada setiap pertanyaan yang mungkin. Itu memberi tahu Anda bahwa port tersebut setia kepada Laya. Itu tidak memberi tahu Anda apa pun tentang apakah Laya benar.

Independen, dikelola komunitas, dan masih belum masuk daftar

Port ini mengatakan hal ini tentang dirinya sendiri, dua kali: ini adalah port MLX independen, bukan rilis resmi Convai Innovations. Pelatihan dan fine-tuning RLCD tetap di upstream. Bobot dikreditkan kepada Convai Innovations. Apache-2.0 di kedua sisi.

Cara upstream memperlakukannya lebih mengungkap daripada disclaimer apa pun. README Laya memuat daftar Community Tools, dan per 2026-09-23 daftar itu berisi empat entri: omp-laya-judge, laya-adk-toolkit, laya-Ascend untuk NPU Huawei Ascend, dan laya-apple — runtime Apple Silicon yang menggunakan GPU MLX dan Neural Engine. Entri keempat itu masuk melalui pull request #260, yang di-merge pada 2026-09-23. Port yang dibahas dalam artikel ini bukan salah satu dari keempatnya. Daftar upstream kini mengarahkan pembaca Apple Silicon ke proyek komunitas yang berbeda dari proyek yang rilis lebih dulu dan memiliki benchmark tersebut.

Pelacak masalah milik upstream sendiri menjelaskan sisanya. Issue #50, "Apple silicon ports," dibuka 2026-09-21, masih terbuka; maintainer menjawab pada hari yang sama bahwa dukungan Apple Silicon sedang dilacak dan bahwa port komunitas seperti Laya-MLX sedang menjajaki inferensi Metal native, lalu membalas lagi pada 2026-09-23 dengan kalimat yang layak dikutip persis: "Port MLX tetap dipelihara komunitas." Perbaikan di sisi PyTorch — MPS autocast dan koreksi RoPE transformers 4.x — masuk sebagai pull request #273, di-merge pada 2026-09-23, dengan seorang reviewer di utas itu menandai bahwa perbaikan tersebut masih perlu digabungkan dengan refaktor autocast terpisah di #109, yang masih terbuka. Dan issue #52, dibuka 2026-09-21, melaporkan sidecar Laya-MLX yang tumbuh menjadi sekitar 21,7 GB memori Metal selama beberapa jam pengoperasian, dengan vmmap mengaitkan sekitar 21,4 GB ke subsistem grafis alih-alih heap Python; issue ini mengusulkan untuk membatasi cache allocator dan membersihkannya setelah setiap inferensi, dan masih terbuka.

Jika semua itu digabungkan, jawaban praktisnya adalah: runtime ini tidak direstui upstream, ia dipelihara komunitas menurut deskripsi pemeliharanya sendiri, dan satu-satunya pertanyaan memori yang penting untuk sidecar yang berjalan lama sedang dikerjakan secara terbuka alih-alih diperbaiki dalam sebuah rilis.

Bisakah saya menjalankannya di laptop saya, dan apa yang harus saya korbankan?

Instalasi cukup dengan satu perintah pip, dan port ini menyediakan bobot FP16 yang sudah dikonversi sehingga Anda tidak perlu mengonversi apa pun sendiri:

pip install laya-mlx

Lalu import laya_mlx as laya, agent = laya.load("aac6fef/laya-mlx"), dan panggil agent.predict(state, questions). Persyaratannya adalah Apple Silicon, Python 3.11+ dan macOS 14+. Lingkungan yang diukur adalah macOS 27.2, Python 3.12.13 dan MLX 0.32.2 — dan port mencatat bahwa rilis MLX yang digunakannya menyertakan wheel untuk macOS 14, 15, dan 26 sementara penginstal memilih yang 26, dan bahwa versi macOS lama yang didukung tidak diuji pada mesin itu.

Apa yang Anda korbankan, dimensi demi dimensi:

• FP16 versus FP32 — FP16 adalah default dan sumber setiap angka utama di atas. FP32 memberikan kesesuaian numerik yang lebih dekat dengan upstream, dan probabilitas dapat sedikit berbeda antar presisi bahkan ketika label yang dipilih sama. BF16 dapat diminta tetapi bukan bagian dari matriks validasi yang dipublikasikan, jadi anggap saja belum diuji.

• Batas bawah memori versus ruang cadangan — di bawah 1 GiB alokasi puncak MLX untuk pertanyaan singkat masih nyaman di Mac seri M mana pun. Ini bukan pernyataan tentang beban server yang berkelanjutan, dan issue #52 adalah alasan untuk berhati-hati jika Anda berencana menjalankannya sebagai sidecar berumur panjang alih-alih sebagai panggilan pustaka.

• Multibahasa versus Inggris — checkpoint multibahasa 322M adalah yang lebih cepat di antara keduanya dan yang mencakup 100+ bahasa, tetapi port ini dengan sengaja meneruskan peringatan upstream: checkpoint bahasa Inggris bukan pengganti checkpoint multibahasa. Perutean di antara keduanya adalah pola yang dimaksudkan, bukan sekadar kemewahan.

• Direstui upstream versus dipelihara komunitas — ini yang kedua. Tidak ada apa pun dalam catatan rilis upstream yang menjamin port ini tetap berfungsi seiring perubahan upstream.

• Kecepatan versus kalibrasi — port yang cepat tidak memperbaiki bucket kalibrasi yang dikirim dengan terlalu percaya diri. Upstream membatasi suhu yang di-fit ke [0.5, 5.0], dan choice:11+ bucket yang dikirim adalah 0.1006, yang akan mempertajam logit sekitar sepuluh kali lipat dan melaporkan lemparan koin sebagai hampir pasti. Suhu kalibrasi yang di-fit ada alasannya; fit-lah pada data held-out Anda sendiri sebelum Anda bercabang pada probabilitas.

Ada dua batasan lagi yang perlu diingat, keduanya dari tracker upstream sendiri. action.act_probability saat ini tidak membawa sinyal yang dapat digunakan — nilainya 1.0 untuk hampir setiap input, dan logit mentahnya, saat diuji terhadap kebenaran, memperoleh AUROC 0.30 pada 396 keputusan berlabel (issue #185). Gunakan gerbang pada confidence sebagai gantinya, yang mencapai 0.77 pada item yang sama. Dan noul pertanyaan dapat mengikuti label opsinya alih-alih state (issue #156) — kartu milik upstream sendiri melaporkan "tidak" yang penuh keyakinan pada input yang jelas positif, paling kuat pada checkpoint bahasa Inggris. Solusi yang disarankannya bukanlah beralih ke model lain, melainkan mengubah bentuk pertanyaannya: ajukan sebagai pilihan dua opsi dengan kunci netral (A/B) dan kata-kata ya/tidak Anda sebagai deskripsi opsi.

Mengapa satu model keputusan dapat diporting dengan bersih dan yang lainnya tidak

Kontras di sini bersifat arsitektural, dan itu adalah hal paling berguna dalam artikel ini bagi siapa pun yang memilih di antara kedua keluarga tersebut.

Tulang punggung Laya adalah ModernBERT-large, encoder dua arah yang dibangun sepenuhnya dari attention. Attention adalah keunggulan utama stack GPU Apple, dan itulah yang telah menjadi fokus upaya MLX. Jadi port ini adalah implementasi ulang dari lapisan-lapisan yang sudah memiliki jalur cepat: encoder, lapisan Transformer pada decision head, scoring head, dan action head semuanya berjalan di MLX, dan tokenisasi tetap melalui tokenizer Rust milik Hugging Face.

Backbone Kev adalah basis Qwen3.5, dan Qwen3.5 memadukan lapisan attention dengan lapisan Gated DeltaNet. DeltaNet bersifat rekuren dan mengabaikan mask attention. Hal itu memiliki dua konsekuensi. Pertama, setiap pertanyaan harus dijalankan sebagai barisnya sendiri alih-alih berbagi satu urutan yang di-mask, yang ditangani proyek Kev dengan menghitung state sekali dan menggunakan kembali cache-nya per baris. Kedua — dan inilah bagian yang mengganggu di Mac — tidak ada kernel PyTorch untuk lapisan-lapisan tersebut di GPU Apple, sehingga PyTorch beralih ke kode referensi. jaredpalmer/kev-4b, kartu modelnya masih mencantumkan batas yang dihasilkan dalam bahasa sederhana: permintaan lima pertanyaan yang membutuhkan 0,17 dtk pada build Qwen3 Kev-4B membutuhkan 0,78 dtk dalam bf16 pada M5.

Periksa dulu kata-kata yang berlaku saat ini sebelum mengutipnya, karena sudah berubah. README repositori Kev sekarang menyatakan bahwa server menjalankan model Qwen3.5 melalui MLX di Apple Silicon, dan menerbitkan angka M5-nya sendiri untuk permintaan lima pertanyaan dengan masing-masing tiga opsi pada state sekitar 270 token: Kev-4B pada 721 ms di state baru dan 136 ms di state berulang melalui cache prefix, dibandingkan dengan 3.302 ms dan 847 ms pada jalur PyTorch bf16 MPS. Kev-0.8B mencapai 149 ms dan 28 ms. Model Qwen3 generasi sebelumnya masih berjalan di PyTorch MPS biasa dan proyek tersebut menyebutnya pilihan yang bagus di Mac.

Hati-hati agar itu tidak berubah menjadi hasil balapan. Ini bukan pengukuran head-to-head. 13,42 ms milik Laya-MLX adalah satu pertanyaan singkat di M3 Max; 721 ms milik Kev adalah lima pertanyaan dengan masing-masing tiga opsi pada state sekitar 270 token di M5. Jumlah pertanyaan berbeda, jumlah opsi berbeda, panjang state berbeda, mesin berbeda, runtime berbeda. Yang dapat diverifikasi dan layak dibandingkan adalah bentuk masalahnya, bukan pemenangnya: encoder dengan attention murni dapat dipindahkan ke Apple Silicon tanpa hambatan, sedangkan model hibrida linear-attention membutuhkan backend kedua yang utuh sebelum dapat digunakan di sana.

Untuk apa sebenarnya model keputusan

Singkirkan tolok ukurnya, dan kasus penggunaan yang jujur itu sempit, dan proyeknya sendiri mengatakan demikian: Laya adalah basis yang cepat untuk dispesialisasi, bukan mesin keputusan zero-shot. Pada tolok ukur typed-decisions milik Convai sendiri, kedua checkpoint dasar mencetak 0,362 dan 0,342 secara zero-shot terhadap baseline kelas mayoritas 0,461 dan baseline acak 0,318. Keduanya berada di bawah garis yang akan Anda dapatkan jika selalu menjawab label paling umum. Angka utama 0,766 dimiliki oleh laya-typed-decisions, checkpoint yang di-fine-tune pada split pelatihan tolok ukur itu sendiri, dan angka itu tidak boleh dikutip sebagai kemampuan umum.

Perbandingan yang dipublikasikan Convai terhadap TypeSafe Jev 1.13.0 layak dibaca justru karena alasan ini, dan hal itu dilabeli dengan hati-hati di sisi mereka: setiap angka Laya adalah apa yang sebenarnya dikembalikan oleh router, sedangkan angka Jev adalah angka yang dipublikasikan pihak ketiga yang tidak pernah diukur Convai karena Convai tidak memiliki akses API TypeSafe. Dalam perbandingan itu, Laya yang dirutekan mencetak skor 0,766 berbanding 0,727 milik Jev pada typed-decisions, dengan ECE pasca-temperature sebesar 0,081 berbanding 0,246, dan latensi p50 sebesar 32,8 ms berbanding 236–276 ms pada Tesla T4 — perbedaan 7,8x pada satu pertanyaan. Itulah angka yang harus dikutip. Angka "50x lebih cepat daripada Jev" yang menyebar di media sosial tidak muncul dalam dokumentasi proyek atau benchmark-nya, dan perbandingan yang dipublikasikan proyek itu sendiri tidak mendukungnya. Jev juga unggul di area yang memang menjadi keunggulannya: pada Banking77, Jev mencetak skor 0,870 berbanding 0,425 milik Laya, karena opsi-opsi Laya berbagi anggaran token tetap dan 77 label menyisakan sekitar tiga hingga empat token untuk masing-masing.

Jadi bentuk penerapan nyata adalah kepala keputusan yang murah, lokal, dan sempit — merutekan tiket, menilai urgensi, menjawab gerbang ya/tidak — dengan sesuatu yang generatif di belakangnya untuk bagian yang perlu menulis. Model keputusan membuat panggilan bertipe dalam milidetik dan mengeskalasi. Separuh generatif adalah model berbeda pada runtime berbeda, dan di situlah router mendapat tempatnya: 200+ model di balik satu kunci dengan harga daftar penyedia tanpa markup, sehingga perubahan harga vendor aktif di hari yang sama, dan failover otomatis saat penyedia mengalami degradasi di tengah proses. OrcaRouter tidak melayani Laya, dan tidak melayani Kev atau Jev — keluarga Qwen3.5 ada di daftar model kami, sedangkan model keputusannya sendiri tidak. Yang kami cakup adalah separuh generatif dari tumpukan itu, yaitu separuh yang Anda panggil pada setiap permintaan yang dieskalasi oleh kepala keputusan.

Ada satu alasan lagi untuk menjaga kedua bagian tetap terpisah alih-alih menggunakan satu model untuk melakukan keduanya. Head keputusan lokal yang tidak memakan token keluaran dan tidak pernah menyentuh jaringan adalah jenis dependensi yang berbeda dari panggilan API: ia tetap bekerja saat jaringan tidak tersedia, dan biayanya tidak bertambah seiring banyaknya teks yang dibacanya. Itulah properti yang layak dibayar. Semua hal lain dalam artikel ini membahas seberapa besar Anda membayarnya dalam hal fidelitas, memori, dan pemeliharaan.

Siapa yang harus menjalankannya, dan siapa yang harus menunggu

Jalankan Laya-MLX jika Anda menggunakan Mac seri M, keputusan Anda dibatasi — pilihan atas opsi bernama, skor rubrik, gerbang ya/tidak — dan Anda entah memiliki label untuk fine-tuning atau siap menyesuaikan suhu kalibrasi sendiri. Instalasinya cukup satu perintah, kebutuhan memori minimumnya di bawah satu gigabyte, dan pekerjaan fidelitasnya telah dilakukan serta dipublikasikan.

Tunggu dulu, jika Anda membutuhkan jaminan dukungan upstream, jika Anda menjalankan sidecar yang berjalan lama dan ingin pertanyaan pertumbuhan memori diselesaikan dalam sebuah rilis, bukan dalam issue yang masih terbuka, atau jika pertanyaan Anda bersifat terbuka. Encoder non-autoregresif yang menjawab "apa yang harus saya lakukan selanjutnya" bukanlah versi lebih kecil dari LLM yang melakukan hal yang sama. Ia adalah instrumen yang berbeda, dan ia hanya menafsirkan dengan baik ketika pertanyaannya sudah dibentuk untuknya.