Ritme Rilis AI Lokal September 2026: Ollama v0.34.2, llama.cpp Harian, Open WebUI 0.11.3

Bagian paling melelahkan dari mengelola tumpukan AI self-hosted bukan konfigurasinya, tapi ritme rilisnya. Data yang ditarik dari API GitHub pada 21 September 2026 memperlihatkan polanya dengan jelas: Ollama merilis lima kali sejak 2 September, llama.cpp menambah beberapa build hanya dalam satu hari, dan Open WebUI terakhir menandai versi pada 31 Agustus. Artikel ini mencatat apa yang benar-benar tertulis di changelog resmi, dan cara memantau ritme itu tanpa harus buka lima halaman tiap pagi.

TL;DR

• Ollama merilis lima kali sejak 2 September 2026, dengan v0.34.2 sebagai versi stabil terbaru yang keluar pada 15 September 2026.
• Ollama v0.34.2 memperbaiki pertumbuhan memori berlebihan saat generasi panjang dengan speculative decoding pada MLX, selain menambah pengaturan awal perintah ollama, skema tautan ollama://apps, dan pembaruan llama.cpp.
• llama.cpp mencatat lima build berurutan pada 20 September 2026 saja, dari b11059 sampai b11064, sehingga sebaiknya nomor build dikunci dan disertai jalur rollback.
• Open WebUI v0.11.3, rilis stabil terakhir per 21 September 2026, keluar pada 31 Agustus dan memperbaiki penanganan migrasi database agar kegagalan berhenti pada error penyebabnya.
• Ritme rilis bisa dipantau lewat API GitHub dengan cron harian tanpa API key, dengan batas 60 request per jam per alamat IP.

Peta rilis yang terukur hari ini

Proyek	Versi tercatat	Dirilis	Jumlah rilis terakhir yang diperiksa
ollama/ollama	v0.34.3-rc1	2026-09-19	5 rilis sejak 2026-09-02
ollama/ollama	v0.34.2	2026-09-15	stabil
ollama/ollama	v0.34.1	2026-09-14	stabil
ollama/ollama	v0.34.0	2026-09-05	minor baru
ollama/ollama	v0.33.3	2026-09-02	siklus sebelumnya
ggml-org/llama.cpp	b11064	2026-09-20	5 build pada tanggal yang sama
astral-sh/uv	0.12.17	2026-09-18	5 rilis sejak 2026-09-10
denoland/deno	v2.9.7	2026-09-17	rilis patch
open-webui/open-webui	v0.11.3	2026-08-31	rilis stabil terbaru yang diperiksa

Dua hal bisa disimpulkan tanpa perlu menebak: proyek yang jadi fondasi (Ollama, llama.cpp, uv) bergerak dalam hitungan hari, sementara antarmuka web seperti Open WebUI bergerak dalam hitungan minggu. Beda ritme ini penting ketika menyusun kebijakan update, karena menyamaratakan semua dependency berarti upgrade tanpa perlu atau ketinggalan jauh.

Apa yang benar-benar berubah di Ollama v0.34.x

Catatan rilis v0.34.2, yang keluar pada 15 September, menuliskan empat butir. Pertama, ada pengaturan awal saat menjalankan perintah ollama, dengan opsi masuk ke akun atau lanjut secara lokal, dan status penyelesaian setup dibagi dengan aplikasi desktop di macOS dan Windows. Kedua, ditambahkan skema tautan ollama://apps untuk membuka halaman Apps di aplikasi desktop pada macOS dan Windows. Ketiga, diperbaiki pertumbuhan memori berlebihan saat generasi panjang dengan speculative decoding pada MLX. Keempat, llama.cpp dibarukan.

Butir ketiga adalah yang paling relevan secara operasional. Speculative decoding adalah teknik mempercepat generasi dengan menebak beberapa token lebih dulu, dan pertumbuhan memori yang tidak stabil di jalur itu bikin sesi panjang jadi berisiko: proses kelihatan sehat sampai suatu ketika makan RAM dan menukar ke swap. Kalau pernah mengalami mesin tiba-tiba lambat di tengah percakapan panjang, pola ini bukan hal asing, dan pembaikan versi 0.34.2 memberi alasan konkret untuk naik.

