llama.cpp surumleri nasil sabitlenir?

llama.cpp sürüm oluşturma sürecinde neler değişti

llama.cpp sürümlerini sabitlemek, belirli bir etiketi (tag) derlemek ve bu ismi model dosyasının yanında kayıt altına almak anlamına gelir. Etiket kendiliğinden değişmediği için sunucu, bugün ürettiği çıktıyı yarın da aynı şekilde üretmeye devam eder. Yıllarca seçim yapılabilecek tek bir etiket türü vardı: master dalından otomatik olarak oluşturulan b10502 gibi bir derleme numarası. 2026 yılından itibaren v0.1.2 gibi ikinci bir etiket türü daha geldi ve her iki iz de aynı geçmişten eş zamanlı olarak oluşturuluyor.

Sürüm etiketleri, bir sürüm numarasının genellikle ifade ettiği anlamı henüz taşımamaktadır. v0.1.2 üzerindeki sürüm notları bunu tek bir satırda belirtmektedir:

Anlamsal sürüm oluşturma (semantic versioning) henüz geliştirme aşamasındadır. Daha fazla bilgi https://github.com/ggml-org/ggml/discussions/1579 adresinde bulunabilir.

Bunu olduğu gibi kabul edin. Bu bağlantının arkasındaki ggml tartışması, sürüm oluşturma sıklığının ne olacağı ve nelerin yama (patch) olarak kabul edileceği dahil olmak üzere sistemin hala üzerinde çalışıldığı yerdir. Bir v0. etiketi, projenin geçmişteki bir noktayı işaretlemeyi seçtiğini gösterir. Son rakam bir artırıldığı için bir sonraki sürümün güvenli bir şekilde mevcut olanın yerini alabileceğini garanti etmez.

Derleme etiketindeki numara da herhangi bir sürüm anlamı taşımaz. Bu numara commit sayısından gelir, dolayısıyla kurulumunuzla ilgili bir değişiklik olup olmadığına bakılmaksızın kendi kendine artar. 19 Ağustos 2026 itibarıyla sürümler listesinin ön sayfasında, b10455 ile b10502 arasında değişen ve aralarında v0.1.2'nin de bulunduğu dokuz adet derleme etiketi yer almaktaydı.

Canlı hizmet veren bir sunucuda asla master dalından derleme yapmayın

git pull komutunu takiben yapılan bir yeniden derleme, son birkaç saat içinde ana dala eklenen her değişikliği sisteminize dahil eder. Bu durum kişisel bilgisayarlar için kabul edilebilir olsa da, sunucularda davranış değişikliği yaşandığında kritik öneme sahip olan "şu an ne çalışıyor ve geçen hafta ne çalışıyordu" sorusuna yanıt verme yeteneğinizi ortadan kaldırır. Modelin ürettiği metin ve bu metni üretme hızı, yapılan derlemeye göre değişkenlik gösterir. Salı günü alınan yanıtların kötüleştiğine dair bir şikayetin, o günkü commit kaydı tutulmadıysa hiçbir yanıtı olamaz.

Bunun yerine belirli bir etiketi (tag) sabitleyin. Proje sizin için bu etiketleri oluşturur ve önceden derlenmiş her sürüm arşivi bu etiketlerden biriyle adlandırılır.

llama.cpp sürümleri için hangi etiket sabitlenmelidir?

Belirli ve bilinen bir durumu korumak istediğinizde bir derleme etiketini (build tag) sabitleyin. Bu, uzun bir geçmişe sahip olan, sürüm arşivlerinin isimlendirildiği ve çoğu hata raporunda referans gösterilen izleme yoludur; dolayısıyla bir derleme numarası, başkalarıyla karşılaştırma yapmak için en kolay yöntemdir.

Daha kısa ve kasıtlı noktalardan oluşan bir listeyi takip etmek isterseniz bir sürüm etiketini (version tag) sabitleyin. Güncelleme yapmadan önce sürüm notlarını okuyun ve numaralandırmanın henüz bir uyumluluk sözleşmesi niteliği taşımadığını, yukarıdaki uyarıyı göz önünde bulundurarak dikkate alın.

