VPS uzerinde llama.cpp sunucusu nasil kurulur?

Ne inşa ediyorsunuz

llama.cpp sunucusunu bir VPS üzerinde çalıştırmak, tek bir GGUF model dosyasını yükleyen ve OpenAI uyumlu bir API üzerinden HTTP isteklerini yanıtlayan llama-server adlı tek bir ikili dosyadan ibarettir. Herhangi bir OpenAI istemcisini http://127.0.0.1:8080/v1 adresine yönlendirdiğinizde sistem çalışır. Kurulum işin kolay kısmıdır.

Geriye kalan iş operasyonel süreçlerdir: bir sürümü sabitlemek, portu localhost üzerinde tutmak, bir systemd birimi yazmak ve sunucunun belleği tükendiğinde ne olacağına karar vermek. Bu kılavuz bunları kapsamaktadır. Eğer henüz iki bariz seçenek arasında karar vermediyseniz, önce Ollama ve llama.cpp arasındaki farkları okuyun; çünkü bu kılavuz, bahsi geçen karşılaştırmanın bilerek dışarıda bıraktığı uygulama adımlarını içermektedir.

Bir sürüm etiketi seçin ve not edin

llama.cpp neredeyse her birleştirme işlemi için bir sürüm etiketi oluşturur, bu nedenle etiketler yapı numaralarıdır. 18 Ağustos 2026 itibarıyla en güncel sürüm b10488'dir. Uzun ömürlü kararlı bir dal bulunmadığından "latest" (en son) ifadesi değişken bir hedeftir ve destekleyebileceğiniz tek sürüm, test ettiğiniz sürümdür. Bir etiket seçin, kaydedin ve aynı dizgiyi klonlama işleminizde, ikili dosya adınızda ve notlarınızda kullanın.

Her etiket ayrıca önceden oluşturulmuş arşivler sunar. Yalnızca CPU kullanan bir x86 VPS için bu llama-b10488-bin-ubuntu-x64.tar.gz'dur; eğer x86 yerine bir ARM VPS üzerindeyseniz, arm64 arşivi de yanında yer alır.

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10488/llama-b10488-bin-ubuntu-x64.tar.gz
tar tf llama-b10488-bin-ubuntu-x64.tar.gz | head

Dosyaların nereye çıkarılacağını bilmek için arşiv içeriğini çıkarmadan önce listeleyin. Bu ikili dosyalar, onları oluşturan imajın C kütüphanesine bağlıdır; bu nedenle eski bir dağıtımda, yüklü olmayan bir GLIBC_ sürümünü belirten bir hata ile başlatma sırasında başarısız olurlar. Küçük bir VPS üzerinde kaynak koddan derleme yapmak birkaç dakika sürer ve bu tür sorunların tamamını ortadan kaldırır; bu nedenle aşağıda izlenen yol budur.

Sabitlenmiş bir etiket kullanarak llama-server derleme

sudo apt update
sudo apt install -y build-essential cmake git libssl-dev
git clone --depth 1 --branch b10488 https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DLLAMA_BUILD_TESTS=OFF -DLLAMA_BUILD_EXAMPLES=OFF
cmake --build build --config Release -t llama-server -j 2

--branch b10488 komutunun bir --depth 1 kopyası üzerinde çalıştırılması, yalnızca o etiketi kontrol eder ve başka hiçbir şeyi değiştirmez; böylece siz çalışırken derleme sürümü değişmez.

libssl-dev gereklidir çünkü LLAMA_OPENSSL seçeneği varsayılan olarak etkindir ve ikili dosyanın daha sonra HTTPS üzerinden model indirmesini sağlayan budur. Başlık dosyaları olmadan yapılandırma adımı başarısız olur.

