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 tek bir ikili dosya, llama-server, anlamına gelir. 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 iki bariz seçenek arasında henüz karar vermediyseniz, önce Ollama ve llama.cpp arasındaki farklar konusunu okuyun; çünkü bu kılavuz, o karşılaştırmanın kasıtlı olarak 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" 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 bu dizgiyi klonlama işleminizde, ikili dosya adınızda ve notlarınızda kullanın.

Her etiket ayrıca önceden oluşturulmuş arşivler de sunar. Yalnızca CPU kullanan bir x86 VPS için bu arşiv llama-b10488-bin-ubuntu-x64.tar.gz'dur; x86 yerine bir ARM VPS kullanıyorsanız, 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şivi çı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. Kaynaktan derleme işlemi küçük bir VPS üzerinde 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 üzerinde bir --depth 1 klonu, yalnızca o etiketi kontrol eder ve başka hiçbir şeyi değiştirmez; bu sayede siz çalışırken derleme sürümü sapma göstermez.

libssl-dev önemlidir çü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 başına çalışan, bağımsız bir ikili dosya sunar. 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 bilinçli bir tercihtir. Her paralel derleme işi kendi çalışma kümesini tutar; bu nedenle küçük bir planda -j $(nproc) kullanımı, derleyiciyi durduran c++: fatal error: Killed signal terminated program cc1plus yani çekirdek bellek yetersizliği sonlandırıcısı 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; çünkü diğer CPU'nun sahip olmadığı komutları kullanan bir ikili dosya, ilk çıkarım (inference) sırasında Illegal instruction (core dumped) hatasıyla çöker.

Dosyayı etiketi içeren bir isimle kurun.

./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 derleme numarasını ve commit bilgisini yazdırır. Kontrol ettiğiniz etiketle eşleşmesi gerekir. 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 numara üzerinden gerçekleştirilmesi anlamına gelir.

GGUF modeli edinin ve önce diski kontrol edin

GGUF, llama.cpp tarafından yüklenen tek dosya biçimidir. Bir dosya ağırlıkları, belirteçleyiciyi (tokenizer) ve meta verileri barındırır; bu nedenle kurulacak başka bir şey yoktur. Dosya adındaki sonek, ağırlıkların saklandığı hassasiyet derecesi olan nicemlemeyi (quantisation) belirtir: Q4_K_M 4-bit bir karışımdır, Q8_0 8-bit'tir ve f16 nicemlenmemiş 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 getirebilir.

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 ayarlar. Bu ayar olmadan dosya, komutu çalıştıran hesabın altındaki ~/.cache/llama.cpp dizinine gider; bu, ev dizinini okunamaz hale getireceğiniz bir servis için yanlış konumdur. Ardından ls -lh /srv/models komutunu çalıştırın, çünkü önbelleğe alınan dosya adı düz dosya adından ziyade depo adından türetilir.

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, insanların karşılaştığı ilk sınırdır. Bunlar, 18 Ağustos 2026 tarihinde kontrol edilen iki model için 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 model için 4-bit dosya 0.81 GB'tır. Aynı modelin nicemlenmemiş hali 2.01 GB'tır; dolayısıyla biçim seçimi sayıyı iki kattan fazla değiştirir. MXFP4 formatındaki bir 20B model 12.11 GB'tır; bu boyut birçok giriş seviyesi planda diske sığmaz ve üstelik bu dosyanın daha sonra belleğe okunması gerekir.

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ği alınır:

