Kendi sunucunuzda hangi yapay zeka modelleri çalışır?

Hangi yapay zeka modellerini kendi sunucunuzda barındırabileceğinizi ne belirler

Hangi yapay zeka modellerini kendi sunucunuzda barındırabileceğinize tek bir değer karar verir: sunucudaki RAM miktarı. Model ailesi ve kullanılan framework, ağırlıkların belleğe sığıp sığmadığından ve geriye boş alan kalıp kalmadığından çok daha az önemlidir. Bu yazı, bu hesaplamayı nasıl yapacağınızı açıklar. Bir çalışma zamanı (runtime) kurmak ayrı bir iştir ve Ollama'yı bir VPS üzerinde çalıştırma rehberi içerisinde ele alınmıştır.

Kararı iki maliyet belirler. Ağırlıklar, parametre sayısı ve kuantizasyon ile belirlenen sabit maliyettir. Bağlam penceresi (context window) ise değişken maliyettir; insanlar genellikle bunu unutur ve dün yüklenen bir modelin bugün yüklenmeyi reddetmesiyle karşılaşırlar.

Boyutlandırma aritmetiği: parametre başına bit

Bir model dosyası neredeyse tamamen ağırlıklardan oluşur. Her ağırlık belirli bir bit sayısında saklanır. Kuantizasyon, ağırlıkların eğitildikleri hassasiyetten daha az bit ile saklanması anlamına gelir; bu işlem az miktarda doğruluk kaybına yol açarken ciddi oranda bellek tasarrufu sağlar. Boyut doğrudan bu değerden hesaplanır:

weights in GB = (parameters in billions x bits per weight) / 8

Modeller 16 bit hassasiyetle yayınlanır, bu da milyar parametre başına 2 GB demektir. Bu nedenle neredeyse hiç kimse yayınlanan hassasiyette bir VPS üzerinde çalıştırma yapmaz. Aşağıda, gerçek ortalama ağırlık başına bit değerleriyle birlikte karşılaşacağınız kuantizasyon türleri yer almaktadır:

• Q8_0 ağırlık başına yaklaşık 8.5 bit saklar, yani milyar parametre başına yaklaşık 1.1 GB.
• Q6_K ağırlık başına yaklaşık 6.6 bit saklar, yani milyar parametre başına yaklaşık 0.83 GB.
• Q5_K_M ağırlık başına yaklaşık 5.7 bit saklar, yani milyar parametre başına yaklaşık 0.71 GB.
• Q4_K_M ağırlık başına yaklaşık 4.8 bit saklar, yani milyar parametre başına yaklaşık 0.6 GB.

Hesaplamalarınızda milyar parametre başına 0.6 GB değerini baz alın. Bellek kısıtlı bir sunucuda Q4_K_M mantıklı bir varsayılan değerdir: çoğu görevde 8 bite kıyasla kalite kaybı düşüktür ve dosya boyutu neredeyse yarı yarıyadır. 4 bitin altına inildiğinde kayıp hızla artar; bu nedenle 2 bite sıkıştırılmış 70B bir model, genellikle aynı nesilden 4 bitlik 32B bir modelden daha kötü yanıt verir. Bellek kısıtlıysa, 4 bitin altına düşmek yerine bir alt boyut sınıfına geçin.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

Yukarıdaki ağırlık sütunu, milyar başına 0.6 GB kuralının uygulanmış halidir. Gerçek GGUF dosyaları bu değerin birkaç yüzde yakınına denk gelir, çünkü embedding ve çıktı katmanları diğer katmanlara göre daha yüksek hassasiyette tutulur. 4 bitlik 3B bir model yaklaşık 1.8 GB'tır. 8B bir model 4.8 GB'tır. 32B bir model 19.2 GB'tır ve 70B bir model 42 GB'tır.

Bağlam uzunluğu neden ağırlıklardan daha fazla RAM tüketir?

