Blog
Model Eğitimi

GPT-OSS 20B Eğitimi: Unsloth, A100 ve Hopper Uyumluluğu

S_aux hatasının attention backend kaynaklı teşhisi, FA2/FA3/FA4 ayrımı, MoE PEFT adapter sorunları ve A100 için güvenli fallback yaklaşımı.

DEHA Araştırma22 Temmuz 202618 dk okuma

GPT-OSS 20B, açık ağırlıklı ve Mixture-of-Experts (MoE) yapısına sahip bir dil modelidir. Model kartında toplam parametre sayısı yaklaşık 21 milyar, token başına etkin parametre sayısı ise yaklaşık 3,6 milyar olarak verilir. Bu nedenle modeli yalnızca “20 milyar parametreli yoğun bir Transformer” gibi değerlendirmek doğru değildir. Expert yönlendirmesi, attention düzeni, quantization ve seçilen GPU kernel'ı birlikte düşünülmelidir.

Bu yazı, GPT-OSS 20B'yi Unsloth ile yüklerken A100 üzerinde görülen S_aux is currently only supported for Hopper GPUs hatasını ve aynı süreçte karşılaşılabilen PEFT adapter uyumsuzluklarını inceliyor. Önemli ayrım şudur: GPT-OSS 20B'nin A100'de çalışması imkansız değildir; ancak bazı optimize attention yolları A100'ün desteklemediği Hopper'a özel kernel'ı seçebilir.

Kısa teşhis

Hata çoğu zaman model ağırlığından değil, Unsloth/Transformers/FlashAttention/Triton katmanlarının donanım capability'sine göre seçtiği yürütme yolundan çıkar. A100 Ampere ailesindedir; H100/H200 Hopper ailesindedir. FA3'ün Hopper'a özel bölümleri A100'de çalışmaz. Optimize yol devre dışı bırakıldığında model daha genel ve yavaş bir attention/inference yoluna düşebilir.

1 GPT-OSS 20B nasıl bir model?

OpenAI'nin açıklamasına göre GPT-OSS serisi MoE Transformer mimarisi kullanır. 20B modeli yaklaşık 21B toplam parametreye sahipken her token için bunların daha küçük bir bölümü etkinleşir. Mimari; alternatif dense ve locally banded sparse attention düzenleri, grouped multi-query attention ve 128K'ya kadar context desteği taşır (OpenAI, gpt-oss mimarisi).

Bu özellikler teorik hesap maliyetini azaltabilir; fakat yazılım katmanının her GPU'da aynı kernel'i kullanacağı anlamına gelmez. MoE expert ağırlıklarının paketlenmesi, sink attention değerlerinin işlenmesi ve düşük hassasiyetli MXFP4 yolları; model loader, Transformers sürümü, Triton, FlashAttention ve GPU capability ile birlikte test edilmelidir.

2 A100, Ada ve Hopper arasındaki fark

AileÖrnekPratik anlam
AmpereNVIDIA A100Olgun CUDA ekosistemi; birçok genel kernel ve FA2 yolu için uygun.
Ada LovelaceL40S, RTX 4090Yeni Tensor Core yetenekleri; backend desteği kernel ve sürüme göre değişir.
HopperNVIDIA H100, H200TMA ve asenkron Tensor Core özellikleri; FA3'ün hedeflediği ana platform.
BlackwellB100, B200 ve türevleriYeni kernel ve runtime sürümlerinde ayrı capability/test matrisi gerekir.

Buradaki “yeni H mimarisi” ifadesi pratikte Hopper'ı anlatır. Ancak donanım adından doğrudan “model çalışır” sonucu çıkarılamaz. Aynı GPU modeli üzerinde CUDA, PyTorch, Triton, FlashAttention wheel'i ve Unsloth release'i sonucu değiştirebilir.

3 FlashAttention 2, 3 ve 4

FlashAttention, attention hesabını aynı matematiksel sonucu daha az gereksiz GPU belleği erişimiyle üretmek üzere tasarlanmış IO-aware bir algoritma ailesidir. FlashAttention-3, Hopper'ın Tensor Memory Accelerator ve asenkron Tensor Core özelliklerinden yararlanacak şekilde geliştirilmiştir (NVIDIA, FlashAttention-3).

