AI Inference Client’a mı iniyor?

AI inference veri merkezinden client’a mı taşınıyor? Apple M5, NVIDIA DGX Spark, AMD ve Microsoft üzerinden performans, enerji, maliyet ve dağıtılmış AI mimarisinin yeni ekonomisini inceliyoruz.

Paylaş
AI Inference Client’a mı iniyor?

Apple Silicon M5, NVIDIA’nın deskside supercomputer yaklaşımı, AMD’nin unified memory (CPU ve GPU’nun ortak bellek havuzunu kullanabildiği mimari) mimarileri ve Microsoft’un Hybrid Intelligence vizyonu: Zekâ hangi cihazda, hangi koşulda ve hangi maliyetle çalışmalı?

Yapay zekânın son birkaç yılını dev veri merkezlerinin hikâyesi olarak okuduk. En güçlü GPU’lar, gigawatt ölçeğinde enerji yatırımları ve milyarlarca dolarlık hesaplama kümeleri bu hikâyenin merkezindeydi. Fakat 2026 sonbaharında aynı anda başka bir bilgisayar ortaya çıkıyor: masanın üzerinde, dizüstünde veya bir departmanın küçük sunucu odasında çalışan yapay zekâ. Bu, veri merkezinin sonu değil; zekânın üretildiği yerin yeniden tartışmaya açılması.

Apple’ın 25 Ağustos Mac Studio duyurusu, M5 Ultra ile 512 GB’a kadar unified memory ve 1,2 TB/s memory bandwidth (belleğin saniyede taşıyabildiği veri miktarı) açıkladı. NVIDIA’nın 2 Ekim duyurusu, DGX Spark ailesine 64 GB’lık yeni seçenek ve küçük AI node’ları birleştiren küme yaklaşımı ekledi. Microsoft’un Hybrid Intelligence duyurusu 7 Ekim’de Windows için yeni ilkeyi ortaya koydu: uygun görev cihazda, gerektiğinde bulutta. AMD’nin Ryzen AI Max PRO 400 açıklaması ise 192 GB birleşik belleği x86 iş istasyonu tarafına taşıdı. Dört hamle aynı haftalarda tek bir soruyu büyütüyor: Inference gerçekten client’a dağıtılabilir mi?

Ortak nokta yalnız yeni bir işlemci yarışı değil. Bir dil modelinin mutlaka uzak API’de çalışması gerektiği varsayımı zayıflıyor. Küçük sınıflandırma modeli kişisel bilgisayarda, daha büyük kod modeli ekipçe kullanılan deskside AI server (masa yanında konumlanan, ekipçe paylaşılabilen AI sunucusu)’da, hassas belge analizi kurumun özel altyapısında, en zor muhakeme ise onaylı bulutta çalışabilir. Üstelik tek kullanıcı isteği, farklı adımlarında bu katmanların birkaçını kullanabilir.

İş modelindeki kırılma burada. Şirketler artık yalnızca “kaç GPU satın alalım?” veya “hangi model API’sine abone olalım?” diye sormayabilir. Çalışanların zaten sahip olduğu silikon, kişisel iş istasyonları, departmental AI server (bir departmanın ortak kullandığı yerel AI sunucusu)’lar, kurumsal GPU havuzu ve bulut arasında kapasiteyi nasıl paylaştıracağını sorabilir. Bazı işlerde API token ücreti azalırken cihaz amortismanı, enerji, yönetim ve model kalitesi yeni maliyet kalemleri haline gelir.

Ancak modelin cihaza sığması yetmez. Kabul edilebilir ilk-token gecikmesi, saniyelik üretim hızı, eşzamanlı kullanıcı sayısı, güç tüketimi, veri politikası ve başarılı görev başına maliyet birlikte tutmalıdır. Yazının tezi bu yüzden “AI buluttan kaçıyor” değil: Eğitim hesaplamayı merkezileştirirken inference, doğru iş yüklerinde dağıtılabilir. Nerede çalışacağına marka değil, ölçüm ve politika karar vermelidir.

1. AYNI ZEKÂ, FARKLI COĞRAFYA

Training, yani modelin eğitimi, büyük modellerde yüksek hızlı ağlarla birbirine bağlanmış çok sayıda hızlandırıcı, ortak veri erişimi ve yoğun enerji gerektirir. Bu nedenle endüstriyel ölçekteki eğitim hesaplamayı merkezileştirir. Inference ise eğitilmiş modelin her yeni istekte çıktı üretmesidir. Ses komutunu tanımak, dosyayı sınıflandırmak, kod önermek, görüntü analiz etmek veya ajanın sonraki adımını planlamak farklı büyüklüklerde inference işleridir.

