OpenTelemetry ile Node.js Uygulamalarında Dağıtık İzleme: OTLP, Grafana Tempo ve Prometheus Entegrasyonu

OpenTelemetry Nedir ve Neden Önemli?

Modern mikroservis mimarilerinde tek bir isteğin birçok servis, kuyruk ve veri deposu üzerinden akması sıradan bir durum haline geldi. Bu akıştaki gecikmeleri, hataları ve dar boğazları anlamanın en güvenilir yolu, dağıtık izleme (distributed tracing), metrik ve log verilerini bir arada toplayıp ilişkilendirmektir. OpenTelemetry (OTel), bu ihtiyacı standartlaştıran açık kaynak bir çatı sunar. Node.js projelerinde OTel kullanarak HTTP isteklerini, veritabanı çağrılarını ve iç fonksiyonlarınızı otomatik veya manuel olarak izleyebilir, verileri OTLP üzerinden Grafana Tempo ve Prometheus gibi sistemlere aktarabilirsiniz.

Mimari: SDK, Collector ve Gözlemleme Katmanı

Basit ve güvenilir bir kurulum için üç katman önerilir: (1) Uygulama içinde @opentelemetry/sdk-node ve otomatik enstrümantasyon paketleri çalışır. (2) Veriler OTLP ile OpenTelemetry Collector’a gönderilir. (3) Collector, gelen trace’leri Tempo’ya, metric’leri Prometheus’a, tercihen log’ları da Loki’ye yönlendirir. Böylece uygulama sadece bir hedefi bilir ve detayları Collector yönetir; yapılandırma değişiklikleri için uygulamayı yeniden dağıtmanız gerekmez.

Ön Koşullar ve Temel Kurulum

- Node.js 18+ önerilir, çünkü AsyncLocalStorage ile bağlam yayılımı daha stabil ve hızlıdır. Paket yöneticisi olarak npm, pnpm ya da yarn kullanabilirsiniz.

- Projenizde hizmet adını ve ortamı belirlemek için şu ortam değişkenlerini ayarlayın: OTEL_SERVICE_NAME, OTEL_RESOURCE_ATTRIBUTES=deployment.environment=prod. OTLP hedefi için Collector URL’niz genelde http://otel-collector:4318 (HTTP) veya 4317 (gRPC) olacaktır.

- OTel’i uygulamanın en erken aşamasında, sunucu başlatılmadan önce başlatın. Örneğin tracing.js dosyanızı ilk import eden dosya yapın; aksi halde bazı framework etkinlikleri enstrümante edilemez.

Otomatik ve Manuel Enstrümantasyon

Node.js tarafında @opentelemetry/auto-instrumentations-node HTTP, gRPC, Express, Fastify, MySQL, PostgreSQL, Redis gibi popüler bileşenleri otomatik izler. Bu sayede hiçbir kod yazmadan gelen istekler, giden HTTP çağrıları ve DB sorguları için span’ler oluşturulur. Kritik işlevlerinizde daha detaylı görünürlük istiyorsanız manuel enstrümantasyonla özel span’ler açıp önemli değişkenleri attribute olarak ekleyebilirsiniz. Örneğin sipariş tutarı, sepet boyutu veya kampanya kodu gibi iş metriklerini PII içermeyecek şekilde iliştirmek, kök nedeni çözmede büyük avantaj sağlar.

Örnek Yapılandırma Prensipleri

- Sampler: Üretimde yüzde 100 örnekleme pahalı olabilir. ParentBasedTraceIdRatio gibi oran bazlı sampler kullanın; giriş noktalarında yüzde 5-10, hata kodlarında ise koşullu olarak yüzde 100 örnekleme tercih edebilirsiniz.

- Propagator: Varsayılan W3C Trace Context yeterlidir. Hizmet zincirindeki tüm servislerin aynı propagatörü kullanması span bağlarının korunmasını sağlar.

- Resource Nitelikleri: service.name, service.version, deployment.environment, cloud.region gibi alanları doldurun. Sürüm numarası (örn. git SHA) hata takibinde altın değerindedir.

- OTLP Exporter: HTTP veya gRPC kullanılabilir. Kurumsal ağlarda HTTP genellikle daha sorunsuzdur. Timeouts ve yeniden deneme ayarlarını Collector’a bırakmak, uygulama üzerinde yükü azaltır.

OpenTelemetry Collector İpuçları

Collector, performans ve güvenilirlik için kritik bir bileşendir. Girişte otlp receiver, ortada batch ve attributes processor’ları, çıkışta tempo ve prometheus exporter’ları kullanılır. Batch, küçük span’lerin birikerek verimli gönderilmesini sağlar. Attributes processor ile gereksiz ya da hassas alanları (örn. e-posta, telefon) maskeleyebilir veya kaldırabilirsiniz. Tempo tarafında multi-tenant ihtiyaç varsa tenant başına service.name veya header tabanlı ayırma stratejisi kullanın.

Grafana Tempo ve Prometheus Entegrasyonu

Tempo, span verilerini ölçeklenebilir şekilde tutar ve Grafana ile mükemmel entegredir. Grafana’da “Explore” bölümünden trace ID ile arama yapabilir, isteklerin gecikme dağılımını görebilir ve sorunlu hizmeti hızlıca belirleyebilirsiniz. Metrikler için Prometheus, Node.js ve Collector’dan gelen ölçümleri toplayarak p95/p99 gecikme, hata oranı ve istek hacmini panolarda görselleştirir. Traces ile metrics arasında exemplar köprüleri kurduğunuzda, grafikteki bir pik noktasından ilgili trace’e tek tıkla bağlanabilirsiniz.

Performans, Maliyet ve Güvenlik

- Overhead: Otomatik enstrümantasyonun CPU/GC etkisi genellikle düşüktür, ancak sıcak yol (hot path) fonksiyonlarda manuel span açmayı sınırlayın. Toplayıcıda batch boyutlarını ve flush aralıklarını gözden geçirerek ağ trafiğini optimize edin.

- Maliyet: Oran bazlı örnekleme ve hata odaklı dinamik örnekleme ile depolama ve sorgu maliyetlerini kontrol altında tutun. Geliştirme ve staging ortamlarında daha yüksek oran, üretimde daha düşük oran kullanmak iyi bir dengedir.

- Gizlilik: PII ve gizli anahtarları span attribute’larına koymayın. Collector’da maskeleme kuralları ekleyin. Log ve trace korelasyonu yaparken veri minimizasyonuna dikkat edin.

Hata Ayıklama ve Yaygın Sorunlar

