llama.cpp v0.2.0 Membuat Janji yang Berbeda untuk Stable dan Nightly
llama.cpp kini memiliki rilis semantik di samping build nightly. Tag stable pertamanya berbagi kode dengan sebuah tag build, menunjukkan bahwa nama channel menggambarkan policy, bukan kualitas.
llama.cpp telah bertahun-tahun merilis tag dengan nomor build hampir secepat perubahan kodenya. Pada 21 Agustus, proyek ini menambahkan jalur kedua: rilis v0.2.0 memulai lini semantic versioning yang konsisten untuk rilis stabil yang lebih lambat, sementara tag b[NUM] tetap menjadi channel nightly atau pengembangan yang cepat.
Itu tidak membuat setiap upgrade local inference aman. Hal ini memberi tim downstream versi yang lebih jelas untuk dipin—serta pilihan yang disengaja ketika GPU, model, atau perbaikan performa yang lebih baru hanya ada dalam build nightly.
Gunakan rilis vX.Y.Z ketika reproducibility dan kompatibilitas downstream lebih penting daripada perubahan terbaru. Gunakan build b[NUM] ketika hardware atau workload Anda memerlukan commit tertentu yang telah diverifikasi. Dalam kedua kasus, pin tag dan commit yang persis, verifikasi binary yang diunduh, dan jalankan smoke test yang sama sebelum promosi.
Stable dan nightly adalah dua policy rilis, bukan tingkatan kualitas
Nama tag baru menggambarkan cadence dan audiens. Rilis llama.cpp menyatakan bahwa tag stable vX.Y.Z hadir lebih lambat dan direkomendasikan untuk distribusi downstream serta pengguna umum. Tag b[NUM] yang sudah ada dibuat pada atau dekat sebagian besar commit, lebih cepat mengekspos fungsionalitas terkini, dan mungkin kurang stabil.
Policy rilis dan versioning proyek yang lebih terperinci menambahkan batas penting dalam packaging. Tag stable llama.cpp dibuat ketika salinan internal ggml-nya cocok dengan versi ggml yang telah dirilis. Hal itu memungkinkan distributor downstream membangun llama.cpp terhadap ggml yang terpasang di sistem dengan titik kompatibilitas yang terdefinisi. Build nightly terus menggunakan salinan internal llama.cpp yang masih dalam pengembangan, yang dapat berbeda dari library yang dirilis secara terpisah.
Ini sudah lebih dari sekadar latihan penamaan. Homebrew mengalihkan formula llama.cpp-nya ke tag v0.2.0 dan commit persis, membangunnya dengan mode pengembangan dimatikan, dan menautkannya ke ggml sistem yang dikemas. Formula yang sama tetap mempertahankan master sebagai build head yang dapat dipilih secara opt-in. Karena itu, stable dan pengembangan terkini hidup berdampingan sebagai pilihan dependensi yang berbeda.
| Pertanyaan | Pilih stable vX.Y.Z |
Pilih nightly b[NUM] |
|---|---|---|
| Apa yang memaksa upgrade? | Jendela pemeliharaan yang direncanakan atau policy rilis yang didukung | Perbaikan model, backend, driver, keamanan, atau regresi tertentu yang tidak ada di stable |
| Seberapa banyak perubahan yang dapat diserap tim? | Delta rilis yang telah ditinjau dengan cadence lebih lambat | Delta commit yang persis, dengan kemungkinan perubahan lanjutan yang lebih cepat |
Bagaimana ggml digunakan? |
Library sistem atau paket downstream mendapat manfaat dari titik kompatibilitas rilis | Build membawa salinan internal ggml llama.cpp saat ini |
| Bukti apa yang diperlukan? | Catatan rilis ditambah tes workload dan packaging | Pull request atau commit yang menjadi alasan, ditambah gate pengujian lengkap yang sama |
| Apa yang dicatat? | Tag semantik, commit lengkap, digest artefak, flag build, backend, dan revisi model | Tag build, commit lengkap, digest artefak, flag build, backend, dan revisi model |
| Apa rollback-nya? | Rilis semantik sebelumnya yang diterima beserta artefaknya | Baseline nightly atau stable terakhir yang diterima, disimpan terpisah dari kandidat |
Nightly tidak otomatis berarti lebih cepat, dan stable bukan klaim bahwa semua regresi telah hilang. Label-label itu menyatakan bagaimana kode dipilih dan dirilis. Performa dan correctness tetap bergantung pada model, kuantisasi, backend, compiler, driver, hardware, campuran prompt, panjang konteks, dan pengaturan server.
v0.2.0 dan b10566 menunjuk ke kode yang sama, tetapi melayani pekerjaan yang berbeda
Rilis stable pertama menunjukkan sebuah detail yang berguna. Tag v0.2.0 dan b10566 sama-sama mengarah ke commit bb4caa7540188872173c44d161602d9271386413. Halaman stable menetapkan rilis semantik dan menautkan ke nightly b10566; rilis b10566 membawa artefak macOS, Linux, Android, Windows, dan iOS yang telah dibangun sebelumnya untuk commit tersebut.
Perbedaan itu mengubah apa yang seharusnya dipin:
- Build sumber atau paket downstream harus mengidentifikasi
v0.2.0dan commit lengkapnya. Tag tersebut menyampaikan kontrak rilis stable. - Tim yang menggunakan salah satu arsip yang telah dibangun sebelumnya oleh proyek harus mencatat
b10566, nama file persis, dan digest-nya karena binary tersebut berada di rilis dengan tag build. - Nightly yang lebih baru tidak boleh dideskripsikan sebagai “v0.2.0 plus perbaikan” tanpa memeriksa rentang commit persisnya. Per 24 Agustus waktu Jakarta, repositori tersebut sudah menerbitkan b10603 pada commit yang berbeda.
Catatan rilis juga menunjukkan mengapa janji performa pada tingkat versi akan menyesatkan. Rentang perubahan v0.2.0 mencakup pekerjaan backend, server, dukungan model, memori, build, dan rekayasa rilis. Sebagian perubahan spesifik untuk Metal, SYCL, OpenCL, Vulkan, CUDA, atau arsitektur model tertentu; perubahan lain merupakan revert. Tidak ada satu angka kecepatan yang dapat merangkum campuran tersebut.
Verifikasi provenance sebelum menguji performa
Rilis binary b10566 menautkan attestation artefak GitHub dan menerbitkan digest SHA-256 untuk file-file tersebut. Attestation artefak adalah pernyataan bertanda tangan yang menghubungkan artefak dengan repositori sumber dan workflow build-nya. Dokumentasi attestation GitHub menjelaskan batasnya secara eksplisit: provenance membantu menetapkan di mana dan bagaimana artefak dibangun; provenance tidak membuktikan bahwa kode aman atau bebas regresi.
Unduh hanya arsip platform yang persis dari halaman rilis proyek, lalu verifikasi sebelum mengekstraknya. Dengan GitHub CLI terkini, bentuk perintah yang didokumentasikan adalah:
gh attestation verify ./llama-b10566-bin-ubuntu-x64.tar.gz \
--repo ggml-org/llama.cppReferensi GitHub CLI menjelaskan policy verifikasi dan outputnya. Hasil yang berhasil harus disimpan bersama catatan deployment, berdampingan dengan repositori yang diharapkan, nama file artefak, digest SHA-256, tag, dan commit. Verifikasi yang gagal atau tidak ada adalah kondisi berhenti, bukan alasan untuk mencoba ulang menggunakan mirror yang tidak terlacak.
Hanya mem-pin master, latest, head, atau channel package manager yang terus bergerak membuat insiden berikutnya lebih sulit direkonstruksi. Tag lebih baik, sedangkan commit persis mengidentifikasi sumber secara independen dari nama channel.
Stable dan nightly menjawab kebutuhan pemeliharaan yang berbeda
Pasangan v0.2.0 dan b10566 yang tidak biasa membuat perbedaannya konkret: tag-tag tersebut menunjuk ke commit sumber yang sama, tetapi rilis semantik menyampaikan kontrak stabilitas sedangkan tag build membawa artefak yang dapat diunduh. Nightly yang lebih baru mungkin memuat perbaikan backend atau model yang dibutuhkan, tetapi juga bergerak menjauh dari kode persis yang dipilih oleh rilis stable.
Itu menjadikan “stable versus nightly” keputusan pemeliharaan, bukan kesimpulan benchmark. Model, kuantisasi, hardware, backend, konteks, dan workload dapat mendominasi performa, sementara provenance hanya dapat menetapkan dari mana artefak berasal—bukan bahwa artefak tersebut aman atau bebas regresi.
Sinyal paling berguna dari policy rilis baru llama.cpp karena itu bersifat organisasional: pengguna downstream akhirnya memiliki jangkar semantik tanpa kehilangan akses ke build yang bergerak cepat. Apakah jangkar tersebut tepat untuk deployment tertentu tetap bergantung pada kapabilitas atau perbaikan yang diperlukan workload itu.