Önceki Inference Ekonomisi yazısında fiziksel kapasitenin ancak utilization (satın alınan kapasitenin gerçekten faydalı iş için kullanıldığı oran), serving, caching ve doğru model seçimiyle ekonomik değere dönüştüğünü görmüştük. Şimdi zincire coğrafya ekleniyor: Hesaplama kapasitesi nerede durmalı? Kullanıcıya yakın cihazda mı, ekipçe paylaşılan düğümde mi, kurumun veri merkezinde mi, elastik bulutta mı?

Bu ayrım beş katman yaratıyor: telefon ve kişisel client; güçlü workstation; deskside veya workgroup AI node; kurumsal edge/on-prem GPU havuzu; public cloud. Bunlar birbirinin alternatifi olduğu kadar tamamlayıcısıdır. Kuruma uygun mimari, her görevi tek katmana zorlayan değil, sınırları belirlenmiş geçişler kuran mimaridir.

2. APPLE: CİHAZ ÖNCE, AMA YALNIZCA CİHAZ DEĞİL

Apple’ın M5 açıklaması Ekim 2025’te GPU çekirdeklerindeki Neural Accelerator’ları ve 153 GB/s unified memory bandwidthni öne çıkardı. M5 Pro ve M5 Max duyurusu Mart 2026’da M5 Max için 128 GB’a kadar bellek ve 614 GB/s bandwidth getirdi. Apple’ın 2026 Mac Studio açıklaması Ağustos’ta M5 Ultra için 512 GB ve 1,2 TB/s düzeyine çıktı. Bunlar resmi donanım özellikleridir; gerçek token/saniye performansını garanti etmez. Ayrıca 512 GB yapılandırmanın sevkiyatı 12 Ekim itibarıyla henüz başlamamış, ekim sonuna planlanmıştır.

Unified memory (unified memory), CPU ve GPU’nun aynı bellek havuzuna erişmesidir. Büyük model ağırlıklarını ayrı ekran kartının sınırlı VRAM’ine sıkıştırma zorunluluğunu azaltabilir. Fakat bellek kapasitesi ile bandwidth farklıdır: ilki model ve KV cache’in sığıp sığmayacağını, ikincisi özellikle token token üretimde verinin ne hızla taşınacağını etkiler. 512 GB’a model yükleyebilmek, 512 GB’lık modelin her kullanıcıya akıcı yanıt vereceği anlamına gelmez.

Apple’ın yazılım hikâyesi de iki katmanlı. Foundation Models framework, uygulamalara cihaz üzerindeki Apple Foundation Models’a erişim ve uygun görevlerde bağlantısız çalışma sunuyor. Mac’te MLX ve Core AI geliştiricilerin kendi modellerini çalıştırmasına alan açıyor. Ancak Apple Intelligence yalnızca on-device değil: daha karmaşık işler için Private Cloud Compute kullanılıyor. Private Cloud Compute genişleme notu Haziran 2026’da Google Cloud üzerinde NVIDIA GPU’larıyla yeni çalışma yolunu açıkladı. Yani cihaz önceliği bulutun ortadan kalkması değil; buluta çıkışın daha seçici ve gizlilik koşullarıyla yönetilmesi.

Apple’ın güvenlik vaatleri teknik mimari ve doğrulanabilirlik mekanizmalarıyla destekleniyor. Ancak şirketin kendi gizlilik güvenceleri, kurumun veri sınıflandırması, hukuki değerlendirmesi ve bağımsız denetiminin yerine otomatik geçmez. Cihazdaki model ile Private Cloud Compute’daki model aynı çalışma yeri değildir.

3. NVIDIA: DESKSIDE SUPERCOMPUTER NEDEN ÖNEMLİ?

DGX Spark teknik özellikleri Grace Blackwell GB10, 128 GB unified memory, 273 GB/s bandwidth, CUDA ekosistemi ve 200 Gb/s ConnectX-7 bağlantısı içeriyor. NVIDIA’nın “1 PFLOP FP4” ifadesi sparsity kullanan teorik düşük hassasiyetli hesaplama tavanıdır. Bu sayı 1 milyon token/saniye demek değildir; BF16 kapasitesi veya gerçek inference throughput’u ile doğrudan kıyaslanamaz.

NVIDIA’nın 2 Ekim duyurusu ile gelen 64 GB Spark, 23 Ekim’de OEM’lerden satışa sunulacak yeni yapılandırmadır; 12 Ekim itibarıyla sevk edilmiş ürün gibi ele alınamaz. “100B modele kadar” ve iki 64 GB cihazda “200B’ye kadar” söylemleri modelin sıkıştırmasına, bağlama ve çalışma ortamına bağlı üretici kapasite iddialarıdır. NVIDIA’nın belirli Qwen testinde iki cihaz için verdiği 1,7 kat artış genel ölçeklenme garantisi değildir.

