GPU satın almak zor ve pahalı, laptop GPU’larının kapasitesi sınırlı. Adamakıllı bir model koşturmak istiyorsunuz ancak çok para harcamak istemiyorsunuz. O zaman GPU kiralamak mantıklı bir seçenek oluyor. Peki kiraladınız bu sefer driver kurulumu yükleme vs. kim uğraşacak? Siz mi yoksa bunlar da hazır gelsin ben sadece kullanayım mı? O halde doğru adres runpod olabilir.

Peki neden RunPod? GPU kiralama pazarında düzinelerce oyuncu var ve daha ucuz teklif her zaman bir yerlerde bulunur. Ama bu serinin bu aşamasındaki hedefimiz pazarlık değil, ilk kiralık GPU deneyimini sürtünmesiz yaşamak: hesap açmaktan çalışan modele giden yolun kısa, arayüzün pürüzsüz, sürprizin az olması. RunPod bu üçünü fiyatı da makul tutarak veriyor — ve vLLM dokümantasyonunun kendi deployment rehberinde yer verdiği platformlardan biri olması^[9] da tesadüf değil.

1. Rakamlarla Başlayalım: Kiralamak Ne Kadar Ucuz?

Önce şu soruyu kapatalım: “4090 alsam mı, kiralasam mı?” Bir RTX 4090’ın sıfır fiyatı hâlâ ciddi para; RunPod’un Community Cloud katmanında aynı kartın saati 0.35$^[1]. Kartın kendini amorti etmesi için yıllarca kesintisiz deney yapmanız gerekir — üstelik kiralıkta istediğiniz an 4090’dan A100’e, oradan H100’e atlayabilirsiniz. Öğrenme ve deneme aşaması için matematik tartışmasız kiralamadan yana.

Ağırlıklar (FP16’da parametre × 2 byte) + KV cache + sabit yükler. Kabaca: 7-8B modeller (FP16) için 24 GB sınıfı yeterli; 1-8B bandı, quantization ile 16-24 GB’lık tek tüketici kartında rahat eder^[12]. 70B sınıfına çıkmak isterseniz ya 2×24 GB kart ile tensor parallelism ya da tek 80 GB’lık kart gerekir^[12]. RunPod’un güncel liste fiyatlarından bir kesit:

Kart	VRAM	Community Cloud	Secure Cloud	Bizim gözümüzde
RTX 3090	24 GB	~0.22-0.50$/saat	0.50$/saat	En ucuz 24 GB kapısı
RTX 4090	24 GB	0.35$/saat[1]	0.75$/saat[2]	Bu yazının kartı — 7-8B modeller rahat
A100 80GB	80 GB	1.39$/saat (PCIe)[1]		70B’ye tek kartla çıkış
H100 80GB	80 GB	2.89$/saat (PCIe)[2]		Hız da isteyenlere

Somut senaryo: bir akşam, üç saat, RTX 4090, Qwen2.5-7B servis edip kurcaladınız. Community’de fatura: ~1 dolar. Bir kahveden ucuz. Faturalamanın saniye bazlı olması^[2] da şu demek: 20 dakika kullanıp kapattıysanız 20 dakikanın parasını ödersiniz. Başlamak için 5-10$ kredi yüklemek yetiyor^[11].

2. Kiraladığınız Şey Bir VM Değil, Container

RunPod’da kiraladığınız şey bir sanal makine (VM) değil, host makinede çalışan bir Docker container’ı. NVIDIA driver’ı container’ın değil host’un parçasıdır ve içeriden değiştirilemez; platform, host driver’ının container’daki CUDA sürümüyle uyumlu olmasını kendisi garanti eder^[6][7]. İlk yazıdaki WSL2 düzeninin birebir aynısı: driver “host”un malı, üst katman sizin.

Bunun pratik iki sonucu var. Birincisi, nvidia-smi her zaman hazır gelir — driver kurulumu diye bir adım yok, zaten yapamazsınız. İkincisi, image seçerken CUDA sürümüne dikkat etmek sizin işiniz: host’un driver’ından daha yeni CUDA isteyen bir image seçerseniz pod “unsatisfied condition: cuda>=12.6, please update your driver” benzeri bir hatayla hiç açılmaz — driver’ı güncelleyemeyeceğiniz için tek çare uyumlu bir host seçmek^[8]. Neyse ki GPU seçim ekranında CUDA sürüm filtresi var; ilk yazının 4. bölümündeki refleks burada da geçerli: sürüm uyumu kontrolü, kurulumdan önce gelir.