-DBUILD_SHARED_LIBS=OFF size tek bir bağımsız ikili dosya sağlar. Varsayılan derleme, paylaşılan kütüphaneleri çalıştırılabilir dosyanın yanına koyar; bu nedenle yalnızca çalıştırılabilir dosyayı /usr/local/bin dizinine kopyalamak error while loading shared libraries: libllama.so hatasıyla sonuçlanır.

-t llama-server yalnızca sunucu hedefini derler. Varsayılan derleme diğer araçları ve testleri de derler; bu da iki çekirdekli bir VPS üzerinde, asla çalıştırmayacağınız dosyalar için fazladan birkaç dakika harcanması anlamına gelir.

-j 2 kullanımı bilinçlidir. Her paralel derleme işi kendi çalışma kümesini tutar; bu nedenle küçük bir planda -j $(nproc) kullanmak, derleyiciyi durduran çekirdek bellek yetersizliği (OOM killer) nedeniyle c++: fatal error: Killed signal terminated program cc1plus ile sonuçlanır. İş sayısını düşürün veya derleme için swap alanı ekleyin.

Değiştirmek isteyebileceğiniz bir bayrak: GGML_NATIVE varsayılan olarak etkindir, bu nedenle derleyici derlemeyi yapan CPU'yu hedefler. Derlemeyi çalıştıracak makinede yapıyorsanız istediğiniz budur. Eğer bir kez derleyip ikili dosyayı farklı bir ana bilgisayara kopyalayacaksanız -DGGML_NATIVE=OFF ekleyin; aksi takdirde diğer CPU'nun sahip olmadığı komutları kullanan bir ikili dosya, ilk çıkarım sırasında Illegal instruction (core dumped) hatasıyla çöker.

Dosyayı etiketi içeren bir isimle yükleyin.

./build/bin/llama-server --version
sudo install -m 755 build/bin/llama-server /usr/local/bin/llama-server-b10488
sudo ln -sfn /usr/local/bin/llama-server-b10488 /usr/local/bin/llama-server

--version komutu derleme numarasını ve commit bilgisini yazdırır. Bu, kontrol ettiğiniz etiketle eşleşmelidir. Eşleşmiyorsa, başka bir şey derlemişsiniz demektir. Numarayı dosya adında tutmak ve bir sembolik bağlantıyı (symlink) ona yönlendirmek, yükseltmenin bir ln -sfn ve bir yeniden başlatma ile yapılabilmesi, geri almanın ise aynı komutla eski numaraya dönülmesi anlamına gelir.

Bir GGUF modeli edinin ve önce disk alanını kontrol edin

GGUF, llama.cpp tarafından yüklenen tek dosya biçimidir. Tek bir dosya ağırlıkları, belirteçleyiciyi (tokenizer) ve meta verileri barındırır; bu nedenle kurulacak başka bir bileşen yoktur. Dosya adındaki sonek, ağırlıkların depolandığı hassasiyet seviyesi olan nicelemeyi (quantisation) belirtir: Q4_K_M 4-bit bir karışımdır, Q8_0 8-bit'tir ve f16 niceleme uygulanmamış yarım hassasiyetli dosyadır.

Herhangi bir indirme yapmadan önce bir servis hesabı ve bir model dizini oluşturun.

sudo useradd --system --home /srv/llama --create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
df -h /srv

Sunucu, derlemenizin çalıştığını kanıtlamanın en hızlı yolu olan -hf ile modeli kendi kendine çekebilir.

sudo -u llama env LLAMA_CACHE=/srv/models /usr/local/bin/llama-server \
  -hf ggml-org/gemma-3-1b-it-GGUF:Q4_K_M --host 127.0.0.1 --port 8080

LLAMA_CACHE indirme dizinini belirler. Bu ayar yapılmazsa dosya, komutu çalıştıran hesabın altındaki ~/.cache/llama.cpp dizinine gider; bu, ana dizinini okunamaz hale getireceğiniz bir servis için yanlış konumdur. Önbelleğe alınan dosya adı düz dosya adından ziyade depo adından türetildiği için, sonrasında ls -lh /srv/models komutunu çalıştırın.