Asıl yenilik, masaüstü bilgisayar ile veri merkezi arasında yeni bir sahiplik biçimi doğmasıdır. Ekip kendi açık ağırlıklı modelini yerel ağda paylaşabilir, gerektiğinde AI node ekleyebilir ve CUDA/vLLM/TensorRT ekosistemine yakın kalabilir. Ama tek cihazın güçlü olması 32 eşzamanlı kullanıcıya istenen gecikmeyle hizmet vereceği anlamına gelmez. Deskside bilgisayar da bir serving ve operasyon problemidir.

NVIDIA’nın daha büyük DGX Station for Windows yönü ayrı sınıftır. Microsoft 7 Ekim’de GB300 tabanlı deskside sistemlerin yıl içinde geleceğini ve ekipler için 32 veya daha fazla eşzamanlı ajan hedefini açıkladı. Bu duyurulmuş platform vizyonudur; her modelde bağımsızca doğrulanmış 32 ajanlık SLA değildir. Spark ile Station aynı ürün, aynı fiyat veya aynı kapasite kategorisi değildir.

4. MICROSOFT VE AMD: YEREL INFERENCE EKOSİSTEME DÖNÜŞÜYOR

Microsoft’un Hybrid Intelligence duyurusu, yerel AI’yı yalnız donanım özelliği değil, işletim sistemi ve ajan çalışma mimarisi olarak tarif ediyor. Windows ML, CPU/GPU/NPU üzerinde uygun çalışma yolunu soyutlamayı hedefliyor. GitHub HydraFusion’ın yerel modellere yönlendirmesi ekim sonunda deneysel önizleme olarak planlanıyor. Copilot’un local context, local actions ve local models özellikleri de aşamalı gelecek. Bunların bugün tüm Windows cihazlarında aynı olgunlukta hazır olduğu varsayılmamalı.

Surface ürün duyurusu, Surface Laptop Ultra’nın 16 Ekim’de, Surface RTX Spark Dev Box’ın ABD sevkiyatının kasımda başlayacağını söylüyor. 128 GB’a kadar unified memory ve büyük modelleri yerel çalıştırma hedefi, sıradan NPU’lu ofis PC’si ile yüksek kapasiteli AI workstation arasındaki farkı gösteriyor. Microsoft’un cihaz karşılaştırmalarındaki hız oranları üretici testidir; Apple veya AMD’nin farklı modellerdeki sonuçlarıyla doğrudan kıyaslanmamalı.

AMD’nin Ryzen AI Max PRO 400 açıklaması, 192 GB’a kadar unified memory ve GPU’ya ayrılabilen 160 GB kapasiteyi x86 workstation tarafına taşıyor. “300B+ model” ifadesi 4-bit sıkıştırma varsayımına dayanıyor. AMD’nin güncel sistem notu bu cihazların kurumsal yerel ajan kullanımını hedeflediğini anlatıyor. Yeni 400 serisinin gerçek model hızları, önceki 395 neslinin benchmark’larıyla karıştırılmamalı.

ASUS “local-first, cloud-flexible”, Dell “deskside agentic AI”, HP yerel AI workstation gibi kavramlarla benzer soruya farklı yanıt veriyor. Adlar değişiyor, mimari soru aynı: Model, veri, araç çalıştırma ve politika sınırları hangi fiziksel katmanda olmalı?

5. BROŞÜRDEN ÖLÇÜLEBİLİR DONANIMA

İlk tablo üreticilerin resmi teknik verilerini yan yana getiriyor. Farklı cihaz türleri, güç bütçeleri ve bellek düzenleri aynı benchmark değildir. Maksimum bellek seçenekleri her konfigürasyonda mevcut olmayabilir; sevkiyat tarihleri özellikle önemlidir.

Platform

Bellek üst sınırı

Bant genişliği

12 Ekim durumu

Not

Apple M5 (temel)

32 GB

153 GB/s

Sevkiyatta

Client; küçük/orta model

Apple M5 Max

128 GB

614 GB/s

Sevkiyatta

MacBook Pro / Mac Studio

Apple M5 Ultra

512 GB

1,2 TB/s

512 GB ekim sonu

Büyük yerel model; vendor spec

NVIDIA DGX Spark

128 GB

273 GB/s

Sevkiyatta

GB10; 240 W adaptör, 140 W TDP

NVIDIA Spark 64 GB

64 GB

