RAM Duvarını Yıkmak: Saf C ile Yazılan Janas-LLM, O_DIRECT ve io_uring Mimarisiyle 48 GB'lık Modeli 32 GB Laptopta Saniyede 37 Token Hızla Nasıl Koşturuyor?

Yerel yapay zeka (Local AI) ekosisteminde çalışan her sistem mimarının ve yazılım mühendisinin er ya da geç çarptığı o soğuk, acımasız duvar aynıdır: Çalıştırmak istediğiniz asıl model, her zaman makinenizin fiziksel belleğinden (RAM/VRAM) biraz daha büyüktür.

Hugging Face üzerinde muazzam muhakeme yeteneklerine sahip 80 milyar parametreli yeni bir Mixture-of-Experts (MoE - Uzmanlar Karışımı) model bulursunuz. Heyecanla Q4_K_M nicemleme (quantization) seviyesindeki dosya boyutuna bakarsınız: 48.4 GB. Ardından kendi dizüstü bilgisayarınızın sistem monitöründeki 32 GB RAM ibaresine bakar ve iç çekerek tarayıcı sekmesini kapatırsınız. Ya da mühendislik inadınıza yenik düşüp modeli mevcut araçlarla yüklemeyi denersiniz; işletim sisteminizin saniyede binlerce sayfa hatası (page fault) üreterek diski dövdüğü, fare imlecinin bile donduğu ve saniyede 2 ila 3 token'ın acı çekercesine ekrana düştüğü o kilitlenme anını izlersiniz.

Ancak Ekim 2026'nın ikinci haftasında Hacker News'in ilk sırasına yerleşen açık kaynaklı bir proje, bu fiziksel bellek duvarını kaba kuvvetle değil, saf sistem programlama zekasıyla yıktığını kanıtladı. İtalyan geliştirici Maurizio "camauri" Cammalleri tarafından, C standart kütüphanesi dışında sıfır harici bağımlılıkla saf C (Pure C) dilinde yazılan Janas (Janas-LLM), yerel çıkarım dünyasında ezber bozan bir基准 (benchmark) tablosu yayınladı: Harici bir ekran kartı (dGPU) bulunmayan, 32 GB RAM'li standart bir dizüstü bilgisayarda, 48.4 GB boyutundaki Qwen3-Next-80B-A3B modelini saniyede 37 token (taslak blokları olmadan 24 token/saniye) hızla çalıştırmayı başardı. Aynı donanımda, aynı modelle endüstri standardı llama.cpp yalnızca 2.8 token/saniye hıza ulaşabildi.

Adını Sardunya mitolojisindeki narin peri figürlerinden alan Janas, modeli küçültmeye veya aşırı nicemlemeye (extreme quantization) zorlamak yerine sorunun kendisini değiştiriyor: "Neden tüm modeli RAM'e sığdırmaya çalışıyoruz ki?"

Bu derinlemesine teknik analizde; işletim sistemi çekirdeklerinin bellekten büyük modellerde neden çöktüğünü, Janas'ın O_DIRECT, io_uring ve özel .jns dosya formatıyla kurduğu sıfır-kopya (zero-copy) NVMe akış mimarisini, llama.cpp ile olan kapsamlı performans düellosunu ve bu deneysel motorun mühendislik dünyası için ne anlama geldiğini inceleyeceğiz.

1. Problem ve Bağlam: İşletim Sistemi mmap İle Neden Çöker? ("Fault Storm" Anatomisi)

Sistem mimarisine aşina bir mühendisin ilk soracağı soru şudur: "İşletim sistemleri zaten sanal bellek (virtual memory) yönetimi yapmıyor mu? Model dosyası hızlı bir NVMe SSD üzerinde duruyorsa, işletim sistemi bunu mmap (memory-mapped file) ile adres uzayına eşleyip gereken parçaları kendiliğinden RAM'e çekemez mi?"