Bir servis için, birim dosyasının (unit file) işaret edebileceği kararlı bir yola indirme yapın.

sudo -u llama curl -L --output-dir /srv/models -O \
  https://huggingface.co/ggml-org/gemma-3-1b-it-GGUF/resolve/main/gemma-3-1b-it-Q4_K_M.gguf

Disk alanı, insanların karşılaştığı ilk sınırlamadır. Bunlar, 18 Ağustos 2026 tarihinde kontrol edilen iki modelin yayınlanmış dosya boyutlarıdır.

[
  {
    "label": "gemma-3-1b-it Q4_K_M",
    "size_gb": 0.81
  },
  {
    "label": "gemma-3-1b-it Q8_0",
    "size_gb": 1.07
  },
  {
    "label": "gemma-3-1b-it f16",
    "size_gb": 2.01
  },
  {
    "label": "gpt-oss-20b MXFP4",
    "size_gb": 12.11
  }
]

1B modelin 4-bit dosyası 0.81 GB'tır. Aynı modelin niceleme uygulanmamış hali 2.01 GB'tır; dolayısıyla biçim seçimi rakamı iki kattan fazla değiştirir. MXFP4 formatındaki 20B bir model 12.11 GB'tır; bu boyut birçok giriş seviyesi planda diske sığmaz ve üstelik bu dosyanın belleğe okunması gerekir. Belirli bir aileye odaklanıyorsanız, GLM için aynı boyutlandırma çalışması, daha küçük bir model sığarken ana modelin nasıl hızla bir VPS bütçesini aştığını gösterir.

Her indirmeden önce df -h komutunu kontrol edin. 12 GB'lık bir aktarım sırasında dolan bir kök dosya sistemi, günlük kayıtları (journal) dahil olmak üzere yazma işlemi yapması gereken diğer her şeyi bozar.

Elle bir kez çalıştırın ve kontrol edin

sudo -u llama /usr/local/bin/llama-server \
  --model /srv/models/gemma-3-1b-it-Q4_K_M.gguf \
  --host 127.0.0.1 --port 8080 \
  --ctx-size 4096 --parallel 1 --threads 2 --no-webui

İkinci bir oturumda, sunucuya hazır olup olmadığını sorun.

curl -s http://127.0.0.1:8080/health

Dosya yüklenirken HTTP 503 hatası ve şu gövde içeriğini alırsınız:

{"error":{"code":503,"message":"Loading model","type":"unavailable_error"}}

Sunucu hazır olduğunda gövde içeriği {"status": "ok" } olur. Ardından gerçek bir istek gönderin.

curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"local","messages":[{"role":"user","content":"Say hello in five words."}]}'

choices dizisine sahip bir JSON nesnesi, sunucunun çalıştığını gösterir. model alanı, OpenAI istemcileri tarafından her zaman gönderildiği için mevcuttur. Bu sunucuda tek bir model yüklüdür, bu nedenle değer herhangi bir seçim yapmak için kullanılmaz.

OpenAI uyumlu API ve port üzerindeki diğer öğeler

POST /v1/chat/completions, POST /v1/completions ve POST /v1/embeddings OpenAI uyumlu rotalardır; GET /v1/models ise yüklenen modeli raporlar. GET /health yukarıda belirtilen hazır olma kontrolüdür, GET /props sunucunun mevcut ayarlarını döndürür ve GET /metrics, --metrics ile başlattığınızda Prometheus sayaçlarını dışa aktarır.

Temel URL'yi http://127.0.0.1:8080/v1 olarak ayarlayıp boş olmayan bir API anahtarı dizisi girdiğinizde herhangi bir OpenAI SDK'sı çalışacaktır. Siz kendiniz --api-key ayarını yapana kadar hiçbir şey bu anahtarı kontrol etmez.