Her iki durumda da operasyonel kural aynıdır. Etiket dizgisi bir dosya içinde tutulur, sunucu yalnızca bu dizgi değiştiğinde yeniden derlenir ve bu değişiklik bilinçli olarak verilmiş bir karardır.

Sabitlenmiş etiketi derleyin

sudo apt update
sudo apt install -y build-essential cmake git
git clone --depth 1 --branch b10502 https://github.com/ggml-org/llama.cpp.git ~/src/llama.cpp-b10502
cd ~/src/llama.cpp-b10502
git describe --tags

git describe --tags, b10502 çıktısını vermelidir. Bir etikette yapılan sığ (shallow) klonlama, yalnızca o commit'i tutar ve sonrasını içermez; böylece kimse dikkatsiz bir git pull ile etiketi daha sonra değiştiremez. Yapılandırma adımı eksik bir bağımlılık nedeniyle durursa, belirtilen paketi kurun ve işlemi tekrar çalıştırın.

Donanımınızın gerektirdiği seçeneklerle derleyin. Yalnızca CPU:

cmake -B build
cmake --build build --config Release -j $(nproc)

NVIDIA GPU (öncelikle CUDA toolkit kurulumu gerektirir):

cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j $(nproc)

CPU tabanlı bir sistemde OpenBLAS:

cmake -B build -DGGML_BLAS=ON -DGGML_BLAS_VENDOR=OpenBLAS
cmake --build build --config Release -j $(nproc)

İkili dosyalar, yükledikleri paylaşımlı kütüphanelerin (libllama.so ve libggml dosyaları) yanında, build/bin dizinine yerleşir. Kurulumdan önce derlemenin çalıştığını doğrulayın:

./build/bin/llama-server --version

Tüm dizini etiket adını taşıyan bir yolun altına kurun, ardından bir sembolik bağlantıyı (symlink) bu dizine yönlendirin:

sudo install -d /opt/llama.cpp/b10502
sudo cp -a build/bin /opt/llama.cpp/b10502/bin
sudo ln -sfn /opt/llama.cpp/b10502 /opt/llama.cpp/current

Tek bir dosyayı değil, dizinin tamamını kopyalayın. Tek başına bir llama-server, ihtiyaç duyduğu kütüphaneler o dizinde yanında bulunduğu için ilk çalıştırılmasında error while loading shared libraries: libllama.so: cannot open shared object file hatasıyla başarısız olur.

Servisi, etiket dizinine değil, her zaman sembolik bağlantıya yönlendirin:

[Service]
ExecStart=/opt/llama.cpp/current/bin/llama-server -m /srv/models/model-q4_k_m.gguf -c 8192 -ngl 99 --host 127.0.0.1 --port 8080

systemd, süreci başlattığında sembolik bağlantıyı çözer; bu nedenle derlemeler arasında geçiş yapmak, yeni bir sembolik bağlantı hedefi ve sudo systemctl restart llama-server komutu gerektirir. Unit dosyasının geri kalanı ve önündeki reverse proxy, VPS üzerinde llama.cpp sunucusu için tam kılavuz içerisinde ele alınmıştır.

GGUF dosyasının yanına etiketi ve nicemleme (quant) değerini kaydedin

Çıktıyı belirleyen unsurların yarısı derleme, diğer yarısı ise model dosyasıdır. GGUF (GGML universal file format), ağırlıkların içinde dağıtıldığı kapsayıcıdır. Aynı model birçok farklı nicemleme seviyesinde yayınlandığından, aynı etikete sahip iki sunucu farklı sonuçlar verebilir; çünkü biri Q4_K_M dosyası kullanırken diğeri Q8_0 kullanıyor olabilir. Kurulumu tam olarak yeniden oluşturmak için gereken her şeyi içeren küçük bir dosyayı modelin yanında tutun:

tag: b10502
commit: 7c1f2a9
model_file: model-q4_k_m.gguf
model_sha256: <output of sha256sum>
quant: Q4_K_M
cmake_args: -DGGML_CUDA=ON
cuda: <output of nvcc --version>
bench_cmd: llama-bench -p 512 -n 128 -r 5
bench_result: <fill in from the run on this box>

