Serinin ilk iki [1- 4 GB’lık Laptop Ekran Kartında vLLM ve 2- RunPod’da GPU Kiralayıp vLLM Koşturma yazısında hep birinin bizim için hazırladığı ortamlarda çalıştık — driver’a hiç dokunmadık, dokunamadık da. Bu final yazısında o perdeyi kaldırıyoruz: AWS’de çıplak bir Rocky Linux makinesi açacağız ve kernel modülünden vLLM sunucusuna kadar her katmanı kendi ellerimizle kuracağız. Kota duvarını, spot fiyatlarını, DKMS’i ve SELinux’u yol üstünde öğreneceğiz — ve aynı LangChain script’ini üçüncü ortamda (aws ec2 gpu’lu instance vLLM), yine değiştirmeden koşturup seriyi kapatacağız.

İlk yazıda laptop GPU’suyla vLLM’in mekaniğini altı hata pahasına öğrendik; ikinci yazıda RunPod’dan dakikalar içinde container kiralayıp 8B’lik modeli internete servis ettik — ve bulutun kendi hata ailesiyle tanıştık. İki ortamın ortak noktası şuydu: NVIDIA driver’ı hep “host”un malıydı — WSL’de Windows’un, pod’da platformun. Kernel’e inemiyorduk. Bugün inebileceğimiz bir ortam kuruyoruz: gerçek bir sanal makine (VM), tam root, bilerek seçilmiş çıplak bir işletim sistemi.

Bu yazı tam bir kılavuz — her adım, sırayla uygulanmak üzere yazıldı. VBO olarak bizden veri ve yapay zeka dünyasına Zafer Bayramı armağan olsun.

1. Neden Bile Bile Zor Yol?

Sadece vLLM koşturmak istiyorsanız altyapı, kurulum, driver vs uğraşmak istemiyorsanız ikinci yazıda 24 GB’lık kartın saatini 0.22$’a kiralamıştık; AWS’de aynı kapasite bunun birkaç katı maliyet. Bu yolu seçmenin tek sebebi var: altyapıyı öğrenmek veya siz ona kurumları da öğrenmek diyin. Kurumsal dünyada — banka, telekom, on-prem GPU cluster’ları — birileri “driver neden yüklenmedi”, “kernel güncellemesi modülü kırdı”, “SELinux neyi engelliyor” vb sorunlarla uğraşacak. Bu konular bana lazım derseniz lazım olsun, sonuçta python ile elde tespih sallamayı herkes yapıyor, bu tür soruların sorulduğu yerlerde işe yarayan ender bilgi, tam da bu yazıda elle yapacağımız işlerdir.

İşletim sistemi seçimi bilerek Rocky Linux yaptım: Örneklerin ezici çoğunluğu Ubuntu ile ama. RHEL klonu olan Rocky, NVIDIA’nın birinci sınıf desteklediği ailede — CUDA ve driver repo’ları RHEL 8/9/10 için resmî olarak yayınlanıyor ve Rocky sürümleriyle birebir eşleşiyor^[11]. Kurumsal GPU dünyasında karşınıza çıkacak ortamın da RHEL ailesi olaması kuvvetle muhtemel. İlk yazının Oracle Linux’u da aynı aileden — orada glibc 2.28 yüzünden Rust derleyicisiyle boğuşmuştuk. Rocky 9’un glibc’si 2.34; bakalım o dert burada da peşimizden gelecek mi, göreceğiz.

2. Adım 0 — Kota Duvarı: Okumayı Bırakıp Şimdi Yapın

Bu adımı en başa koydum çünkü bekleme süresi var — talebi şimdi açın, yazının kalanını onay gelene kadar okuyun. Korkmayın kota talep edince para almıyorlar ve fatura sayacı falan işlemiyor 🙂 Hesabınız olsa bile GPU’lu instance başlatamayabilirsiniz, çünkü her hesaba bölge bazında vCPU kotaları tanımlı ve kotayı aşan başlatma istekleri reddedilir^[6]. GPU ailelerinde bu kota yeni hesaplarda genellikle sıfırdır^[8].

Tıklama yolu:

AWS Console → Service Quotas → AWS services → arama: EC2
→ listeden "Amazon Elastic Compute Cloud (Amazon EC2)" satırını seç
   (dikkat: "Amazon EC2 Auto Scaling" DEĞİL — o başka servis; Service Quotas
    servisleri tam resmî adla listeler, kısaltma tam eşleşme getirmez)
→ kota arama kutusuna "G and VT" yaz

Karşınıza iki ayrı kota çıkacak ve işte klasik tuzak — bunlar farklı kotalar^[8]:

Şimdi ikisinin mevcut değerine bakın — sonuç hesabınızın geçmişine göre iki uçtan birine düşecek. Taze hesapta tipik değer sıfırdır^[8] ve talep açmanız gerekir: kotayı seçin → Request increase at account level → 8 yazın. Yanlış kategoriye başvurup “kotam onaylandı ama hâlâ 0 vCPU hatası alıyorum” yaşamak bu duvarın en bilinen şekli — bir kullanıcının projesini iki hafta geciktirmişliği var^[9]. Küçük talepler çok daha hızlı onaylanır^[10]. Yaşı ve kullanım geçmişi olan hesapta ise AWS kotaları çoktan yükseltmiş olabilir. Benim hesabım ise dersin en öğretici halini verdi — iki uç aynı anda:

On-demand kotam 384’tü — yıllanmış hesabın konforu; ama gideceğimiz yol olan spot’un kotası 0. Bakmadan spot launch’a gitseydim “MaxSpotInstanceCountExceeded” ile ilk duvara burada çarpacaktım. Spot satırından 8 vCPU’luk artırım talebi açtım ve onaylandı (süre: birkaç saat) — küçük taleplerin hızlı onaylandığı iddiası^[10] tuttu. Kotalar bölge başınadır^[7]; hangi bölgede çalışacaksanız orada bakın ve talebi orada açın.

Beklerken beş dakikalık bir sigorta daha: billing alarmı. CloudWatch → Billing → Create alarm ile “tahmini fatura 10$’ı geçerse e-posta at” kuralı kurun. İkinci yazıda RunPod’un ön ödemeli kredisi doğal bir frendi — kredi bitti, pod durdu. AWS’de öyle bir fren yok; bu alarm, o frenin sizin kurduğunuz versiyonu.

3. Adım 1 — Anahtar ve Kapı

SSH anahtarı: İkinci yazıda WSL’de ürettiğimiz ed25519 anahtarı burada da iş görür — yeni anahtar üretmeye gerek yok, aynı public key’i AWS’ye tanıtacağız:

EC2 Console → Network & Security → Key Pairs → Actions → Import key pair
→ isim: lenovo_wsl → ~/.ssh/lenovo_wsl_runpod.pub içeriğini yapıştır

Güvenlik grubu: EC2 → Security Groups → Create. Kural tek: Inbound’da SSH (22), kaynak My IP. Hepsi bu — 8000 portunu açmıyoruz. İkinci yazıda endpoint internete açıktı ve --api-key kilidi şarttı; burada vLLM’e SSH tüneliyle ulaşacağız (Adım 7): port hiç internete çıkmayacak, trafik şifreli akacak. Dürüst bir not: bu, tek kişilik birkaç saatlik laboratuvarın doğru ölçüsü — kurumsal desen değil. Şirket ortamında model private subnet’te oturur, erişim VPN/SSM gibi kontrollü kanallardan geçer ve endpoint’in önünde yine kimlik doğrulama olur; “iç ağdayız, anahtara gerek yok” varsayımı, zero trust çağında kurumların bilerek terk ettiği varsayımdır. Bizim tünelimiz o dünyanın minyatürü değil, tek kullanıcılık pragmatik hali.

4. Adım 2 — Makineyi Tarif Et: Rocky 9 + g5.xlarge Spot

EC2 → Launch instance. Dört karar:

AMI: “Browse more AMIs” → Community AMIs sekmesi → arama: Rocky. Ve karşınızda ikinci yazının community image dersinin AWS sahnesi: 81 sonuç — sekmenin kendi uyarısı da başında, “anyone can publish… ensure you know and trust the publisher”:

81’i bire indiren üç süzgeç: (1) Yayıncı — Rocky Linux’un resmî AWS hesabı 792107900819; Owner sütunu bu numarayı göstermiyorsa geçin (Docker Hub’daki “push eden vllmbot mu” kontrolünün buradaki karşılığı). Resmî imajlar ücretsizdir, yalnızca instance ücreti ödersiniz^[15]. (2) Sürüm — Rocky 9: runbook’umuzun driver reposu cuda-rhel9; listede bolca gezen Rocky 10 da resmî ama bizim zincir 9 üstüne kurulu. (3) Mimari — x86_64: g5.xlarge x86 makinedir, listedeki aarch64 (ARM) imajları seçerseniz launch mimari uyumsuzluğuyla düşer; soldaki “64-bit (x86)” filtresi işinizi görür. Pratikte üçü tek hamleye iner: aramayı Rocky-9-EC2-Base-9 yapın, x86 filtresini işaretleyin — 81 sonuç 4’e düşer, hepsi resmî, en yeni tarihlisini seçin:

Benim seçimim: Rocky-9-EC2-Base-9.8-20260525.0.x86_64 (ami-09b713c4da77161c3, owner 792107900819).

Instance tipi: g5.xlarge — 4 vCPU, 16 GiB RAM, 24 GB VRAM’li NVIDIA A10G. On-demand fiyat bölgeye göre değişir: us-east-1 listesi 1.006$/saat^[1], benim bölgemde konsol 1.258$/saat gösterdi. Her durumda RunPod’daki 3090 ile aynı VRAM sınıfına 4-5 kat fiyat — bugün satın aldığımız şey compute değil, müfredat. Konsolun bir dip notu daha var: “Current generation: false” — G5, 2026 itibarıyla önceki nesil; bizim müfredat için hiç dert değil, tersine spot fiyatını düşük tutan etkenlerden.

Spot: Advanced details → Purchasing option → Spot instances. GPU ailelerinde spot tasarrufu tipik olarak %60-90 bandında^[3]; g5.xlarge spot us-east-1’de ~0.44$/saatten başlıyor^[2]. Seçeneğin kendi açıklaması da güven verici: spot fiyatından istersin, tavan on-demand fiyatıdır — yani sürpriz yukarı yönlü olamaz. Bedeli: makine iki dakikalık uyarıyla geri alınabilir (interruption) — bir akşamlık kurulum dersi için kabul edilebilir risk. Plan buydu; gerçekte ne ödediğimi birazdan göreceksiniz — spot macerası beklediğimiz gibi gitmedi.

Disk: 60 GB gp3. Dağılım kabaca: sistem + paketler ~10 GB, CUDA/driver ~5 GB, model ağırlıkları ~16 GB, pip cache ve nefes payı gerisi. İkinci yazıdaki 25+25’in tek diskte toplanmış hali.

Ağ: Network settings → Edit gerekmez; Firewall bölümünde Select existing security group deyip GPUDemo-SG‘yi seçmek yeterli. Subnet “No preference”, Auto-assign public IP “Enable” — varsayılanlar bizim senaryo için doğru.

Ve özet paneli — Launch instance‘a basmadan önce son okuma:

Paneldeki bir satır kafa karıştırabilir: biz 60 GiB verdik, özet “2 volume(s) – 310 GiB” diyor. Panik yok, fatura hatası değil: g5.xlarge, EBS diskinizin yanında 250 GB’lık yerel NVMe instance store ile gelir^[18] — makineye lehimli, bedava, ama ephemeral: instance durunca/gidince içindekiler de gider. Kalıcı hiçbir şey koymayın; buna karşılık ders sırasında hızlı geçici alan (mesela HF indirme cache’i) olarak kullanılabilir. RunPod’daki “container disk durunca silinir” kavramının AWS’deki akrabası.

Spot gerçeği: iki başarısız launch ve bir karar

Launch instance’a bastım ve karşılama ekranı yerine şunu yedim:

Instance launch failed
Insufficient capacity.

İlk refleks kendini suçlamak — “kotayı mı yanlış aldım?” Hayır. Burada iki farklı hata ailesini ayırmak gerekiyor: “MaxSpotInstanceCountExceeded” ya da vCPU limitinden bahseden hatalar sizin hesabınızla ilgilidir (Adım 0’daki kota eksik demektir); “Insufficient capacity” ise AWS’nin stoğuyla ilgilidir — o anda, o bölgenin availability zone’larında boşta g5.xlarge spot kapasitesi yok. Spot, tanımı gereği artık kapasite pazarı; artık yoksa, mal yok. Acı ironi: Adım 0’da spot kotası için mücadele etmiştik — meğer kota size launch hakkı verir, kapasite garantisi vermez.

İkinci deneme: g5.2xlarge — belki büyük boy havuzda yer vardır?

Instance launch failed
There is no Spot capacity available that matches your request.

Yoktu, ve olmaması mantıklıydı: g5.xlarge da 2xlarge da aynı fiziksel kartın (A10G) havuzundan beslenir — biri kuruysa öbürü de kurudur. Boy değiştirmek çare değil; çare listesi şöyle sıralanır: (a) kart ailesini değiştir — g4dn (T4) havuzu apayrı ve genelde derindir, driver dersi birebir aynı işler, sadece 16 GB VRAM’e model ayarı gerekir; (b) bölge değiştir — us-east-1’in havuzu en derinidir ama spot kotası, key pair ve SG oraya yeniden taşınır (kota muhtemelen yine 0’dan başlar: yeni talep, yeni bekleme); (c) birkaç saat sonra tekrar dene — kapasite gün içinde dalgalanır; (d) on-demand köprüsü — kotası hazırsa anında kalkar, farkı ödersin.

Benim kararım (d) oldu: Purchasing option’ı None’a çekip aynı g5.xlarge’ı on-demand 1.258$/saatten başlattım. Gerekçe basit: bu yazının başında “satın aldığımız şey compute değil, müfredat” demiştik — ve müfredatın bu akşam işlenmesi, saatte 80 sentlik spot tasarrufundan değerli. Üç saatlik ders ~4$; sabırsızlık vergisi olarak kabul. Spot’u sonraki seanslarda, (a) veya (c) ile kovalamak serbest — runbook’un geri kalanı için hiçbir şey değişmiyor, on-demand ile spot’un kurulum akışı birebir aynı.

5. Adım 3 — İlk Temas: “command not found” Anı

ssh -i ~/.ssh/lenovo_wsl_runpod rocky@<INSTANCE-DNS>

# Kart PCI'da görünüyor mu? (driver YOK, sadece donanım)
lspci | grep -i nvidia
# -bash: lspci: command not found   <-- ilk sürpriz: imaj o kadar minimal ki lspci bile yok

sudo dnf install -y pciutils
lspci | grep -i nvidia
# Beklenen: 3D controller: NVIDIA Corporation GA102GL [A10G]

nvidia-smi
# bash: nvidia-smi: command not found   <-- işte bu satır için buradayız

İlk komutta yediğimiz “command not found” daha kartla ilgili bile değildi: Rocky’nin EC2 Base imajı, bulut imajı felsefesine sadık — gereksiz her şey atılmış, pciutils de listeye girmiş. RunPod’un her şey dahil container’ından gelen biri için ideal “çıplak makine” karşılaması; ve RHEL dünyasının işe yarar refleksi de hemen burada: “bu komut hangi pakette?” sorusunun cevabı dnf provides '*/lspci'.

Kullanıcı adı konusunda konsolun “root” tahminine kanıp root@ ile denerseniz — ben ders olsun diye denedim — makine sizi kibarca kapı önünde düzeltir:

Please login as the user "rocky" rather than the user "root".
Connection to ec2-3-64-61-254.eu-central-1.compute.amazonaws.com closed.

Resmî Rocky imajı root girişini bilerek kapatır; Adım 2’deki “konsola değil AMI sağlayıcısına inanın” uyarısının canlı kanıtı. Bir de ilk bağlantıda göreceğiniz host fingerprint sorusu var — “The authenticity of host … can’t be established” normaldir: makineyle ilk tanışmadır, yes deyip geçersiniz, parmak izi known_hosts‘a yazılır.

O “command not found”, serinin ilk iki yazısında görmemizin mümkün olmadığı bir çıktı — WSL’de de pod’da da nvidia-smi hazır gelmişti, çünkü driver hostundu. Burada kart var, işletim sistemi onunla konuşamıyor. Benim makinemde ikili aynen böyle düştü: lspci kartı gördü — 00:1e.0 3D controller: NVIDIA Corporation GA102GL [A10G] (rev a1) — ve hemen ardından nvidia-smi, -bash: nvidia-smi: command not found dedi. Aradaki köprüyü şimdi biz kuracağız.

6. Adım 4 — Zemin: RHEL Dünyasının Ev Ödevi

NVIDIA’nın driver paketleri EPEL’deki bağımlılıklara ihtiyaç duyar; depolar eklenmeden kurulum eksik bağımlılıkla durur^[11]. Rocky 9 reçetesi^[11][12]:

# Önce sistemi güncelle — kernel yenilenirse modül o kernel'e derlenecek
sudo dnf -y upgrade
sudo reboot   # kernel güncellendiyse şart; kısa kesinti

# Depo zemini
sudo dnf config-manager --set-enabled crb
sudo dnf install -y epel-release
sudo dnf groupinstall -y "Development Tools"

# Kernel başlıkları: sürüm ÇALIŞAN kernel ile birebir eşleşmeli
sudo dnf install -y kernel-devel-matched kernel-headers dkms

Buradaki incelik kernel-devel-matched: depodaki en yeni kernel-devel ile çalışan kernel farklı sürümlerse modül derlenemez — RHEL dünyasının klasik takılma noktası. Bu paket, adı üstünde, çalışan kernel’e eşleşeni kurar^[12]; baştaki dnf upgrade + reboot da ikisini aynı hizaya getirmek için. Doğrulama refleksi: uname -r ile rpm -q kernel-devel aynı sürümü söylemeli.

7. Adım 5 — Driver: Serinin Beklediği An

# NVIDIA'nın RHEL9 CUDA reposu Rocky 9'da doğrudan çalışır
sudo dnf config-manager --add-repo \
  https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo

# Driver: open kernel module + DKMS stream
sudo dnf module install -y nvidia-driver:open-dkms
sudo reboot

İki seçimin gerekçesi: open — AWS’nin kendi RHEL/Rocky rehberi de open kernel module’ü öneriyor^[13]; A10G gibi güncel kartlarda (Turing+) önerilen varyant bu, eski kartlar (Maxwell/Pascal/Volta) proprietary latest-dkms ister^[14]. dkms — kernel her güncellendiğinde NVIDIA modülünü otomatik yeniden derler^[14]; yoksa her dnf upgrade kernel sonrası kartınız kaybolurdu.

Reboot sonrası, üçlü doğrulama:

lsmod | grep nvidia    # modül yüklü mü? dolu satırlar gelmeli
lsmod | grep nouveau   # açık kaynak eski driver: BOŞ dönmeli
nvidia-smi

Doğrulamanın ders kitabı hali bu: nvidia modülü yüklü, nouveau devre dışı, ve nvidia-smi kartı basıyor^[16]. Benim makinemde üçlü şöyle düştü: lsmod | grep nvidia tam kadroyu döktü — çekirdek nvidia modülü, üstünde CUDA’nın unified memory kapısı nvidia_uvm (vLLM’in konuşacağı katman), nvidia_modeset ve nvidia_drm; lsmod | grep nouveau bomboş döndü; ve final:

[rocky@ip-172-31-11-153 ~]$ nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 610.57.04    KMD Version: 610.57.04    CUDA UMD Version: 13.3    |
|-------------------------------+----------------------+----------------------|
|   0  NVIDIA A10G         On   | 00000000:00:1E.0 Off |                    0 |
|  0%   27C    P8    11W / 300W |      0MiB / 23028MiB |      0%      Default |
+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

Driver 610.57.04, CUDA 13.3, 23 GB VRAM, 27°C’de P8’de uyuklayan tertemiz bir kart. İnce bir kapanış detayı: lspci‘ın Adım 3’te gösterdiği 00:1e.0 adresi, tabloda Bus-Id sütununda aynen duruyor — donanımdan driver’a köprü, adresiyle birlikte kuruldu. O tablonun orada olmasının her adımını siz yaptınız; serinin en tatmin edici anı burası.

SELinux notu: Rocky’de SELinux enforcing gelir (getenforce ile bakın) ve Ubuntu’dan gelenlere ilk sürprizi burada yaşatır. Bu yazının akışında (driver + pip + vllm) genelde engel çıkarmaz; ama izin hatası görürseniz refleksiniz setenforce 0 değil, sudo dnf install setroubleshoot-server sonrası audit2why ile neyin engellendiğini okumak olsun. Kurumsal ortamda bu refleks altın değerindedir. Karşılaştığım SELinux olayı olmadı.

8. Adım 6 — Tanıdık Sular: Python, vLLM, Model

Driver çalıştıktan sonra gerisi ilk yazının kopyası — bu da güzel bir ders: dip katman ne olursa olsun üst katman aynı. Bir düzeltmeyle: yaygın söylem “pip’le kurulan vLLM kendi CUDA runtime’ını getirir, toolkit’e (nvcc) gerek yok” der — runtime için doğru, ama vLLM’in FlashInfer sampler’ı gibi parçaları kernel’lerini çalışma anında derler ve gerçek nvcc ister. Çıplak VM’de bu, toolkit’i fiilen zorunlu kılıyor; neyse ki repo zaten ekli, tek satır^[13]: sudo dnf install -y cuda-toolkit — /usr/local/cuda‘yı driver’ınızla uyumlu nvcc ile oluşturur, vLLM’in aradığı varsayılan adres tam orası.

sudo dnf install -y python3.12 python3.12-pip python3.12-devel
#                                              ^^^^^^^^^^^^^^^^
# -devel'i unutmayın: Python.h burada. İlk sürümünde bu satırda -devel yoktu
# ve bedelini birazdan göreceğiniz hatayla ödedim.
python3.12 -m venv ~/vllm-env && source ~/vllm-env/bin/activate
pip install uv
uv pip install vllm --torch-backend auto



vllm serve Qwen/Qwen3-8B \
  --dtype bfloat16 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192 \
  --reasoning-parser qwen3

“Madem uv kullanıyoruz, venv’i neden python -m venv ile yaratıyoruz?” Haklı soru — uv’nin kendi uv venv --python 3.12 komutu var, hatta Python’u bile kendisi indirebilir. Buradaki hibrit tercih bilinçli: bu yazının dünyası RHEL dünyası — Python dnf‘ten gelir ki rpm ile denetlensin, güvenlik güncellemesini dağıtım yapsın; curl | sh ile binary indirmek kurumsal ortamların sevmediği desendir. pip install uv ise uv’yi venv’in içine kurar: izole, sisteme dokunmaz, venv’le birlikte silinir. uv’yi reçeteye sokan asıl şey zaten venv yaratmak değil, --torch-backend auto — PyTorch’u driver’ınızın CUDA sürümüne uygun index’ten seçen, uv’ye özgü bir kolaylık. Kendi makinenizde “saf uv” yolu (installer + uv venv) da aynı sonuca çıkar; ikisi de doğru, felsefeleri farklı.

Sunucu ilk açılışını yaparken (soğuk başlangıç 5-10 dakika: indirme → ağırlık yükleme → torch.compile → KV cache) ikinci bir SSH oturumundan nvidia-smi ile ilerlemeyi izleyebilirsiniz — ilk yazının “log okuma” dersinin canlı versiyonu:

Bu -devel vurgusunun hikayesi var. İlk denemede paketi kurmadım ve sunucu KV cache’i boyutlandırırken şu satırla çöktü:

/tmp/tmpo_p8_rjp/cuda_utils.c:9:10: fatal error: Python.h: No such file or directory

Tanıdık geldi mi? Gelmeli — ilk yazının 3 numaralı hatası, kelimesi kelimesine. Triton, CUDA yardımcı kodunu çalışma anında derler ve Python.h ister; venv sistem Python’u üstüne kuruluysa header’lar ayrı pakettedir. Oracle Linux’ta da böyleydi, Rocky’de de böyle — dağıtım değişti, ders değişmedi. Serinin ana fikri bir kez daha: katman değişince hatalar yok olmuyor, katman değiştiriyor — ama bazıları da hiç değişmeden peşinizden geliyor, ve ikinci karşılaşmada artık log’daki tek satırdan tanıyıp saniyeler içinde çözüyorsunuz. Bonus gözlem: aynı eksik, --enforce-eager‘sız ilk denememde sunucuyu hata basmadan asılı bırakmıştı (4 vCPU’da compile zinciri sessizce kilitlendi); eager modda ise hata yüzeye tertemiz çıktı. Takılan sunucuyu eager’la yeniden başlatmak, sadece hız değil, teşhis aracı da.

-devel kurulup yeniden başlatınca bu kez ağırlıklar yüklendi (123 saniyede 15.27 GiB), KV cache muhasebesi bile düştü — ve motor tam kalkarken ikinci tanıdık yüz kapıda belirdi:

RuntimeError: Could not find nvcc and default cuda_home='/usr/local/cuda' doesn't exist

İlk yazının 4 numaralı hatası. FlashInfer sampler kernel derlemek için nvcc arıyor. Ama işte VM’in farkı: WSL’de bu hatayı hack’le geçmiştik — torch’un gömülü toolkit’ine CUDA_HOME göstermiş, altından da 5 numaralı skew hatası çıkmıştı. Burada root’uz ve NVIDIA reposu ekli: gerçek çözüm tek satır — yukarıdaki dnf install cuda-toolkit. Kurdum, yeniden başlattım, ve:

(APIServer pid=19847) INFO:     Application startup complete.

İsyan molası: Bu noktada “hani laptop’ta yaptığımız için burada uğraşmayacaktık?” diye söylenebilirsiniz — ben söylendim, hem de sansürlenecek kelimelerle. Ama süreölçere bakın: Python.h hatası laptop’ta kök nedeni bulana kadar kim bilir kaç deneme yemişti, burada log’daki tek satırdan tanınıp iki dakikada kapandı; nvcc hatası WSL’de toolkit avcılığı + hack + hack’in doğurduğu yeni hatayla saatler sürmüştü, burada “haa, 4 numara” deyip tek satırla bitti. Antrenmanın alım gücü hata sayısında değil, hata başına düşen sürede. Uğraşmıyorsunuz; hızlı geçiyorsunuz.

A10G’nin açılış muhasebesi de böylece elimizde — serinin üç kartı yan yana:

Okuma dersi aynı, rakamlar büyümüş: A10G, laptop’ın iki katı context’te (8192) daha yüksek eşzamanlılığı, iki kat KV token havuzuyla taşıyor. Ve vLLM yine --kv-cache-memory önerisini byte’ına kadar kendisi vermiş — “kapasiteyi tahmin etmiyorsunuz, okuyorsunuz” cümlesi üçüncü ortamda da geçerli.

Model bilerek ikinci yazıyla aynı: Qwen/Qwen3-8B — üç ortamı aynı modelle kapatınca karşılaştırma anlamlı oluyor. Dikkat: --api-key yok ve --host varsayılanda (localhost) — çünkü bu sunucu internete hiç çıkmayacak. Açılış logundaki bellek muhasebesini az önce tabloda okuduk — üç ortamın raporu artık yan yana.

9. Adım 7 — SSH Tüneli ve Üçüncü Kanıt

Laptop’ta (WSL) ikinci bir terminal:

ssh -i ~/.ssh/lenovo_wsl_runpod -L 8000:localhost:8000 rocky@<INSTANCE-IP>
# Bu oturum açık kaldıkça localhost:8000, şifreli tünelden EC2'deki vLLM'e gider

Ve serinin kapanış sınavı — ilk yazıda laptop’a, ikinci yazıda RunPod’a bağladığımız aynı LangChain script’i, üçüncü kez, yine iki satır farkla:

VLLM_BASE_URL=http://localhost:8000/v1 uv run python runpod.py
# api_key: sunucu şart koşmuyor; istemcinin istediği herhangi bir string olur

Ve gerçek çıktı — üçüncü ortam, aynı kod:

=== basic ===
The capital of Japan is Tokyo.

Dört demo, dört başarı — ve iki kapanış bulgusu. Birincisi, ölçek hipotezi mühürlendi: thinking kapalıyken 0.6B laptop modeli “Osaka City” demişti, 8B RunPod’da “Tokyo” demişti; aynı 8B, A10G’de yine “Tokyo” — takas modelin ölçeğine ait, altındaki makineye değil. İkincisi, beklenmedik bir hediye: output_token_details alanına bakın — RunPod koşusunda boş gelen bu alan şimdi {'reasoning': 100} taşıyor. İlk yazıdaki thinking vergisi artık faturada kalem kalem: 111 output token’ın 100’ü düşünme, 11’i cevap. “LangChain reasoning’i düşürür” bulgusunun güncel hali de böylece netleşti: düşüncenin metni hâlâ istemci katmanında kayboluyor, ama sayısı artık usage muhasebesinde görünüyor — maliyet takibi yapanlar için tam ihtiyaç duyulan taviz.

Base URL’in localhost olması da tatlı bir simetri: seri, ilk yazının adresine geri döndü — ama bu localhost’un arkasında artık bir tünel, bir VM ve bizim kurduğumuz bir driver var.

10. Fatura Disiplini: Frensiz Dünya

İkinci yazının deploy paneli “stopped cost” satırını daha baştan gösteriyordu; AWS o dürüstlüğü göstermez — kalemleri kendiniz bileceksiniz^[3]:

Stop ≠ terminate, bu sefer de. Instance’ı durdurmak compute faturasını keser ama 60 GB’lık gp3 EBS diski var olduğu sürece aylık ücretini yazar. Ders bitti mi terminate (disk de silinsin); yarın devam edecekseniz stop yeterli. (Spot ile gitseydik stop/start davranışı ayrıca konuşulacaktı; on-demand köprüsünün sessiz bir konforu da bu — stop/start klasik şekilde çalışır.)

Egress ücretlidir. Model ağırlıklarını lokale çekmeyin — zaten HF’ten her yerde yeniden iner. İçeri veri sokmak (bizim yönümüz) ücretsizdir, dışarı çıkarmak paralıdır.

Alarm kuruluydu. Adım 0’daki billing alarmı bu bölümün sigortasıydı; üç saatlik ders seansının gerçek maliyeti:  toplam $ (on-demand 1.258$/sa × süre + EBS) 4-5 dolar falan oldu.

Kapanış: Serinin Haritası

Üç yazının sonunda elinizde üç vitesli bir kutu var. Birinci vites, laptop: flag’leri, API’yi, bellek matematiğini bedavaya öğrenmek — her yeni araç denemesinin başlangıç noktası. İkinci vites, RunPod: beş dakikada büyük kart, kahve parasına büyük model — deneylerin, demoların, kısa işlerin vitesi. Üçüncü vites, EC2 + Rocky: pahalı ve zahmetli ama katmanların tamamı sizin — altyapı bilgisinin kendisi hedef olduğunda seçilir.

Ve serinin başından beri tekrarlayan iki büyük fikir. Birincisi: hangi katmanın kimin malı olduğunu bilmek. WSL’de driver Windows’undu, container’da platformundu, VM’de sizin — bir ortamda neyin değiştirilebilir neyin dokunulmaz olduğunu okuyabilmek, “GPU’da bir sorun var” cümlesini duyduğunuzda nereye bakacağınızı söyler. İkincisi: katman değişince hatalar yok olmuyor, katman değiştiriyor — laptop’ta derleyiciyle, bulutta konfigürasyonla, VM’de kernel ve kotayla boğuştuk; üçünde de kurtarıcı aynıydı: semptomu bırak, log’da kök nedeni ara. Kolay gelsin; terminate etmeyi unutmayın, nvidia-smi‘ınız hep dolu dönsün!

Kaynaklar

1. Vantage — g5.xlarge Pricing and Specs
2. DoiT Compute — g5.xlarge Spot, On-Demand & Savings Plans (us-east-1)
3. Thunder Compute — EC2 GPU Instances: A Full Guide to AWS GPUs (2026)
4. Wring — AWS GPU Instance Pricing: P5, P4d, G5, Inf2
5. DevZero — g5.xlarge Pricing & Specs (ve G6e Karşılaştırması)
6. AWS Docs — Amazon EC2 Service Quotas
7. AWS re:Post — Request a Service Quota Increase for an On-Demand Instance
8. AWS re:Post — EC2 Instance Creation: vCPU Limit Issue (Spot vs On-Demand Kota Ayrımı)
9. Ayooluwaposi Olomo (Medium) — How to Apply for an AWS Service Quota Increase
10. RONIN — How to Request an EC2 Quota Increase (and Get It Approved Faster)
11. NVIDIA — Driver Installation Guide: Rocky Linux
12. Rocky Linux Docs — Installing NVIDIA GPU Drivers
13. AWS re:Post — Install NVIDIA GPU Driver, CUDA Toolkit, Container Toolkit on EC2 (RHEL/Rocky/AlmaLinux 8/9/10)
14. LinuxCapable — How to Install NVIDIA Drivers on Rocky Linux 10, 9 and 8
15. AWS Marketplace — Rocky Linux (Official) AMI
16. Sean Zheng (Medium) — Step-by-Step Guide to Installing NVIDIA Drivers on RHEL 9
17. AWS — Amazon EC2 Spot Instances Pricing
18. AWS — Amazon EC2 G5 Instances
19. nOps — Amazon EC2 GPU Instances: The Complete Guide
20. vLLM Docs — Quickstart