Kimsenin verim iddiasını kendi planınız için bir referans olarak almayın. CPU çıkarım hızı; çekirdek sayısına, bellek bant genişliğine ve sunucuyu paylaştığınız komşularınıza bağlıdır; bu nedenle kendi makinenizde saniyedeki token sayısını ölçün ve bu sonucu gerçek veri olarak kabul edin. Gürültülü bir komşudan kaynaklanan steal time, burada saatten saate değişen bir üretim hızı olarak kendini gösterir.

127.0.0.1 üzerinde tutun ve önüne bir proxy yerleştirin

--host halihazırda varsayılan olarak 127.0.0.1 değerindedir, bu nedenle siz değiştirene kadar sunucu dışarıdan erişilemez durumdadır. Bu ayara dokunmayın. llama-server içerisinde bir kullanıcı modeli, hız sınırlaması (rate limit) veya faydalı bir denetim günlüğü (audit log) bulunmamaktadır; tek yerleşik kontrol, bir dizgiyi karşılaştıran --api-key mekanizmasıdır. Açık bir çıkarım (inference) portu, onu bulan herkes için bedava işlem gücü demektir; Ollama ile yapılan aynı hata burada da aynı sonucu doğurur: self-hosted model API'sini güvenli hale getirme rehberi burada satırı satırına geçerlidir.

TLS (transport layer security) sonlandırma işlemini nginx üzerinde yapın ve trafiği loopback portuna yönlendirin.

server {
    listen 443 ssl;
    server_name llm.example.com;

    location /v1/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_read_timeout 600s;
    }
}

proxy_buffering off, akış (streaming) için gereklidir. Tamponlama (buffering) açık olduğunda nginx, yanıt tamamlanana kadar sunucu tarafından gönderilen olayları (SSE) tutar; bu durumda istemci sessizce bekler ve yanıtın tamamını tek seferde alır. proxy_read_timeout 600s, uzun süren üretim süreçlerini kapsar; çünkü 60 saniyelik varsayılan değer, yavaş bir yanıtın 504 Gateway Time-out hatasına dönüşmesine neden olur. Sertifikayı nginx üzerinde Certbot ve Let's Encrypt kullanarak alın.

systemd birimi

/etc/systemd/system/llama-server.service dosyasını oluşturun.

[Unit]
Description=llama.cpp server
After=network-online.target
Wants=network-online.target

[Service]
User=llama
Group=llama
Environment=LLAMA_ARG_MODEL=/srv/models/gemma-3-1b-it-Q4_K_M.gguf
Environment=LLAMA_ARG_HOST=127.0.0.1
Environment=LLAMA_ARG_PORT=8080
Environment=LLAMA_ARG_CTX_SIZE=4096
Environment=LLAMA_ARG_N_PARALLEL=1
Environment=LLAMA_ARG_THREADS=2
ExecStart=/usr/local/bin/llama-server --no-webui
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
MemoryHigh=3G
MemoryMax=3500M
OOMPolicy=stop
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes

[Install]
WantedBy=multi-user.target

Ayarlar Environment= satırlarında tutulur; çünkü llama-server çoğu bayrak için LLAMA_ARG_* değişkenlerini okur ve komut satırı argümanı, eşleşen değişkeni geçersiz kılar. Bu yöntem, bağlam boyutunu değiştirmek için tek bir merkez sağlar ve ExecStart dosyasının bir bakışta okunabilecek kadar kısa kalmasını sağlar.

ProtectSystem=strict, bu birim için tüm dosya sistemini salt okunur hale getirir; sunucu yalnızca modeli okuduğu için bu durum bir sorun teşkil etmez. Servisin -hf ile model indirmesini istiyorsanız ReadWritePaths=/srv/models ayarını ekleyin. ProtectHome=yes, /home ve /root dizinlerini gizler; modelleri /srv içinde tutmanın ikinci nedeni de budur: ProtectHome etkinleştirildiğinde, varsayılan ~/.cache/llama.cpp yolu süreç tarafından hiçbir şekilde görülemez.