273 GB/s sınıfı

23 Ekim planı

OEM SKU; vendor spec

AMD Ryzen AI Max+ 395

128 GB

256 GB/s

Sevkiyatta

Eski nesil benchmark referansı

AMD Ryzen AI Max PRO 400

192 GB

Ürüne göre teyit

OEM modelleri var

GPU’ya 160 GB ayrılabilir

Kaynaklar: Apple’ın M5 açıklaması, M5 Pro ve M5 Max duyurusu, Apple’ın 2026 Mac Studio açıklaması; DGX Spark teknik özellikleri ve NVIDIA’nın 2 Ekim duyurusu; AMD’nin Ryzen AI Max PRO 400 açıklaması. Bellek, bandwidth, FP4 hesaplama ve güç farklı metriklerdir.

Apple’ın M5 Ultra bandwidth ile NVIDIA Spark’ın FP4 petaFLOP değeri farklı fiziksel büyüklüklerdir. NVIDIA’nın 240 W adaptör değeri de cihazın sürekli 240 W tükettiği anlamına gelmez. AMD 400 serisinde toplam sistem belleği, GPU’ya ayrılabilir bellek ve kullanılabilir model belleği aynı değildir.

6. MODEL SIĞIYOR MU, YOKSA İŞ BİTİYOR MU?

Bir modelin parametre sayısı cihaza sığma hesabının başlangıcıdır. 4-bit quantization kaba olarak parametre başına yarım bayt ağırlık alanı kullanır; ölçekler, metadata ve çalışma formatı ek yük yaratır. KV cache, uzun context, batch büyüklüğü ve runtime çalışma alanı için ayrıca bellek gerekir. MoE (Mixture-of-Experts) modellerinde her token için ağırlıkların yalnız bir kısmı etkinleşebilir; bu decode hızını değiştirebilir, bütün ağırlıkların saklanması gereğini ortadan kaldırmaz.

Model tipi

Kaba 4-bit ağırlık

Ek ihtiyaç

İlk yorum

8B dense

~4 GB

KV cache + runtime

Çoğu modern client adayı

27B dense

~13,5 GB

Uzun context’te artar

Yüksek RAM’li PC/workstation

70B dense

~35 GB

KV cache ve batching büyük

Sığmak ≠ akıcı hız

120B toplam MoE

~60 GB

Aktif uzman sayısı ve cache

Hız mimariye çok bağlı

300B toplam MoE

~150 GB

Sıkıştırma ve servis payı

192 GB sınıfında bile test şart

Kaba hesap yalnız ağırlıklar içindir; modelin kesin GGUF/MXFP4 dosya boyutu ve KV cache’i farklı olabilir. llama.cpp DGX Spark sonuçları, gpt-oss-120b MXFP4 paketinin yaklaşık 59 GiB olduğunu gösteriyor.

7. GERÇEK TOKEN HIZI: ÜRETİCİ İDDİASI VE BAĞIMSIZ TEST

LLM Bench deney seti, Apple M5 Max, NVIDIA DGX Spark ve AMD Ryzen AI Max+ 395 üzerinde aynı Qwen3.5 model ailesi, aynı Q4_K_M GGUF ve llama.cpp tabanıyla tek akış üretim hızını karşılaştırıyor. Beş tekrarlı medyan, rastgele test sırası ve önbellek kontrolü gibi yöntem ayrıntıları yayımlanmış. Yine de hakemli veya kurumsal SLA denetiminden geçmiş bir benchmark değil; bağımsız ve yeniden çalıştırılabilir topluluk ölçümüdür.

Qwen3.5 / Q4_K_M

M5 Max 128 GB

DGX Spark 128 GB

Ryzen AI Max 395

9B dense

75,9 tok/s

36,8 tok/s

32,6 tok/s

27B dense

24,8 tok/s

11,5 tok/s

10,3 tok/s

35B-A3B MoE

94,1 tok/s

59,6 tok/s

58,0 tok/s

122B-A10B MoE

42,9 tok/s

21,7 tok/s

22,9 tok/s

Kaynak: LLM Bench deney seti, Track B; tek akış, 512 output token, Q4_K_M, ortak llama.cpp/GGUF. Ölçülen sistemler farklı konfigürasyonlardır. Bu tablo M5 Ultra veya AMD 400 serisi benchmark’ı değildir; güç, TTFT, kalite ve çoklu kullanıcı ölçmez.