“GPT-OSS FA2'yi desteklemiyor” cümlesi bu nedenle fazla geneldir. Daha doğru ifade şudur: GPT-OSS'nin bazı attention özellikleri için kullanılan belirli optimize backend, FA3/Hopper yolunu zorunlu kılabilir; bu yol A100'de çalışmaz. Modelin saf PyTorch, uygun SDPA, farklı Triton yolu veya başka bir serving engine ile çalışması ayrı bir sorudur. FA4 için de aynı kural geçerlidir: destek, modelden çok kullanılan release ve donanım-kernel matrisine bağlıdır.

4 S_aux hatası ne anlatıyor?

RuntimeError: S_aux is currently only supported for Hopper GPUs

Bu mesaj, modelin giriş verisinin hatalı olduğunu veya LoRA ağırlıklarının bozuk olduğunu söylemez. S_aux, seçilen attention uygulamasına verilen yardımcı sink/attention bilgisini işleyen bir çalışma yolu olarak düşünülebilir. Hata, bu yolun mevcut backend tarafından yalnızca Hopper GPU'larda uygulandığını belirtir.

Teşhis sırası “A100 yetersiz” demekle bitmemelidir. Önce hangi attention implementation'ın seçildiği,torch.cuda.get_device_capability() sonucu, FlashAttention/Triton sürümü ve Unsloth'un model patch'inin hangi backend'e yönlendirdiği incelenmelidir.

5 Unsloth neden bu yola düşebiliyor?

Unsloth, standart Transformers yürütmesini hızlandırmak için model forward, loss, backpropagation, gradient checkpointing ve kernel seçimlerine müdahale edebilir. Bu optimizasyonlar doğru donanımda ciddi hız ve bellek avantajı sağlar; fakat capability'si desteklenmeyen bir backend seçildiğinde hata daha teknik bir noktada görünür.

GPT-OSS repository'si de referans PyTorch uygulaması ile optimize Triton uygulamasını ayrı yollar olarak sunar. Reference implementation doğruluk ve açıklık için daha genel işlemler kullanırken Triton yolu MXFP4 ve attention optimizasyonlarıyla performansa odaklanır (OpenAI gpt-oss repository). Bu iki yolun aynı GPU ve sürüm kombinasyonunda aynı davranması beklenmemelidir.

6 A100 üzerinde güvenli fallback

İlk amaç performans rekoru değil, modelin doğru ve tekrarlanabilir şekilde yüklenmesidir. Sorun optimize attention seçiminden çıkıyorsa aşağıdaki environment değişkenleri Unsloth'un compile/optimize yolunu devre dışı bırakıp daha genel bir yürütme yoluna geçmeyi sağlayabilir:

import os

# Unsloth/TorchDynamo'nun uyumsuz optimize yolunu kapat
os.environ["UNSLOTH_COMPILE_DISABLE"] = "1"
os.environ["TORCHDYNAMO_DISABLE"] = "1"
os.environ["PYTORCH_CUDA_ALLOC_CONF"] = "expandable_segments:True"

import torch
from unsloth import FastLanguageModel

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="openai/gpt-oss-20b",
    max_seq_length=1024,
    load_in_4bit=True,
    dtype=None,
    device_map={"": 0},
    gpu_memory_utilization=0.72,
    full_finetuning=False,
    fast_inference=False,
)

FastLanguageModel.for_inference(model)

Bu ayarlar her environment'ta sihirli bir çözüm değildir. Bazı sürümlerde değişkenler import'tan önce okunur; bu nedenle environment ayarları Unsloth veya ilgili runtime import edilmeden önce yapılmalıdır. Fallback hız, bellek ve context kapasitesini düşürebilir; çalışan konfigürasyon paket sürümleri ve GPU bilgisiyle lock edilmelidir.

7 PEFT neden doğrudan yüklemede kırılabilir?

Klasik dense Transformer katmanlarında LoRA genellikle nn.Linear modüllerine uygulanır. PEFT bu modülün forward davranışını sararak temel dönüşüme düşük-rank bir güncelleme ekler:

y = W x + B A x

MoE modellerinde expert projection'ları her zaman ayrı nn.Linear nesneleri değildir. Bazı Transformers implementasyonlarında gate_up_proj ve down_proj çok boyutlu ham nn.Parametertensörleri olarak tutulur. Ham parametrenin kendi forward metodu olmadığı için module-level injection yolu burada yeterli olmaz.

Güncel PEFT dokümantasyonu bu durumda target_parameters kullanılabileceğini açıkça belirtir. Örnek:

from peft import LoraConfig

