Blog

OpenAI’nın açık ağırlıklı akıl yürütme modeli gpt-oss-120b çalıştırma senaryosu, kısa süre öncesine kadar çok kartlı bir küme gerektiriyordu. Bugün ise model, ağırlıkları doğal olarak 4 bit MXFP4 formatında dağıtıldığı için tek bir 96 GB VRAM barındıran GPU sunucusuna sığabiliyor. Bu rehberde gpt-oss-120b çalıştırma sürecini baştan sona ele alıyor; bellek bütçesinden Ollama ve vLLM kurulumuna, KV cache ayarlarından maliyet karşılaştırmasına kadar pratik adımları paylaşıyoruz.

Modelin tek karta sığması, kurumsal ekipler için önemli bir eşiği kaldırıyor: veri dışarı çıkmadan, kendi altyapınızda, açık ağırlıklı bir akıl yürütme modelini servis edebiliyorsunuz. Ancak işin kolay kısmı modeli indirmek; zor kısmı 96 GB’lık belleği doğru planlamak ve tutarlı bir servis performansı yakalamak.

gpt-oss-120b Nedir ve Tek GPU’ya Nasıl Sığıyor?

gpt-oss-120b, seyrek etkinleştirmeli bir mixture-of-experts (MoE) mimarisi kullanıyor. Toplam parametre sayısı 120 milyar bandında olsa da her token için yalnızca küçük bir uzman alt kümesi etkinleşiyor; pratikte token başına hesaplanan parametre sayısı 5 milyar civarında kalıyor. Bu tasarım iki avantajı birlikte getiriyor: model kapasitesi yüksek kalıyor, buna karşılık çıkarım (inference) maliyeti yoğun bir modele göre çok daha düşük oluyor.

Tek karta sığmanın asıl nedeni ise niceleme tercihi. Model ağırlıkları sonradan kırpılarak değil, üretim aşamasında MXFP4 adı verilen 4 bitlik bir formatta yayınlanıyor. Yani siz indirdiğinizde ekstra bir niceleme adımı çalıştırmıyorsunuz; dosyalar zaten sıkıştırılmış halde geliyor. Bu sayede ağırlıkların toplam ayak izi 60–65 GB bandına iniyor ve 96 GB’lık bir kartta KV cache ile çalışma zamanı rezervine yer kalıyor.

Modelin öne çıkan özellikleri şöyle özetlenebilir:

• Yerel 4 bit ağırlıklar: MXFP4 formatı sayesinde 80 GB sınıfı kartlarda dahi çalıştırma denemesi yapılabiliyor.
• Uzun bağlam: Yaklaşık 131 bin token’a kadar bağlam penceresi destekleniyor; bu da uzun doküman analizi ve kod tabanı incelemesi için uygun zemin hazırlıyor.
• Ayarlanabilir akıl yürütme eforu: Düşük, orta ve yüksek seviyeler arasında geçiş yapılabiliyor. Yüksek seviye daha doğru ama daha uzun yanıtlar üretirken token tüketimini de artırıyor.
• Metin odaklı yapı: Görsel girdi desteği yok; bu da bellek planlamasını öngörülebilir kılıyor.
• Açık ağırlıklar: Kendi sunucunuzda barındırma, ince ayar ve günlük denetim serbestisi sunuyor.

96 GB VRAM Bütçesi: Bellek Nereye Gidiyor?

Çalıştırma sırasında en sık yapılan hata, “kart 96 GB, model 65 GB, geriye 31 GB kalıyor” şeklinde düşünmek. Gerçekte bellek; model ağırlıkları, KV cache, çalışma zamanı rezervi ve aktivasyon tamponları arasında paylaşılıyor. Tipik bir dağılım şu aralıklarda seyrediyor:

Bileşen	Tipik boyut	Açıklama
Model ağırlıkları (MXFP4)	~60–65 GB	Doğal 4 bit dağıtım; yeniden niceleme gerekmez
KV cache	~8–20 GB	Bağlam uzunluğu ve eşzamanlı istek sayısıyla doğru orantılı
Çalışma zamanı rezervi	~2–5 GB	Sürücü, kütüphaneler ve bellek parçalanması
Aktivasyon tamponları	~2–4 GB	Parti (batch) boyutu büyüdükçe artar
Toplam	~72–90 GB	96 GB’lık kartta güvenli hareket alanı bırakır