- Bağlam Kaybı: Özellikle eski Promise zincirlerinde veya üçüncü taraf kütüphanelerde bağlam kaybı olabilir. Node 18+ ve AsyncLocalStorage ile bu sorun büyük ölçüde azalır. Framework düzeyinde middleware sırasını kontrol edin.

- Eksik Span’ler: Uygulamada OTel başlatma dosyasının en önce import edildiğinden emin olun. Sunucu başlatma komutunuzda -r ./tracing.js gibi bir preload yaklaşımı kullanmak güvenilirdir.

- Gönderim Hataları: Collector’a ulaşamıyorsanız firewall veya servis keşfi sorunlarını kontrol edin. OTLP gRPC ile MTLS yapılandırıyorsanız sertifika yollarını ve SNI ayarlarını doğrulayın.

Sonuç

OpenTelemetry, Node.js uygulamalarınızda uçtan uca görünürlük sağlayarak sorun tespiti ve performans optimizasyonunu hızlandırır. Uygulama içinde hafif bir SDK, merkezde güçlü bir Collector ve gözlemleme katmanında Tempo/Prometheus kombinasyonu ile maliyet-etkin, taşınabilir ve geleceğe dönük bir çözüm elde edersiniz. Doğru örnekleme, sağlam kaynak nitelikleri ve sıkı gizlilik politikaları ile ekipler hem geliştirici deneyimini hem de kullanıcı memnuniyetini anlamlı biçimde artırabilir.

WebGPU ile Tarayıcıda Gerçek Zamanlı Nesne Tespiti: ONNX Runtime Web ile Adım Adım

Giriş

Tarayıcıda yapay zekâ çalıştırmak, yerel gizlilik, düşük gecikme ve kurulum gerektirmeyen dağıtım gibi avantajlar sunuyor. WebGPU’nun olgunlaşması ve ONNX Runtime Web’in hızla gelişmesi sayesinde, bugün artık masaüstü veya sunucuya gerek duymadan tarayıcı içinde gerçek zamanlı nesne tespiti mümkün. Bu yazıda, WebGPU ve ONNX Runtime Web kullanarak YOLO tabanlı hafif bir modelle, sıfırdan çalışan bir demo kurulumunun nasıl yapılacağını, performans ipuçlarını ve dikkat edilmesi gereken noktaları adım adım anlatıyorum.

Gereksinimler ve Hazırlık

Öncelikle güncel bir tarayıcıya ihtiyacınız var. WebGPU için Chrome/Edge 121+ tavsiye edilir; bazı cihazlarda WebGPU devre dışı olabilir, bu durumda ONNX Runtime Web otomatik olarak WASM (WebAssembly) yürütücüsüne düşebilir. Uygulamanızı HTTPS üzerinden ve mümkünse yerel geliştirmede localhost ile çalıştırın. Kamera erişimi için getUserMedia iznine de ihtiyaç olacak.

Proje Kurulumu

Hızlı başlamak için Vite kullanacağız. Terminalde aşağıdaki adımları izleyin:
1) npm create vite@latest webgpu-onnx-demo -- --template vanilla
2) cd webgpu-onnx-demo
3) npm install onnxruntime-web
4) npm install ve ardından npm run dev ile geliştirme sunucusunu başlatın.

Model Seçimi ve Dosya Yapısı

Tarayıcı için hafif bir model seçmek kritik. YOLO ailesinden yolov8n veya benzeri küçük bir ONNX modeli başlangıç için ideal. Model dosyasını projenizde public/models/yolov8n.onnx gibi bir yola koyun. Eğer int8/FP16 gibi quantized sürüm elinizde varsa performans kazanabilirsiniz; WebGPU bu tür ağlarda ciddi hız kazandırır.

ONNX Runtime Web ile Oturum Oluşturma

Tarayıcıda model çalıştırmak için onnxruntime-web kütüphanesi tek noktadan çözüm sunar. Basit bir başlatma şeması şöyle olabilir: import * as ort from 'onnxruntime-web' ardından const session = await ort.InferenceSession.create('/models/yolov8n.onnx', { executionProviders: ['webgpu', 'wasm'] }). Bu yapı, WebGPU destekliyse GPU’yu, değilse WASM’ı kullanır. Uygulama açılışında bir kez oturum oluşturup bellekte tutmak başlangıç gecikmesini azaltır.

Görüntü Kaynağı ve Ön İşleme

Kameradan akış almak için navigator.mediaDevices.getUserMedia({ video: { facingMode: 'environment' } }) kullanın. Video karesini bir canvas üzerine çizip modelin beklediği çözünürlüğe (örneğin 640x640) yeniden boyutlandırın. Piksel verisini canvas.getContext('2d').getImageData(...) ile alın, RGB sırasına getirip 0-1 aralığına normalize edin ve tensörü NCHW formatında Float32Array olarak oluşturun. ONNX’a beslemek için new ort.Tensor('float32', data, [1, 3, 640, 640]) şeklinde bir tensör üretin.

Çıktı Sonrası İşleme (Post-Processing)

YOLO benzeri modellerin çıktısı genellikle kutular, sınıf olasılıkları ve skorlar içerir. Sigmoid/Softmax dönüşümlerini uyguladıktan sonra bir Non-Maximum Suppression (NMS) adımı gerekir. NMS için IoU eşiğini (ör. 0.45) ve skor eşiğini (ör. 0.25) kendiniz belirleyin. Tarayıcı performansı için döngüleri optimize edin, mümkünse tek tip diziler (Float32Array) ve önceden ayrılmış tamponlar kullanın.

Çalıştırma Döngüsü ve Çizim

Her karede sırasıyla: videodan canvas’a çizim → ön işleme → session.run(feeds) → post-processing → kutuları ve etiketleri ikinci bir overlay canvas’ına çizim. Çizim için requestAnimationFrame kullanarak akıcı bir döngü yakalayın. WebGPU yürütücüsü açıkken orta sınıf bir dizüstünde 30 FPS ve üzeri değerlere ulaşmak mümkün; WASM yolunda ise 8-15 FPS aralığı gerçekçi bir beklentidir.

Performans İpuçları

1) Web Worker + OffscreenCanvas: Ön işleme ve NMS’i bir Worker içine alarak ana iş parçacığını boşaltabilirsiniz. OffscreenCanvas ile çizimleri de iş parçacığı dışında yapmak mümkün.
2) Isınma (Warm-up): Uygulama açılışında bir yapay girişle bir kez session.run çağırarak ilk kare gecikmesini düşürün.
3) Boyut ve Oran: Giriş çözünürlüğünü cihaz gücüne göre 320, 480, 640 şeklinde seçin. Düşük çözünürlük daha yüksek FPS demektir.
4) Kuantizasyon: FP16 veya INT8 modellerle hem bant genişliği hem de hesap yükünü azaltırsınız. WebGPU ile özellikle FP16 iyi sonuç verir.
5) Bellek Yönetimi: Her karede yeni dizi oluşturmak yerine tamponları yeniden kullanın; gereksiz GC duraklamalarını önleyin.