KV cache (anahtar-değer önbelleği; modelin o anki konuşmadaki her token için tuttuğu dikkat durumu), ikinci maliyet kalemidir. Model yüklendiğinde, talep ettiğiniz bağlam uzunluğuna göre boyutlandırılarak tahsis edilir ve bu uzunlukla doğru orantılı olarak artar.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Ollama'nın varsayılan bağlam ayarında, bu 8B model önbellek için yarım gigabayt harcar. 8192 token değerinde 1 GB tüketir. Model kartında belirtilen 128k bağlam uzunluğunda ise 16 GB harcar ki bu, ağırlıkların üç katından fazladır. 70B modelde durum tam tersidir: 128k bağlamdaki önbelleği 40 GB'dir ve kendi ağırlıklarından daha az yer kaplar. Bunun nedeni, grouped query attention mekanizmasının token başına maliyetin parametre sayısına yakın bir hızda artmasını engellemesidir.

Ollama'nın varsayılan bağlam uzunluğu, yalnızca CPU kullanılan sunucularda 4096 tokendır. GPU mevcut olduğunda ise varsayılan değer VRAM kapasitesine göre seçilir: 24 ile 48 GiB arasında 32k, 48 GiB ve üzerinde ise 256k olarak belirlenir. Bu değeri sunucu üzerindeki OLLAMA_CONTEXT_LENGTH değişkeni ile artırabilir, ardından çalışan bir modelin gerçekte ne kadar aldığını ollama ps içindeki CONTEXT sütunundan kontrol edebilirsiniz. Bu ayarın arkasındaki bellek hesaplamaları num_ctx ve bağlam uzunluğu hakkındaki gönderide detaylandırılmıştır.

Önbellek kullanımını düşürmenin iki yolu vardır. Model kartında belirtilen bağlam uzunluğu yerine, ihtiyaç duyduğunuz bağlam uzunluğunu talep edin; çünkü çoğu sohbet ve kodlama işi 8k ile 32k arasına sığar. Alternatif olarak, önbelleği 8 bite sıkıştırarak boyutunu yarıya indirebilirsiniz; ancak bu işlem uzun bağlam hatırlama başarısında bir miktar kayba neden olabilir.

Yerleşik bir model, bir şey onu bellekten boşaltana kadar RAM'i tutar

Ollama, bir modeli son istekten sonra 5 dakika boyunca bellekte tutar ve ardından boşaltır. Bu varsayılan ayar dizüstü bilgisayarlar için uygundur ancak sunucular için yanlıştır; sunucularda her boşluktan sonra gelen ilk istek, yükleme süresini tekrar beklemek zorunda kalır.

ollama ps
ollama stop qwen3:4b

ollama ps komutu nelerin yerleşik olduğunu listeler; SIZE sütunu ne kadar bellek tutulduğunu, UNTIL sütunu ise sürenin ne zaman dolacağını gösterir. Bir modeli kalıcı olarak sabitlemek için servis üzerinde OLLAMA_KEEP_ALIVE=-1 ayarını yapılandırın. 0 değeri, her yanıt tamamlandığında modeli bellekten boşaltır.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Bir istem gönderin ve on dakika sonra ollama ps komutunu tekrar çalıştırın. Model hala listelenmektedir; tam olarak amaçlanan da budur: kimse kullanmasa bile RAM'i işgal etmeye devam eder. Sabitlenmiş bir model, boş kapasite değildir. 16 GB RAM'e sahip bir VPS üzerinde, 8k bağlam (context) boyutundaki 8B bir model, servis çalıştığı sürece yaklaşık 6 GB yer kaplar. Bu nedenle sunucu boyutunu yalnızca modelin boyutuna göre değil, model ve uygulamanızın toplam ihtiyacına göre belirleyin. Bir modeli bellekte sabitleme konusu, soğuk başlangıç gecikmesine karşı yapılan bu takası detaylandırır.

4 GB VPS üzerinde neler çalışır

İşletim sistemi ve model sunucusu için yaklaşık 1 GB ayırın; bu durumda geriye kabaca 3 GB kalır. Bu, 4096 token bağlamında, 4 bit seviyesinde 1B ile 4B arası bir model demektir. Ağustos 2026 itibarıyla bu sınıfa 3B boyutunda Llama 3.2, 1.7B ve 4B boyutlarında Qwen 3 ile küçük Gemma ve Phi sürümleri girmektedir. Bunları öneri olarak değil, boyut örneği olarak değerlendirin. İsimler birkaç ayda bir değişir ancak matematik değişmez.

