Omarchy 4.0 ve LLM Çıkarım Altyapısı: Yerel Edge AI Mimarisi ve Kurumsal Ölçeklenebilirlik
Puan —Omarchy 4.0 üzerinde LM Studio ve Intel Arc B580 ile yerel dil modeli çalıştırmak: kurulum, performans ve kurumsal kullanım.
İçindekiler
Özet: Yazı verinin dışarı çıkmaması gereken işler için dil modellerini yerelde çalıştırmayı savunuyor ve bunun için bir yapı öneriyor: Omarchy 4.0 çekirdeğinde düşük gecikmeli zamanlayıcı ve ReBAR ayarları, XMX motorları ve VRAM bant genişliği nedeniyle Intel Arc B580, ölçek için Arc Pro B70 kümeleri ve çıkarım tarafında LM Studio ile llama.cpp. Son bölüm gerçek kullanım senaryolarını sıralıyor.
Yapay zeka ekosistemi, son birkaç yılda devasa bir ivme kazanarak teknoloji dünyasının merkezine yerleşti. Ancak bu gelişimin ilk evresi, milyarlarca parametreye sahip Büyük Dil Modellerinin (Large Language Models - LLM) devasa veri merkezlerinde, bulut tabanlı API’ler aracılığıyla sunulmasıyla karakterize edildi. Günümüzde ise veri egemenliği (data sovereignty), gizlilik, güvenlik ve düşük gecikme (latency) talepleri, yepyeni bir paradigma değişimini zorunlu kılıyor: Yapay zekanın buluttan uca (Edge AI), yani yerel donanımlara taşınması.
Kurumsal sırların, tescilli kaynak kodların ve kişisel verilerin işlenmesi söz konusu olduğunda, verilerin üçüncü taraf sunuculara (OpenAI, Anthropic, Google Cloud vb.) gönderilmesi ciddi güvenlik riskleri barındırır. Bu bağlamda, tamamen kapalı devre (air-gapped) veya yerel ağ (LAN) üzerinden hizmet veren yapay zeka altyapıları bir lüks değil, siber güvenlik standartları açısından bir zorunluluktur. Bu makalede, tam da bu ihtiyaca yanıt vermek üzere tasarlanan Omarchy 4.0 Linux tabanlı işletim sistemini, bu mimarinin üzerinde koşan Intel Arc B580 donanım substratını, geleceğe dönük ARC Pro B70 ölçeklenebilirliğini ve LM Studio yazılımının orkestrasyon yeteneklerini mühendislik perspektifinden derinlemesine inceleyeceğiz.
1. Bulut AI’dan Yerel Edge AI’a Geçişin Anatomisi
Bulut tabanlı LLM’lerin en büyük dezavantajı deterministik olmayan gecikme süreleri ve sürekli artan işletme maliyetleridir. Bir kullanıcı veya uygulama bir API isteği gönderdiğinde, ağdaki yönlendirme (routing), sunucu tarafındaki kuyruğa alınma (queueing) ve modelin o anki yük durumuna bağlı olarak yanıt süresinde ciddi dalgalanmalar (jitter) yaşanır. Gerçek zamanlı sistemlerde, otonom karar alma mekanizmalarında veya akıllı ev otomasyonlarında bu gecikmeler kabul edilemez.
Edge AI mimarisi, çıkarım (inference) işlemini doğrudan verinin üretildiği yerde veya kullanıcıya en yakın yerel sunucuda gerçekleştirir. Bu geçişin temel motivasyonları şunlardır:
-
Sıfır Veri Sızıntısı (Zero Data Exfiltration): Veri, fiziksel donanımı asla terk etmez. Bu durum GDPR, KVKK ve HIPAA gibi sıkı veri koruma regülasyonlarına tam uyum sağlar.
-
Düşük ve Sabit Gecikme (Low and Deterministic Latency): İnternet bağlantısından bağımsız çalışabilme yeteneği, milisaniyeler seviyesinde (Time to First Token - TTFT) yanıt süreleri elde edilmesini sağlar.
-
Maliyet Optimizasyonu (CapEx vs. OpEx): Bulut API’lerinde her token üretimi operasyonel bir giderdir (OpEx). Yerel mimaride ise donanım bir kez satın alınır (CapEx) ve sonrasında sadece elektrik ve soğutma maliyetiyle sınırsız çıkarım yapılabilir.
2. İşletim Sistemi Çekirdeği: Omarchy 4.0 ve Derin Kernel Optimizasyonları
Yapay zeka iş yükleri için sıradan bir masaüstü işletim sistemi kullanmak, yüksek performanslı bir spor arabayı toprak yolda kullanmaya benzer. Omarchy 4.0, özellikle Arch ve Fedora tabanlı Linux sistemlerinin esnekliğini ve modülerliğini temel alarak, yapay zeka geliştiricileri için sıfırdan derlenmiş (custom-compiled) deterministik bir işletim sistemi vizyonudur. LLM çıkarım süreçlerinde işlemcinin (CPU), sistem belleğinin (RAM) ve grafik belleğinin (VRAM) birbiriyle mikrosaniyeler seviyesinde kesintisiz haberleşmesi hayati önem taşır.
Low-Latency Kernel ve Zamanlayıcı (Scheduler) Mimarisi
Omarchy 4.0, standart Linux CFS (Completely Fair Scheduler) yerine yapay zeka iş yüklerine özel yapılandırılmış düşük gecikmeli (low-latency/PREEMPT_RT) bir kernel kullanır. Bu kernel konfigürasyonu, CPU üzerinde çalışan çıkarım motorunun arka plan görevleri tarafından kesintiye uğramasını (context switching overhead) engeller. Model ağırlıklarının diskten belleğe, bellekten VRAM’e aktarılması sırasında oluşan I/O darboğazları, optimize edilmiş kernel parametreleriyle minimuma indirilir.
PCIe Bus Yönetimi ve Resizable BAR (ReBAR)
LLM’lerin en büyük düşmanı VRAM darboğazıdır. Sistem belleğinden ekran kartına veri aktarılırken, geleneksel sistemlerde CPU, VRAM’e sadece 256MB’lık küçük bloklar halinde erişebilir. Omarchy 4.0, çekirdek seviyesinde Resizable BAR (Base Address Register) teknolojisini agresif bir şekilde yöneterek, işlemcinin GPU’nun tüm bellek havuzuna tek seferde erişmesine olanak tanır. Bu sayede model yükleme süreleri saniyelere düşer ve “offloading” (VRAM yetmediğinde modelin bir kısmının sistem RAM’inde çalıştırılması) durumlarında PCIe veri yolunun (bus) tam bant genişliği (PCIe 4.0 x16 için ~31.5 GB/s) verimli bir şekilde kullanılır.
Çatışmasız Bağımlılık Yönetimi
Yapay zeka ekosistemi kütüphane cehennemi (dependency hell) olarak bilinir. NVIDIA CUDA, AMD ROCm, Intel oneAPI/SYCL, PyTorch ve TensorFlow versiyonları sürekli birbirleriyle çakışır. Omarchy 4.0’ın yalıtılmış paket yönetimi, bu kütüphanelerin container veya izole sanal ortamlar (venv/conda) kullanmadan, doğrudan donanıma (bare-metal) en yakın seviyede, birbirlerini bozmadan yerel olarak derlenmesini sağlar.
3. Donanım Substratı: Intel B580 Seçiminin Mühendislik Gerekçesi
LLM çıkarım işlemi sanılanın aksine doğrudan hesaplama gücüne (TFLOPS) aç bir işlem değildir; çıkarım işlemi Bellek Bant Genişliği (Memory Bandwidth) ile sınırlanan (Memory-bound) bir süreçtir. “Text generation” aşamasında üretilen her bir token için, modelin tüm ağırlıklarının bellekten okunup işlem birimlerine iletilmesi gerekir. Bu mühendislik gerçeği ışığında, Intel’in Xe-HPG (High Performance Graphics) mimarisine dayanan B580 kartının seçilmesi tesadüf değildir.
Xe Matrix Extensions (XMX) Motorları
Yapay zeka modellerinin temeli devasa matris çarpım işlemlerine (GEMM - General Matrix Multiply) dayanır. Intel B580 mimarisinde bulunan XMX (Xe Matrix Extensions) donanım birimleri, standart ALU’lara kıyasla matris operasyonlarını tek bir saat döngüsünde (clock cycle) çoklu veri işleyerek (Systolic Array benzeri bir yaklaşımla) donanımsal olarak ivmelendirir. XMX, özellikle düşük hassasiyetli veri tiplerinde (FP16, bfloat16, INT8) yüksek verimlilik sunar.
VRAM Bant Genişliği ve Kuantizasyon Verimliliği
B580’in optimize edilmiş bellek kontrolcüsü, hızlı GDDR bellek modülleriyle birleştiğinde yüksek bir bellek bant genişliği sunar. Kuantizasyon teknikleri (modeli 16-bit’ten 4-bit’e sıkıştırma) uygulandığında, bellekten okunması gereken veri miktarı dörtte birine düşer. B580’in bellek veri yolu, bu sıkıştırılmış ağırlıkları XMX motorlarına beslerken kesintiye uğramaz, bu da saniyede üretilen token (Tokens per Second - t/s) oranını doğrudan maksimize eder.
NVIDIA Tekelini Kırmak: oneAPI ve SYCL Standartları
Sektörde NVIDIA ve CUDA ekosisteminin kurduğu tekel, donanım maliyetlerini suni olarak yükseltmektedir. Intel’in açık standartlara dayalı donanım bağımsız programlama modeli olan SYCL ve oneAPI araç setleri, açık kaynaklı LLM motorlarıyla (llama.cpp gibi) sorunsuz çalışır. Bu uyum, geliştiricilerin kodlarını bir kez yazıp hem Intel CPU’larda, hem entegre GPU’larda, hem de B580 gibi ayrık (discrete) hızlandırıcılarda performans kaybı yaşamadan çalıştırmasına olanak tanır.
4. Ölçeklenebilirlik Vizyonu: Çoklu ARC Pro B70 Kümeleri ve Kurumsal AI
Günümüzde açık kaynaklı ve performansı kapalı modellere (GPT-4) denk olan Llama 3 70B, Qwen 72B veya Mixtral 8x22B gibi modeller mevcuttur. Ancak bu devasa modellerin en büyük handikabı “VRAM Duvarı”dır (VRAM Wall). Tek bir GPU’nun belleği bu modelleri yüklemeye yetmez. Kurumsal çapta bir yapay zeka altyapısı kurmak için sistemin yatayda ve dikeyde ölçeklenebilir (scalable) olması şarttır.
Omarchy 4.0 mimarisinin bir sonraki vizyonu, yüksek performanslı ve iş istasyonu (workstation) sınıfı olan ARC Pro B70 hızlandırıcı kartlarının çoklu (Multi-GPU) topolojilerle sisteme entegre edilmesidir. Bu geçişin temel hedefleri şunlardır:
-
Tensör Paralelliği (Tensor Parallelism): Çoklu B70 kurulumlarında, devasa bir LLM’in ağırlıkları (weights) tek bir karta yüklenmek yerine matematiksel olarak parçalanır ve birden fazla GPU’ya dağıtılır. Çıkarım sırasında bu kartlar PCIe 4.0/5.0 hatları üzerinden birbirleriyle yüksek hızda (P2P - Peer to Peer) iletişim kurarak sonucu ortaklaşa üretirler.
-
Devasa Bağlam Pencereleri (Massive Context Windows): Kurumsal kullanımda yüzlerce sayfalık PDF dosyalarının, veritabanı şemalarının veya binlerce satırlık log kayıtlarının modele analiz ettirilmesi gerekir. 128K veya 256K token büyüklüğündeki bu bağlam pencereleri (Context/KV Cache) devasa VRAM tüketir. B70 dizisinin birleştirilmiş VRAM havuzu, bu cache belleğin sisteme (RAM’e) taşmasına gerek kalmadan doğrudan GPU üzerinde işlenmesini sağlar.
-
Eşzamanlı Çıkarım (High-Throughput Batching): Bir kurum ağında, aynı anda onlarca personel veya servis yerel LLM’e istek gönderebilir. Çoklu GPU altyapısı, Continuous Batching algoritmalarıyla farklı istekleri aynı anda (paralel olarak) işleyerek, sistemin saniyedeki toplam çıktı hacmini (Throughput) kurumsal API hizmetleri seviyesine çıkarır.
5. Çıkarım Motoru ve Yazılım Katmanı: LM Studio ve llama.cpp
Mükemmel bir donanım ve işletim sistemi, ancak üzerinde koşan yazılım kadar yeteneklidir. Sistemin kullanıcı arayüzü, model orkestrasyonu ve API sunum katmanı olarak LM Studio konumlandırılmıştır.
Sadece Bir Arayüz Değil, Tam Teşekküllü Bir REST API Sunucusu
LM Studio’yu sıradan sohbet uygulamalarından ayıran en temel özellik, arka planda yerel bir REST API sunucusu (OpenAI API spesifikasyonlarıyla %100 uyumlu) olarak çalışabilmesidir. Bu sayede bir yazılım geliştirici, mevcut kodundaki (örneğin LangChain veya AutoGen ile yazılmış bir projedeki) OpenAI API adresini (base_url) http://localhost:1234/v1 olarak değiştirdiği anda, tüm sistem hiçbir kod değişikliğine gerek kalmadan buluttan yerel donanıma taşınmış olur.
Motor Dairesi: llama.cpp ve GGUF Formatı
LM Studio, kaputun altında sektör standardı haline gelen llama.cpp motorunu kullanır. Georgi Gerganov tarafından C/C++ ile geliştirilen bu motor, minimum bellek ayak izi ve maksimum performans prensibiyle çalışır. Intel’in SYCL backend’i llama.cpp’ye resmi olarak entegre edilmiştir.
llama.cpp’nin en önemli yeniliği GGUF (GPT-Generated Unified Format) adlı model dosya formatıdır. Geleneksel PyTorch modelleri (saf FP16 tensörler) onlarca gigabayt yer kaplar. GGUF formatı ve beraberinde getirdiği kuantizasyon algoritmaları (Q4_K_M, Q5_K_M, AWQ, GPTQ) sayesinde modelin ağırlıkları 4-bit veya 8-bit tam sayılara (integer) dönüştürülür.
GGUF kuantizasyonu basit bir dosya sıkıştırması (zip) değildir. Bu, yapay sinir ağının bağlantı ağırlıklarının matematiksel hassasiyetinin, modelin analitik zekasını (perplexity) neredeyse hiç bozmadan düşürüldüğü kayıplı ama zeki bir optimizasyon sürecidir. Bu sayede 70 Milyar parametreli bir model, yüzlerce gigabayt VRAM yerine 40-45 GB VRAM havuzuna sığdırılabilir.
6. Yerel Edge AI Mimarisi İçin Gerçek Dünya Kullanım Senaryoları
Omarchy 4.0 tabanlı bu tam donanımlı yapı, pratikte birçok yeni kullanım senaryosunun kapısını aralar:
-
Yerel Kod Asistanları: Yazılım mühendisleri, VS Code veya Neovim gibi editörlerine Continue.dev gibi eklentiler kurarak, LM Studio’nun sunduğu yerel API üzerinden kod tamamlama ve refactoring işlemlerini gerçekleştirebilirler. Özel kurumsal projelerin kodları internete sızmamış olur.
-
RAG (Retrieval-Augmented Generation) Sistemleri: Kurumun kendi iç dokümanları (PDF’ler, sözleşmeler, yönetmelikler) vektör veritabanlarına (ChromaDB, Milvus) dönüştürülerek, tamamen yerel ağda çalışan ve dışarıya kapalı bilgi sorgulama botları (Enterprise Search) oluşturulabilir.
-
Akıllı Ağ ve Güvenlik Analizi: Yerel router logları, OPNsense/pfSense güvenlik duvarı kayıtları ve IDS/IPS sistemlerinden gelen veriler yerel LLM’e beslenerek, anormallik tespiti ve siber saldırı analizleri otomatikleştirilebilir.
Benim okumam
Bulut bilişim yapay zekayı demokratikleştirmiş olsa da, teknolojinin geleceği gizlilik, hız ve kontrolün merkeze alındığı Edge AI mimarisindedir. Omarchy 4.0 Linux çekirdeğinin deterministik stabilitesi, Intel Arc B580’in (ve gelecekteki B70 kümelerinin) XMX ve VRAM bant genişliği gücü, LM Studio ve llama.cpp ikilisinin yazılım optimizasyonlarıyla birleştiğinde ortaya çıkan ekosistem, bireysel hobi projelerinin çok ötesindedir.
Bu mimari; kurumların kendi yapay zeka kaderlerini tayin edebildikleri, verinin fiziksel sınırları terk etmediği, dışa bağımlılığın sıfırlandığı tam teşekküllü bir Yerel AI Kümesi (Local Edge AI Cluster) manifestosudur. Açık kaynak kodlu yazılımlar ve Intel’in donanım standartları (oneAPI/SYCL) geliştikçe, bu altyapının token üretim hızı ve çalıştırabileceği model parametre boyutu logaritmik olarak artmaya devam edecektir.
Kaynaklar
-
Gerganov, G. (2023). llama.cpp: Port of Facebook’s LLaMA model in C/C++. C/C++ tabanlı düşük seviyeli LLM çıkarım motoru bellek optimizasyonları ve GGUF format spesifikasyonları.
-
Intel Corporation. (2024). Intel® oneAPI Programming Guide & SYCL Standard. Çapraz platform yapay zeka hızlandırma, Xe-HPG mimarisi ve XMX donanım matris çarpım birimleri dokümantasyonu.
-
Lin, J., et al. (2023). AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration. (arXiv:2306.00978). Dil modellerinde donanım dostu kuantizasyon algoritmaları ve VRAM bant genişliği daralmasını önleme teknikleri.
-
Frantar, E., et al. (2022). GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers. (arXiv:2210.17323). Milyar parametreli devasa modellerde bellek darboğazlarının aşılması.
-
Linux Kernel Organization. CFS Scheduler and PREEMPT_RT patchset documentation. Düşük gecikmeli kernel yönetimi ve yapay zeka iş yükleri için işlemci zamanlaması yönergeleri.