sudo systemctl daemon-reload
sudo systemctl enable --now llama-server
systemctl status llama-server
curl -s http://127.0.0.1:8080/health
journalctl -u llama-server -n 50 --no-pager

enable --now, insanların atladığı kısımdır. enable olmadan, sunucu bir sonraki yeniden başlatmadan sonra çalışmayacaktır. Servis çevresinde, yeni bir sürüm için gece yapılan kontroller gibi zamanlanmış işler istiyorsanız, bunun için kullanılacak mekanizma bir systemd servisi ve zamanlayıcıdır.

OOM durumunda ne olacağına önceden karar verin

Bellek kullanımı iki bölümden oluşur ve bir sınır altında farklı davranışlar sergilerler. Model dosyası varsayılan olarak belleğe eşlenmiştir (memory-mapped), bu nedenle sayfaları dosya desteklidir: çekirdek bunları bırakabilir ve gerektiğinde diskten tekrar okuyabilir. Sunucunun her aktif konuşma için tuttuğu token bazlı durum olan KV cache ise anonim bellektir. Bu bellek bırakılamaz, bu yüzden sürecin sonlandırılmasına neden olan şey budur.

Unit dosyasındaki iki sınırın farklı işlevleri olmasının nedeni budur. MemoryHigh=3G yumuşak bir sınırdır: bu sınır aşıldığında çekirdek cgroup üzerinde geri kazanım baskısı oluşturur, böylece eşlenmiş model sayfaları tahliye edilir ve bir sonraki token sırasında diskten tekrar okunur. Servis çalışmaya devam eder ancak yavaşlar. MemoryMax=3500M ise katı bir sınırdır: bu sınır aşıldığında süreç sonlandırılır ve günlük kayıtlarında (journal) bu durum açıkça belirtilir.

llama-server.service: A process of this unit has been killed by the OOM killer.

--ctx-size değerini kendiniz belirleyin. Varsayılan değer 0'tür; bu, modelin eğitildiği bağlam boyutu anlamına gelir ve modern, uzun bağlamlı bir modelde başlangıçta çok büyük bir KV cache ayrılmasına neden olur. Bu durumda servis, tek bir istek bile karşılayamadan sonlanır. --parallel aynı maliyeti çarpar, çünkü her slot kendi konuşma durumunu tutar; bu nedenle eşzamanlılığa ihtiyacınız olduğundan emin olana kadar bu değeri 1'de bırakın.

Restart=on-failure ile sonlandırılan bir servis geri gelir. Eğer her başlangıçta sonlandırılıyorsa, systemd pes eder ve systemctl status üzerinde start request repeated too quickly çıktısını verir. Doğru davranış budur: 12 GB'lık bir dosyayı her beş saniyede bir yeniden okuyan bir yeniden başlatma döngüsü, kesintiden daha kötüdür. Sınırı veya bağlam boyutunu düzeltin, ardından sudo systemctl reset-failed llama-server ile durumu temizleyin.

Bir istek çalışırken systemctl show llama-server -p MemoryCurrent ile gerçek sayıları izleyin. systemd ile süreç belleğini ve CPU'sunu sınırlama konusu, bu yönergeleri daha ayrıntılı olarak ele almaktadır.

Bu iş yükü için swap kullanmaktan kaçının. Swap alanına taşınmış bir model, her token işlemini rastgele ofsetli disk okumalarına dönüştürür. Model dosyasını belleğe eşlemek, çekirdek ihtiyaç duyduğu sayfaları doğrudan dosyadan okuduğu için daha az zararla aynı etkiyi sağlar.

Ollama'nın daha iyi bir seçenek olduğu durumlar

Bu noktada bir yol ayrımındasınız. Belirlediğiniz flag'ler, sabitlediğiniz bir build ve seçtiğiniz bir dosya ile çalışan, arka planda başka hiçbir şey çalışmadığı için yapısı değişmeyen tek bir süreç istediğinizde llama-server tercih edilmelidir.

