Day 0'da GPT-OSS
ROSE'u FP8, havuz dikkati ve MoE optimizasyonlarıyla uyarlayarak H200 üzerinde GPT‑OSS için Day‑0 desteği
Perplexity, doğru ve güvenilir yanıtlar ile temsilci eylemleri talep eden meraklı insanlara en iyi AI modellerini sunmayı taahhüt eder. OpenAI yakın zamanda açık ağırlıklı modellerini duyurdu (gpt-oss-20b ve gpt-oss-120b). Birçok lider modelde olduğu gibi Perplexity, gpt-oss-20b ve gpt-oss-120b modellerini değerlendiren ilk kuruluşlar arasındadır.
Bu yazıda, Day-0 desteğini mümkün kılan şirket içi çıkarım yığınımızın altyapı kararlarını paylaşıyoruz. Çekirdek değişikliklerini, dağıtım seçeneklerini ve hız-maliyet ödünleşimlerini detaylandırarak bu modellerin NVIDIA H200 GPU'larda sunulmasına odaklanıyoruz.
Hopper Üzerinde GPT-OSS
Açık ağırlıklı modeller, tüketici sınıfı donanımlardaki belleğe sığmalarına veya NVIDIA Blackwell'de en yüksek iş hacmine ulaşmalarına yardımcı olan MXFP4 nicelemesi kullanılarak gönderilir. Ancak, ilk değerlendirme için bunları minimum çıkarım motoru değişikliğiyle mevcut H200 Hopper kümelemesinde çalıştırmak istedik. Hopper, Blackwell tarafından sunulan özel FP4 tensör çekirdeklerine sahip değildir. Sonuç olarak, özel çekirdek ihtiyacını en aza indirmek ve mevcut donanımı en iyi şekilde kullanmak için modelleri bunun yerine FP8 hassasiyetiyle sunmaya karar verdik.
Üst düzeyde, dönüştürücü (transformer) LLM'ler yapısal olarak basittir:
Girdi yerleştirmesi (Input embedding)
Dönüştürücü katmanları dizisi. Her biri bir dikkat bloğu (attention block) ve yoğun bir MLP veya seyrek bir MoE bloğu içerir.
Çıktı logit projeksiyonu
Yeni bir dönüştürücü modelini devreye alırken, gerekli değişiklikleri belirlemek için mevcut modellerle ne ölçüde eşleştiklerini öğrenmekle öncelikli olarak ilgileniyoruz. OpenAI, modellerine ilişkin genel bir bakışı önceden nazikçe paylaşarak çıkarım kurulumumuzu buna göre ayarlamamıza olanak tanıdı. Modelin oldukça fazla sayıda küçük değişiklik gerektirdiğini gördük.
Dikkat (Attention): Dikkat Havuzlarına Sahip GQA (GQA with Attention Sinks)
Her dikkat başlığının, Softmax'e dahil edilen önceden eğitilmiş bir havuz (sink) parametresi vardır
DeepSeek-V3'e benzer YaRN konumsal kodlaması
Qwen 2'ye benzer şekilde QKV projeksiyonlarının önyargıları (biases) vardır
Çıktı projeksiyonunun önyargısı (bias) var
MLP: Seyrek Uzman Karışımı (Sparse Mixture-of-Expert - MoE)
Çoğu açık ağırlıklı modelden farklı olarak SwiGLU aktivasyon fonksiyonu
Uzman ağırlıkları için Top-K sonrasında Softmax
Uzmanların önyargıları (biases) vardır
Parametre sayısının 100B-200B civarında olmasını bekleyerek şunları yapmaya karar verdik:
Dikkat havuzlarını desteklemek için FlashInfer'ı genişletmek
DeepSeek-V3 model ailesi için halihazırda oluşturulmuş olan MoE uygulamasını yeniden kullanmak
DeepGEMM çekirdeklerini bir önyargı (bias) terimini destekleyecek şekilde genişleterek, niceleme şeması olarak FP8 128x128 blok ölçeklendirmesini seçmek.
Şirket İçi Çıkarım Motoru
Çıkarım çalışmalarımız, şirket içi çıkarım motorumuz ROSE tarafından desteklenmektedir. ROSE'u, yeni modellerin hızlı bir şekilde devreye alınmasını sağlayan esnek bir çerçeve olacak şekilde geliştiriyoruz. Ek olarak, bir modeli ölçekli bir şekilde sunmaya karar verdiğimizde, son teknolojiye ulaşmak için performansı optimize eden ve artıran bir platform sağlar.
ROSE; spekülatif ve MTP kod çözücüler dahil olmak üzere birden fazla kod çözücü aracılığıyla bir modeli yükleyebilen ve bunun için kodu çözülmüş belirteçler (token'lar) üretebilen bir LLM motoru sunar. Modellerin kendileri, niceleme ve paralellik için çeşitli yapılandırma düğümlerini destekleyen özel bir katman kümesinden oluşur. Katmanların altında, bireysel katmanlar tarafından gerçekleştirilen hesaplamaları verimli bir şekilde uygulayan ve birleştiren hem Triton hem de CUDA çekirdeklerini bir araya getirir.
ROSE öncelikle Python ile yazılmıştır ve model tanımlamaları için PyTorch'a dayanır. Python esnek olmamıza ve yeni modellere uyum sağlamamıza olanak tanırken, sunucu ve toplu planlama (batch scheduling) gibi performansa duyarlı bileşenlerin çoğunu Rust'a taşıyoruz.
Yeni bir modeli hayata geçirmek için öncelikle model hiyerarşisini tanımlıyor ve bunun için bir ağırlık dönüştürücü oluşturuyoruz. Tüm ağırlıklar hesaba katıldıktan sonra, en basit TP=1 kullanım durumu için bir ileri geçiş (forward pass) tanımlıyor ve uçtan uca çalıştığından emin oluyoruz. Son olarak, yeni bir kapsayıcı (container) yayınlamadan ve modeli değerlendirme için bir küme üzerinde dağıtmadan önce çeşitli paralellik biçimleri için desteği uyguluyor ve test ediyoruz. Ardından, hem kontrol panellerinden hem de daha ayrıntılı kıyaslamalardan (benchmark) gelen geri bildirimlere güvenerek performans üzerinde yinelemeler yapıyoruz.
ROSE, entegrasyon testleri dışındaki sohbet formatları hakkında çok az bilgiye sahip olarak sayısal belirteçler (token) üzerinde çalışır. Paralel olarak, Harmony belirteç oluşturucusunu (tokenizer) desteklemek ve istekleri girdi belirteç dizilerine doğru bir şekilde eşlemek için çevre altyapıyı ayarlamayı incelemek zorunda kaldık.
GPT OSS modeliyle, kod çözücülerimizde, CUDA grafik donanımlarımızda veya çevre altyapımızda hiçbir değişiklik gerekmediğini gördük; bu da çabalarımızı modelin arkasındaki çekirdeklere ince ayar yapmaya odaklamamıza olanak tanıdı.
GPT-OSS için Çekirdekler
Havuz Dikkat (Sink Attention)
Havuz dikkati (Sink attention), Q ve K çarpımıyla birleştirilen softmax öncesi ek bir önyargı faktörü sunar:
attn = softmax(q @ k^T * sm_scale + sink) * VSaf bir uygulama oldukça basit olsa da FlashInfer gibi verimli dikkat uygulamaları, dikkatin hesaplanmasını hem bağımsız kafalar (heads) üzerinden hem de KV dizi uzunluğu boyunca paralelleştirir. Ek olarak, sayısal kararlılık için Softmax, sayısal kararlılık için en büyük eleman da çıkarılırken çevrimiçi olarak hesaplanır:
softmax(x) = e^x / sum(e^x) = e ^ (x - max(x)) / sum(e ^ (x - max(x))Çevrimiçi uygulama, -inf değerine başlatılan çalışan bir m maksimumunu ve 1 değerine d ölçeğini izledi. Maksimumu mevcut kafanın havuz değerine başlatarak, Softmax'te doğru bir şekilde birikeceğinden emin olurduk. Dikkatin dizi uzunluğu boyunca birden fazla blok halinde bölünmesi durumunda, bu maksimumun yalnızca ilk yığınsa dahil edilmesini sağlamaya özen göstermeliydik.
Ön doldurma (prefill) ve kod çözme (decode) için kullanılan FlashInfer FA2 çekirdek şablonunu havuz parametrelerini içerecek şekilde ayarladık.
MoE
Farklı modellerin MoE katmanı arasındaki temel fark genellikle yönlendirme şemasıdır. Önemli bir değişkenlik bekleyen ROSE, bu çekirdeği Triton'da uygulayarak yeni modellere kolayca uyum sağlamamıza olanak tanır. GPT-OSS durumunda, softmax'i tüm uzmanlar üzerinden hesaplayan bazı DeepSeek tarzı modellerin aksine, yalnızca Top-K seçilen uzmanlar üzerinden softmax gerçekleştirmek için ağırlık puanlamasını ayarlamak zorunda kaldık. Uzman ağırlıklarını bfloat16 hassasiyetinde hesaplamanın doğrusal açıdan kritik olduğunu gördük.
MoE katmanındaki zorluk, önyargı (bias) terimleri için destekten yoksun olan mevcut DeepGEMM çekirdeklerini yeniden kullanma kararımızdan kaynaklanıyordu. Neyse ki zaman içinde bunlarla derinlemesine entegre olarak, bunları özel all-to-all dağıtım çekirdeklerimizle daha iyi bağlamak için değişiklikler yaptık. WGMMA biriktirici (accumulator) yazmaçlarını (registers) bellekten yüklenen önyargı değerlerine başlatarak DeepGEMM'e önyargı desteği ekledik. Bu, bir MN bloğunun işlenmesi sırasında bir kez yapılır, bu nedenle maliyet muhtemelen ihmal edilebilir düzeydedir ve L2 önbelleği (cache) bu değerlere verimli erişim sağlar.
Bu modeller Veri Paralelliğinden (Data Parallelism) kolayca yararlanmadığından, TP'ye özel dağıtım ve birleştirme çekirdeklerini yeniden kullandık. Dağıtıma yapılan girdiler tüm dereceler (ranks) arasında çoğaltılır, böylece dağıtım yerel olarak kullanılabilen uzmanlar için belirteçleri seçer. Birleştirme (Combine), NVLink üzerinden ağırlıklı birikimi gerçekleştirir.
Performans İnce Ayarları
Amacımız modelleri hızlı bir şekilde hayata geçirmek olsa da performansın yine de makul olmasını sağlamak istiyorduk. OpenAI tarafından sağlanan bir referans uygulamaya karşı doğruluğu sağladıktan sonra, çekirdekler arasındaki blok ve iş parçacığı (thread) tahsislerine dikkat ederek varsayılan PyTorch profil oluşturucusunu kullanarak uygulamamızın profilini çıkardık. Yeniden kullandığımız işlevsellik, GPT-OSS modellerinin 2880'inden önemli ölçüde daha büyük olan 7168'lik daha büyük bir gizli boyuta (hidden dimension) sahip modeller için oluşturulmuştu. Daha iyi ızgara (grid) boyutları seçmek ve iş hacmini önemli ölçüde artırmak için çekirdek başlatıcıları özelleştirdik.
Tokenizasyon ve kanallar
Harmony'nin sohbet formatı, konuşmaları yapılandırmak, akıl yürütme içeriğini ve işlev çağrılarını düzenlemek için çeşitli önemli kavramlara sahiptir. Bu formatta her mesaj bir başlık ve içerikten oluşur:
<|start|>{header}<|message|>{content}<|end|>Başlık meta verileri taşır — en önemlisi rol (sistem, geliştirici, kullanıcı, asistan, araç), kanal ve bir araç çağrısı çağrılırken to=functions.<function-name> gibi bir alıcı.
Kanallar (analiz, yorum ve son yanıt gibi) modelin çıktılarını daha şeffaf ve bölümlere ayrılmış hale getirir. Format bu ayrımı zorunlu kıldığı için model, düşünce zincirini (chain-of-thought) üretime sızdırmadan şeffaf bir şekilde akıl yürütebilir (ve hata ayıklama için incelenebilir). Alıcı etiketleri (to= başlıkları), çalışma zamanına (runtime) sonraki yükün hangi aktör tarafından alınması gerektiğini tam olarak söyler; bu ister bir fonksiyon, ister modelin kendisi veya son kullanıcı olsun.
Çıkarım motorumuz ROSE formattan bağımsızdır. Bir girdi belirteçleri (tokens) topluluğu alır ve çıktı belirteçlerini akış (stream) olarak geri gönderir. Çıkarım yığınımızda, girdileri belirteçleştirilmiş bir komut istemine biçimlendirme ve LLM sonuçlarını yapılandırılmış mesajlara geri ayrıştırma görevi, özel JSON API ön uç hizmeti tarafından gerçekleştirilir. Harmony'yi bu ön uca yeni takılabilir bir biçimlendirici/ayrıştırıcı ekleyerek entegre ettik; böylece ön uç sohbet formatı kurallarını, araç çağrılarını ve akışı temiz bir şekilde yönetirken arka ucun değişmeden kalmasına olanak sağladık. Bu endişelerin ayrılması (separation of concerns) mimariyi modüler tutarak yeni formatların, yanıt özelliklerinin minimum arka uç değişikliğiyle hızlı bir şekilde benimsenmesini sağlar.
Maliyet ve Performans
GPT-OSS modellerinin nispeten küçük boyutu göz önüne alındığında, düğümler arası iletişim ek yükünü önlemek için bir çoğaltmanın (replica) dağıtımını tek bir düğümle sınırlandırıyoruz. Uygulamamız uzman paralelliği (EP), veri paralelliği (DP) ve tensör paralelliği (TP) esnek kombinasyonlarını destekler. Optimum dağıtım kurulumunu belirlemek için, 1 ila 128 arasındaki toplu iş boyutlarında (batch sizes) tüm parça stratejisi kombinasyonlarını kıyasladık. Ön Doldurma-Kod Çözme Ayrıştırma (Prefill-Decode Disaggregation) sayesinde, ön doldurma ve kod çözme için performans-maliyet ödünleşimini ayrı ayrı tartışabiliyoruz.
Maliyet tahminleri için, nominal bir H200 piyasa fiyatı olan 3,00$/saat değerini varsayıyoruz (not: bu bizim gerçek GPU fiyatımız değildir).
batch_size=1 ve DP=1 ayarının en iyi ön doldurma performansını sağladığını keşfettik. Farklı TP yapılandırmaları daha sonra ilk belirteç gecikmesi (first-token latency) ile maliyet arasında değişen ödünleşimler sağlar. Aşağıdaki tablolar, çeşitli yapılandırmalar ve girdi uzunlukları için ön doldurma gecikmesini ve milyon girdi belirteci başına maliyeti sunar.
GPT-OSS 120B:
Girdi Uzunluğu | 8192 | 32768 | 65536 | 128000 |
EP1 DP1 TP1 | 0.364s, $0.037 | 2.421s, $0.062 | 7.375s, $0.094 | 23.902s, $0.156 |
EP2 DP1 TP2 | 0.190s, $0.039 | 1.245s, $0.063 | 3.786s, $0.096 | 12.116s, $0.158 |
EP4 DP1 TP4 | 0.165s, $0.067 | 0.900s, $0.092 | 2.449s, $0.125 | 7.165s, $0.187 |
EP8 DP1 TP8 | 0.179s, $0.145 | 0.839s, $0.171 | 2.003s, $0.204 | 5.119s, $0.267 |
GPT-OSS 120B için paralel yapılandırma ve giriş uzunluğuna göre ön doldurma gecikmesi ve milyon giriş tokenı başına maliyet.
GPT-OSS 20B:
Girdi Uzunluğu | 8192 | 32768 | 65536 | 128000 |
EP1 DP1 TP1 | 0.239s, $0.024 | 1.610s, $0.041 | 4.895s, $0.062 | 16.037s, $0.104 |
EP2 DP1 TP2 | 0.127s, $0.026 | 0.833s, $0.042 | 2.522s, $0.064 | 8.143s, $0.106 |
EP4 DP1 TP4 | 0.108s, $0.044 | 0.593s, $0.060 | 1.616s, $0.082 | 4.766s, $0.124 |
EP8 DP1 TP8 | 0.116s, $0.094 | 0.547s, $0.111 | 1.310s, $0.133 | 3.365s, $0.175 |
GPT-OSS 20B için paralel yapılandırma ve giriş uzunluğuna göre ön doldurma gecikmesi ve milyon giriş tokenı başına maliyet.
Kod çözme (decode) için EP4 DP1 TP4'ün çoğu durum için en iyi yapılandırma olduğunu keşfettik. Aşağıdaki dört grafik, 8192 ve 32768 dizi uzunluklarında hem 120B hem de 20B modelleri için kod çözme hızı ile milyon çıktı belirteci başına maliyet arasındaki ödünleşimi göstermektedir.
Daha küçük 20B modelini daha büyük 120B modeli için spekülatif kod çözme (speculative decoding) taslak modeli olarak kullanmayı da değerlendirdik. Ancak, etkinleştirilen parametre sayısı benzer olduğundan (3B'ye karşı 5B) elde edilen hız artışları marjinal düzeyde kaldı.
Kaynakça
Ayrıştırılmış Ön Doldurma ve Kod Çözme (Disaggregated Prefill and Decode)
Spekülasyon Yoluyla Sonar'ı Hızlandırma (Accelerating Sonar Through Speculation)
Çok Düğümlü DeepSeek Dağıtımı ile Daha Düşük Gecikme ve Daha Yüksek İş Hacmi
FlashInfer: LLM Çıkarım Sunumu için Verimli ve Özelleştirilebilir Dikkat Motoru
Dikkat Havuzlarına Sahip Verimli Akış Dil Modelleri
OpenAI Harmony Yanıt Formatı | OpenAI Cookbook
Alıntı
@online{perplexity2025GptOssOnDay0,
author = {{Perplexity} and Nandor Licker and Lequn Chen and Vladimir Zaytsev and Kevin Hu and Lauren Kolm and Jesse Dwyer},
title = {{GPT-OSS on day 0}},
date = {2025-08-08},
url = {https://www.perplexity.ai/hub/blog/gpt-oss-on-day-0}
}