WebGPU Özel Notlar

Bazı cihazlarda navigator.gpu görünse bile adaptör kısıtları performansı etkileyebilir. adapter = await navigator.gpu.requestAdapter() ve device = await adapter.requestDevice() çağrılarında hata yakalama koyun. Uzun süren işlemlerde device.lost olayını dinleyip yeniden kurulum yapın. Ayrıca, farklı GPU sürücülerinde küçük nüanslar olabilir; kritik bölümlerde tarayıcı konsolunu takip edin.

WASM Yürütücüsü İçin Ek Ayarlar

WebGPU devre dışıysa ONNX Runtime Web’in WASM yürütücüsü devreye girer. graphOptimizationLevel: 'all' gibi seçeneklerle optimizasyonu artırın. Bazı SIMD hızlandırmaları için COOP/COEP başlıkları gereklidir; üretimde sunucu yapılandırmanızı Cross-Origin-Opener-Policy: same-origin ve Cross-Origin-Embedder-Policy: require-corp ile güncellemeyi düşünün. Bu sayede WASM SIMD ve bazı paralel özellikler etkin hale gelir.

Hata Ayıklama ve Ölçüm

FPS’i ölçmek için basit bir sayaç yazın ya da PerformanceObserver kullanın. ONNX katman sürelerini anlamak için giriş/çıkış zamanlarını konsola basmak yeterli olur. Çıktılar boşsa ilk bakacağınız yer ön işleme adımıdır: kanal sırası (NCHW/NHWC), normalize edilmemiş değerler veya çözünürlük uyuşmazlığı genellikle sorumludur.

WebGL mi, WebGPU mu?

WebGL tabanlı çözümler hâlâ iş görse de, makine öğrenmesi iş yüklerinde WebGPU ile daha tutarlı ve modern bir performans elde ediliyor. ONNX Runtime Web’in WebGPU yürütücüsü, operator kapsamını genişlettikçe fark daha da açılıyor. Kısacası, uzun vadede WebGPU tercih etmek mantıklı.

Sonuç

Bu rehberle, WebGPU ve ONNX Runtime Web kullanarak tarayıcıda gerçek zamanlı nesne tespiti uygulamasını uçtan uca kurmanın temel adımlarını gördük. Doğru model, dikkatli ön/post-işleme ve küçük optimizasyonlarla akıcı bir deneyim elde edebilirsiniz. Üstelik tümü istemci tarafında çalıştığı için gizlilik ve dağıtım kolaylığı cabası. Bir sonraki adım olarak, izleme (tracking), bölütleme (segmentation) veya metin çıkarımı (OCR) gibi ek yetenekleri aynı altyapı üzerinde denemeyi düşünebilirsiniz.

Laptopta Yerel LLM Çalıştırma Rehberi: Ollama ile GPU Hızlandırmalı RAG Kurulumu (2025)

Giriş

Üretken yapay zekâ servislerini bulut yerine kendi bilgisayarınızda çalıştırmak hem gizliliği artırıyor hem de maliyeti düşürüyor. Son aylarda adını sıkça duyduğumuz Ollama, yerel LLM çalıştırmayı son derece pratik hâle getiriyor. Bu rehberde, laptop veya masaüstünüzde GPU hızlandırmalı bir kurulum yapacak, ardından basit bir RAG (Retrieval Augmented Generation) akışı kurgulayarak kendi belgeleriniz üzerinde akıllı arama ve soru-cevap deneyimi oluşturacağız. Tüm adımlar sade ve SEO dostu bir “how-to” olarak planlandı.

Sistem Gereksinimleri ve Model Seçimi

Modern bir CPU ve en az 16 GB RAM önerilir. GPU tarafında NVIDIA (CUDA) veya Apple Silicon (Metal) destekleri performansı ciddi biçimde artırır. Disk alanınızın en az 10–20 GB boş olması faydalıdır. Model seçerken boyut-kalite dengesine dikkat edin: llama3:8b veya mistral:7b gibi 7–8B modeller, 4-bit kuantizasyonla çoğu senaryoda iyi sonuç verir. Daha ciddi analizler için 13B üstü modellere yönelebilirsiniz, ancak VRAM ve RAM kullanımınız artacaktır.

Ollama Kurulumu

macOS üzerinde brew install ollama ile kurulumu tamamlayabilirsiniz. Windows için resmi yükleyiciyi tercih edin (Ollama sitesinden .exe indirerek). Linux’ta ise curl -fsSL https://ollama.com/install.sh | sh komutu işinizi görecektir. Kurulumdan sonra servisi başlatmak için ollama serve komutunu çalıştırın; arka planda http://localhost:11434 adresinde bir API sunucusu açılır.

İlk Modeli İndirme ve Çalıştırma

Örnek olarak Llama 3’ün 8B sürümünü indirelim: ollama pull llama3:8b. Ardından hızlı bir test için ollama run llama3:8b komutunu çalıştırın. Komut satırında modele doğrudan soru sorabilirsiniz. Türkçe anlama ve yanıt üretimi konusunda tatmin edici sonuçlar için sistem talimatını kısa bir bağlamla başlatmanız iyi olur; örneğin “Türkçe, kısa ve teknik yanıt ver” gibi bir içerikle diyaloğu yönlendirin.

GPU Hızlandırma İpuçları

Apple Silicon (M1/M2/M3) cihazlarda Metal desteği otomatik devreye girer. NVIDIA tarafında en iyi sonuç için güncel CUDA ve cuDNN sürümlerini kurun, ardından ortam değişkenleriyle ince ayar yapın. Örneğin, OLLAMA_NUM_GPU=1 ile kaç GPU kullanılacağını sınırlandırabilir, OLLAMA_MAX_LOADED_MODELS=1 ile aynı anda yüklenen model sayısını azaltarak VRAM taşmalarını önleyebilirsiniz. Ayrıca 4-bit kuantize sürümler (Q4_K_M benzeri) daha az bellek tüketir; ilk denemelerde bunları tercih etmek stabilite sağlar.

RAG Nedir ve Neden Gerekli?