Bu tablodan çıkan pratik sonuç şu: uzun bağlam ile yüksek eşzamanlılık aynı anda hedeflendiğinde bellek hızla daralır. 80 GB sınıfı bir kartta model açılır, ancak bağlamı 32 bin token civarına çekmeniz ve eşzamanlı istek sayısını düşük tutmanız gerekir. 96 GB sınıfı kart ise gerçek anlamda rahat bir çalışma alanı sunar. GPU kaynaklarını esnek kiralamak ile sabit sunucu arasındaki tercihi GPU VPS mi saniye bazlı GPU bulutu mu daha ekonomik başlıklı yazımızda ayrıntılı kıyaslamıştık.

Donanım ve Yazılım Önkoşulları

Kuruluma geçmeden önce ortamın hazır olduğundan emin olmak, sonradan yaşanacak saatlerce süren hata ayıklamanın önüne geçer.

• GPU: 96 GB VRAM. Sürücünün NVIDIA CUDA 12.x ile uyumlu güncel bir sürüm olması beklenir.
• Disk: Model dosyası tek başına 60 GB’ı aşar. En az 150 GB NVMe alan ayırın; yavaş disk, ilk yükleme süresini dakikalardan saatlere çıkarabilir.
• RAM: 32 GB sistem belleği alt sınır; 64 GB daha rahat bir deneyim sunar.
• Konteyner altyapısı: Docker ve NVIDIA Container Toolkit, hem vLLM hem de yalıtılmış denemeler için pratiklik sağlar.
• Ağ: Modeli sunucuya aktarırken yüksek indirme hızı, toplam süreyi doğrudan belirler.

Bu gereksinimlerin tamamını karşılayan bir VPS hosting hizmeti üzerinde çalışmaya başlamak, kurulum öncesi donanım tedarik sürecini ortadan kaldırır. Yoğun ve kesintisiz çıkarım planlıyorsanız, GPU kaynaklarını tek kiracı olarak ayırabildiğiniz dedicated server seçenekleri daha öngörülebilir bir performans eğrisi çizer.

Ollama ile Hızlı Kurulum

Modeli ilk kez denemek, yanıt kalitesini ölçmek ve prompt tasarımı yapmak için en kısa yol Ollama’dır. Adımlar sade:

1. Sürücüyü doğrulayın. nvidia-smi komutu kartı ve sürücü sürümünü hatırlamalı, bellek miktarı 96 GB görünmelidir.
2. Ollama’yı kurun. Resmî kurulum betiği tek komutla servisi ayağa kaldırır.
3. Modeli çekin. ollama pull gpt-oss:120b komutu ağırlıkları indirir. İndirme boyutu nedeniyle ilk seferde sabırlı olmak gerekir.
4. Etkileşimli test edin. ollama run gpt-oss:120b ile terminal üzerinden doğrudan konuşabilirsiniz.
5. API üzerinden doğrulayın. Yerel uç noktaya basit bir istek göndererek yanıt süresini ölçün.

curl http://localhost:11434/api/generate -d '{"model":"gpt-oss:120b","prompt":"Sunucu bellek planlamasını üç maddede açıkla","stream":false}'

Ollama, arka planda llama.cpp tabanlı bir çalışma zamanı kullanır ve tek kullanıcılı senaryolarda oldukça pratiktir. Buna karşılık sürekli batching, ayrıntılı metrik ve ince ayarlı bellek yönetimi gibi üretim gereksinimlerinde sınırlı kalır. Ayrıca servisin dış dünyaya açılması planlanıyorsa, ters proxy arkasına alınması ve kimlik doğrulama eklenmesi şart. Bu tür bir yapıyı VPS üzerinde Docker ile Nginx Proxy Manager kurulumu yazımızdaki adımlarla hızlıca kurabilirsiniz.

vLLM ile Üretim Seviyesi Servis

Modeli bir uygulamaya, ajana veya iç araca bağlayacaksanız vLLM daha doğru tercih. PagedAttention ile KV cache’i sayfa mantığında yönettiği için aynı donanımda belirgin biçimde daha fazla eşzamanlı istek kaldırabiliyor.