Evet, llama.cpp dahil olmak üzere mevcut çıkarım motorlarının neredeyse tamamı tam olarak bunu yapar. Model ağırlıklarını mmap sistem çağrısıyla sanal belleğe eşlerler ve bellek yönetimini işletim sistemi çekirdeğine (Linux veya Windows kernel) bırakırlar. Modelin boyutu fiziksel RAM'inizden küçük olduğu sürece bu yöntem kusursuzdur. Ancak aktif çalışma kümesi (working set) fiziksel RAM kapasitesini aştığı anda, işletim sisteminin genel amaçlı tasarım felsefesi bir felakete dönüşür.

Çekirdeğin Körlüğü ve Sayfa Hatası Fırtınası (Fault Storm)

Belleğe eşlenmiş (memory-mapped) bir dosya, içindeki verinin semantik yapısını veya gelecekteki erişim örüntüsünü bilmez. Linux çekirdeğinin sayfa önbelleği (page cache) mekanizması, genel amaçlı iş yükleri için LRU (Least Recently Used - En Az Yakın Zamanda Kullanılan) türevi algoritmalarla çalışır.

Bir Büyük Dil Modeli (LLM) çıkarım yaparken, katmanları (layers) 0'dan $N$'e kadar sırayla tarar. 48.4 GB'lık bir modeli 32 GB RAM'de mmap ile çalıştırdığınızda şu senaryo gerçekleşir:

1. İlk 25-28 GB'lık katmanlar okunurken sayfa hataları (major page faults) oluşur ve çekirdek bu sayfaları SSD'den RAM'e çeker.
2. Sonraki katmanlara geçildiğinde fiziksel RAM tamamen dolar.
3. Çekirdek, yeni katmanlara yer açmak için "en eski kullanılan" sayfaları tahliye etmeye (page eviction) başlar. Peki en eski kullanılan sayfalar hangileridir? Bir sonraki token üretiminde ilk ihtiyaç duyacağınız 0., 1. ve 2. katmanların ağırlıkları!
4. Yeni token üretimi başladığında motor tekrar 0. katmanı ister, ancak o sayfalar az önce silinmiştir.

Araştırmacıların "Fault Storm" (Hata Fırtınası) veya thrashing olarak adlandırdığı bu durumda, işletim sistemi çekirdeği körlemesine sayfaları silip yeniden yüklerken CPU zamanının büyük kısmı çekirdek içi sayfa tablosu kilitlerinde (page table locks) ve disk I/O beklemelerinde harcanır.

MoE (Mixture-of-Experts) Modellerinin İki Ucu Keskin Doğası

Qwen3-Next-80B-A3B gibi modern Mixture-of-Experts modelleri bu durumu hem daha karmaşık hale getirir hem de çözümün anahtarını sunar. Bu model toplamda 80 milyar parametreye sahiptir, ancak seyrek (sparse) yapısı gereği üretilen her bir token için yönlendirici (router) yalnızca yaklaşık 3 milyar parametreyi (A3B) aktif hale getirir.

Yani her bir kelimede modelin %96'sı aslında "ölü ağırlıktır". Ancak standart GGUF dosya diziliminde ve mmap okumasında, işletim sistemi 4 KB'lık bellek sayfalarını (pages) çekerken hangi uzmanın (expert) sıcak, hangisinin soğuk olduğunu ayırt edemez. Üstelik llama.cpp'nin standart CPU arka ucu (backend), SIMD performansını artırmak için ağırlıkları bellekte yeniden paketlemeye (weight repacking) çalışır ve Vulkan/GPU devreye girdiğinde işletim sisteminin geri kazanamadığı tampon bellekler (buffers) tahsis ederek 32 GB'lık sistemi anında OOM (Out of Memory) hatasıyla çökertir.

"Mimari Not: İşletim sistemi çekirdeğindeki sanal bellek yöneticisi geçmişe bakarak (LRU) tahmin yürütür; oysa bir MoE dil modelinin yönlendirici ağı (router) bir sonraki milisaniyede hangi ağırlık matrisine ihtiyaç duyacağını deterministik olarak bilir. Janas'ın temel felsefesi, bellek yönetimini kör çekirdekten alıp modelin farkında olan (model-aware) uygulama katmanına taşımaktır."