config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    target_parameters=[
        "mlp.experts.gate_up_proj",
        "mlp.experts.down_proj",
    ],
    task_type="CAUSAL_LM",
)

Bu ayar modelin gerçek parameter isimleriyle doğrulanmalıdır; her GPT-OSS/Transformers revision'ında isimlerin aynı olduğu varsayılmamalıdır. Güncel PEFT target_parameters desteği sunsa da eski environment'lar veya Unsloth'a özgü adapter config'leri aynı adapter'ı standart PeftModel.from_pretrained yolunda yeniden kuramayabilir (Hugging Face PEFT LoRA dokümantasyonu).

8 Unsloth loader ile saf PEFT loader aynı değildir

Unsloth loader, GPT-OSS mimarisini, expert parameter'larını ve kendi adapter metadata'sını tanıyabilir. Saf Transformers + PEFT loader ise base modelin güncel module/parameter yapısına güvenir. Base revision, tokenizer boyutu, adapter config, target parameter isimleri ve quantization tipi eşleşmiyorsa adapter hiç yüklenmeyebilir veya eğitimdeki modelle aynı çıktıyı üretmeyebilir.

Bu nedenle “PEFT GPT-OSS desteklemiyor” demek de artık doğru değildir. Doğru ifade şudur: kullandığınız PEFT sürümü, adapter formatı ve base model yapısı parameter-level MoE LoRA'yı aynı şekilde yeniden kuramıyor olabilir.

9 Adapter merge neden deployment için önemlidir?

Expert parametrelerine doğrudan LoRA uygulandığında PEFT bazı inference adımlarında expert başına LoRA katkısını materialize edebilir. Her token yalnızca az sayıda expert'i etkinleştirse bile bu ek yol gecikme oluşturabilir. Güncel PEFT dokümantasyonu MoE parameter targeting sonrası inference overhead'ini azaltmak için adapter'ı merge etmeyi önerir.

# Adapter doğru ortamda doğrulandıktan sonra
model = model.merge_and_unload()
model.save_pretrained("gpt-oss-20b-merged")
tokenizer.save_pretrained("gpt-oss-20b-merged")

Merge ilk adım olmamalıdır. Önce adapter-only modelin çıktısı, ardından merge edilmiş modelin çıktısı aynı sabit prompt ve eval setiyle karşılaştırılmalıdır. Quantized base üzerinde merge, dtype ve export yolu ayrıca test edilmelidir; “checkpoint dosyası oluştu” tek başına doğrulama değildir.

10 İki hata sınıfını ayırmak

HataKırılan katmanDoğru yaklaşım
S_aux ... HopperAttention backend / GPU capabilityHopper-only yolu kapat, A100 uyumlu fallback seç.
Expected nn.LinearPEFT adapter injectionMoE parameter hedeflerini ve PEFT sürümünü doğrula.
EmptyLogitsUnsloth output / evaluationLoss, logits ve metric yolunu birbirinden ayır.
Shape mismatchTokenizer veya embedding artifact'iBase revision, tokenizer ve embedding boyutunu eşleştir.

Bu hataları tek bir “Unsloth bozuk” başlığı altında toplamak teşhisi zorlaştırır. İlk hata GPU kernel seçimiyle, ikinci hata adapter'ın nereye enjekte edildiğiyle, üçüncü hata Trainer'ın model çıktısını nasıl topladığıyla ilgilidir.

11 A100 üzerinde sistematik smoke test

Uzun eğitime geçmeden önce şu zincir çalıştırılmalıdır:

  1. GPU capability: GPU adı, compute capability, CUDA ve PyTorch sürümünü kaydet.
  2. Base load: Adapter olmadan kısa ve deterministik bir prompt üret.
  3. Adapter load: Trainable parametre sayısını yazdır ve forward'u çalıştır.
  4. Loss/backward: Tek batch üzerinde finite loss ve sıfır olmayan adapter gradient'i doğrula.
  5. Generation: torch.inference_mode() içinde kısa çıktı al.
  6. Save/reload: Yeni process'te adapter'ı yükleyip aynı promptu karşılaştır.
  7. Merge: Yalnızca önceki adımlar geçtikten sonra merge ve serving testine geç.
print("GPU:", torch.cuda.get_device_name(0))
print("capability:", torch.cuda.get_device_capability(0))
print("torch:", torch.__version__)

with torch.inference_mode():
    outputs = model.generate(**inputs, max_new_tokens=128, do_sample=False)

print(tokenizer.decode(outputs[0], skip_special_tokens=True))