RAG, modelin kendi parametrelerinde olmayan güncel veya özel bilgiyi, harici bir bilgi tabanından anlık olarak alıp yanıtları zenginleştirmesini sağlar. Örneğin, şirket içi dokümanlarınızı veya notlarınızı vektör dizinine (vector store) dönüştürür, sorgu anında en uygun parçaları çekip modele “bağlam” olarak verirsiniz. Böylece hallucination azalır, doğruluk artar.

Basit RAG Akışı: Adım Adım

1) Belgeleri Hazırla: PDF, Markdown veya düz metin dosyalarınızı tek bir klasörde toplayın. Büyük dosyaları ~500–1000 token’lık parçalara bölmek arama kalitesini artırır.

2) Embedding Modelini Çek: Ollama içinden bir gömme modeli indirin: ollama pull nomic-embed-text veya çok dilli kullanım için all-minilm benzeri alternatifleri deneyin.

3) Vektör Üret: Hızlı bir test için Ollama’nın HTTP API’sini kullanabilirsiniz. Örnek bir istek: curl -s http://localhost:11434/api/embeddings -d '{"model":"nomic-embed-text","input":"Merhaba dünya"}'. Script ile belgelerinizi satır satır embed ederek bir JSONL çıktısı oluşturabilirsiniz.

4) Vektör Dizini Kur: Hafif bir çözüme ihtiyaç varsa Chroma veya FAISS gibi kütüphaneleri tercih edin. Python tarafında pip install chromadb ile başlayabilir, vektörleri ve metin parçalarını koleksiyonlara ekleyebilirsiniz. Alternatif olarak SQLite tabanlı vektör eklentileri (ör. sqlite-vss) yerel, dosya tabanlı bir yaklaşım sunar.

5) Sorgu ve Geri Getirme: Kullanıcı sorgusunu aynı embedding modeliyle vektöre çevirin, en benzer N doküman parçasını bulun ve bu parçaları model istemine (prompt) “bağlam” olarak ekleyin. Ardından curl -s http://localhost:11434/api/generate veya ollama run llama3:8b üzerinden, oluşturduğunuz bağlamı içeren bir istemle yanıt üretin.

Performans ve Doğruluk İçin İnce Ayar

- Daha hızlı yanıt için kısa bağlam ve az sayıda parça ile deneyin; gerekirse N değerini 3–5 aralığında tutun. Uzun bağlamlar, özellikle küçük modellerde kaliteyi bazen düşürebilir.

- Top-k ve top-p örnekleme ayarları ile yaratıcılık/kararlılık dengesini kurun. Kritik teknik metinlerde deterministikliğe yakın ayarlar tercih edin.

- Kaynak parçaları yanıtın sonunda listeler veya dipnotlar olarak ekletin. Bu hem şeffaflık sağlar hem de güveni artırır. İstemde “Kaynaklardan alıntı yap ve bağlantı ver” gibi net talimatlar verin.

Güvenlik ve Gizlilik

Yerel kurulumun en büyük artısı verilerin bilgisayarı terk etmemesidir. Yine de hassas belgelerle çalışırken disk şifrelemesi, güçlü oturum açma yöntemleri ve düzenli yedekleme kullanın. Eğer API’nizi ağ üzerinden açacaksanız bir ters proxy arkasında kimlik doğrulama ekleyin. Model ve embedding versiyonlarını not edin; üretim senaryosunda değişikliklerin etkisini takip etmek için versiyonlama kritiktir.

Sonuç

Ollama ile yerel LLM kurmak, düşündüğünüzden daha hızlı ve verimli. Küçük bir embedding modeli ve hafif bir vektör diziniyle kuracağınız RAG katmanı, kişisel notlarınızdan teknik dokümanlara kadar geniş bir bilgi tabanını akıllıca sorgulamanıza imkân tanır. Donanımınıza göre doğru model ve kuantizasyonu seçip GPU hızlandırmayı aktifleştirdiğinizde, bulut bağımlılığını azaltan, düşük gecikmeli ve gizlilik dostu bir üretken yapay zekâ deneyimi elde edersiniz. İlk POC’yi başarıyla tamamladıktan sonra; bir REST arayüzü ekleyip arka planda planlanmış yeniden indeksleme görevleri ve log analiziyle yapınızı olgunlaştırabilirsiniz.

Tarayıcıda Yerel Yapay Zeka: WebGPU ve ONNX Runtime Web ile Görsel Sınıflandırma Nasıl Çalıştırılır?

Özet ve Neden Önemli?

Tarayıcıda çalışan yapay zeka, gizlilik, gecikme ve kullanıcı deneyimi açısından oyunun kurallarını değiştiriyor. WebGPU ile birlikte ONNX Runtime Web kullanarak bir görsel sınıflandırma modelini tamamen istemcide, yani kullanıcının cihazında çalıştırabilirsiniz. Böylece veriler sunucuya gönderilmez, ağ gecikmesi azalır ve uygulama çevrimdışı senaryolarda dahi işlevini sürdürür. Bu yazıda, sıfırdan bir ön yüz projesine WebGPU destekli ONNX Runtime Web ekleyerek, bir görüntüyü sınıflandırma adımlarını sade ama teknik açıdan tatmin edici bir şekilde ele alacağız.

Gereksinimler ve Mimari

WebGPU, modern tarayıcılarda donanım hızlandırmalı hesaplamaya erişmek için tasarlanmış, Vulkan/Metal/DX12 benzeri bir grafik ve hesap arayüzüdür. Chrome ve Edge’de kararlı; Safari’de Technology Preview; Firefox’ta ise genellikle bayrakla etkinleştirilmektedir. ONNX Runtime Web (kısaca ort), ONNX formatındaki modelleri tarayıcıda WASM, WebGL veya WebGPU üzerinde çalıştırır. Mimari şu şekilde işler: model dosyası (örn. mobilenetv3.onnx), tarayıcıya indirilir; preprocess aşamasıyla görüntü tensöre dönüştürülür; WebGPU yürütücüsü ile ileri besleme yapılır; sonuçlar postprocess ile insan tarafından anlaşılır etiketlere çevrilir.

Kurulum ve Dosya Yapısı

Basit bir yapı için bir HTML dosyası (index.html), bir JavaScript dosyası (app.js) ve model/etiket dosyalarınız (models/mobilenetv3.onnx, labels.txt) yeterlidir. Paket yöneticisi kullanacaksanız onnxruntime-web paketini ekleyebilir veya CDN üzerinden import edebilirsiniz. Yerel geliştirme için npm create vite@latest ile hafif bir iskelet kurup, npm i onnxruntime-web komutuyla kütüphaneyi dahil edebilirsiniz. Veya basit bir HTML sayfasında <script type="module"> ile ESM import yapabilirsiniz.