{"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şlatıldığında 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ışır. Siz kendiniz --api-key ayarını yapana kadar anahtar kontrol edilmez.

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 saniye başına token değerini ölçün ve bu sonucu gerçek veri olarak kabul edin. Gürültülü bir komşudan kaynaklanan çalınan zaman (steal time), burada saatten saate değişen üretim hızı olarak kendini gösterir.

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

--host varsayılan olarak 127.0.0.1 adresine bağlıdır, bu nedenle siz değiştirene kadar sunucu dışarıdan erişilemez durumdadır. Bu ayarı değiştirmeyin. llama-server içerisinde kullanıcı modeli, hız sınırlaması (rate limit) veya işe yarar bir denetim günlüğü (audit log) bulunmaz; yerleşik tek kontrol mekanizması olan --api-key ise yalnızca tek bir dizgiyi karşılaştırır. Açık bir çıkarım (inference) portu, onu bulan herkes için bedava işlem gücü demektir; Ollama ile yapılan hatanın aynısı burada da geçerlidir: self-hosted model API'sini güvenli hale getirme rehberi, satırı satırına burada da uygulanmalıdır.

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, sunucu tarafından gönderilen olayları (SSE) yanıt tamamlanana kadar 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ı 504 Gateway Time-out hatasına dönüştürür. Sertifikayı nginx üzerinde Certbot ve Let's Encrypt kullanarak alın.

systemd birimi

/etc/systemd/system/llama-server.service dosyasını yazın.

[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 yer alır; çü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 yapı, 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ına yardımcı olur.

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 kontrolü gibi zamanlanmış işler yapmak istiyorsanız, bir systemd servisi ve zamanlayıcısı bunun için uygun mekanizmadır.

OOM gerçekleşmeden önce ne olacağına karar verin

Bellek kullanımı iki kısımdan oluşur ve bir sınır altında farklı davranışlar sergilerler. Model dosyası varsayılan olarak memory-mapped (bellek eşlemeli) yapıdadır, bu nedenle sayfaları dosya desteklidir: çekirdek bunları silebilir 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 silinemez, bu yüzden sürecin sonlandırılmasına neden olan kısım budur.

Unit dosyasındaki iki sınırın farklı işlevleri olmasının nedeni budur. MemoryHigh=3G bir yumuşak sınırdır (soft limit): bu değerin üzerinde ç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 sert bir sınırdır (hard limit): bu değerin üzerinde süreç sonlandırılır ve journal kayıtlarında 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 alanı ayırır. Bu durumda servis, tek bir istek bile karşılayamadan sonlanır. --parallel aynı maliyeti çarpar, çünkü her yuva 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 tekrar ayağa kalkar. 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 gerçek sayıları systemctl show llama-server -p MemoryCurrent ile izleyin. systemd ile süreç belleğini ve CPU'sunu sınırlama konusu, bu direktifleri 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ı memory-map yapmak, ç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 bir yol ayrımıdır. Ayarladığınız bayraklar, sabitlediğiniz bir derleme ve seçtiğiniz bir dosya ile tek bir süreç çalıştırmak istediğinizde ve arka planda başka hiçbir şey çalışmadığı için hiçbir şeyin değişmeyeceğinden emin olmak istediğinizde llama-server seçilmelidir.

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

Sabitlenmiş bir derlemeyi yükseltme

bNNNNN ifadesini 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 kalır, bu nedenle geri alma işlemi ln -sfn dosyasını llama-server-b10488 konumuna geri yüklemek ve bir kez 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 bayraklar (flags) yeniden adlandırılabilir: --mlock ve --no-mmap, --load-mode lehine kullanımdan kaldırılmıştır ve kaldırılmış bir bayrağı geçiren bir unit dosyası, başlatma sırasında tanınmayan argüman hatası vererek 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 üretir. -DBUILD_SHARED_LIBS=OFF ile yeniden derleyin veya tüm build/bin dizinini kopyalayın.

Illegal instruction (core dumped) başlangıçta 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 gelir. Bu durum normaldir: sunucu, VPS'in loopback adresi üzerinde dinleme yapmaktadır. VPS üzerinde test edin veya ssh -L 8080:127.0.0.1:8080 user@your-vps ile bir tünel açıp yerel olarak 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 dosyayı okumak zaman alır; systemd, birimi süreç başladığı anda aktif olarak raporlar, ancak bu durum modelin belleğe yüklenmesinden çok önce gerçekleşir.

İstekler askıda kalır ve ardından 504 Gateway Time-out döner. Proxy, model işlemi tamamlamadan ö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ışır ve ardından start request repeated too quickly ile durur. Bir şey, her başlatmada süreci sonlandırmaktadır. OOM killer satırı için journalctl -u llama-server dosyası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 otomatik güncellemenin müdahale etmediği tek bir model dosyası tutmak 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 yoktur, bu yüzden "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 bir sembolik bağ (symlink) ile işaretleyin; böylece yükseltme ve geri alma işlemleri tek bir komutla gerçekleştirilebilir.

llama-server ne kadar RAM gerektirir?

GGUF dosyasının boyutundan başlayın, ardından --ctx-size ve --parallel yuva sayısı ile artan KV önbelleğini ekleyin. Yayınlanan rakamlar kendi kurulumunuzu ölçmenin yerini tutmaz; çünkü toplam miktar 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 neden "Loading model" mesajıyla 503 hatası döndürür?

İşlem 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 ile sorgulama yapın.

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 özelliğidir. 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.