3. İki Katman: Community mi, Secure mu?

RunPod’un fiyat tablosundaki ikili yapı ilk kararınız. Secure Cloud, RunPod’un anlaştığı T3/T4 sınıfı veri merkezlerindeki donanımdır — tam liste fiyatı ödersiniz, karşılığında öngörülebilirlik ve kurumsal ortam alırsınız. Community Cloud ise bağımsız sağlayıcıların platforma bağladığı donanımdır ve çoğu kartta fiyat yarıya yakın düşer^[1] — 4090’daki 0.34$ / 0.69$ farkı tam olarak bu.

Buradaki takas dürüstçe konuşulmalı: Community’de donanımın fiziksel olarak kimin elinde olduğunu bilemezsiniz ve host’tan host’a ufak performans/kesinti farkları görebilirsiniz. Pratik kural basit^[1]: deney, öğrenme ve açık kaynak modellerle oynama → Community; hassas veri, müşteri verisi, uyumluluk kaygısı veya prod işi → Secure. Bu serideki her şey birinci kategoride — Qwen’in ağırlıkları zaten herkese açık, prompt’larımız da “Where is the capital of Japan?” seviyesinde. Community ile başlayın; Secure’a geçmeniz gereken gün, bunu zaten bilirsiniz.

4. RunPod ile Adım Adım vLLM API Oluşturma

Şimdi işin mutfağı — menüden ilk token’a, her adım kendi ekran görüntüsüyle. (Görüntüler benim gerçek koşumdan; pod adı erkan_blog_deneme, işi bitince terminate edildi, görünen anahtar emekliye ayrıldı.)

4.1. Pod’u tarif etmek

Sol menüden Pods, sonra Deploy:

Deploy ekranında sizi bir template arama kutusu karşılar. Doğrudan aramak yerine Explore all ile galeriyi açın:

Galeride Public + Verified filtrelerini açın — RunPod’un doğruladığı template’ler kalır ve resmî image’lı “vLLM Latest” (vllm/vllm-openai:latest) hemen öne çıkar:

Pod’a bir isim verin:

4.2. Ödev: image’ın CUDA şartını öğren, GPU’yu ona göre filtrele

2. bölümdeki “CUDA uyumu sizin işiniz” dersinin uygulaması burası. Image’ı körlemesine seçmeden önce Docker Hub’da sayfasını açıp katmanlarına bakın —vllm/vllm-openai:qwen38-x86_64-cu130’in layer’larında şart açıkça yazıyor: NVIDIA_REQUIRE_CUDA cuda>=13.0:

Bu bilgiyle Compute bölümüne dönüp Filter‘ı açın:

Cloud type olarak Community (3. bölümdeki kararımız — RunPod’un kendi uyarısı da ekranda: öngörülebilirlik istiyorsan Secure), CUDA versions olarak 13.0 ve üstü:

Karta gelince: 24 GB sınıfında iki mantıklı aday listelenir — 4090 (0.34$/sa) ve 3090 (0.22$/sa):

Ben bu koşuda 3090‘ı seçtim — 8B’lik model için 24 GB’ın kendisi yeterli, throughput farkı bir akşam deneyinde hissedilmez, ve saatte 12 sent farkın öğrettiği bir şey yok.

4.3. Disk ve SSH hazırlığı

Storage bölümünde iki ayrı disk var ve farkları önemli: Container disk pod durdurulunca silinir (geçici), Volume disk ise /workspace‘e mount edilir ve pod yaşadıkça kalır. İkisini de 25 GB yaptım:

SSH erişimi isteyeceksiniz — log okumak, nvidia-smi‘a bakmak, pod’un gerçekten ne olduğunu kurcalamak için. RunPod parola değil public key ile çalışır; anahtar hesap seviyesinde bir kez tanımlanır. WSL’de üretin:

Sonra konsolda Credentials → SSH Public Keys → Add SSH key:

4.4. Overrides: işin kalbi

Şimdi en kritik pencere. Template kartındaki Set overrides (veya Edit Template) ile açılır ve template’in bütün görünmez varsayılanlarını — image, start command, disk, port — görünür kılar:

Buradaki iki alanı açalım. Container image: ben vllm/vllm-openai:qwen38-x86_64-cu130 kullandım — :latest yerine, vLLM ekibinin yeni Qwen ailesi desteği için yayınladığı build’in CUDA 13.0 varyantı. Tag ne kadar egzotik görünürse görünsün kural aynı: sahibi vllm organizasyonu, o yüzden güvenli. (Tag’deki cu130, 4.2’de filtrelediğimiz CUDA sürümüyle bilerek eşleşiyor — zincirin son halkası.) İlk denemenizde :latest de aynı akışla çalışır. Container start command: laptop refleksinizi kenara koyun — bu kutuya vllm serve ... diye komut yazılmaz. Image’ın entrypoint’i zaten vllm serve‘dür; kutu, o komuta eklenecek argümanları alır. Benim yapıştırdığım tek satır:

--host 0.0.0.0 --port 8000 --model Qwen/Qwen3-8B --dtype bfloat16 --gpu-memory-utilization 0.85 --max-model-len 4096 --reasoning-parser qwen3 --api-key COK-GIZLI-ANAHTAR

Laptop’takinden farklar öğretici. --host 0.0.0.0 --port 8000 laptop’ta hiç yazmadığımız bir ikili: sunucunun tüm arayüzleri dinlemesi gerekiyor ki RunPod’un proxy’si ona ulaşabilsin — bunları silerseniz pod “çalışır” ama proxy 404 döner. --gpu-memory-utilization 0.85 ve --max-model-len 4096: ilk açılış için muhafazakâr değerler; 24 GB’da 8B model bunlarla çok rahat, oturduktan sonra 0.90/8192’ye çıkabilirsiniz — ilk yazıda 0.75’e mahkûm eden Windows payının burada olmadığını hatırlayın. (Model --model flag’iyle veriliyor; vLLM logları bu flag’in ileride kalkacağı, positional tercih edildiği uyarısını basar — ikisi de çalışır, template gelenekleri henüz flag’li.) --reasoning-parser qwen3‘ü ilk yazıdan tanıyorsunuz: düşünce blokları content‘e karışmasın. Ve --api-key, çünkü endpoint internete açık: public URL’i olan bir LLM sunucusunu anahtarsız bırakmak, kapıyı açık bırakıp tatile gitmek gibidir.

Bu anahtarı nereden alıyoruz? Hiçbir yerden — kendiniz uyduruyorsunuz. --api-key, RunPod’un ya da bir servisin verdiği bir şey değil; sunucuya “isteklerde şu paroloyu ara” demenin yolu. openssl rand -hex 32 ile üretin; istemcide aynı string’i api_key olarak verin, biter. Credentials sayfasındaki RunPod API Keys ile (pod yönetimi içindir) karıştırmayın. Bir de hijyen: bu anahtar start command’da düz metin durur — log ve ekran görüntüsü paylaşırken içindeyse, paylaştıktan sonra anahtarı yenileyin.

4.5. Deploy ve bekleme

Overrides kaydedilince deploy ekranının sağ paneli faturanın tam dökümünü verir — okumaya değer:

Deploy Pod‘a basınca RunPod host’a image’ı çekmeye başlar — 8+ GB’lık image’ın katman katman inişini izlersiniz:

Image inince sıra modele gelir (HF’ten ~16 GB) ve loglar ilk yazıdan ezbere bildiğimiz finale koşar:

4.6. Bağlanmak: üç kapı

Pod hazır olunca Connect sekmesi üç erişim yolunu tek ekranda toplar. Overrides’ta 8000’i exposed HTTP ports’a eklediğimiz için RunPod o portu https://<pod-id>-8000.proxy.runpod.net formatında bir public URL olarak dışarı açmış durumda^[9]:

Proxy URL’in /docs‘una gidin — ilk yazıdan tanıdık interaktif API arayüzü, artık internetin üstünde:

İstemci tarafında değişen, söz verdiğimiz gibi, iki satır:

client = OpenAI(
    base_url="https://<pod-id>-8000.proxy.runpod.net/v1",
    api_key="COK-GIZLI-ANAHTAR",
)

Dashboard da bu arada pod’un nabzını gösterir — GPU %0’da boşta beklerken bile bellek dolu, çünkü vLLM ilk yazıda öğrendiğimiz gibi KV cache havuzunu baştan rezerve eder:

Model cache notu: pod’u durdurup açtığınızda container disk silindiği için model yeniden iner. Ağırlıkları /workspace‘teki volume’e yönlendirmek (ör. HF_HOME=/workspace/hf_home environment variable’ı) bu israfı keser^[10] — volume’ün kendi faturası olduğunu 8. bölümde konuşacağız.

5. Gerçek Dünya Molası: İlk Pod’um 20 Dakika Crash Döngüsünde Kaldı

Buraya kadar anlattığım akış, işlerin doğru gittiği versiyondu. Şimdi dürüstlük zamanı: benim ilk pod’um öyle gitmedi. İlk yazının altı hatalık maratonundan sonra “bulutta her şey hazır gelir” rahatlığına kapılmıştım; bulut bana kendi hata zincirini yaşattı. Üç perde halinde anlatayım, çünkü her perdenin dersi ayrı.

Perde 1 — Semptomlar: SSH kopuyor, proxy 404 veriyor. Pod’u hazır vLLM template’inden açtım. SSH bağlanıyor ve birkaç saniye içinde Connection closed ile düşüyordu; proxy URL ise 404. İkisini de ayrı ayrı debug etmeye kalktım — ağ mı, port mu, SSH ayarı mı derken dakikalar geçti. Halbuki ikisi de hastalık değil semptomdu: container bir crash-restart döngüsündeydi. Her restart SSH oturumunu koparıyor, proxy de arkasında dinleyen kalmadığı için 404 basıyordu. İlk yazının en büyük dersi burada da geçerliymiş: semptomla boğuşma, log’da kök nedeni ara.

Perde 2 — Log’daki kök neden: 401 Unauthorized. Pod loglarına nihayet baktığımda gerçek sebep tek satırdı:

httpx.HTTPStatusError: Client error '401 Unauthorized' for url
'https://huggingface.co/meta-llama/Meta-Llama-3.1-8B-Instruct/resolve/main/config.json'

Meta-Llama mı? Ben Llama seçmemiştim ki. Seçmemiştim, çünkü seçim yapmamıştım: hazır template’in start command’ında model gömülü geliyordu ve varsayılanı gated (erişim onaylı) bir modeldi — Llama ailesini indirmek için Hugging Face hesabı, model sayfasında lisans onayı ve HF_TOKEN gerekir. Üstelik template’in environment ayarında HF_TOKEN={{ RUNPOD_SECRET_HF_TOKEN }} gibi bir secret referansı vardı; o secret’ı hesabımda hiç oluşturmadığım için container’a token yerine boşluk gidiyordu. Ve bir bonus mayın daha: template’in container disk varsayılanı 8 GB’dı — 401’i çözseydim bile 16 GB’lık ağırlıklar diski doldurup pod’u başka bir sebeple öldürecekti. Yani “tek tıkla vLLM” vaadi, üç okunmamış varsayımın üstüne kuruluydu: gated model, doldurulmamış secret, yetersiz disk.

Perde 3 — Panik hamleleri ve community image tuzağı. Bu noktada iki yanlış hamle yaptım ki ikisi de öğretici. Önce image alanındaki tag’i model adı sandım — “image’ı qwen‘li bir tag’e çekersem model değişir” diye. Değişmez: image tag’i vLLM yazılımının hangi build’i olduğunu seçer, servis edilecek modeli değil — model her zaman start command’ın argümanıdır. (Kafa karıştırıcı bir detay: vLLM ekibi yeni model aileleri için qwen38 gibi model adlı build tag’leri de yayınlıyor — bunlar o modelin desteğini içeren motor sürümleridir, model önyüklü image değil.) İkinci hamle daha tehlikeliydi: template galerisinde “qwen” aratıp bulduğum bir pod açtım ve loglar akmaya başlayınca gördüm ki çektiğim image pasterfild/qwen3.5-9b-vllm — resmî vllm/ organizasyonundan değil, bilinmeyen bir kullanıcıdan. İçinde ne çalıştığını bilmediğiniz bir container’a environment variable olarak vereceğiniz her secret (HF token, API anahtarı) o container’ın koduna emanettir; GPU pod’ları kripto madenciliği gömülü image’ların da bilinen hedefidir. Anında terminate. Kural basit: image sahibi vllm organizasyonu değilse, içine secret koymayın — 4. bölümde “Edit Template’i açıp Image alanını gözünüzle doğrulayın” dememin sebebi buydu. Aynı komut satırını gösteren o pencere, start command’daki gömülü modeli de, disk varsayılanını da görebileceğiniz tek yerdir; galeriden seçtiğiniz hiçbir template’e o pencereyi açmadan güvenmeyin.