Öğretici sonuç kazanan marka değil: 35B toplam fakat yaklaşık 3B aktif parametreli MoE (Mixture of Experts, yani her istekte tüm parametreler yerine ilgili uzman alt ağların etkinleştirildiği model) modelinin 27B dense (her token üretilirken modelin ilgili bütün katmanlarının çalıştığı yoğun mimari) modelden hızlı çıkabilmesi, model mimarisinin belirleyici olduğunu gösteriyor. LLM Bench’in M5 Max için verdiği bandwidth metadata’sı Apple’ın resmi 614 GB/s değeriyle uyuşmuyor. Bu nedenle hız sonuçları bağımsız tekrar gerektiren topluluk verisi olarak kalmalı; kesin satın alma sıralaması çıkarılmamalı.

İkinci bağımsız kanıt GPUwerk ölçüm raporu: 2 Eylül 2026’da tek DGX Spark AI node üzerinde vLLM 0.27.1 ile iki model mimarisinin concurrency karşısındaki davranışını ölçüyor. GPUwerk metodolojisi test girdilerini ve ham logları açıklıyor. LLM Bench ile model, engine ve quantization farklı olduğu için iki tablo arasında doğrudan hız oranı kurulamaz.

8. TEK KULLANICI İLE OTUZ İKİ KULLANICI AYNI İŞ DEĞİL

Tek kullanıcı için 80 token/saniye iyi deneyim olabilir. Otuz iki kullanıcı geldiğinde soru yalnız toplam throughput değildir. İlk token’a kadar süre (TTFT, yani kullanıcının yanıtın ilk parçasını görene kadar beklediği süre), her kullanıcının decode hızı, P95 gecikme, kuyruk, hata oranı ve KV cache baskısı birlikte ölçülür. Batching GPU’yu daha verimli doldurabilir ama istek başına beklemeyi uzatabilir.

Eşzamanlı istek

MoE 30B: kişi başı decode

Dense 70B: kişi başı decode

MoE toplam*

Dense toplam*

1

80,9 tok/s

6,0 tok/s

80,9 tok/s

6,0 tok/s

8

35,2 tok/s

5,2 tok/s

845 tok/s

125 tok/s

32

18,4 tok/s

3,9 tok/s

1.679 tok/s

298 tok/s

128

8,2 tok/s

1,4 tok/s

3.010 tok/s

485 tok/s

Kaynak: GPUwerk ölçüm raporu, 2 Eylül 2026, tek DGX Spark, vLLM 0.27.1, AWQ. *1 istek satırı ayrı kısa testte yalnız output decode; 8/32/128 toplam değerleri prompt + output token’larını birlikte sayıyor ve 512 input/256 output, üç istek/slot koşullarına dayanıyor. Toplam ile kişi başı hız doğrudan bölünemez.

MoE modelin 32 istekte kişi başına 18,4 token/saniyeye, dense 70B’nin 3,9’a düşmesi, “model açılıyor” ile “kurumsal asistan çalışıyor” arasındaki farkı gösterir. Bu tablolar Apple M5 Ultra’nın 32 kullanıcı performansını, AMD 400 serisinin concurrency’sini veya tüm cihazların duvar prizi gücünü kanıtlamıyor.

9. ENERJİ VE TCO (Total Cost of Ownership, yani donanım, enerji, bakım, yönetim ve amortismanı içeren toplam sahip olma maliyeti): YEREL HER ZAMAN UCUZ DEĞİL

Yerel inference’ın API faturasını azaltması bedava olduğu anlamına gelmez. Satın alma ve amortisman, güç, soğutma, bakım, model güncelleme, güvenlik, izleme, ağ ve operatör zamanı maliyet üretir. Boşta duran sistem de enerji tüketir. Üstelik yerel model kalite eşiğini kaçırırsa başarısız görev ve buluta yeniden yönlendirme artabilir.

Enerji ölçümünde türleri ayırmalıyız. DGX Spark’ın 240 W güç adaptörü ve 140 W çip TDP’si üretici teknik değeridir; sürekli wall power değildir. Tom’s Hardware ölçümü, belirli Spark cihazında yazılım güncellemesi sonrası yaklaşık 22-25 W boşta tüketim raporladı; bu bağımsız ama tek cihaz/firmware koşuluna özgü ölçümdür. Mobil enerji çalışması, iki telefon ve bir sunucu üzerinde batched sunucu inference’ının token başına daha verimli olabildiğini buldu. Bu ön çalışma tüm workstation’lara genellenemez; “local mutlaka daha yeşil” sloganına itirazdır.