Perlu ditegaskan apa yang tidak diklaim di sini: changelog resmi tidak menyebut angka percepatan, tidak menyebut konsumsi memori tertentu, dan tidak menyebut model mana yang lebih baik. Semua klaim performa yang beredar di utas media sosial bukan bagian dari data ini.

llama.cpp: build harian dan cara menahan diri

Pada 20 September saja tercatat lima rilis berurutan, dari b11059 sampai b11064. Untuk proyek dengan ritme secepat ini, mengikuti nomor build terbaru di produksi hampir selalu ide buruk. Praktik yang lebih masuk akal:

• Pakai nomor build yang sudah diuji di mesin sendiri, lalu tulis di berkas lock atau image. Nomor build llama.cpp adalah versi yang bisa dikunci, bukan sesuatu yang harus selalu terbaru.
• Baca changelog antar-build yang dilompati, bukan cuma judul rilis. Perubahan backend atau dukungan kartu grafis adalah bagian yang paling sering menjatuhkan inferensi.
• Simpan satu jalur rollback: binary sebelumnya beserta konfigurasi model. Restore binary lebih cepat daripada mencari penyebab regression.

Pola ini juga berlaku untuk pelayan inference lain yang berbasis CUDA atau Metal. Perbedaan hasil pada kartu grafis tertentu lebih sering disebabkan versi backend daripada versi modelnya.

Open WebUI 0.11.3 dan pelajaran soal migrasi database

Rilis 0.11.3 pada 31 Agustus menyebut empat butir yang berkaitan dengan penggunaan sehari-hari. Mode aksesibilitas ditandai lebih kuat pada entri menu, submenu, pemilih model, beserta kontrol filter dan bandingnya, sehingga kontrasnya mengikuti pedoman aksesibilitas di kedua tema. Cabang percakapan yang tersimpan di bawah pesan sebelumnya tetap terhubung setelah reload, dan chat lama yang tersimpan tanpa tautan itu diperbaiki saat dibuka, dengan rujukan isu bernomor 29299. Ada pula perbaikan terjemahan, termasuk bahasa Indonesia, yang disebut diperluas.

Butir yang paling perlu perhatian tim yang self-host adalah penanganan upgrade basis data. Release note-nya menjelaskan bahwa kegagalan migrasi kini berhenti pada error penyebabnya, alih-alih tetap memulai dan kemudian melaporkan tabel atau kolom yang hilang di belakang, seperti kolom timer pada tabel chat. Buat yang pernah melihat layanan jalan separuh lalu menumpuk error aneh, ini jenis perbaikan yang membuatnya mudah dijelaskan ke manajemen: kegagalan yang keras dan jelas lebih murah daripada kegagalan yang diam-diam.

Konsekuensi praktisnya sebelum naikkan versi antarmuka web apa pun yang menyimpan state di database: cadangkan database lebih dulu, dan jangan cuma cadangkan berkas aplikasinya. Migrasi yang gagal di tengah jalan meninggalkan skema yang tidak cocok dengan kode lama maupun baru.

Ritme toolchain: uv dan Deno

uv dari Astral bergerak dari 0.12.13 pada 10 September ke 0.12.17 pada 18 September, empat rilis dalam delapan hari. Deno tercatat di v2.9.7 pada 17 September, setelah v2.9.6 pada 27 Agustus. Keduanya bukan bagian dari tumpukan inferensi, tapi sering muncul di proyek yang sama, dan ritmenya mengingatkan bahwa sebagian besar proyek yang gagal di upgrade bukan karena runtime AI-nya, tapi karena alat build dan pengemasan.

Cara memantau tanpa membuka browser

API GitHub melepas daftar rilis sebagai JSON, jadi satu cron kecil cukup jadi radar mingguan:

curl -s "https://api.github.com/repos/ollama/ollama/releases?per_page=5" | jq -r ".[] | [.published_at[:10], .tag_name] | @tsv"