Saniyede kabaca 6 ile 14 arası token üretimi bekleyin. Bu kadar küçük modeller dar kapsamlı işlerde iyi performans gösterir: sınıflandırma, etiket çıkarma, kısa özetler oluşturma, bir paragrafı kurum diline göre yeniden yazma. Çok adımlı akıl yürütme ve birden fazla dosyayı kapsayan kod yazma konularında zayıftırlar; hiçbir istem (prompt) tekniği bunu düzeltemez.

Bu seviyedeki hata modu swap kullanımıdır. Model sığmazsa Linux yüklemeyi reddetmez. Bunun yerine belleği diske aktarır (page out); tek bir token üretmek her ağırlığı bir kez okumayı gerektirdiğinden, üretim hızı token başına saniyelere düşer. Model yanıt verirken free -h komutunu izleyin ve vmstat 1 çıktısındaki si ve so sütunlarını gözlemleyin. Üretim sırasında sıfırdan farklı swap in ve swap out değerleri, modelin bu plan için çok büyük olduğu anlamına gelir.

8 ila 16 GB RAM'e sahip bir VPS üzerinde neler çalıştırılabilir

Self-hosted bir modelin genel olarak kullanışlı hale geldiği nokta burasıdır. 8 GB RAM üzerinde, 8k bağlam (context) uzunluğu ile 4 bit seviyesinde yaklaşık 4.8 GB ağırlığa sahip 7B veya 8B bir model çalıştırabilirsiniz. 16 GB RAM üzerinde ise 4 bit seviyesinde yaklaşık 8.4 GB ağırlığa sahip 13B veya 14B bir model çalıştırabilir ya da belleği parametre sayısı yerine hassasiyete harcamayı tercih ederseniz 8B bir modeli 8 bit seviyesinde kullanabilirsiniz.

Buradaki temel kısıt hızdır. CPU üzerinde çalışan 8B bir model saniyede yaklaşık 3 ila 7 token üretirken, 14B bir model saniyede 1.5 ila 3.5 token üretir. Bir insan saniyede yaklaşık 5 ila 10 token okuduğu için, CPU tabanlı bir VPS üzerinde 8B bir model kullanmak, yavaş bir daktilo kullanıcısını izlemek gibidir. Bu durum arka plan görevleri için kabul edilebilir olsa da interaktif sohbetler için yorucudur. Bir VPS üzerinde Qwen 3 8B ve daha büyük modellerle yapılan ölçümlü çalıştırmalar, bu durumun pratikte nasıl göründüğünü ortaya koymaktadır.

32 ila 64 GB VPS üzerinde neler çalışır

4 bit seviyesindeki 32B bir model yaklaşık 19.2 GB yer kaplar; bu nedenle kısa bir bağlam (context) ile 32 GB'lık bir plana sığar, 48 GB veya 64 GB üzerinde ise rahatça çalışır. 4 bit seviyesindeki 70B bir model yaklaşık 42 GB yer kaplar; dolayısıyla herhangi bir önbellek (cache) eklemeden önce 64 GB belleğe ihtiyaç duyar.

Ardından hızı gerçekçi biçimde değerlendirin. CPU üzerinde çalışan bir 32B model saniyede yaklaşık 0.6 ile 1.5 token üretirken, 70B modelde bu değer 0.2 ile 0.5 arasındadır. Bu 70B modelinden 500 token uzunluğunda bir yanıt alınması yaklaşık yirmi dakika sürer. Bu hızda istek genellikle model yanıtı tamamlamadan sonlanır. Bunun nedeni, Ollama'nın önündeki bir istemci veya proxy tarafından tanımlanan zaman aşımının önce devreye girmesidir. context deadline exceeded hatası buradan kaynaklanır. Bunlar toplu işlem araçlarıdır. Belgelerden oluşan bir kuyruğu gece boyunca işleme vermek için kullanıldıklarında hız önemli değildir. Bunları bir sohbet arayüzünün arkasına yerleştirdiğinizde ise hız büyük önem taşır.