Model yönetimi istediğinizde ise Ollama tercih edilmelidir: modelleri isimleriyle çekmek, diskte birden fazla model tutmak, boşta kalanları bellekten boşaltmak ve yeniden derleme yapmak yerine tek bir komutla yükseltme yapmak gibi. Bunlar, aksi takdirde kendinizin script yazarak yapmanız gerekecek gerçek iş yükleridir. Ollama'yı bir VPS üzerinde çalıştırmak, aynı işin farklı bir yaklaşımla yapılmasıdır. Her ikisi de OpenAI uyumlu bir API sunduğundan, istemci kodunuz her iki yöndeki geçişte de çalışmaya devam eder.

Sabitlenmiş bir sürümün yükseltilmesi

bNNNNN kısmını geçiş yapacağınız etiket ile değiştirin.

cd llama.cpp
git fetch --tags
git checkout bNNNNN
cmake -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DLLAMA_BUILD_TESTS=OFF -DLLAMA_BUILD_EXAMPLES=OFF
cmake --build build --config Release -t llama-server -j 2
sudo install -m 755 build/bin/llama-server /usr/local/bin/llama-server-bNNNNN
sudo ln -sfn /usr/local/bin/llama-server-bNNNNN /usr/local/bin/llama-server
sudo systemctl restart llama-server

Eski binary dosyası diskte kalmaya devam eder, bu nedenle geri alma işlemi ln -sfn dosyasını llama-server-b10488 konumuna geri döndürmek ve servisi yeniden başlatmaktan ibarettir. Yükseltme yapmadan önce sürüm notlarını okuyun. GGUF dosyaları sürümlüdür ve eskileri yüklenmeye devam eder, ancak flag'ler yeniden adlandırılabilir: --mlock ve --no-mmap, --load-mode lehine kullanımdan kaldırılmıştır; kaldırılmış bir flag'i geçiren bir unit dosyası, tanınmayan argüman hatası vererek başlatma sırasında başarısız olur.

Hata modları ve karşılaşacağınız dizgeler

error while loading shared libraries: libllama.so ikili dosyayı başka bir yere kopyaladıktan sonra oluşur. Varsayılan derleme, paylaşılan kütüphaneleri dosyanın yanında oluşturur. -DBUILD_SHARED_LIBS=OFF ile yeniden derleyin veya tüm build/bin dizinini kopyalayın.

Illegal instruction (core dumped) başlatma sırasında veya ilk istekte oluşur. İkili dosya, üzerinde çalıştığı CPU'dan farklı bir CPU için GGML_NATIVE açık şekilde derlenmiştir. Bu makinede yeniden derleyin veya -DGGML_NATIVE=OFF ile yapılandırın.

c++: fatal error: Killed signal terminated program cc1plus derleme sırasında oluşur. Derleyici, çok fazla bellek kullandığı için sonlandırılmıştır. -j değerini düşürün veya derleme için swap alanı ekleyip işlem sonrasında kaldırın.

curl: (7) Failed to connect ... Connection refused dizüstü bilgisayarınızdan geliyorsa bu normaldir. Sunucu, VPS'in loopback adresi üzerinde dinleme yapmaktadır. Testi doğrudan VPS üzerinde gerçekleştirin veya ssh -L 8080:127.0.0.1:8080 user@your-vps ile bir tünel açıp yerelde http://127.0.0.1:8080 kullanın.

"message":"Loading model" ile HTTP 503 yeniden başlatmanın ardından gelen ilk saniyelerde veya dakikalarda oluşur. Çok gigabaytlık bir dosyanın okunması zaman alır; systemd, model belleğe yüklenmeden çok önce, süreç başladığı anda birimi aktif olarak raporlar.