Ekonomiyi somutlaştırmak için aşağıdaki hesabı yapalım. Bu gerçek bir cihazın ölçülmüş faturası değil, parametreleri açık karar simülasyonudur: 5.000 USD satın alma, 36 ay amortisman, ayda 100 USD operasyon gideri, aktifken 200 W, boşta 30 W, elektrik 0,15 USD/kWh, ayda 720 saat erişilebilirlik. Başarılı görev kalitesini sabit varsayıyoruz. 200 tok/s satırları, batching ile bu faydalı toplam output throughput’una ulaşıldığı varsayılan ikinci senaryodur; cihaz performans iddiası değildir.

Faydalı kullanım

Varsayılan üretim

Aylık output

Aylık toplam

1M output maliyeti

%10

50 output tok/s

12.96 M

243.96 $

18.82 $

%40

50 output tok/s

51.84 M

249.47 $

4.81 $

%80

50 output tok/s

103.68 M

256.82 $

2.48 $

%40

200 output tok/s

207.36 M

249.47 $

1.20 $

%80

200 output tok/s

414.72 M

256.82 $

0.62 $

Hesap: amortisman 5.000/36 + 100 USD/ay işletim + [(aktif saat × 0,2 kW) + (boşta saat × 0,03 kW)] × 0,15 USD/kWh. Finansman, vergi, soğutma, ağ, insan düzeltmesi ve model kalite farkı dahil değildir. Bu bir piyasa benchmark’ı değildir.

Aynı cihaz yüzde 10 kullanımda milyon output token başına yaklaşık 18,82 dolar, yüzde 80 kullanımda 2,48 dolar maliyet çıkarıyor. İş yükü gerçekten 200 faydalı output tok/s’ye ulaşırsa yüzde 80 kullanımda örnek maliyet yaklaşık 0,62 dolara iniyor. Yani yerel ekonomiyi donanım etiketi değil, yararlı utilization ve hizmet seviyesi belirliyor.

Peki bulut? Amazon Bedrock fiyat tablosu, 12 Ekim 2026 itibarıyla Sidney bölgesinde standart Qwen3 Coder 30B-A3B için milyon input token başına 0,1545 dolar ve output token başına 0,6180 dolar gösteriyor. OpenAI GPT-5.4 mini fiyat sayfası ise sırasıyla 0,75 ve 4,50 dolar. Bunlar gerçek liste fiyatları, fakat eşdeğer model kalitesi veya aynı quantization değildir. Yerel Qwen ile Bedrock Qwen’in aynı ağırlık/servis koşulunda olduğu da doğrulanmadı. Dolayısıyla yalnız “0,62 dolara indim, bulutla başa başım” sonucunu çıkaramayız; input, cache, kalite, tool çağrıları, bölge, SLA ve başarılı görev birlikte hesaplanmalı.

Bir başka fark yatırımın mevcut kapasiteye ek mi, sıfırdan mı yapıldığıdır. Zaten çalışan ve boş GPU zamanı olan workstation’ın marjinal maliyeti farklıdır; sırf AI için yeni alınan cihazın amortismanı farklı. Merkezi kurumsal GPU havuzunun yüksek utilization ve batching avantajı, onlarca düşük kullanımlı client cihazından daha ekonomik olabilir. Cloud fiyatı düştükçe eşik yeniden hesaplanmalıdır.

10. HANGİ İŞ HANGİ KATMANDA ÇALIŞMALI?

Karar matrisi bir ürün önerisi değil, ilk yönlendirme hipotezidir. “En yakın cihaz” ancak model kalite eşiğini, veri politikasını ve hizmet seviyesini sağlıyorsa doğru adrestir. Aynı görev farklı kurumlarda farklı katmana yerleşebilir.

Katman

Güçlü aday

Ana sınır

Ölçülecek karar

Client / laptop

Ses, basit özet, kişisel bağlam

Pil, ısı, RAM, cihaz çeşitliliği

TTFT, pil, privacy, kalite

Personal workstation

Kod, araştırma, özel büyük model

Tek kullanıcı/termal sınır

tok/s, aktif güç, TCO

Deskside / workgroup

Paylaşılan 20-120B MoE, ekip ajanı

Kuyruk, concurrency, bakım

1/8/32 kullanıcı, P95, utilization

Kurumsal on-prem / edge

Hassas veri, sürekli çok kullanıcı

CapEx, serving operasyonu

SLA, GPU doluluğu, güvenlik

Public cloud

Frontier model, ani talep, elastik iş

Egress, veri politikası, API maliyeti

Kalite, maliyet/görev, fallback

Yerleşim statik olmamalı. Ajan kişisel dosyaları yerelde tarayıp yalnız izinli özeti kurum içi modele gönderebilir; karmaşık muhakemeyi onaylı buluta taşıyabilir. Ancak veri minimizasyonu, kullanıcı rızası, kurum politikası, kayıt ve geri dönüş yolu her geçişte uygulanmalı. Bazı işler hiçbir koşulda buluta çıkmayabilir; bazıları da yerelde yeterli kaliteyi sağlayamayabilir.