Ve faturanın acı dersi: bu 20 dakikalık döngü boyunca sayaç işledi. Pod “çalışmıyor”du ama açıktı — crash-restart döngüsündeki pod da ücretlendirilir. Buradan çıkan altın kural: takıldıysanız önce stop, sonra düşünün. Debug’ı log okuyarak yaparsınız, pod açıkken kafa patlatarak değil.

Mutlu son reçetesi — yaşananların damıtılmış hali, 4. bölümdeki akışın neden öyle olduğunun gerekçesi:

Tuzak	Belirti	Panzehir
Template’in gated model varsayılanı	Log’da HF 401, crash döngüsü	Start command’ı kendin yaz; ilk denemede gated olmayan model (Qwen)
Doldurulmamış secret referansı	{{ RUNPOD_SECRET_X }} boş gider	Gated model şartsa: HF’te lisans onayı + Read token + env var, sonra restart
8 GB container disk	İndirme ortasında ölüm	40-50 GB disk veya HF cache’i volume’e
Image tag’i ≠ model	Tag değişir, aynı model inmeye devam eder	Model = start command argümanı
Community image	kullanici/model-vllm kalıbı	Yalnızca vllm/vllm-openai; sahibini Docker Hub’da doğrula
Crash sırasında sayaç	“Çalışmayan” pod’a fatura	Takıldın mı: stop → log oku → düzelt → başlat

Son bir incelik: temiz kurulumla pod nihayet açıldığında tarayıcıdan kök URL’e bakıp yine 404 gördüm — ama bu iyi 404’tü. vLLM kök path’te sayfa servis etmez; her şey /v1/... ve /docs altındadır. Dünkü 404 “dinleyen yok” demekti, bugünkü “dinliyorum ama o adreste bir şey yok.” Aynı üç rakam, zıt iki teşhis — farkı loglardaki API server: HTTP server started satırı söyler.

6. Kanıt: Laptop Kodu Bulutta, Değişmeden

Serinin başından beri verdiğim söz şuydu: laptop’ta yazılan her istemci satırı kiralık GPU’ya değişmeden bağlanır. Pod ayağa kalktığına göre sözün test vakti. İlk yazının 9. bölümündeki LangChain script’ini aldım; değişen gerçekten iki satır: base_url proxy URL’i oldu, api_key pod’un anahtarı. Dört demo, canlı çıktılarıyla:

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

[tokens: {‘input_tokens’: 29, ‘output_tokens’: 111, ‘total_tokens’: 140, …}]

=== chained === Sunucu çalışıyor. === streamed === 1,2,3,4,5 === no_thinking === The capital of Japan is **Tokyo**. It is the country’s largest city and serves as the political, economic, and cultural center of Japan.

Bu dört satırlık çıktı, ilk yazının üç yarım kalmış hikayesini kapatıyor:

Osaka hadisesi çözüldü — suçlu ölçekmiş. Hatırlayın: 0.6B model, thinking kapatılınca başkent sorusuna “Osaka City” diyordu ve dersimiz “bu model doğruluk için o token’lara muhtaç” olmuştu. 8B’ye sorduk: thinking kapalıyken bile Tokyo. Yani thinking-doğruluk takası model ailesinin değil, ölçeğin özelliğiymiş — parametre büyüdükçe modelin düşünmeden bildiği şeyler artıyor, takasın bedeli düşüyor. 24 GB’lık kartın satın aldığı şey sadece hız değil; ayarlarınızın affediciliği.

Çeviri zinciri artık hem temiz hem doğru. Laptop’ta zincirden <think> bloklu, “Server çalışıyor” diyen bir string çıkmıştı. Şimdi çıktı: “Sunucu çalışıyor.” — pod’daki --reasoning-parser qwen3 düşünceyi content’ten ayıkladı, 8B de “server” kelimesini Türkçeleştirecek kadar dil biliyor. Aynı zincir kodu, sıfır değişiklik.