curl -s "https://api.github.com/repos/ggml-org/llama.cpp/releases?per_page=5" | jq -r ".[] | [.published_at[:10], .tag_name] | @tsv"

Simpan hasilnya ke berkas bertanggal, bandingkan dengan versi yang terpasang di mesin, dan hanya baca changelog kalau memang beda. Tanpa API key, batasnya 60 request per jam per alamat IP, lebih dari cukup untuk cron harian. Untuk proyek yang butuh notifikasi, ubah perbandingan versi menjadi satu baris pesan, bukan email berisi seluruh changelog.

Jadwal upgrade yang realistis untuk tim kecil

• Kontrol. Satu orang, satu catatan berisi versi terpasang di tiap mesin. Tanpa daftar ini, diskusi upgrade selalu berujung pada tebakan.
• Pilih jalur. Tandai mana yang boleh naik mingguan (alat development) dan mana yang naik setelah diuji (mesin inference produksi).
• Uji dengan beban nyata. Satu prompt pendek tidak membuktikan apa pun. Jalankan percakapan panjang dan muat file yang biasa dipakai, karena perbaikan memori di 0.34.2 pun hanya terlihat pada generasi panjang.
• Catat hasil uji. Versi, tanggal, mesin, dan apa yang berubah. Catatan ini yang membuat upgrade berikutnya cepat.
• Beri tanggal tinjauan. Kalau ada satu komponen yang selalu ditunda, itu kandidat untuk dihapus dari arsitektur, bukan untuk dikasihani.

Uji 20 menit yang lebih berguna daripada benchmark orang lain

Sebelum menandai sebuah mesin inference sebagai siap produksi, ada empat pemeriksaan yang hasilnya hanya terlihat di beban sendiri. Semuanya bisa diselesaikan dalam 20 menit.

• Warm-up dan cold-start. Catat waktu dari perintah mulai sampai respons token pertama. Angka ini yang dialami pengguna pertama tiap pagi setelah mesin menyala, bukan yang tertulis di halaman benchmark.
• Kurva memori. Jalankan satu percakapan panjang, bukan sepuluh percakapan pendek, dan amati apakah pemakaian memori berhenti naik. Perbaikan Ollama v0.34.2 masuk kategori ini, dan itu sebabnya pengujian dengan beban pendek tidak akan menemukannya.
• Perilaku saat konteks penuh. Ada pelayan yang memotong riwayat diam-diam, ada yang menolak permintaan. Keduanya bisa diterima; yang tidak bisa adalah tidak tahu mana yang terjadi di sistem sendiri.
• Batas kartu grafis. Naikkan ukuran batch atau panjang konteks sampai gagal, lalu catat di angka berapa. Setelah itu ada angka perencanaan yang nyata, bukan harapan.

Empat catatan itu lebih berharga daripada tabel token per detik dari mesin orang lain, karena yang lo punya adalah perangkat keras sendiri, dengan model sendiri, dan pola pemakaian sendiri.

Kenapa Open WebUI tampak tertinggal, dan itu bukan masalah

Selisih hampir tiga minggu antara rilis antarmuka dan rilis runtime bukan tanda proyeknya mandul. Open WebUI v0.11.1 keluar pada 25 Agustus, v0.11.2 dan v0.11.3 pada 31 Agustus, dan tidak ada rilis yang tercatat setelah itu sampai data ini ditarik. Antarmuka web menyimpan state pengguna, jadi ritmenya melambat karena yang dipertaruhkan bukan cuma fitur tapi juga data yang sudah ada di dalamnya. Justru karena itu butir perbaikan migrasi basis data di 0.11.3 lebih signifikan daripada satu fitur baru: ia mengubah cara kegagalan ditangani, dan itu langsung terasa saat upgrade.

Bagian yang perlu dibaca teliti saat naik versi antarmuka biasanya tiga: skema basis data, konfigurasi otentikasi, dan indeks pengetahuan untuk RAG. Tiga area itu yang paling sering membuat upgrade terasa merusak walau aplikasinya sendiri jalan.

Tanya jawab singkat