11. MODELİN YERİ, AJANIN EYLEM YERİ DEĞİLDİR

Yerel model, agent oturumunun otomatik olarak çevrimdışı veya güvenli olduğu anlamına gelmez. Model client’ta çalışırken arama, kimlik doğrulama, CRM veya ödeme aracı uzakta olabilir. Yerel tool execution da cihazdaki dosya ve credential’lara doğrudan erişim riski yaratabilir. Bu nedenle inference placement ile execution placement ayrı kararlardır.

Microsoft Execution Containers, dosya, ağ ve işlem erişimini policy ile sınırlandırmaya çalışıyor. Apple’ın Private Cloud Compute yaklaşımı ise modelin buluta taşındığı durumda gizlilik güvencelerini teknik denetimle kurmaya çalışıyor. Bunlar aynı ürün değil, aynı mimari sorunun farklı parçaları: Hesaplamanın yeri kadar hangi yetkinin nerede kullanıldığı da tasarlanmalıdır.

Önceki AI Çalışmazsa Ne Olur? dosyasının dayanıklılık sorusu burada yeniden beliriyor. İnternet kesildiğinde local model ayakta kalabilir, fakat kimlik servisi, şirket verisi veya araç API’si erişilemiyorsa iş yine durabilir. Gerçek offline fallback, hangi görevlerin hangi yerel veri ve sınırlandırılmış yetkiyle devam edeceğinin önceden belirlenmesidir. Yerellik süreklilik imkânıdır, tek başına süreklilik garantisi değil.

12. YENİ YATIRIM MODELİ: HERKESİN MASASINA GPU MU?

Kurumun önünde artık yalnız “bulut mu, kendi veri merkezimiz mi?” ikilemi yok. Çalışan bilgisayarlarının boş kapasitesini, uzman workstation’larını, departman başına paylaşılan deskside AI server’larını, merkezi özel GPU havuzunu ve bulut taşmasını birlikte planlayabilir. Bu, finansmanı da değiştirir: token başına değişken gider ile amortismana yayılan yerel sermaye harcaması aynı mimaride birleşir.

Bin çalışanlı bir kurumda herkesin aynı büyük modeli laptop’unda tutması bellek, enerji ve güncelleme maliyetini çoğaltabilir. Buna karşılık sık kullanılan küçük kişisel modelleri yerelde çalıştırıp ağır işleri paylaşılan departmental AI server’a göndermek kaynak kullanımını iyileştirebilir. Fakat bu örnek bir tasarım hipotezidir. Gerçek karar için çalışma saatleri, eşzamanlılık, mevcut lisanslar, model kalitesi ve BT operasyonu ölçülmelidir.

Yeni metrik “kaç AI PC aldık?” değil, her katmanda üretilen başarılı iş başına toplam maliyet ve kabul edilebilir risk olmalıdır. Inference Ekonomisi’nin ölçüm merdiveni burada yeni basamak kazanıyor: Cost per token → Cost per successful task → Value per outcome; ayrıca bu sonucu hangi fiziksel katmanın ürettiği kayda girmelidir.

13. TEZİ NE YANLIŞLAR?

Yerel inference’ın büyümesini kesin zafer ilan etmek için erken. Frontier model kalite farkı açılırsa büyük işler buluta geri dönebilir. Cloud token fiyatları daha hızlı düşerse yerel amortisman zayıflar. Cihaz filosunu güncellemek, güvenli tutmak ve çok kullanıcılı servis etmek pahalı çıkabilir. Bellek artarken decode hızı, termal sınırlar veya pil ömrü darboğaz olabilir. Unified memory tek başına yüksek throughput değildir.

Satın alma öncesi asgari test aynı model ailesi ve mümkünse aynı ağırlık/quantization ile yapılmalı: 1/8/32 eşzamanlı istekte TTFT, P50/P95 yanıt (isteklerin sırasıyla yarısının ve yüzde 95’inin tamamlandığı süre), input/output token throughput’u, KV cache ve RAM, duvardan ölçülen aktif/boşta güç, görev kalitesi, hata/retry, 7/24 işletim maliyeti ve utilization. Bulut alternatifi de aynı prompt ve başarı kriteriyle test edilmelidir. Bugünkü kamuya açık ölçümler bu matrisin tüm hücrelerini doldurmuyor.

14. BİR KURUMUN İÇİNDE YÜZLERCE KÜÇÜK AI MERKEZİ