İstekler askıda kalıyor ve ardından 504 Gateway Time-out dönüyor. Proxy, model işlemi tamamlanmadan önce vazgeçmiştir. proxy_read_timeout değerini yükseltin ve token'ların üretildikçe istemciye ulaşması için proxy_buffering ayarını kapatın.

Birim kararsız çalışıyor ve ardından start request repeated too quickly ile duruyor. Bir şey, her başlatmada süreci sonlandırıyor. OOM killer satırı için journalctl -u llama-server kayıtlarını kontrol edin, ardından --ctx-size değerini düşürün, --parallel değerini düşürün veya MemoryMax değerini yükseltin.

FAQ

VPS üzerinde llama.cpp sunucusunu mu yoksa Ollama mı çalıştırmalıyım?

Tam bir derleme sürümünü sabitlemek, belirli flag değerlerini geçmek ve hiçbir şeyin arka planda güncelleme yapmadığından emin olmak istediğinizde llama-server çalıştırın. Model yönetimi ve tek komutla yükseltme istediğinizde Ollama kullanın; çünkü modelleri isme göre çekmek, diskte birden fazla model tutmak ve boşta kalanları bellekten boşaltmak, aksi takdirde kendinizin betik yazması gereken işlerdir. Her ikisi de OpenAI uyumlu bir API sunduğundan, daha sonra geçiş yapsanız bile istemci kodunuz değişmez.

Hangi llama.cpp sürümünü sabitlemeliyim?

Gerçekten derlediğiniz ve test ettiğiniz herhangi bir etiketi kullanın. llama.cpp neredeyse her birleştirmeyi etiketler ve isimler, 18 Ağustos 2026 itibarıyla en yenisi olan b10488 gibi derleme numaralarından oluşur. Ayrı bir kararlı (stable) dal bulunmadığından, "güncel" sürüm günde birkaç kez değişir. --branch <tag> ile klonlayın, ikili dosyayı bu etiketi içeren bir dosya adı altında kurun ve ona bir sembolik bağ (symlink) yönlendirin; böylece yükseltme ve geri alma işlemleri tek bir komutla yapılabilir.

llama-server ne kadar RAM'e ihtiyaç duyar?

GGUF dosyasının boyutundan başlayın, ardından --ctx-size ve --parallel yuva sayısıyla artan KV önbelleğini ekleyin. Yayınlanan rakamlar kendi kurulumunuzu ölçmenin yerini tutmaz; çünkü toplam ihtiyaç modele, nicemlemeye (quantisation) ve izin verdiğiniz bağlama (context) bağlıdır. Bir istek işlenirken systemctl show llama-server -p MemoryCurrent komutunu çalıştırın ve gördüğünüz rakamı baz alın.

/health uç noktası neden "Loading model" mesajıyla 503 hatası döndürüyor?

Süreç başlamıştır ancak model dosyası henüz belleğe yüklenmemiştir, bu nedenle sunucu {"error":{"code":503,"message":"Loading model","type":"unavailable_error"}} yanıtını verir. Bu, her yeniden başlatmadan sonra normaldir ve dosyanın okunması süresince devam eder. Bu durum yalnızca bir istemci veya proxy, bu ilk 503 yanıtını kalıcı bir hata olarak değerlendirdiğinde sorun yaratır. {"status": "ok" } dönene kadar /health uç noktasını sorgulamaya devam edin.

llama-server'ı doğrudan internete açabilir miyim?

Onu 0.0.0.0 adresine bağlamayın ve portu dış dünyaya açmayın. Hesap yönetimi, hız sınırlaması (rate limiting) veya denetlenebilir bir istek günlüğü yoktur; yerleşik tek güvenlik kontrolü, tek bir dizgiyi karşılaştıran --api-key değeridir. Varsayılan 127.0.0.1 bağlamasını koruyun, önüne TLS ile birlikte nginx koyun ve ayrıca --api-key ayarını yapın; böylece proxy yapılandırmasındaki bir hata, modeli herkese açık hale getirmez.