2. Janas-LLM Mimarisi: .jns Formatı, O_DIRECT ve Sıcak Uzman Önbelleği

Maurizio Cammalleri'nin GPL-3.0 lisansı altında yayınladığı Janas-LLM, bu darboğazı aşmak için sıfırdan, yalnızca C standart kütüphanesine (libc) dayanarak inşa edilmiş bir çıkarım motorudur. Janas'ın mimarisi üç temel sütun üzerinde yükselir: Hizalanmış .jns depolama düzeni, O_DIRECT ve io_uring ile çekirdek baypası ve dinamik Sıcak Uzman Önbelleği (Hot-Expert Cache).

+-------------------------------------------------------------------------+
|                    JANAS-LLM ÇIKARIM VE I/O MİMARİSİ                    |
+-------------------------------------------------------------------------+
                                     |
                      [ Token Router / Gating Network ]
                     (80B parametreden ~3B aktif uzman)
                                     |
                    +----------------+----------------+
                    |                                 |
           [ HIT: Sıcak Uzman ]              [ MISS: Soğuk Uzman ]
                    |                                 |
                    v                                 v
      +---------------------------+     +---------------------------+
      |   Uygulama İçi RAM Cache  |     |   Linux Kernel Bypass     |
      |   (Hot-Expert Cache)      |     |   (O_DIRECT + io_uring)   |
      |   ~19 GB Ayrılmış Alan    |     |   Sayfa Önbelleği Yok!    |
      +---------------------------+     +---------------------------+
                    |                                 |
                    |                                 v
                    |                   +---------------------------+
                    |                   |   NVMe SSD (.jns Format)  |
                    |                   |   Hizalı Slotlar (5.7GB/s)|
                    |                   |   [Gate | Up | Down]      |
                    |                   +---------------------------+
                    |                                 |
                    +----------------+----------------+
                                     |
                                     v
                    [ AVX2 SIMD / Vulkan (iGPU) Çıkarım ]

1. GGUF'tan .jns (Janas Format v2) Düzenine Geçiş

Janas, modelleri doğrudan GGUF formatında çalıştırmaz; bunun yerine hf2jns_mtp veya janas-get araçlarıyla GGUF dosyalarını yeniden nicemlemeden (kalite kaybı yaşatmadan) kendi .jns (sürüm 2) formatına dönüştürür. Bu dönüşümün kritik bir mimari amacı vardır: Fiziksel Disk Hizalaması (Storage Alignment).

Bir MoE katmanındaki her bir uzman (expert), üç temel ağırlık matrisinden oluşur: gate, up ve down projeksiyonları. .jns formatında;