Ama parser’ın LangChain’deki bedeli streaming’de görünür oldu. Streaming demosu cevabı bastı basmasına, öncesinde uzun bir sessizlik vardı: reasoning parser açıkken düşünce token’ları vLLM’in standart dışı reasoning alanından akıyor, LangChain o alanı tanımadığı için chunk’ların .text‘i boş geliyor — bu koşuda cevap başlamadan önce ~525 boş chunk saydım. İlk yazıdaki “LangChain reasoning’i düşürür” bulgusunun streaming yüzü: kayıp sadece veri değil, algılanan gecikme. UI yapıyorsanız bu sessizliğe bir “düşünüyor…” göstergesi koymak sizin işiniz.

Bir pratik not daha: istemcideki timeout‘u cömert tutun (script’te 120 sn). Araya proxy hop’u giriyor, soğuk pod’da ilk istek model yüklemesini bekleyebiliyor — laptop’taki refleksle 10 saniyelik timeout koyarsanız sunucu sağlıklıyken istemciniz pes eder.

7. Trafiği Kesikli Olanlara: Serverless

Pod modeli, sayaç mantığıyla çalışır: açık kaldığı her saniye — istek gelse de gelmese de — yazar. Bir akşamlık yoğun kurcalama için ideal; ama senaryonuz “arada bir istek gelen demo/API” ise yanlış mimaridir. O iş için RunPod’un ikinci modu var: Serverless. Modelinizi bir endpoint olarak tanımlarsınız; istek gelince worker ayağa kalkar, iş bitince sıfıra kadar ölçeklenir (scale to zero) ve yalnızca işlenen istek süresinin parasını ödersiniz^[10]. RunPod’un hazır vLLM worker’ı sayesinde model adını verip endpoint açmak, pod kurmaktan bile az iş.

Bedeli de saklamayalım: sıfırdan uyanan worker’ın cold start‘ı var — model VRAM’e yeniden yüklenirken ilk istek bekler. Sürekli trafikte pod, seyrek trafikte serverless kazanır; ikisinin kesişim noktası sizin trafiğinize bağlı. Pratik başparmak kuralı: günde toplam bir saatten az GPU işi üretiyorsanız serverless’ı ciddiye alın. RunPod’da hangi mod, hangi katman? 30 saniyelik karar akışı Trafik nasıl? Yoğun seans mı, arada bir istek mi? yoğun seans / sürekli arada bir istek Serverless İstek başına ödeme, sıfıra ölçeklenir Bedeli: cold start bekleme Veri hassas mı? Müşteri verisi, uyumluluk, prod? hayır, deney evet Community Cloud 4090: 0.34$/sa — bu serinin evi Donanım bağımsız sağlayıcıda Secure Cloud 4090: 0.69$/sa — liste fiyatı Veri merkezi, öngörülebilirlik (Serverless’ta da aynı Community/Secure seçimi worker’lar için geçerli) İki soru, dört çıkış. Bu serinin senaryosu — akşam kurcalaması, açık model, hassas veri yok — sol alt kutuda oturuyor: Community Cloud + pod.

8. Fatura Disiplini: Sayaç Nerelerde İşler?

Saniye bazlı faturalama cömert bir başlangıç, ama sayaç yalnızca GPU’da değil. Üç kalemi bilerek yönetin:

Stop ≠ terminate. Pod’u durdurmak GPU faturasını keser ama diskler durmaz: network volume ilk 1 TB için 0.07$/GB/ay faturalanır^[2] ve durdurulmuş pod’ların unutulan diskleri sessizce yazmaya devam eder — platformun en klasik tuzağı bu^[1]. Kural, üçüncü yazıda AWS için söyleyeceğimizin aynısı: iş bitti mi terminate; devam edecekseniz volume’lü kurulumla stop.

Volume matematiği. 50 GB’lık bir HF cache volume’ü ayda ~3.5$ demek. Haftada birkaç akşam deney yapıyorsanız indirme süresinden kazandığınız vakit buna değer; ayda bir kurcalıyorsanız değmez — terminate edip modeli yeniden indirin.

Kredi bittiğinde fren var. RunPod ön ödemeli kredi ile çalışır: bakiye biterse pod durur. AWS’nin “sayaç siz durdurana kadar işler” dünyasına kıyasla bu, yeni başlayan için doğal bir sigorta — üçüncü yazıda o frensiz dünyaya geçtiğimizde farkı hissedeceğiz.