Sabitlenmiş checkout içindeki git rev-parse --short HEAD ile commit bilgisini alın. sha256sum model-q4_k_m.gguf ile sağlama toplamını (checksum) alın ve indirme sırasında yayıncının değeriyle karşılaştırın; çünkü bir indirmeyi yayınlanan sağlama toplamı ile doğrulamak, eksik inmiş bir dosyanın kafa karıştırıcı bir hataya dönüşmesini önler. Nicemleme seviyesinin cevapları ne kadar değiştirdiği ayrı bir konudur ve her nicemleme seviyesinin maliyeti bu konuyu açıklamaktadır.

Sunucuyu bozmadan yükseltme işlemi nasıl yapılır?

Yükseltme işlemini bir tatbikat gibi gerçekleştirin. Yeni etiketi eskisinin yanında derleyin, her ikisini de ölçümleyin ve yeni olan başarıyla çalışana kadar eskisini tutun.

1. Yeni etiketi kendi dizinine kopyalayın. Eski checkout dizinini tekrar kullanmayın.
2. Manifest dosyasında kayıtlı olan aynı cmake argümanlarını kullanarak derleyin.
3. Her iki derleme üzerinde de aynı model dosyası, aynı istem uzunluğu ve aynı tekrarlama sayısı ile llama-bench komutunu çalıştırın.
4. Cevabını iyi bildiğiniz bir istemi her iki sunucuya da gönderin ve iki yanıtı karşılaştırın.
5. Sembolik bağı (symlink) taşıyın, servisi yeniden başlatın ve eski dizini diskte bırakın.

/opt/llama.cpp/b10502/bin/llama-bench -m /srv/models/model-q4_k_m.gguf -p 512 -n 128 -r 5
/opt/llama.cpp/<new tag>/bin/llama-bench -m /srv/models/model-q4_k_m.gguf -p 512 -n 128 -r 5

llama-bench, test başına bir satır yazdırır; bu satırda bir backend sütunu, bir ngl sütunu ve standart sapmayı içeren saniye başına token sayısı sütunu bulunur. Bir derlemenin istem satırını diğerinin üretim satırı ile değil, her iki derlemenin aynı satırlarını birbiriyle karşılaştırın. Farklı istem uzunluklarında alınan bir değer farklı bir ölçümdür; bu nedenle saniye başına token sayısını her seferinde aynı şekilde ölçmek sayının kendisinden daha önemlidir.

Geri alma işlemi iki komuttan oluşur ve yalnızca eski dizin hala orada olduğu için çalışır:

sudo ln -sfn /opt/llama.cpp/b10502 /opt/llama.cpp/current
sudo systemctl restart llama-server

En azından bir önceki derlemeyi saklayın. Bu, yanında bulunan model dosyasının diskte kapladığı alanın çok küçük bir kısmını kaplar.

llama.cpp yükseltmelerinde neler bozulur