WebGPU’nun Etkinliği ve Geri Dönüş Planı

Önce tarayıcının WebGPU desteğini kontrol edin: if ('gpu' in navigator). ONNX Runtime Web oturumunu başlatırken yürütücüleri öncelik sırasına koyabilirsiniz: executionProviders: ['webgpu', 'webgl', 'wasm']. Böylece WebGPU yoksa WebGL, o da yoksa WASM’a otomatik düşülür. Bu yaklaşım, geniş bir cihaz/tarayıcı yelpazesini hedeflemenizi sağlar.

Modeli Yükleme ve Oturum Oluşturma

Bir InferenceSession başlatırken, graphOptimizationLevel ve preferredOutputLocation gibi seçeneklerle performansı iyileştirebilirsiniz. Örnek bir akış şu şekildedir: modeli fetch ile indirip await ort.InferenceSession.create çağırarak oturumu hazırlayın; etiket dosyasını (labels.txt) satır satır belleğe alın; giriş tensörünü uygun boyuta (ör. 224x224), kanal sırasına ve normalizasyona getirip Float32Array içine yerleştirin; ardından session.run(feeds) ile çıktı alın.

Ön İşleme: Doğru Tensör, Doğru Sonuç

Ön işleme aşaması, modelden iyi sonuç almak için kritiktir. Tipik olarak aşağıdaki adımları uygularsınız: resmi canvas üzerinde 224x224’e yeniden boyutlandırma; RGB kanallarını çıkarma; piksel değerlerini 0–1 aralığına ölçekleme; modelin beklediği ortalama ve standart sapma ile normalizasyon; kanal sırasını HWC’den CHW’ye çevirme. Son olarak tensörü new ort.Tensor('float32', data, [1, 3, 224, 224]) şeklinde oluşturursunuz.

Çıktının İşlenmesi ve Etiketleme

Modelden alınan ham skorları (logit) softmax ile olasılığa çevirmek, ardından en yüksek değere sahip sınıfı ve olasılığını bulmak temel adımdır. Etiket dosyanızla eşleyip kullanıcıya en olası ilk üç sonucu gösterebilirsiniz. Basit bir kullanıcı arayüzü için bir dosya yükleme alanı ve sonuç listesini güncelleyen kısa bir fonksiyon yeterlidir.

Performans İpuçları

1) WebGPU seçimi: Cihaz destekliyse WebGPU belirgin hız sağlar. 2) Kantizasyon: INT8 veya FP16 kantize modeller daha küçük ve hızlıdır; doğruluk/performans dengesini ölçün. 3) Toplu işleme: Birden fazla görseli ardışık yerine mini-batch olarak çalıştırmak throughput’u artırabilir. 4) WASM ayarları: Geri dönüş halinde ort.env.wasm.numThreads gibi ayarlarla CPU tarafını hızlandırın. 5) IO binding: Gelişmiş senaryolarda giriş/çıkışları GPU belleğinde bağlamak kopyalama maliyetini düşürür. 6) Önyükleme: İlk yüklemede modeli önbelleğe almak (Service Worker, HTTP caching) deneyimi iyileştirir.

Uyumluluk ve Sorun Giderme

Eğer “WebGPU desteklenmiyor” uyarısı alırsanız tarayıcınızı güncelleyin veya geçici olarak WebGL/WASM geri dönüş yolu kullanın. CORS hataları için model ve etiket dosyalarınızı aynı origin’den servis edin veya uygun başlıkları ayarlayın. Bozuk sonuçlar genelde ön işleme hatalarından kaynaklanır: kanal sırası (CHW vs HWC), normalizasyon değerleri ve giriş boyutunu iki kez kontrol edin. Performans düşükse geliştirici araçlarında GPU işlem kullanımını izleyin; entegre GPU’larda FP16/INT8 kazancı değişebilir.

Gizlilik ve Güvenlik

Yerel çıkarım, görsellerin cihazdan çıkmaması sayesinde gizliliği güçlendirir. Yine de kullanıcı izni olmadan dosya okuma, kalıcı depolama veya kamera erişimi gibi API’ler kullanılmamalıdır. Büyük modeller için indirme boyutunu küçültmek (sıkıştırma, kantizasyon) hem veri kullanımı hem de ilk yükleme süresini azaltır.

Sonuç

WebGPU ve ONNX Runtime Web ile tarayıcıda görsel sınıflandırma, artık bir prototipten öteye geçmiş durumda. Doğru model, sağlam ön işleme ve akıllı geri dönüş stratejileriyle, yüksek performanslı ve gizliliğe saygılı deneyimler oluşturabilirsiniz. Küçük bir demoyla başlayın; ardından etkileşimli görsel arama, canlı kamera üzerinde etiketleme veya tamamen çevrimdışı çalışan PWA gibi senaryolara genişleyin. Gelecek, kullanıcıların cihazında—ve siz bugün bunun temelini atabilirsiniz.

Passkey (WebAuthn) ile Parolasız Giriş Nasıl Eklenir? Next.js ve SimpleWebAuthn ile Adım Adım

Passkey nedir ve neden şimdi?

Parolalar artık güvenliğin en zayıf halkası. Passkey, FIDO2 ve WebAuthn standartları ile çalışan, kimlik doğrulamayı cihazınızdaki güvenli donanım modüllerine (Secure Enclave, TPM) emanet eden parolasız bir giriş yöntemidir. Kimlik avına dayanıklıdır, şifre sızmalarından etkilenmez ve iCloud Anahtar Zinciri, Google Parola Yöneticisi ve Microsoft hesabı ile senkronize olabilir. Bu yazıda, modern bir React çerçevesi olan Next.js üzerinde SimpleWebAuthn kullanarak passkey entegrasyonunu adım adım kuracağız.

Mimariyi hızlıca anlayalım

WebAuthn iki temel akıştan oluşur: Kayıt (Registration) ve Giriş (Authentication). Sunucu “relying party” olarak bir challenge üretir, tarayıcı ve cihazınızdaki kimlik doğrulama modülü bu challenge’ı özel anahtar ile imzalar, sunucu da daha önce kaydedilen genel anahtar ile imzayı doğrular. Kritik parametreler: rpId (alan adınız), origin (https kökeniniz), user.id (kalıcı benzersiz kimlik), counter (replay saldırılarına karşı sayaç) ve userVerification (biyometrik/PIN doğrulaması). Hepsi doğru ayarlanmadığında tarayıcı güvenlik nedeniyle işlemi reddeder.

Gerekenler ve kurulum