Mixture of experts (MoE) yönlendirmesi bu hesaplamayı değiştirir ve öğrenilmesi gereken tek mimari detay budur. Bir MoE modeli, her token'ı ağırlıklarının yalnızca küçük bir kısmından geçirir. Toplam 30B parametreye sahip ve token başına 3B aktif parametre kullanan bir model, 30B'lik bir modelin bellek kapasitesine ihtiyaç duyar ancak 3B'lik yoğun (dense) bir modelin hızına yakın bir üretim yapar; çünkü her token yalnızca aktif uzmanları okur. 32 GB'lık bir sunucuda bu yapıdaki bir MoE, yoğun bir 30B modelden çok daha kullanışlıdır. Akılda tutulması gereken kural şudur: toplam parametreler bellek ihtiyacını, aktif parametreler ise hızı belirler.

CPU çıkarımı gerçekte ne kadar hızlıdır?

Bir token üretmek, aktif ağırlıkların her birinin bellekten bir kez okunmasını gerektirir. Bundan kaçınmanın bir yolu yoktur; dolayısıyla CPU üzerindeki üretim hızı çekirdek sayısına değil, bellek bant genişliğine bağlıdır. Üst sınır bir bölme işlemidir: kullanılabilir bellek bant genişliğinin, ağırlıkların bayt cinsinden boyutuna bölünmesi. Küçük bir paylaşımlı VPS, vCPU'ları üzerinden gerçekçi olarak saniyede 10 ila 25 GB arası hız sunar; bu nedenle 4,8 GB boyutundaki bir model saniyede yaklaşık 2 ila 5 token hızında çalışır.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

Bunlar, tek bir makinenin kıyaslama sonucu değil, sıradan VPS donanımlarında yaygın olarak bildirilen aralıklardır. Elde edeceğiniz değer; bellek nesline, ana makinedeki kanal sayısına ve aynı kaynak için yarışan komşu süreçlerin sayısına bağlıdır. Kendi hızınızı, halihazırda sahip olduğunuz herhangi bir model etiketiyle ölçün:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

Cevap tamamlandıktan sonra yazdırılan özet, eval rate: ... tokens/s ifadesini içeren bir satırla biter. Bu, üretim hızınızdır. Bir oturumun ilk çalışmasını dikkate almayın, çünkü aynı özet içindeki load duration değeri ağırlıkların diskten okunma süresini de içerir. Saniyedeki token sayısını doğru ölçme bölümü, karşılaştırmaya değer bir sonucun nasıl alınacağını açıklar.

Burada iki sonuç insanları şaşırtır. vCPU eklemek kısa sürede faydasını yitirir; çünkü yaklaşık 8 çekirdekten sonra ek çekirdekler aritmetik işlem yapmak yerine belleği bekler. Ayrıca paylaşımlı bir planda aynı komut saatten saate farklı sonuçlar döndürür; bu, yanlış yapılandırdığınız bir şeyden ziyade gürültülü bir komşudan kaynaklanan CPU çalınma süresi ile ilgilidir.

İstemi okumak, cevabı üretmekten farklı bir iştir. İstem işleme süreci hesaplama yoğunlukludur, bu nedenle çekirdek sayısıyla ölçeklenir ve GPU'nun en çok fark attığı nokta burasıdır. Uzun bir belgeyi okumak CPU için dakikalar, GPU için ise saniyeler sürer. Kodlama aracını barındırdığınız bir modele yönlendirdiğinizde çarptığınız ilk engel budur; çünkü her turda, cevabın tek bir token'ı bile gelmeden önce dosya içeriği ve araç tanımları yeniden gönderilir.

GPU eklediğinizde ne değişir

Aritmetik değişmez, sadece uygulandığı havuz değişir. VRAM kesin bir sınırdır, bu nedenle kiralamadan önce neyin sığacağını hesaplayın:

• 8 GB VRAM, kısa bir bağlam (context) ile 4 bitlik bir 7B veya 8B modeli barındırır.
• 16 GB VRAM, gerçek bir bağlam ile 4 bitlik bir 14B modelini veya 8 bitlik bir 8B modelini barındırır.
• 24 GB VRAM, kısa tutulan bir bağlam ile 4 bitlik bir 32B modelini barındırır.
• 48 GB ve üzeri, önbellek ve eşzamanlılık için yer bırakarak 4 bitlik bir 70B modelini barındırır.