Bir model dosyası yüklenemez. İnsanların yükseltme yapmasının temel nedeni genellikle budur: yeni yayınlanan bir model, sabitlenmiş sürümün tanımadığı bir mimari kullanır ve bu nedenle yüklenemez. llama-server başlatma sırasında kapanır ve günlük kaydında bir failed to load model from /srv/models/model-q4_k_m.gguf satırı görünür. Yükleyicinin ne kadar ilerlediğini gösteren, hemen öncesindeki satırları inceleyin. GGUF, başlığında bir biçim sürümü taşır (spesifikasyonun güncel değeri 3'tür ve sürüm 2, uzunluk alanlarını 32 bitten 64 bite genişletmiştir); ancak pratikte bilinmeyen bir mimari adı, biçim sürümü sorunuyla karşılaşmadan çok önce süreci durdurur. Çözüm, seçilmiş ve not edilmiş daha yeni bir etiket kullanmaktır.

Bir sunucu bayrağı yeniden adlandırılır veya kullanımdan kaldırılır. Tanınmayan bir bayrak, llama-server sürecini başlatma sırasında durdurur; bu durum systemd altında sürekli yeniden başlayan bir servis gibi görünür. journalctl -u llama-server -n 50 gerçek hata mesajını gösterir. 19 Ağustos 2026 itibarıyla sunucu belgeleri, -lm, --load-mode lehine --mlock ve --mmap bayraklarını kullanımdan kaldırılmış olarak işaretlemektedir; -lm, --load-mode bayrağı auto, mmap, mlock ve dio gibi değerler alır. GPU offload bayrağı -ngl, --gpu-layers olarak belgelenmiştir, eski kılavuzlarda ise --n-gpu-layers olarak geçer. Sembolik bağı (symlink) taşımadan önce /opt/llama.cpp/<new tag>/bin/llama-server --help komutunu çalıştırın ve unit dosyanızdaki her bayrağı bu komutun çıktısıyla karşılaştırın.

Bir derleme seçeneği yeniden adlandırılır. CMake seçenekleri LLAMA_ önekinden GGML_ önekine taşınmıştır ve kök dizindeki CMakeLists.txt dosyası bu eşlemeyi taşımaya devam etmektedir. LLAMA_CUBLAS kullanımı artık GGML_CUDA seçeneğinin kullanılmasını zorunlu kılan ölümcül bir hatadır; LLAMA_CUDA ve LLAMA_METAL ise uyarı üretir ve sizin yerinize dönüştürülür. Derleme betiğinin yapılandırma adımında durması iyi bir sonuçtur. Sessiz hata ise daha kötüdür: -DGGML_CUDA=ON seçeneğini yanlışlıkla atlarsanız derleme başarılı olur, sunucu başlar ancak her şey CPU üzerinde çalışır. llama-bench bunu anında gösterir, çünkü backend sütununda CPU değeri okunur.

Hızlandırıcı derlemesi taşınabilir değildir. 19 Ağustos 2026 itibarıyla bir derleme etiketine eklenen Linux varlıkları; x64, arm64 ve s390x mimarileri için CPU, Vulkan, SYCL ve OpenVINO varyantlarıdır. Bu listede Linux için CUDA arşivi bulunmamaktadır; bu nedenle NVIDIA sunucusu kullanıyorsanız kaynak koddan derleme yapmanız veya bir container imajı çalıştırmanız gerekir. Windows CUDA arşivleri, araç seti sürümüne göre yayınlanır; bu yararlı bir ipucudur: araç seti sürümü ikili dosyanızı tanımlayan unsurlardan biridir, bu yüzden onu cmake argümanlarınızla birlikte kaydedin.

Bunun yerine container imajını sabitlemek

Aynı kural, farklı bir isim için geçerlidir. Yayınlanan imajlar (ghcr.io/ggml-org/llama.cpp:server ve hızlandırıcı varyantları) değişken isimlere sahiptir; bu nedenle gelecek ay :server çekildiğinde, aynı etiket altında farklı bir program elde edersiniz. Bir kez çekin ve digest değerini okuyun:

docker pull ghcr.io/ggml-org/llama.cpp:server

docker pull bir Digest: sha256:... satırı yazdırır. Bu digest değerini, etiket yerine compose dosyasına yerleştirin; böylece bir sonraki sefer birisi docker compose pull komutunu çalıştırdığında imaj sizin bilginiz dışında değişemez. Önceki digest değerini bir yorum satırında tutun; böylece geri alma işlemi tek bir düzenleme ile gerçekleşir. Bu yöntem, Compose yığını için yükseltme ve geri alma rutini içerisinde diğer tüm servisler için uygulanan yöntemle aynıdır.

Sabitlemenin amacı

Sabitleme (pinning), tam olarak hangi sürümün çalıştığını belirtmenize ve bir değişiklik işleri kötüleştirdiğinde önceki derlemeyi bir dakika içinde geri yüklemenize olanak tanır. llama.cpp, derleme etiketi ve model dosyası olmak üzere iki öğeyi ayrı ayrı sunduğu için bu işlemde bu iki öğeyi takip etmenizi ister. Bunları paket halinde sunan çalışma zamanları farklı davranır ve Ollama ile llama.cpp'nin sunucu olarak karşılaştırılması bu değiş tokuşu ele alır: tüm yapı için tek bir sürüm numarası, kaydedilmesi ve kontrol edilmesi gereken daha az veri anlamına gelir.

FAQ

bNNNN build etiketini mi yoksa v0.x etiketini mi sabitlemeliyim?

Her ikisi de iş görür, yeter ki birini sabitleyin. b10502 gibi build etiketleri uzun süreli takip edilen sürümlerdir: her önceden derlenmiş sürüm arşivi bu etiketle adlandırılır ve çoğu hata raporunda bu etiket referans alınır; bu nedenle bir build numarası, başka bir operatörle karşılaştırma yapmak için en kolay yöntemdir. v0.1.2 gibi sürüm etiketleri ise daha az sayıda, bilinçli olarak belirlenmiş noktalardır ve yılda birkaç kez müdahale ettiğiniz sunucular için uygundur. Seçimden daha önemli olan, etiket dizisinin model dosyasının yanında kayıtlı olması ve yükseltme işleminin git pull sonucunda oluşan bir yan etki değil, bilinçli bir karar olmasıdır.

llama.cpp şu anda anlamsal sürümleme (semantic versioning) kullanıyor mu?

Projenin kendi beyanına göre henüz hayır. v0.1.2 sürüm notları, anlamsal sürümlemenin hala geliştirilme aşamasında olduğunu belirtmekte ve sürüm sıklığı ile yama tanımı gibi konuların tartışıldığı bir ggml başlığına işaret etmektedir. Bir sürüm etiketini, geliştiricilerin işaretlemek için seçtiği bir nokta olarak değerlendirin. Son hanedeki bir değişikliğin doğrudan yükseltme garantisi sunduğunu varsaymayın ve yeni etiketi geçiş yapmadan önce kendi model dosyanızla test edin.

Sunucumun hangi llama.cpp build sürümünü çalıştırdığını nasıl anlarım?

llama-server --version komutu sürüm ve build bilgilerini yazdırır. Başlangıç günlüğü de build numarasını, commit hash değerini ve kullanılan derleyiciyi içeren bir build satırı ile açılır; bu nedenle çalışan bir servis için journalctl -u llama-server komutu bu bilgiyi bulur. Kaynaktan kurulum yapıldıysa, sabitlenmiş checkout içindeki git describe --tags komutu etiketi yazdırır ve readlink /opt/llama.cpp/current komutu servisin aslında hangi dizine işaret ettiğini gösterir.

llama.cpp sürümünü yükselttikten sonra modelim neden yüklenmeyi durdurdu?

Yükseltme sonrasında yaşanan bir yükleme hatası, build ile GGUF dosyası arasındaki uyumsuzluktan kaynaklanır. Günlük dosyası, yolu belirten bir failed to load model from satırı ile biter ve üzerindeki satırlar yükleyicinin ne kadar okuma yaptığını gösterir. İleriye dönük olarak, çok yeni bir model dosyası, mimarisini tanıyan bir build gerektirir. Geriye dönük olarak, dosyanın oluşturulduğu etiketin altına yapılan bir geri alma (rollback), dün çalışan bir dosyayı bozabilir. Sembolik bağı (symlink) önceki build sürümüne yönlendirin, yeniden başlatın ve hangisini değiştireceğinize karar vermeden önce hangi build ve dosyanın doğru şekilde eşleştiğini doğrulayın.

Derleme yapmak yerine sabitleyebileceğim önceden derlenmiş Linux binary dosyaları var mı?

Evet, bazı kurulumlar için mevcuttur. Her build etiketi, 19 Ağustos 2026 itibarıyla arm64, s390x, Vulkan, SYCL ve OpenVINO varyantlarıyla birlikte llama-b10502-bin-ubuntu-x64.tar.gz gibi kendi adını taşıyan sürüm arşivlerine sahiptir. İsimlendirme, etiket dosya adında yer aldığı için sabitlemeyi kolaylaştırır. Bu listede Linux için CUDA arşivi bulunmamaktadır, bu nedenle bir NVIDIA sunucusu için hala -DGGML_CUDA=ON ile kaynaktan derleme yapmak veya CUDA container imajlarından birini çalıştırmak gerekmektedir.