Perlu ikut rc1? Untuk mesin produksi, tidak. Nomor release candidate berguna untuk menguji lebih awal agar laporan bug sampai sebelum versi stabil keluar, tapi bukan target deploy.

Berapa sering memeriksa? Cron mingguan yang membandingkan versi terpasang dengan rilis terbaru sudah cukup untuk hampir semua kasus. Yang perlu perhatian lebih cepat adalah advisory keamanan, bukan rilis rutin.

Bagaimana kalau versi lo tidak ada di daftar ini? Berarti data ini tidak berlaku untuk mesin tersebut. Periksa daftar rilis proyek yang dipakai, dan catat tanggal pemeriksaannya sendiri.

Batas data ini

Seluruh nomor versi dan tanggal di atas diambil dari endpoint rilis GitHub resmi pada 21 September 2026, dan hanya lima rilis terakhir per proyek yang diperiksa. rc1 berarti rilis calon, bukan versi stabil. Dan tidak ada satu pun angka benchmark di artikel ini, karena sumbernya memang tidak menyebutnya.

Sumber

• Rilis Ollama, termasuk catatan v0.34.2.
• Rilis llama.cpp untuk nomor build 20 September.
• Rilis Open WebUI, catatan v0.11.3 dan tautan isu 29299.
• Rilis uv dan rilis Deno.

Untuk yang menjalankan model di mesin sendiri, ritme rilis secepat ini sebenarnya kabar baik: perbaikan yang mengganggu, seperti pembengkakan memori pada generasi panjang, selesai dalam hitungan hari, bukan hitungan kuartal. Syaratnya cuma satu, yaitu punya kebiasaan membaca changelog sebelum menaikkan versi, bukan sesudahnya.

Rekomendasi Tools & Layanan

Kalau lo mau langsung praktikkan panduan di atas, dua layanan yang gue pake sehari-hari: free trial Alibaba Cloud buat coba-coba tanpa biaya di awal, dan ECS instance 9th-gen kalau udah siap naik ke VPS production.

FAQ

Apakah perlu memasang release candidate seperti Ollama v0.34.3-rc1 di mesin produksi?

Untuk mesin produksi, tidak perlu. Release candidate berguna untuk menguji lebih awal agar laporan bug sampai sebelum versi stabil keluar, tapi bukan target deploy.

Seberapa sering sebaiknya memeriksa rilis baru dari proyek AI self-hosted?

Cron mingguan yang membandingkan versi terpasang dengan rilis terbaru sudah cukup untuk hampir semua kasus. Yang perlu perhatian lebih cepat adalah advisory keamanan, bukan rilis rutin.

Apa yang diperbaiki di Open WebUI 0.11.3 terkait migrasi database?

Kegagalan migrasi kini berhenti pada error penyebabnya, alih-alih tetap memulai lalu melaporkan tabel atau kolom yang hilang di belakang, seperti kolom timer pada tabel chat. Sebelum upgrade, cadangkan database lebih dulu, bukan hanya berkas aplikasinya.

Mengapa mengikuti build terbaru llama.cpp di produksi tidak disarankan?

llama.cpp bisa merilis beberapa build dalam satu hari, seperti lima build dari b11059 sampai b11064 pada 20 September. Lebih aman memakai nomor build yang sudah diuji di mesin sendiri, membaca changelog antar-build, dan menyimpan satu jalur rollback berupa binary sebelumnya beserta konfigurasi model.

Apa yang disebut changelog resmi Ollama v0.34.2 soal performa?

Changelog resmi hanya menyebut perbaikan pertumbuhan memori berlebihan saat generasi panjang dengan speculative decoding pada MLX. Ia tidak menyebut angka percepatan, konsumsi memori tertentu, atau model mana yang lebih baik, dan semua klaim performa di luar itu bukan bagian dari data ini.

Sumber & Referensi

Rujukan resmi yang dipakai untuk memverifikasi klaim di artikel ini:

• Dokumentasi resmi Open WebUI
• Dokumentasi GitHub Releases REST API
• Dokumentasi resmi Ollama