Başlamak için Node.js 18+ ve Next.js 13+ önerilir. Örneklerde App Router kullanılacaktır. Projeyi oluşturmak için: npx create-next-app@latest passkey-demo. Ardından gerekli kütüphaneler: npm i @simplewebauthn/server @simplewebauthn/browser cookie. Basitlik için oturumları cookie ile yöneteceğiz; gerçek projede JWT veya session store tercih edebilirsiniz.

Kayıt (registration) akışı

1) Sunucu tarafı seçenek üretimi: Kullanıcı yeni bir passkey oluşturmak istediğinde generateRegistrationOptions ile istemciye seçenek döndürün. Örnek ayarlar: rpName: 'Örnek Uygulama', rpID: 'alanadiniz.com', userID: 'kalici-uuid', userName: '[email protected]', attestationType: 'none', authenticatorSelection: { residentKey: 'preferred', userVerification: 'preferred' }. Bu adımda kullanıcıya bir challenge ve uyumlu parametreler verilir.

2) İstemci tarafı oluşturma: Tarayıcıda startRegistration(options) çağrılır ve kullanıcı cihazındaki biyometrik/PIN doğrulaması tetiklenir. İşlem başarılıysa dönen attestationResponse’ı backend’e gönderirsiniz.

3) Doğrulama ve kaydetme: Sunucuda verifyRegistrationResponse ile origin ve rpID doğrulanır. Başarılıysa veritabanına şu alanları kaydedin: credentialId (Base64URL), publicKey, counter, userId, transports, tercihen aaguid ve device type. Bu kayıt, o kullanıcının passkey’inin “kamu anahtarını” temsil eder.

Giriş (authentication) akışı

1) Seçenek üretimi: generateAuthenticationOptions ile istemciye yeni bir challenge gönderin. Eğer sadece belirli kayıtlı kimlik bilgilerine izin vermek isterseniz allowCredentials içinde credentialId’leri gönderin. Parolasız deneyim için discoverable credentials (residentKey) tercih edilir.

2) İstemci doğrulaması: Tarayıcıda startAuthentication(options) çağrılır. Kullanıcı biyometrik/PIN ile onaylar, ortaya çıkan assertionResponse sunucuya gönderilir.

3) Sunucu doğrulaması: verifyAuthenticationResponse ile imza doğrulanır; challenge, origin, rpId ve counter kontrol edilir. Sayaç değeri yükseldiyse veritabanındaki counter güncellenir. Başarılıysa kullanıcıyı oturum açmış sayıp güvenli bir Set-Cookie ile session başlatın.

Üretim için kritik güvenlik ayarları

- HTTPS zorunludur. WebAuthn yalnızca güvenli kökenlerde çalışır (localhost hariç). Cloudflare, Vercel veya kendi Nginx ters proxy’nizle TLS sağlayın.

- rpID tam alan adınız olmalı ve origin ile uyumlu olmalı. Örn. app.ornek.com kullanıyorsanız http:// değil https://app.ornek.com üzerinden test edin.

- userVerification’ı en az preferred, kritik işlemlerde required yapın; böylece biyometri/PIN doğrulaması zorunlu olur.

- Attestation çoğu senaryoda none kalabilir. Cihaz sınıfı kontrolü istiyorsanız indirect veya direct kullanabilir, gizlilik etkilerini değerlendirmelisiniz.

- Orta katmanda rate limiting, CSRF koruması ve replay önlemleri (tek kullanımlık challenge, kısa süreli TTL) uygulayın.

Tarayıcı ve cihaz uyumluluğu

Güncel Chrome, Safari ve Edge sürümleri passkey’i destekliyor. iOS ve Android cihazlarda platform authenticator ile sorunsuz çalışır. Masaüstünde “telefonla doğrula” akışı (QR/BT) mümkün. Kullanıcılara “fiziksel güvenlik anahtarı” (YubiKey) ile ek kayıt yaptırmak da kurtarma planı olarak önerilir.

Sık karşılaşılan hatalar

NotAllowedError: Kullanıcı etkileşimi (click) yoksa veya işlem zaman aşımına uğradıysa görülür. İşlemleri buton tıklamasıyla başlatın ve timeout değerini 60–120 sn yapın.

InvalidStateError: Aynı cihazda aynı kullanıcı için tekrar kayıt deneniyorsa oluşabilir. Kayıt öncesi kullanıcıya mevcut passkey’i kaldırma veya yeni cihaz olarak ekleme seçenekleri sunun.

RP ID hatası: “The RP ID is not a registrable domain” mesajı alıyorsanız muhtemelen localhost dışı http kullanıyorsunuzdur. Her zaman https kullanın ve alan adınızın kökeni ile rpID’yi eşleştirin.

Sonuç ve öneriler

Passkey entegrasyonu hem güvenliği hem de dönüşümü artırır: kullanıcılar parolaları hatırlamak zorunda kalmaz, giriş süresi kısalır. Next.js ve SimpleWebAuthn ikilisiyle temel kurulum birkaç saat içinde tamamlanabilir. Üretimde çoklu cihaz desteği, kurtarma seçenekleri (ikinci passkey, e-posta destekli destek süreci), denetim kayıtları ve ayrıntılı telemetriyi (başarı/başarısızlık oranları, tarayıcı/cihaz dağılımı) planlayın. Parolasız geleceğe adım atmak için bugün küçük bir pilotla başlayabilir, kullanıcılarınızdan gelen geri bildirimlere göre akışı iyileştirebilirsiniz.

Ubuntu 24.04’te Rootless Podman: Kurulum, Güvenlik ve Performans İpuçları (Güncel Kılavuz)

Rootless Podman Nedir?

Podman, Docker benzeri bir konteyner motorudur ancak arka planda daemon gerektirmez ve root yetkisi olmadan çalışabilir. Rootless (köksüz) kurulumlar, tekil kullanıcıların sistem genelinde yetki almadan konteyner çalıştırmasına izin vererek saldırı yüzeyini daraltır. Ubuntu 24.04 LTS ile gelen güncel çekirdek ve kullanıcı alanı araçları, rootless Podman kullanırken güvenlik ve performans açısından önemli avantajlar sunar.

Önkoşullar ve Kurulum

Başlamadan önce sisteminizin güncel olduğundan emin olun. Ubuntu 24.04 ile Podman 4.x/5.x depolarda hazır gelir. Kurulum için sudo apt update && sudo apt install -y podman uidmap fuse-overlayfs slirp4netns komutu yeterlidir. Bu paketler, köksüz ağ ve depolama katmanları için gereklidir. Gerekirse buildah ve podman-compose de ekleyebilirsiniz.