docker run --gpus all -p 8000:8000 vllm/vllm-openai:latest --model openai/gpt-oss-120b --max-model-len 32768 --gpu-memory-utilization 0.92

Kurulumda dikkat edilecek noktalar:

• Sürüm uyumu: MXFP4 desteği görece yeni sürümlerde olgunlaştı; imaj etiketini sabitleyin ve güncellemeleri kontrollü yapın.
• Bellek oranı: --gpu-memory-utilization değerini 0,90–0,95 aralığında tutmak, sürücü kaynaklı ani bellek açığı hatalarını engeller.
• Bağlam sınırı: --max-model-len değeri doğrudan KV cache rezervini belirler. Kullanım senaryonuz 32 bin token’ı geçmiyorsa 131 bini açık bırakmak gereksiz bellek tüketimidir.
• Çoklu kart: 2×48 GB gibi bir yapıda --tensor-parallel-size 2 ile modeli bölebilirsiniz; ancak kartlar arası bant genişliği gecikmeyi etkiler.
• API uyumu: Servis, OpenAI uyumlu /v1/chat/completions uç noktası sunduğu için mevcut istemci kodunuzu büyük ölçüde değiştirmeden taşıyabilirsiniz.

Ollama mı vLLM mi: Karar Tablosu

Ölçüt	Ollama	vLLM
Kurulum kolaylığı	Tek komut	Konteyner ve parametre yapılandırması
Eşzamanlı istek kapasitesi	Sınırlı	Sürekli batching ile yüksek
Bellek verimliliği	Orta	PagedAttention ile yüksek
Gözlemlenebilirlik	Temel	Metrik uç noktası ve ayrıntılı günlükler
Uygun senaryo	Prototip, tek kullanıcı, test	Çok kullanıcılı API servisi

KV Cache, Bağlam ve Eşzamanlılık Ayarı

Üretimde kararlılığı belirleyen en önemli değişken, aynı anda kaç isteğin ve ne kadar bağlamla işleneceğidir. KV cache büyüklüğü kabaca bağlam uzunluğu, eşzamanlı istek sayısı ve model katman yapısıyla ilişkilidir. Bu nedenle 131 bin token’lık teorik sınırı her senaryoda açık bırakmak doğru değildir.

• Kısa sohbet ve destek botu: 8 bin–16 bin token bağlam genellikle yeterlidir; bu aralıkta daha yüksek eşzamanlılık yakalanabilir.
• Doküman analizi: 32 bin token bağlam dengeli bir başlangıçtır. Daha uzun metinler için istekleri parçalayıp özetleme katmanı eklemek maliyeti düşürür.
• Kod tabanı inceleme: 32 bin–64 bin token aralığı kullanılabilir; ancak yanıt süresi ve bellek tüketimi belirgin şekilde artar.
• Toplu çıkarım: Batch boyutu büyüdükçe aktivasyon tamponları ve KV cache baskısı artar. Bellek kullanımını izleyerek güvenli üst sınırı deneysel olarak belirleyin.

Pratik bir yaklaşım, --gpu-memory-utilization değerini 0,90 civarında tutup --max-model-len değerini gerçek ihtiyaca göre daraltmaktır. Böylece sürücü rezervi korunur ve ani bellek açığı hatalarının önüne geçilir.

Performans Ölçümü ve Beklentiler

Tek GPU üzerinde gpt-oss-120b, seyrek etkinleştirme sayesinde beklenenden iyi bir token/sn değeri sunabilir; ancak performans yalnızca modele bağlı değildir. İstek uzunluğu, çıktı uzunluğu, eşzamanlılık, kullanılan çalışma zamanı ve sürücü sürümü sonucu doğrudan etkiler.

• İlk token gecikmesi: Uzun promptlarda artar; özellikle 32 bin token üzeri bağlamda belirginleşir.
• Token üretim hızı: Kısa bağlamda daha yüksek, uzun bağlamda daha düşüktür.
• Eşzamanlı istekler: vLLM ile sürekli batching sayesinde toplam verim artar; buna karşılık tek istek gecikmesi yükselebilir.
• Akıl yürütme eforu: Yüksek seviye daha uzun çıktı ürettiği için toplam süreyi ve token maliyetini artırır.