Bir model sığmadığında Ollama onu böler: bazı katmanlar GPU üzerinde, geri kalanı CPU üzerinde çalışır. ollama ps, bu bölünmeyi PROCESSOR sütununda 78%/22% CPU/GPU gibi bir ifadeyle raporlar. Bunu bir özellikten ziyade bir uyarı olarak değerlendirin. CPU tarafı hızı belirler, çünkü her token hala o katmanları bekler; bu nedenle katmanlarının dörtte biri CPU üzerinde olan bir model, GPU hızından ziyade CPU hızına çok daha yakın çalışır. İstemediğiniz bir bölünme görürseniz, önce bağlam uzunluğunu düşürün. Sınırı aşan genellikle önbellektir.

Eşzamanlılık, kapasite artırmanın diğer nedenidir. Ağırlıklar eşzamanlı istekler arasında paylaşılır, ancak her aktif istek kendi KV önbelleğine ihtiyaç duyar; bu nedenle 8k bağlamlı bir 8B modelini kullanan on eşzamanlı kullanıcı, ağırlıklara ek olarak 1 GB önbelleğe ihtiyaç duyar. Tek bir self-hosted modelden eşzamanlı kullanıcılara hizmet vermek bölümü, bu tavanın nerede oluştuğunu açıklar.

GPU kiralamanın mantıklı olup olmadığı da bir aritmetik sorusudur ve ayda kaç token ürettiğinize bağlıdır. GPU VPS ile API tokenları arasındaki başa baş noktası bu sayıları içerir.

Kendi sunucunuzda barındıramayacaklarınız

Burada iki farklı engel bulunmaktadır ve hangisiyle karşılaştığınızı bilmek faydalıdır.

Birincisi kapalı ağırlıklardır. Öncü ticari modeller dağıtılmamaktadır; bu nedenle indirilebilecek bir dosya yoktur ve RAM miktarını ne kadar değiştirirseniz değiştirin bu durum değişmez. Arayüz, getirme katmanı, aracı döngüsü ve günlük kayıtları gibi modelin çevresindeki her şeyi kendi sunucunuzda barındırabilirsiniz. Modelin kendisi uzak bir API olarak kalır. Claude modelini kendi sunucunuzda barındırıp barındıramayacağınız konusu bunu tüm detaylarıyla ele almaktadır.

İkincisi ise sadece çok büyük olan açık ağırlıklardır. En büyük açık kaynaklı sürümler, toplamda yüz milyarlarca parametreye sahip uzman karışımı (mixture of experts) tasarımlarıdır. Aynı kural bunlar için de geçerlidir: 4 bit seviyesinde toplam 400B parametreli bir model, herhangi bir önbellek hesaba katılmadan sadece ağırlıklar için yaklaşık 240 GB alana ihtiyaç duyar. Bu, uzmanlaşmış donanım gerektirir ve bu donanımı aylık olarak kiralamak, çoğu kişinin bir yılda API tokenlarına harcadığından çok daha fazlasına mal olur. Kimi sınıfı bir modeli kendi sunucunuzda barındırmanın maliyeti gerçek gereksinimleri adım adım açıklar. Aynı ayrım Ollama'nın kendi kütüphanesinde de görülür; burada GLM 5.2 yalnızca bulut modeli olarak listelenirken bir VPS'e indirilebilen model, onun çok daha küçük bir kardeşidir.

İkisi arasındaki dürüst ayrım şudur: Yük sabit olduğunda ve veriler sunucunuzdan çıkmaması gerektiğinde kendi sunucunuzda barındırın. Yük düzensiz olduğunda veya ihtiyaç duyduğunuz şey öncü modellerin yanıt kalitesi olduğunda token satın alın.

Seçim yapmadan önce mevcut kaynakları kontrol edin

free -h
nproc
lscpu | grep 'Model name'

Planlamanızı total sütununa göre değil, available sütununa ve free -h değerine göre yapın; çünkü total, sistemin halihazırda kullandığı belleği de kapsar. İşletim sistemi ve model sunucusu için yaklaşık 1 GB değerini çıkarın. Kalan miktarı 0,6'ya bölerek 4 bit seviyesinde çalıştırabileceğiniz en yüksek milyar parametre sayısını elde edin. Ardından, hedeflediğiniz bağlam (context) için gereken KV önbelleğini çıkarın. Geriye kalan değer sizin cevabınızdır; model isimlerinden oluşan bir listenin aksine bu yöntem güncelliğini yitirmez.