Bir kurumun gelecek mimarisini dört halkalı bir sistem olarak düşünelim. İlk halka çalışanların client cihazlarıdır: kişisel bağlam, düşük gecikme ve sınırlı, sık tekrarlanan görevler mümkün olduğunca burada yürür. Ancak yerel modelin kapasitesi veya kalite eşiği aşıldığında istek bir üst halkaya taşınır.

İkinci halka, birimin paylaştığı deskside AI node’dur. Hukuk ekibi sözleşme inceleme modelini, yazılım ekibi kod asistanını, çağrı merkezi konuşma çözümleme ve özetleme işlerini kendi yakın hesaplama havuzunda çalıştırabilir. Bir bakıma her departmanın küçük bir veri merkezi vardır. Fakat bu, her departmanın ayrı güvenlik politikası, ayrı model kataloğu ve ayrı operasyon ekibi kurması anlamına gelmemelidir.

Üçüncü halka kurumun merkezi AI altyapısıdır. Daha büyük modeller, çok kullanıcılı hizmetler, hassas veri sistemleri, ortak kimlik ve denetim kayıtları burada yönetilir. Dördüncü halka cloud’dur: yerel kapasite yetmediğinde, frontier model kalitesi gerektiğinde veya talep ani yükseldiğinde, kurumun izin verdiği veri ve görevler için devreye girer.

Bu dört halkayı gerçekten tek sisteme dönüştüren unsur model değil, yerleşim kararıdır. Bir yönlendirme katmanı önce veri hassasiyetini ve yetkiyi kontrol eder; ardından kalite eşiği, gecikme, kapasite, eşzamanlılık, enerji ve başarılı görev başına maliyeti değerlendirir. İstek en yakın cihaza değil, bu koşulları karşılayan en uygun katmana gider. Gerektiğinde başka katmana geçiş de aynı kurallarla yapılır.

Böyle bir mimari, şirketlerin AI yatırımını yalnız merkezi GPU alımı veya API bütçesi olarak değil, dağıtılmış kapasitenin yönetimi olarak görmesini gerektirir. İhtiyaç duyulan yeni yetenek; envanter, model dağıtımı, politika, ölçüm, maliyet atfı ve kesinti anındaki kontrollü davranışı uçtan uca yöneten bir kontrol düzlemidir. Bu vizyon bugünün her kurumunda kurulmuş bir gerçeklik değil; donanım ve yazılımın olgunlaşmasıyla test edilmesi gereken güçlü bir tasarım olasılığıdır.

Geleceğin AI altyapısı belki de tek bir dev veri merkezi olmayacak. Kullanıcının masasından departmanın küçük hesaplama AI node’a, kurum merkezinden buluta uzanan; merkezi olarak yönetilen ama fiziksel olarak dağıtılmış bir zekâ ağı olacak. Asıl rekabet de yalnız en güçlü çipi üretmekte değil, bu ağı güvenli, ekonomik ve yönetilebilir biçimde işletmekte yaşanabilir.

15. SONUÇ: YENİ BİLGİSAYAR BİR YER DEĞİL, YERLEŞİM KARARI

Bir dönem zekânın adresi model sağlayıcısının veri merkezi gibi görünüyordu. Şimdi Apple kişisel cihazdan gizlilik odaklı buluta uzanan yol, NVIDIA masanın üzerindeki paylaşılan AI node, AMD yüksek bellekli x86 workstation, Microsoft ise local ve cloud arasında akıllı yönlendirme öneriyor. Bu yollar birbirinin kopyası değil; farklı ekosistemlerin aynı ekonomik ve mimari probleme verdiği yanıtlar.

Training büyük ölçüde merkezileşmeye devam ederken inference’ın bir bölümü client’a, workstation’a ve departmental AI server’a inebilir. Ama her model değil, her görev değil, her zaman değil. Güçlü mimari “önce cihaz” veya “önce bulut” sloganıyla değil; kalite, gecikme, maliyet, enerji, güvenlik, eşzamanlılık ve iş sürekliliğini birlikte değerlendiren policy-driven workload placement ile kurulabilir.

AI’ın yeni fiziksel haritasında en önemli soru kaç GPU’ya sahip olduğumuz değil, doğru işi doğru yerde ve doğru yetkiyle çalıştırıp çalıştıramadığımız olabilir. Dağıtılan kapasitenin ekonomik değere dönüşmesi, her zamankinden fazla ölçüm ve kontrol gerektirecek.

Yapay zekâ Atlası'nda keşfetmeye devam edeceğiz. Bir sonraki yazıda görüşmek üzere.

How to Cite

M. Seçkin Bedük, “AI Inference Client’a mı iniyor?,” The Intelligence Atlas, 2026.