12 Performans ile uyumluluk arasında seçim

Hopper GPU'da FA3 tabanlı optimize yol, donanımın TMA ve asynchronous Tensor Core özelliklerinden yararlanabilir. NVIDIA, FA3'ün FA2'ye kıyasla Hopper üzerinde önemli hızlanmalar hedeflediğini bildiriyor (NVIDIA teknik açıklaması). A100'de aynı yolu zorlamak yerine genel backend'e dönmek daha yavaş olabilir; fakat çalışmayan hızlı kernel, çalışan yavaş kernel'dan daha değerli değildir.

Üretim için donanıma göre ayrı environment tanımlamak daha sağlıklıdır: A100 için uyumlu fallback, H100/H200 için Hopper optimize yol ve yeni nesil GPU'lar için ayrı canary test. Aynı kernel varsayımını bütün makinelerde zorlamak, yeni attention özellikleri kullanan modellerde gereksiz risk yaratır.

13 Sonuç

GPT-OSS 20B eğitimi ve inference'ında asıl mesele yalnızca VRAM değildir. Model mimarisi, MoE expert parametreleri, Harmony formatı, attention sink yolu, FlashAttention sürümü, Triton, PyTorch ve GPU architecture aynı zincirin parçalarıdır. Bir katmanın capability'si diğerinden daha yeni olabilir ve model loader beklenmedik biçimde Hopper-only bir kernel'a geçebilir.

A100 üzerinde alınan S_aux hatasının pratik çözümü, optimize derleme yolunu kapatıp A100 uyumlu genel yürütme yoluna dönmektir. PEFT tarafında ise standart nn.Linear hedefleriyle MoE'nin hamnn.Parameter hedeflerini ayırmak gerekir. En güvenilir akış; önce temiz baseline, sonra adapter gradient ve çıktı testi, ardından save/reload ve merge doğrulamasıdır.

Kısacası: “GPT-OSS 20B A100'de çalışmaz” yerine “kullandığım optimize backend bu A100 üzerinde çalışmıyor” demek teknik olarak daha doğrudur.

Sık sorulan sorular

GPT-OSS 20B A100'de çalışır mı?

Evet, uygun loader ve A100 destekleyen attention/backend yolu kullanılırsa çalışabilir. Sorun çoğu zaman modelin kendisi değil Hopper-only kernel seçimidir.

FA3 neden A100'de hata veriyor?

FA3'ün bazı kernel'ları Hopper'ın TMA ve ilgili Tensor Core özelliklerini hedefler. A100 Ampere olduğu için bu kernel'lar doğrudan çalışmayabilir.

UNSLOTH_COMPILE_DISABLE=1 performansı düşürür mü?

Muhtemelen düşürür; bu ayar bir compatibility fallback'idir. Önce doğru sonuç alınmalı, sonra A100 uyumlu optimizasyonlar ayrı ayrı açılmalıdır.

PEFT GPT-OSS adapter'ını neden yükleyemedi?

MoE expert projection'ları nn.Linear yerine ham nn.Parameter olarak tutulabilir. Bu durumda target_parameters desteği, doğru adapter config'i ve uyumlu PEFT sürümü gerekir.

Adapter'ı hemen merge etmeli miyim?

Hayır. Önce unmerged adapter çıktısını ve save/reload davranışını doğrulayın. Merge edilmiş modeli aynı eval setiyle karşılaştırdıktan sonra deployment'a alın.

Kaynakça

  1. OpenAI. gpt-oss-20b Model Card.
  2. OpenAI. Introducing gpt-oss.
  3. OpenAI. gpt-oss Reference Repository.
  4. Hugging Face. PEFT LoRA: target_parameters for MoE parameters.
  5. NVIDIA. The Next Generation of FlashAttention.
  6. Dao, T. ve ark. (2024). FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision.
  7. OpenAI. gpt-oss-120b & gpt-oss-20b Model Card Paper.

Bu yazı 22 Temmuz 2026 tarihinde hazırlanmıştır. Backend ve kernel uyumluluğu sürümlere bağlıdır; production kurulumu öncesi hedef GPU üzerinde kısa bir smoke test çalıştırılmalıdır.

Türkçe öncelikli yapay zeka çalışma alanını deneyin

Belge analizi, web ve akademik arama, makale, sunum ve kaynaklı sohbet özelliklerini tek çalışma alanında kullanın.

DEHA'yı Ücretsiz Dene →