FAQ

8B bir modeli çalıştırmak için ne kadar RAM gerekir?

4 bit kuantizasyon ile ağırlıklar için yaklaşık 4.8 GB, buna ek olarak bağlam uzunluğunuz için KV önbelleği ve işletim sistemi ile model sunucusu için kabaca 1 GB RAM gerekir. 8192 token bağlam uzunluğunda önbellek yaklaşık 1 GB ek yük getirir; bu nedenle 8 GB'lık bir plan yeterli olurken 4 GB'lık bir plan yetersiz kalır. Model kartında belirtilen tam 128k bağlam uzunluğunu kullanmak isterseniz, sadece önbellek 16 GB yer kaplar ve 32 GB'lık bir plana ihtiyaç duyarsınız.

VPS üzerinde çok sayıda vCPU olmasına rağmen modelim neden yavaş?

Çünkü üretim süreci çekirdek sayısıyla değil, bellek bant genişliği ile sınırlıdır. Her token, aktif ağırlık setinin tamamının RAM'den çekilmesini gerektirir; bu nedenle birkaç çekirdek bellek kanallarını doyurduğunda, geri kalan çekirdekler sadece bekler. Bir diğer yaygın neden ise swap kullanımıdır. Model yanıt verirken vmstat 1 komutu sıfırdan farklı si ve so değerleri gösteriyorsa, ağırlıklar RAM'e sığmıyor demektir. Bu durumda her token'ın bir kısmı diskten servis edilir ve bu işlem beklediğinizden çok daha fazla maliyet yaratır.

Daha uzun bir bağlam penceresi gerçekten daha fazla bellek gerektirir mi?

Evet, bellek kullanımı token sayısı ile doğrusal olarak artar. Tipik bir 8B model, token başına yaklaşık 128 KiB KV önbelleği harcar; bu nedenle 8192 token 1 GB, 131072 token ise 16 GB maliyet oluşturur. Önbellek, konuşma uzadıkça değil, model yüklendiğinde rezerve edilir. Bu yüzden 128k bağlam uzunluğu talep ettiğinizde, gönderdiğiniz her istem sadece 200 token uzunluğunda olsa bile bu bellek miktarı en baştan ayrılır.

Büyük bir modeli 2 bit ile mi yoksa daha küçük bir modeli 4 bit ile mi çalıştırmalıyım?

Daha küçük olan modeli 4 bit ile çalıştırmayı tercih edin. Kalite, 8 bitten 4 bite kadar yavaş, 4 bitin altında ise hızla düşer. Bu nedenle 2 bite sıkıştırılmış 70B bir model, genellikle aynı model nesline ait 4 bitlik 32B bir modelden daha kötü yanıtlar verir. Ağır kuantizasyon, hata mesajı yerine tekrara düşme ve talimatları göz ardı etme şeklinde kendini gösterir; bu da sorunu isteminize bağlamanıza neden olabilir. 4 biti alt sınır olarak kabul edin ve bunun yerine parametre sayısını değiştirin.

Büyük ticari modeller kadar yetenekli bir modeli kendi sunucumda barındırabilir miyim?

Sıradan bir VPS üzerinde hayır. En güçlü açık ağırlıklı modeller yüz milyarlarca parametreye sahiptir; bu da 4 bit seviyesinde, herhangi bir KV önbelleği hesaba katılmadan bile 200 GB'ın üzerinde RAM gerektirir. En güçlü ticari modeller ise zaten dağıtılmamaktadır. Sıradan donanımların başarılı olduğu alan, belirli bir iş için iyi bir 8B veya 32B model çalıştırmaktır; burada dar kapsamlı ve iyi yapılandırılmış küçük bir model, genellikle genel amaçlı bir modelle aynı performansı verir. Eğer en üst düzey kaliteye ihtiyacınız varsa, donanım satın almadan önce API maliyetlerini donanım maliyetleriyle karşılaştırın.