Ölçüm yaparken sabit bir prompt seti kullanın; ortalama gecikme, 95. yüzdelik gecikme ve saniyedeki token sayısını ayrı ayrı kaydedin. Bu üç metrik, kapasite planlamasında tek başına ortalama değerden daha güvenilirdir.

Maliyet ve Kaynak Seçimi

Tek GPU’da gpt-oss-120b çalıştırmak, çok kartlı kümelere göre donanım maliyetini ciddi biçimde düşürür. Yine de toplam maliyet yalnızca GPU saat ücretinden ibaret değildir; disk, ağ trafiği, yedekleme, izleme ve bakım da hesaba katılmalıdır.

• Deneysel kullanım: Saniye bazlı veya kısa süreli GPU kiralama daha ekonomik olabilir.
• Kesintisiz servis: Sabit faturalı GPU VPS veya dedicated server, öngörülebilir maliyet ve performans sunar.
• Yoğun üretim: Tek kiracılı sunucu, gürültülü komşu etkisini azaltır ve kapasite planlamasını kolaylaştırır.
• Depolama: Model dosyaları ve günlükler için NVMe disk ayırmak, yükleme ve yanıt sürelerini iyileştirir.

Kısa süreli testlerden üretime geçerken kaynakları kademeli artırmak, hem maliyeti hem de operasyonel riski düşürür.

Güvenlik ve Üretim Kontrolleri

Modeli kendi altyapınızda çalıştırmak veri gizliliği açısından avantaj sağlar; ancak servis güvenliği ayrıca ele alınmalıdır.

• Kimlik doğrulama: API uç noktasını mutlaka token veya ters proxy katmanında kimlik doğrulama ile koruyun.
• Ters proxy: Nginx veya benzeri bir proxy ile TLS sonlandırma, hız sınırlama ve erişim günlüğü ekleyin.
• İzleme: GPU belleği, sıcaklık, gecikme ve hata oranlarını sürekli izleyin.
• Güncelleme: Sürücü, konteyner imajı ve kütüphane sürümlerini kontrollü biçimde güncelleyin.
• Yedekleme: Özel prompt şablonları ve yapılandırma dosyalarını sürüm kontrolünde tutun.

Sık Karşılaşılan Hatalar ve Çözümleri

• CUDA out of memory: Bağlam uzunluğunu düşürün, --gpu-memory-utilization değerini azaltın veya eşzamanlılık sınırını daraltın.
• Model yüklenmiyor: Disk alanını, indirme bütünlüğünü ve çalışma zamanının MXFP4 desteğini kontrol edin.
• Yavaş ilk yanıt: Modelin soğuk yükleme yaptığını doğrulayın; disk hızını ve ağ gecikmesini inceleyin.
• API bağlantı hatası: Konteyner port eşlemesini, güvenlik duvarı kurallarını ve ters proxy yapılandırmasını kontrol edin.
• Tutarsız çıktı: Sıcaklık, top-p ve akıl yürütme eforu ayarlarını sabitleyip testleri aynı koşullarda tekrarlayın.

Sonuç

gpt-oss-120b, MXFP4 ağırlıkları ve seyrek MoE yapısı sayesinde tek bir 96 GB GPU üzerinde çalıştırılabilecek pratik bir açık model haline geldi. Hızlı denemeler için Ollama, çok kullanıcılı üretim servisleri için vLLM öne çıkıyor. Başarılı bir kurulumun anahtarı ise modeli indirmekten çok, bellek bütçesini, bağlam uzunluğunu ve eşzamanlılık sınırını gerçek kullanım senaryosuna göre planlamak.

Kendi altyapınızda çalıştırarak veri gizliliğini koruyabilir, maliyeti öngörülebilir hale getirebilir ve modeli iç uygulamalarınıza güvenli biçimde bağlayabilirsiniz. Doğru donanım ve yazılım yapılandırmasıyla tek GPU VPS, gpt-oss-120b için gerçekçi ve sürdürülebilir bir çalışma ortamı sunar.