Kullanıcı adınız için kullanıcı ve grup eşlemesi (subuid/subgid) tanımlı olmalıdır. Bunu /etc/subuid ve /etc/subgid dosyalarında kullaniciadi:100000:65536 biçiminde kontrol edin. Eksikse ekleyin ve oturumu yeniden başlatın. Bu sayede rootless Podman, kullanıcı ad alanlarını güvenle izole eder.

Kullanıcı oturumunuzda Podman’ı ilk kez çalıştırdığınızda, podman info ile köksüz modun aktif olduğunu doğrulayın. graphRoot ve runRoot yollarının ~/.local/share/containers ve /run/user/<uid> gibi kullanıcı alanına işaret etmesi gerekir.

Rootless Ağ ve DNS

Köksüz ağ, slirp4netns ile sağlanır. Varsayılan ayarlar çoğu senaryoda yeterli olsa da yüksek throughput gereken durumlarda --network slirp4netns:mtu=65520,tap=true gibi iyileştirmeler deneyebilirsiniz. DNS tarafında, /etc/resolv.conf içeriği konteyner içerisine geçirildiğinden sıkı DNS politikalarınız varsa özel bir --dns parametresi belirtmek bağlantı sorunlarını azaltır.

Depolama: fuse-overlayfs ve Katman Önbelleği

Rootless modda overlay sürücüsü, fuse-overlayfs üzerinden çalışır. Performansı iyileştirmek için Podman otomatik algılama yapar; yine de podman info ile store.graphDriverName değerinin overlay olduğunu doğrulayın. Büyük imajlarda build sürelerini kısaltmak için podman build --layers=true --cgroup-manager=cgroupfs --jobs=4 gibi parametreler kullanabilirsiniz. --jobs, bağımsız katmanların eşzamanlı derlenmesini teşvik eder.

Sık kullanılan baz imajları yerel olarak güncel tutmak önbelleği güçlendirir. podman pull ile düzenli çekim yapın ve podman image prune ile atık katmanları temizleyin. Geliştirme sırasında bağımlılıkları ayrı katmanlara taşımak (ör. pip install -r requirements.txt adımını kod kopyalamadan önce yapmak) build tekrarlarında büyük fark yaratır.

Güvenlik Sertleştirmeleri

Rootless Podman zaten güçlü bir izolasyon sağlar; yine de ek sertleştirme önerilir. Çalıştırma sırasında gereksiz yetkileri bırakmak için --cap-drop=ALL ile başlayın ve yalnızca gerekliyse spesifik yetkileri ekleyin. Dosya sistemi bütünlüğü için --read-only ve yazma gereken yollar için -v /yol:rw yaklaşımı tercih edin.

Ubuntu’da AppArmor profilleri varsayılan olarak etkindir. Profil saptamak ve sorun yaşarsanız geçici olarak rahatlatmak için --security-opt apparmor=unconfined denenebilir; ancak kalıcı çözüm için minimal özel profil oluşturmanız önerilir. Ek olarak, seccomp filtreleri varsayılandır; özel çağrılar gerekiyorsa --security-opt seccomp=dosya.json ile dar kapsamlı izin verin.

Konteyner başlatırken kullanıcıyı düşürmek kritik önem taşır. İmajda USER app tanımlayın veya çalıştırmada -u 1000:1000 kullanın. Böylece rootless üzerinde ek bir güvenlik katmanı oluşturmuş olursunuz.

Geliştirici İş Akışı: Compose, Build ve SBOM

Takım çalışması için podman-compose ile docker-compose.yml dosyalarını büyük ölçüde uyumlu biçimde kullanabilirsiniz. Rootless ortamda bağlanan portları -p 8080:80 gibi kullanıcı alanı NAT üzerinden yayınlayın. Geliştirme/test ayrımı için --env-file ile yapılandırma yönetimi düzenli tutulmalıdır.

Build süreçlerinde buildah ve Podman birlikte çalışır. Tek Dockerfile ile çok aşamalı imajlar (multi-stage) oluşturmak, final katmanı küçük tutar. Tedarik zinciri görünürlüğü için podman build --sbom=true ve podman manifest ile çok mimarili imajlar üretmeyi düşünün. İmaj imzalama için sigstore/notation entegrasyonları güveni artırır.

Hizmet Olarak Çalıştırma ve Sistem Entegrasyonu

Sunucu uygulamalarını kullanıcı oturumundan bağımsız başlatmak için systemd user ünitelerini kullanın. loginctl enable-linger <kullanici> komutu, oturum kapalıyken bile user systemd’nin çalışmasını sağlar. Podman, podman generate systemd --new --files --name servis ile servis dosyaları üretir; bunları ~/.config/systemd/user altına koyup systemctl --user enable --now ile etkinleştirin.

Sorun Giderme İpuçları

Ağ erişimi yavaşsa slirp4netns’in yeni sürümünü deneyin veya MTU değerini düşürüp tekrar test edin. Cgroups v2’nin etkin olduğundan emin olun; değilse kapsayıcı kaynak sınırlamaları beklediğiniz gibi çalışmayabilir. Disk alanı hızla doluyorsa podman system df ile katmanları analiz edip podman system prune çalıştırın. Yetki hatalarında çoğunlukla /etc/subuid//etc/subgid eksik veya dar aralık tanımlıdır; aralığı genişletmek çözüm sağlar.

Sonuç

Ubuntu 24.04 üzerinde rootless Podman, güvenliği artırırken geliştirici hızını düşürmeden modern konteyner iş akışlarını mümkün kılar. Doğru ağ, depolama ve sertleştirme ayarlarıyla hem yerel geliştirme hem de kullanıcı bazlı servislerde verimli, izole ve izlenebilir bir ortam kurabilirsiniz. Bu kılavuzdaki pratik ayarları uygulayarak konteynerlerinizi daha güvenli ve performanslı çalıştırabilirsiniz.

Jetson Orin Nano’da Llama.cpp ile 7B LLM Çalıştırma ve Optimize Etme Rehberi

Giriş: Neden Jetson Orin Nano’da Yerel LLM?

Gizlilik, gecikme ve maliyet avantajları nedeniyle büyük dil modellerini (LLM) uçta çalıştırmak giderek daha cazip hale geliyor. Nvidia Jetson Orin Nano; CUDA hızlandırması, kompakt form faktörü ve yeterli bellek bant genişliğiyle, 7B sınıfı LLM’leri makul hızlarda çalıştırmak için güçlü bir aday. Bu rehberde, llama.cpp ile 7B bir modeli Jetson Orin Nano’da kurup çalıştırmayı, ardından performans ve stabiliteyi iyileştirmek için yapabileceklerinizi adım adım anlatıyorum.