9. Karar Tablosu

Durum	Tercih	Neden
İlk kiralık GPU deneyimi, akşam kurcalaması	Community pod	4090 0.34$/sa[1]; üç saatlik seans ~1$
7-8B model servis etmek	24 GB kart (4090)	FP16 ağırlık + KV cache rahat sığar[12]
70B denemek	A100/H100 80 GB veya 2×24 GB	Tek kart 1.39-2.89$/sa[1][2]; çift kartta tensor parallelism[12]
Kesikli trafikli demo/API	Serverless	İstek başına fatura, sıfıra ölçeklenme[10]; bedeli cold start
Hassas veri, uyumluluk, prod	Secure Cloud	Veri merkezi donanımı, öngörülebilirlik[1]

Peki daha ucuzu yok mu? Var — GPU kiralama pazarında marketplace modeliyle çalışan, etiket fiyatları RunPod’un da altına inen platformlar mevcut. Ama pazarlık, host güvenilirliği okuma ve kesinti yönetimi gibi ek işler getiriyorlar. Bu serinin felsefesi “önce mekaniği sürtünmesiz öğren”; fiyat avcılığı, mekanik oturduktan sonra kendi başına çıkılacak bir yolculuk.

Kapanış: Konfor Alanının Bedeli

Bugün GPU kiraladık, 8B’lik modeli internete servis ettik, laptop kodumuzun değişmeden çalıştığını kanıtladık — ve cebimizden birkaç kahve parası çıktı (crash döngüsünde yanan 20 dakika dahil). İlk yazının altı hatasından tek biriyle bile karşılaşmadık — glibc yok, derleyici yok, pin memory kapısı yok; hepsi vllm/vllm-openai image’ının ve platformun içinde eritilmiş. Ama bulut, yerine kendi hata ailesini koydu: template varsayılanları, secret referansları, disk boyutları, image güveni. Ders şu: katman değişince hatalar yok olmuyor, katman değiştiriyor. Laptop’ta derleyiciyle boğuşuyorduk, bulutta konfigürasyonla. Ve dikkat ettiyseniz bir şeye yine hiç dokunmadık: driver kuruluşu, kernel, işletim sistemi… Container dünyası o katmanları bizden bilerek saklıyor — hız ve ucuzluk tam da bu saklamadan geliyor.

Peki ya o katmanları öğrenmek istiyorsanız? Kurumsal dünyada, on-prem GPU cluster’larında, “driver neden yüklenmedi” sorusunun sorulduğu yerlerde çalışacaksanız? O zaman konfor alanından çıkmak lazım. Serinin son yazısında AWS EC2’de çıplak bir Rocky Linux açıp NVIDIA driver’ından vLLM’e kadar her katmanı elle, dipten kuracağız — nvidia-smi‘ın kartı ilk kez gördüğü o anın keyfi de cabası. Kolay gelsin, pod’larınızı terminate etmeyi unutmayın!

---

Kaynaklar

1. Hack’celeration — How Much Does RunPod Cost? 2026 GPU Pricing and Real Cost
2. UsagePricing — RunPod Pricing Calculator (2026 Rates)
3. Thunder Compute — Runpod Pricing vs Thunder Compute (2026): H100, A100, RTX 4090
4. SynpixCloud — Cloud GPU Pricing 2026: Lambda, AWS, Google Cloud, Runpod
5. ComputePrices — Runpod GPU Pricing: Compare 33+ GPUs
6. Claudia Yao (Medium) — Setting Up a TensorRT Environment on a RunPod GPU Container (driver’ın host’ta olduğu üzerine)
7. Runpod — PyTorch 2.4 and CUDA 12.4 on Runpod: Driver Compatibility Guarantees
8. runpodctl (GitHub) — Issue #253: CUDA/Driver Compatibility When Scheduling Pods
9. vLLM Docs — RunPod Deployment (Proxy URL and Port 8000)
10. Runpod — Deploy vLLM with Docker on Runpod: Container Config, Model Loading, Production Tuning
11. Markaicode — RunPod Setup Guide: Deploy Your First GPU Pod Step by Step
12. Will It Run AI — vLLM Tensor Parallel Setup: Exact VRAM Math per GPU Count
13. AI Shipping Labs — Serving Open Models with vLLM on RunPod (Workshop Notes)