• Her zaman kullanılan paylaşımlı katmanlar (attention ağırlıkları, embedding'ler, normlar ve yönlendirici ağlar) dosyanın başında "Resident Region" (Yerleşik Bölge) olarak gruplanır ve çıkarım boyunca RAM'den hiç çıkarılmaz.
• Her bir MoE uzmanı ise gate, up ve down ağırlıkları birbirine bitişik ve sektör sınırlarına (4096 byte) tam hizalanmış (aligned storage slot) tekil bir blok olarak diske yazılır. Böylece motor bir uzmana ihtiyaç duyduğunda, disk üzerinde dağınık aramalar (random seek) yapmak yerine tek bir hizalı I/O isteğiyle o uzmanın tüm matrislerini tek seferde çekebilir.

2. O_DIRECT ve io_uring ile İşletim Sistemini Devre Dışı Bırakmak

Janas, Linux üzerinde .jns dosyasını açarken O_DIRECT bayrağını ve asenkron io_uring arayüzünü kullanır. O_DIRECT kullanımı, işletim sistemi çekirdeğine şu emri verir: "Bu dosyadan okuduğun verileri sakın kendi Page Cache'ine kopyalama, doğrudan benim verdiğim kullanıcı uzayı (user-space) bellek adresine DMA (Direct Memory Access) ile yaz."

Bu yaklaşım iki devasa avantaj sağlar:

• Sıfır Çift Kopyalama (Zero Double-Buffering): Veri önce çekirdek önbelleğine, oradan uygulama belleğine kopyalanmaz; NVMe kontrolcüsünden doğrudan Janas'ın tensör tamponlarına akar.
• Sıfır Page Thrashing: İşletim sistemi sayfa önbelleği hiç kirlenmediği için çekirdek panikleyip rastgele bellek tahliyesine (eviction) girişmez.

3. 19 GB'lık Dinamik "Hot-Expert Cache" ve Hibrit iGPU Kullanımı

Doğal dilde kelimeler ve kavramlar rastgele dağılmaz; belirli bir bağlamda (örneğin Python kodu yazarken veya tıbbi bir metni özetlerken) MoE yönlendiricisi sürekli aynı uzman alt kümelerini aktive etme eğilimindedir.

Janas başlatıldığında makinenin donanım topolojisini, boş RAM miktarını ve disk hızını ölçer (~/.cache/janas altına kaydeder). 32 GB RAM'li referans makinede Qwen3-Next-80B çalıştırılırken, motor boş belleğin yaklaşık 19 GB'lık kısmını "Hot-Expert Cache" (Sıcak Uzman Önbelleği) olarak ayırır.

• Token üretimi sırasında çağrılan bir uzman halihazırda bu 19 GB'lık önbellekteyse (Cache Hit), bellek hızında (DDR5 bant genişliğiyle) işlenir.
• Eğer uzman önbellekte yoksa (Cache Miss), NVMe SSD'den 5.7 GB/s hızla okunur. Tekرار çağrılma frekansı yüksek olan uzmanlar RAM'de tutulurken, nadiren kullanılan "soğuk" uzmanlar hesaplama biter bitmez serbest bırakılır.

Ayrıca Janas, entegre GPU'yu (iGPU) çok akıllıca bir görev paylaşımıyla kullanır: Bütün modeli GPU belleğine yüklemeye çalışmak yerine, entegre Intel Arc GPU'yu (Vulkan üzerinden) yalnızca yoğun paralel matris çarpımı gerektiren "Prompt Okuma" (Prefill) aşamasında kullanır. Bellek bant genişliği ve disk I/O darboğazına takılan "Token Yazma" (Decode) aşamasında ise AVX2 SIMD komut setleriyle optimize edilmiş CPU çekirdekleri ve doğrudan NVMe akışı devreye girer.

Aşağıdaki C kodu, Janas'ın kaputunun altında gerçekleştirdiği hizalı O_DIRECT uzman okuma ve uygulama içi önbellekleme mekanizmasının mimari mantığını göstermektedir:

// Janas-LLM Mimari Simülasyonu: O_DIRECT ve Hizalı (.jns) MoE Uzman Akışı
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdint.h>
#include <errno.h>

#define SECTOR_ALIGNMENT 4096
#define EXPERT_SLOT_SIZE (16 * 1024 * 1024) // Örnek: 16 MB hizalı uzman bloğu (gate+up+down)

typedef struct {
    int nvme_fd;
    void *hot_cache_pool;     // 19 GB ayrılmış sıcak uzman önbelleği
    size_t max_cached_experts;
    int *expert_freq_table;   // Uzman kullanım frekansı izleme tablosu
} janas_engine_t;

// Soğuk bir MoE uzmanını OS Page Cache'i baypas ederek doğrudan NVMe'den çekme
int janas_stream_cold_expert(janas_engine_t *engine, int layer_id, int expert_id, void **out_weights) {
    // 1. Uzman frekansını artır (Sıcak önbelleğe terfi edilip edilmeyeceğini belirler)
    int global_expert_idx = (layer_id * 64) + expert_id;
    engine->expert_freq_table[global_expert_idx]++;

    // 2. O_DIRECT için bellek adresi 4096-byte (sektör) sınırına hizalı OLMAK ZORUNDADIR
    void *aligned_buffer = NULL;
    if (posix_memalign(&aligned_buffer, SECTOR_ALIGNMENT, EXPERT_SLOT_SIZE) != 0) {
        return -ENOMEM;
    }

    // 3. .jns dosyasındaki hizalı ofseti hesapla (Resident bölge sonrası)
    off_t jns_offset = (off_t)global_expert_idx * EXPERT_SLOT_SIZE;

    // 4. OS Page Cache'i tamamen atlayarak NVMe'den DMA ile tek seferde oku
    ssize_t bytes_read = pread(engine->nvme_fd, aligned_buffer, EXPERT_SLOT_SIZE, jns_offset);
    if (bytes_read != EXPERT_SLOT_SIZE) {
        free(aligned_buffer);
        return -EIO;
    }

    *out_weights = aligned_buffer;
    return 0; // Başarılı: Ağırlıklar doğrudan AVX2/SIMD matris çarpımına hazır
}

3. Performans ve Kıyaslama: 13 Modelde llama.cpp Düellosu

Geliştirici Maurizio Cammalleri, 9-12 Ekim 2026 tarihleri arasında tüm testlerini tek bir referans dizüstü bilgisayar üzerinde gerçekleştirdi:

• İşlemci: Intel Core Ultra 9 185H
• Bellek: 32 GB DDR5 RAM
• Depolama: 1 TB NVMe SSD (~5.7 GB/s sıralı okuma hızı)
• Grafik: Entegre Intel Arc GPU (Vulkan API üzerinden, harici GPU yok)

Test edilen 13 farklı modelin tamamında (Q4_K_M nicemleme seviyesinde; Qwen3, Qwen3.5, Qwen3.6, Qwen3-Next ve Gemma 4 ailelerinin hem yoğun/dense hem de MoE varyantlarında) Janas-LLM, llama.cpp'yi geride bıraktı.

Tablo verileri geliştiricinin 9-12 Ekim 2026 tarihli 1.024 token'lık prompt okuma ve yanıt üretme ölçümlerine dayanmaktadır.

Rakamların Arkasındaki Kritik Mühendislik Detayları

Tablodaki en çarpıcı satır kuşkusuz 48.4 GB'lık Qwen3-Next-80B-A3B sonucudur. Normal şartlarda llama.cpp, bu modeli 32 GB RAM'li makinede varsayılan ayarlarla hiç çalıştıramadı (GPU devreye girdiği anda bellek tükendiği için çöktü). Cammalleri, llama.cpp'den karşılaştırılabilir bir rakam alabilmek için ağırlık yeniden paketlemeyi kapatan özel bir derleme (GGML_CPU_REPACK=OFF) yapmak ve --no-host 1 -lm mmap bayraklarını kullanmak zorunda kaldı. Buna rağmen llama.cpp işletim sistemi sayfa önbelleği darboğazına takılarak saniyede 2.8 token üretebilirken, Janas hiçbir özel bayrağa ihtiyaç duymadan 24 token/saniye, modelin kendi MTP (Multi-Token Prediction) taslak bloklarıyla (speculative decoding) ise 37 token/saniye hıza ulaştı. Bu, yaklaşık 8.5 kat ile 13 kat arasında bir hızlanma demektir.

Objektif Bakış: İstisnalar ve Bağımsız Testler

Mühendislik dürüstlüğü gereği madalyonun diğer yüzünü de vurgulamak gerekir:

1. Tek Makine Ölçümü: Yukarıdaki başlık rakamları geliştiricinin kendi tekil laptopundan alınmıştır.
2. 64 GB RAM Bağımsız Testi: Topluluk tarafından Janas'ın daha eski bir sürümüyle 64 GB RAM'li başka bir dizüstü bilgisayarda yapılan tek bağımsız testte; model RAM'e tamamen sığdığında llama.cpp'nin daha hızlı olduğu veya berabere kaldığı, ancak 64 GB RAM'i aşan 235 milyar parametreli devasa modelde Janas'ın yine llama.cpp'den yaklaşık iki kat hızlı çalıştığı gözlemlendi.
3. 3-Bit İstisnası: Geliştirici, unsloth'un 3-bit nicemlenmiş Qwen3-30B modelinde Janas'ın prompt okuma hızının llama.cpp'den daha yavaş kaldığını şeffaf bir şekilde raporlamıştır.

"Mimari Not: Janas, yerel yapay zeka dünyasında 'uzmanları diskten akıtma' (stream experts from SSD) akımının en yeni ve en bütünleşik üyesidir. Daha önce Colibrì (GLM-5.2'yi 25 GB RAM'de koşturan), TurboFieldfare (Gemma 4 26B'yi ~2 GB RAM'de koşturan) ve Edge0 (35B modeli 2.5 GB RAM'de koşturan) gibi projeler benzer fikirleri denemişti. Janas'ı ayıran şey; tekil bir model hack'i olmak yerine genel amaçlı bir C motoru, OpenAI uyumlu bir sunucu ve bir MCP aracı olarak paketlenmesidir."

4. Sektör ve Yazılımcılar İçin Çıkarımlar: Kod Tamamlama, MCP ve Agresif Sınırlar

Janas sadece terminalde sohbet edilen (janas-chat) akademik bir oyuncak değil; günlük yazılım geliştirme iş akışlarına doğrudan entegre olabilecek üç kritik bileşenle (janas-server, janas-mcp, janas-bench) birlikte geliyor.

1. Sabit Pencereli Kod Tamamlama (/infill Optimizasyonu)

janas-server, OpenAI uyumlu HTTP API'sinin yanı sıra VS Code / VSCodium üzerindeki llama.vscode eklentisinin kullandığı /infill (Fill-in-the-Middle) uç noktasını da uygular. Geliştirici, Qwen3-Coder-30B-A3B gibi bir kod modelini yerel olarak koştururken çok zekice bir önbellek mühendisliği yapmıştır:

Standart kod tamamlama araçlarında her tuşa bastığınızda (keystroke) bağlam penceresi kayar ve modelin KV önbelleği (KV cache) geçersiz kılınarak baştan okunur. Janas ise gönderilen bağlam penceresini sabit tutar, böylece her tuş vuruşunda yalnızca değişen son kısım yeniden okunur. Referans makinede bu optimizasyon sayesinde kod önerisi süresi 1.5 ila 2.2 saniye arasındadır. Bağlam penceresi tam bir satır kaydığında ise yeniden okuma süresi 17 saniyeye fırlamaktadır; bu da yerel büyük modellerde önbellek mühendisliğinin (cache engineering) ham işlemci gücünden ne kadar daha önemli olduğunu kanıtlar.

2. Ajanik İş Akışları İçin Yerel MCP Sunucusu (janas-mcp)

Claude Code veya benzeri ajan tabanlı geliştirme araçlarını kullanan mühendisler için janas-mcp, yerel 80B modeli bir Model Context Protocol (MCP) aracı olarak dışa açar. Bu sayede hibrit bir mimari kurabilirsiniz: Kritik mimari kararları ve orkestrasyonu buluttaki sınır modele (Frontier Model) bırakırken, yüksek hacimli kod taslağı oluşturma, dokümantasyon tarama ve yerel veri analizi görevlerini sıfır API maliyetiyle laptopunuzdaki 80B modele devredebilirsiniz.

Aşağıdaki Python betiği ve kurulum adımları, Janas'ı Linux x86-64 üzerinde ayağa kaldırıp OpenAI uyumlu API'si ve /infill uç noktasıyla nasıl entegre edebileceğinizi göstermektedir:

import requests
import time

# Kurulum (Linux x86-64):
# curl -LO https://github.com/prabanta-dev/janas/releases/latest/download/janas-linux-x86_64.tar.gz
# tar xf janas-linux-x86_64.tar.gz && cd janas
# ./janas-server --model qwen3-coder-next-80b-q4km.jns --cache 16

JANAS_BASE_URL = "http://127.0.0.1:8080"

def request_code_infill(prefix: str, suffix: str) -> dict:
    """
    Janas-Server'ın sabit bağlam pencereli /infill uç noktasını kullanarak
    bellekten büyük MoE modeliyle yerel kod tamamlama (FIM) gerçekleştirir.
    """
    payload = {
        "input_prefix": prefix,
        "input_suffix": suffix,
        "n_predict": 64,
        "temperature": 0.1
    }
    
    start_time = time.perf_counter()
    response = requests.post(f"{JANAS_BASE_URL}/infill", json=payload, timeout=30)
    response.raise_for_status()
    latency = time.perf_counter() - start_time
    
    return {
        "completion": response.json().get("content", ""),
        "latency_sec": round(latency, 2)
    }

if __name__ == "__main__":
    code_prefix = "def calculate_nvme_bandwidth(bytes_transferred: int, elapsed_ns: int) -> float:\n    "
    code_suffix = "\n    return round(gb_per_sec, 2)"
    
    result = request_code_infill(code_prefix, code_suffix)
    print(f"[Janas 80B FIM Önerisi ({result['latency_sec']}s)]:\n{result['completion']}")

3. Çekinceler ve "Bu Bir Deneydir, Ürün Değil" Uyarısı

Janas'ı hemen üretim ortamınıza veya ana geliştirme makinenize kurmadan önce Maurizio Cammalleri'nin README dosyasına koyduğu açık uyarıları dikkate almalısınız: "Bu bir deneydir, bir ürün değil (This is an experiment, not a product)."

• Kasten Agresif Donanım Kullanımı: Janas boş belleğin tamamını kendi uzman önbelleğiyle doldurmak ve diski O_DIRECT ile maksimum hızda okumak üzere tasarlanmıştır. Eğer arka planda bir web tarayıcısı ve kod editörü açıksa, model hızının yaklaşık dörtte üçünü korusa da disk bekleme süresi 5 katına çıkmaktadır. Daha da önemlisi, bellek payı yanlış hesaplanırsa masaüstü ortamınız swap alanına itilip tamamen tepkisiz kalabilir (hatta geliştirici, GPU kullanımının bir kez grafik sürücüsünü sıfırlayarak masaüstü oturumunu çökerttiğini dürüstçe belirtmektedir).
• Kaçış Valfleri (Escape Valves): Sisteminizi korumak için çalıştırırken mutlaka --cache <GiB> bayrağıyla sert bir bellek sınırı koymanız ve kararlılık sorunlarında JANAS_GPU=0 ortam değişkeniyle iGPU'yu devre dışı bırakmanız önerilir.
• Sürekli Değişen API: Komut satırı bayrakları ve API haftada birkaç kez değişmektedir; geriye dönük uyumluluk sözü verilen tek bileşen .jns (v2) model dosyası formatıdır.

Sonuç: Bellek Kapasitesinden I/O Bant Genişliğine Paradigma Değişimi

Janas-LLM, kusursuz ve bitmiş bir kurumsal ürün olmayabilir; ancak yerel yapay zeka mühendisliğinde çok kritik bir paradigma değişiminin habercisidir. Yıllarca büyük dil modellerini yerel donanımda çalıştırmanın tek yolunun daha fazla RAM/VRAM satın almak veya modeli agresif nicemlemeyle (2-bit/3-bit) aptallaştırmak olduğu düşünüldü.

Janas ise modern MoE mimarilerinin seyrek aktivasyon doğasını, NVMe SSD'lerin devasa sıralı okuma hızlarıyla (O_DIRECT) birleştirerek denklemi değiştirdi. Artık yerel makinenizde ne kadar büyük bir model çalıştırabileceğinizi anakartınızdaki RAM slotları değil, NVMe diskinizin I/O bant genişliği ve uygulama katmanındaki önbellek algoritmanızın zekası belirliyor. PCIe 5.0 SSD'lerin saniyede 14 GB okuma hızlarını standartlaştırdığı bir dünyada, bellek duvarları sandığımızdan çok daha kırılgan.