Önkoşullar ve Donanım Notları

Jetson’unuzda JetPack’in güncel bir sürümü kurulu olmalı (CUDA/cuBLAS bu pakette gelir). Orin Nano 8 GB ile 16 GB bellek arasında fark hissedilir; 8 GB’de 7B model çalışır ama bağlam penceresi büyükse (ör. 4K) bellek baskısı artar. Uzun oturumlarda throttling’i önlemek için iyi bir soğutma ve yeterli güç adaptörü şart. Kartı microSD ile kullanıyorsanız, mümkünse UHS-I hızlı bir kart ya da NVMe tercih edin. Sistem kararlılığı için 2–4 GB swap da hayat kurtarıcı olabilir.

Gerekli Paketler ve Derleme

llama.cpp, Jetson’da cuBLAS üzerinden GPU hızlandırmayı destekler. Önce temel araçları kuralım:

Komutlar:
sudo apt update && sudo apt upgrade -y
sudo apt install -y build-essential git cmake ninja-build

Kaynak kodu alın ve CUDA destekli derleyin:

git clone https://github.com/ggerganov/llama.cpp.git
cd llama.cpp
make LLAMA_CUBLAS=1 -j6

Derleme tamamlandığında klasörde main ikilisini göreceksiniz. Bu ikiliyi kullanarak modeli çalıştıracağız.

Model Dosyası (GGUF) ve Boyut Seçimi

llama.cpp, GGUF formatındaki modelleri kullanır. 7B bir modelin Q4_K_M gibi agresif bir quantization’ı genellikle 4–5 GB civarındadır ve Jetson Orin Nano 8 GB için iyi bir başlangıçtır. Q5 tipleri biraz daha çok bellek ister, karşılığında doğruluk artar. GGUF dosyasını örneğin ~/models içine koyduğunuzu varsayalım. Büyük bağlam pencereleri (ör. 4096 token) KV önbelleği nedeniyle bellek kullanımını ciddi artırır; ilk denemelerde 2048 civarı daha güvenlidir.

İlk Çalıştırma: Doğru Bayraklarla Başlayın

Aşağıdaki örnek, 7B bir modeli Q4_K_M ile, GPU’ya katman offload ederek başlatır. -ngl GPU’ya atılacak katman sayısını, -t CPU iş parçacığı sayısını, -c bağlam penceresini belirler.

./main -m ~/models/your-7b.Q4_K_M.gguf \
-ngl 20 -t 4 -c 2048 -n 200 \
--temp 0.7 --repeat-penalty 1.1 \
-p "Türkçe olarak, Jetson Orin Nano’da yerel LLM çalıştırmanın avantajlarını anlat."

İlk denemede -ngl 20 ile başlayın. Bellek yeterliyse 24–32 aralığına kademeli çıkabilirsiniz. Jetson’un birleşik belleği nedeniyle ekran, tarayıcı gibi uygulamalar açıkken OOM (out-of-memory) hatası alabilirsiniz; gereksiz süreçleri kapatın.

Performans İpuçları: nvpmodel, jetson_clocks ve Isıl Yönetim

Orin’in performans modunu en yükseğe almak için şunları uygulayın:

sudo nvpmodel -m 2
sudo jetson_clocks

Bu iki komut, güç bütçesini ve saat hızlarını maksimuma yaklaştırır. Uzun oturumlarda sıcaklıklar yükselebilir; iyi bir fan profili ve havalandırma şarttır. Aksi halde GPU/CPU termal kısıtlamaya girip tokens/s değeriniz düşer.

Doğru Ayarları Bulmak: Denge Sanatı

- Quantization seçimi: Q4_K_M genelde iyi bir başlangıç; daha iyi kalite istiyorsanız Q5 seçeneklerini deneyin ancak bellek kullanımına dikkat edin.
- Bağlam penceresi: 2048→4096’a çıkmak kaliteyi artırır ama KV önbelleği büyür. Bellekte zorlanıyorsanız 1536–2048 aralığı iyi dengedir.
- İş parçacığı (-t): Orin Nano’da 4–6 aralığını test edin. Her zaman maksimum çekirdek sayısı en iyi sonuç vermez; ısı ve bellek bant genişliği sınırlayıcı olabilir.
- GPU katmanları (-ngl): Değer yükseldikçe hız artar ama VRAM/birleşik bellek tüketimi de artar. OOM görürseniz önce -ngl’yi, sonra -c’yi düşürün.
- Ön ısıtma (warm-up): İlk birkaç istekte hız düşük görünebilir; oturum uzadıkça derleyici ve önbellek etkileriyle stabil hale gelir.

Swap/ZRAM ve Kararlılık

8 GB’lık sistemlerde büyük bağlamlarda swap faydalıdır. ZRAM etkinleştirmek için sisteminizdeki servis mevcutsa aşağıdaki komut işinizi görebilir:

sudo systemctl enable nvzramconfig
sudo systemctl start nvzramconfig

Klasik bir swap dosyası da oluşturabilirsiniz; fakat swap’ın SSD ömrü ve performansı etkileyebileceğini unutmayın. Hedefiniz OOM’u önlemek için “emniyet kemeri” sağlamaktır, sürekli swap tüketmek değil.

Sorun Giderme

- CUDA out of memory: -ngl ve/veya -c değerlerini azaltın, diğer uygulamaları kapatın. Q4 yerine daha küçük bir quantization da deneyebilirsiniz.
- Düşük tokens/s: Güç modu ve saatlerin açık olduğundan emin olun; soğutmayı güçlendirin; -t ve -ngl kombinasyonlarını test edin.
- Derleme hataları: make temizleyip yeniden derleyin: make clean && make LLAMA_CUBLAS=1 -j6. Gerekirse cmake ile taze bir build klasörü kullanın.

Sonuç: Uçta LLM, Pratikte Mümkün

Jetson Orin Nano üzerinde llama.cpp ile 7B bir LLM’i çalıştırmak, doğru quantization ve ayarlarla gayet mümkün. Gizlilik hassasiyetleri olan uygulamalarda, internet bağlantısının zayıf olduğu senaryolarda veya düşük gecikmeli etkileşim gereken robotik/kontrol projelerinde yerel LLM büyük fark yaratır. Bu rehberdeki adımlar ve ince ayar ipuçlarıyla, hem stabil hem de tatmin edici hızlarda bir kurulum elde edebilirsiniz. Geriye kalan, kullanım amacınıza uygun prompt mühendisliği ve model seçimi ile deneyimi zenginleştirmek.