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.

OpenTelemetry ile Node.js Mikroservislerde Uçtan Uca Gözlemlenebilirlik: Adım Adım Kurulum

OpenTelemetry Nedir ve Neden Önemlidir?

OpenTelemetry (OTel), uygulamalarınızdan metrik, iz (trace) ve log verilerini standart bir formatla toplayıp farklı arka uç (backend) sistemlerine göndermenizi sağlayan, CNCF çatısı altındaki açık kaynak bir çatı projedir. Mikroservis mimarilerinde bir isteğin hangi servislerde gezdiğini, nerede yavaşladığını veya hata verdiğini anlamak için dağıtık izleme, performans metrikleri ve log korelasyonu kritik öneme sahiptir. OTel; SDK’lar, otomatik enstrümantasyon modülleri, Collector (aracı) ve OTLP adlı açık protokol ile bu süreci basitleştirir.

Hedef Mimari ve Bileşenler

Bu makalede bir Node.js (Express) servisinden izleri OpenTelemetry Collector’a, oradan da Grafana Tempo’ya taşıyacağız. Görselleştirme için Grafana kullanılacak. Metrikler için Prometheus veya Grafana Cloud tercih edilebilir; ancak odak noktamız uçtan uca izleme (tracing) kurulumu olacak. Basitçe akış şöyle: Uygulama (OTel SDK) → OTLP (gRPC) → OTel Collector → Tempo → Grafana.

Ön Koşullar

Node.js 18+ sürümü, Docker ve Docker Compose kurulu olmalı. Yerel ortamda çalışıyorsanız 4317 (OTLP gRPC) ve 3000 (Grafana) portlarının boş olduğundan emin olun. Örnekler Linux ve macOS için benzer; Windows’ta da WSL ile rahatça yürütülebilir.

1) Node.js Projesini Hazırlama

Önce basit bir Express API oluşturalım ve OpenTelemetry paketlerini ekleyelim. Yeni bir klasör açın ve terminalde şu komutları çalıştırın: npm init -y ardından npm i express @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node @opentelemetry/exporter-trace-otlp-grpc @opentelemetry/resources. Bu paketler sırasıyla temel OTel SDK, otomatik enstrümantasyon, OTLP gRPC exporter ve kaynak (service.name vb.) tanımları için gereklidir.

2) OpenTelemetry Yapılandırması (tracing.js)

Projenizin köküne tracing.js adlı bir dosya ekleyin ve aşağıdaki içeriği yerleştirin. Bu dosya Collector’a giden OTLP gRPC bağlantısını kurar ve otomatik enstrümantasyonu aktif eder: const { NodeSDK } = require('@opentelemetry/sdk-node'); const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-grpc'); const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node'); const { Resource } = require('@opentelemetry/resources'); const exporter = new OTLPTraceExporter({ url: process.env.OTEL_EXPORTER_OTLP_ENDPOINT || 'http://localhost:4317' }); const sdk = new NodeSDK({ resource: new Resource({ 'service.name': process.env.OTEL_SERVICE_NAME || 'orders-api', 'service.namespace': 'example', }), traceExporter: exporter, instrumentations: [getNodeAutoInstrumentations()], }); sdk.start().then(() => console.log('OTel tracing started')).catch(err => console.error(err)); process.on('SIGTERM', () => sdk.shutdown());

3) Express Uygulaması (app.js)

Express sunucusunu başlatmadan önce tracing’i import etmek önemlidir; aksi halde otomatik enstrümantasyon bazı modülleri kaçırabilir. app.js dosyası için örnek: require('./tracing'); const express = require('express'); const app = express(); app.get('/health', (req, res) => res.send('ok')); app.get('/orders/:id', async (req, res) => { // İş mantığı simülasyonu await new Promise(r => setTimeout(r, 50)); res.json({ id: req.params.id, status: 'ready' }); }); const port = process.env.PORT || 3001; app.listen(port, () => console.log('API listening on ' + port));

4) OpenTelemetry Collector ve Tempo

Collector, üretim ortamlarında veriyi merkezileştirip birden fazla hedefe yönlendirmek için idealdir. Aşağıdaki basit collector.yaml Tempo’ya iz aktarmaya yeter. Docker ile kullanırken dosyayı aynı klasöre koyun ve mount edin: receivers: otlp: protocols: grpc: exporters: otlp: endpoint: tempo:4317 tls: insecure: true service: pipelines: traces: receivers: [otlp] exporters: [otlp] Bu yapı, Collector’ın 4317 portundan OTLP gRPC ile aldığı izleri, aynı docker ağı içindeki tempo servisine yine OTLP ile iletir.

Basit bir docker-compose.yaml ile Tempo ve Collector’ı ayağa kaldırabilirsiniz. Özetle, otel-collector servisini otel/opentelemetry-collector:latest imajı ile çalıştırıp 4317 portunu publish edin; tempo için grafana/tempo imajını kullanın. Grafana’yı grafana/grafana ile 3000 portunda başlatın. Grafana içinden “Add data source” menüsünde Tempo’yu ekleyip Collector/Tempo adresini işaret edin.

5) Test ve Doğrulama

Node.js uygulamanızı node app.js ile başlatın. Ardından birkaç istek atın: curl http://localhost:3001/orders/123. Grafana’da Tempo veri kaynağını açıp “Explore” sekmesinde hizmet adınızla (ör. orders-api) arama yapın. Trace grafında isteklerin gecikme dağılımını, otomatik enstrümantasyon sayesinde HTTP client/server span’lerini ve hata durumlarını görebilirsiniz. Trace ayrıntılarında attributes altında http.method, http.route gibi alanlar hazır gelir.

Gelişmiş İpuçları ve En İyi Uygulamalar

Üretimde örnekleme (sampling) oranını dikkatle seçin. Başlangıç için parentbased_traceidratio ile %5–10 iyi bir denge sağlar. Node tarafında OTEL_TRACES_SAMPLER=parentbased_traceidratio ve OTEL_TRACES_SAMPLER_ARG=0.1 gibi değişkenler kullanabilirsiniz. Ağ ve depolama maliyetlerini kontrol altında tutmak için gereksiz etiketleri (attributes) azaltın, sadece iş değeri yüksek etiketleri aktarın.

Servisler arası çağrılarda bağlam aktarımı (context propagation) hayati önem taşır. Varsayılan W3C Trace Context çoğu senaryo için yeterlidir. Gateway veya API proxy katmanınız varsa, traceparent ve tracestate başlıklarının bozulmadığından emin olun. Mikroservis zincirlerinde bu başlıkların taşınmaması, izlerin kopuk görünmesine neden olur.

Metrik ve log’larla korelasyon kurmak için aynı resource attributes değerlerini (ör. service.name, service.namespace, deployment.environment) hem uygulama hem Collector tarafında tutarlı kullanın. Log yönünde OTel Logger ile Grafana Loki entegrasyonu, bir trace ID’sinden ilgili log satırına tek tıkla geçiş imkanı verir. Bu, MTTR’ı ciddi biçimde düşürür.

Güvenlik açısından üretimde OTLP trafiğini TLS ile şifreleyin ve Collector’ı egress katmanı olarak konumlandırın. Kubernetes’te DaemonSet veya sidecar modeliyle dağıtım yapabilir, her node’da yerel Collector çalıştırarak ağ gecikmesini azaltabilirsiniz. SLO takibi için kritik endpoint’lerinizde özel span adları ve durum kodu etiketleri kullanmak; hata bütçesi yönetimi ve kök neden analizlerinde büyük kolaylık sağlar.

Sonuç

OpenTelemetry, Node.js mikroservislerinizde gözlemlenebilirliği standart, taşınabilir ve ölçeklenebilir hale getirir. Collector ve Tempo ile kuracağınız hafif mimari hem yerelde hem de bulutta hızlıca devreye alınabilir. Bu rehberle temel taşıyıcıları ayağa kaldırdıktan sonra, metrik ve log entegrasyonlarını ekleyerek tam üç sütunlu gözlemlenebilirlik elde edebilir, üretim ortamında güvenle iterasyon yapabilirsiniz.

PostgreSQL + pgvector ile Semantik Arama ve RAG: Kurulum, İndeks ve Performans Rehberi

Giriş

Semantik arama ve RAG (Retrieval-Augmented Generation) uygulamaları, yalnızca bir metnin kelimelerine değil, anlamına göre sonuç döndürerek daha isabetli yanıtlar verebiliyor. Bu yaklaşımı uygulamak için vektör veritabanı şart. Pek çok ekip, halihazırda kullandıkları PostgreSQL üzerinde pgvector eklentisiyle bu ihtiyacı karşılıyor. Bu yazıda, PostgreSQL + pgvector kombinasyonuyla semantik arama altyapısını nasıl kuracağınızı, indekslemeyi nasıl yapacağınızı ve performansı nasıl optimize edeceğinizi adım adım anlatıyorum.

Neden pgvector?

Pgvector, PostgreSQL’e vektör veri tipi (vector) ve benzerlik aramaları (cosine, L2, inner product) kazandırır. Ayrı bir veritabanı yönetmek yerine tek bir Postgres kümesi üzerinde hem ilişkisel verilerinizi hem de embedding’lerinizi saklayabilirsiniz. Bu, devops maliyetini azaltırken güçlü ACID garantileri ve yedekleme stratejilerinden de yararlanmanızı sağlar.

Önkoşullar

PostgreSQL 14+ önerilir; performans ve özellikler için 15/16 daha iyi. Sunucuda en az 4 CPU, 8 GB RAM başlamak için konfor sağlar. Ayrıca embedding üretmek için bir model (örneğin OpenAI text-embedding-3-small, Instructor, E5-large veya yerel bir model) gereklidir.

Kurulum (Docker ve Yerel)

Docker ile hızlı kurulum: Resmi Postgres imajı yerine pgvector içeren bir imaj kullanabilirsiniz. Örnek:

docker run -d --name pg -e POSTGRES_PASSWORD=secret -p 5432:5432 ankane/pgvector

Yerel kurulum (Ubuntu/Debian): Paket yöneticinizde pgvector olmayabilir. Kaynaktan kurulum tipik akış:

sudo apt-get update && sudo apt-get install -y postgresql postgresql-server-dev-all git make gcc

git clone https://github.com/pgvector/pgvector.git && cd pgvector && make && sudo make install

Veritabanını Hazırlama

Postgres’e bağlandıktan sonra eklentiyi etkinleştirin ve şemanızı oluşturun:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (id bigserial PRIMARY KEY, title text, body text, embedding vector(1536));

Burada vector(1536) embedding boyutunu temsil ediyor. Kullanacağınız modele göre bu değeri değiştirin (örn. 768, 1024, 1536).

Embedding Üretme ve Veri Ekleme

Embedding’leri uygulama katmanında üretip Postgres’e yazmak en yaygın yaklaşım. Basit akış: metni temizle, cümlelere/segmentlere böl, embedding modeline gönder, sonuç vektörünü tabloya ekle.

Örnek bir ekleme akışı:

INSERT INTO documents (title, body, embedding) VALUES ('KVKK Özeti', 'Kişisel verilerin korunması...', '[0.012, -0.034, ...]');

Not: pgvector, köşeli parantezle vektör alır. Uygulama dilinizde (Python/Node/Go) embedding dizisini string’e çevirip eklemek pratik bir yöntemdir.

Benzerlik İndeksleri: IVFFlat ve HNSW

Büyük veri kümelerinde ham tarama yavaştır. Bu nedenle IVFFlat veya HNSW indeksleri kullanılır. IVFFlat için önce tabloyu kabaca küme merkezlerine göre “eğitmek” gerekir.

-- Koşul: önce yeterince satır eklenmiş olmalı

CREATE INDEX ON documents USING ivfflat (embedding vector_cosine) WITH (lists = 100);

HNSW, eğitime gerek duymaz ve bazı veri setlerinde daha iyi gecikme/kalite dengesi sunabilir:

CREATE INDEX ON documents USING hnsw (embedding vector_cosine) WITH (m = 16, ef_construction = 128);

Metrik seçimi kritiktir: embedding modeliniz cosine ile eğitildiyse vector_cosine seçin. Performans için lists (IVFFlat) ve ef_search (HNSW) değerlerini iş yükünüze göre ayarlayın.

Semantik Arama Sorguları

Arama anında, sorgu metnini embedding’e çevirin ve en yakın komşuları çekin:

-- sorgu_embedding uygulama katmanından parametre olarak gelir

SELECT id, title, body FROM documents ORDER BY embedding <#> :sorgu_embedding LIMIT 5;

<#> operatörü cosine distance’dır. En iyi sonuçları almak için LIMIT’i ve filtre koşullarını (ör. kategori, tarih aralığı) birlikte kullanın.

RAG İçin Basit Bir Akış

- Kullanıcı sorusunu alın ve embedding’e dönüştürün.

- PostgreSQL’den en alakalı 5–10 dokümanı semantik aramayla çekin.

- Cevaplayıcı LLM’e, bu parçaları bağlamsal ek metin (context) olarak verin.

- Kaynakları (title ve id) cevapla birlikte kullanıcıya gösterin. Bu yaklaşım, halüsinasyonları azaltır ve izlenebilirlik sağlar.

Performans ve Ölçek İpuçları

1) İndeks ısınması: Sık aranan sorgu türleri için sistem başladığında birkaç “ısınma” araması yapın. Bu, sayfa önbelleğini doldurur.

2) Paralelleştirme: Toplu embedding üretiminde çoklu iş parçacığı ya da job queue kullanın. Veritabanına batch insert (ör. 100–1000 satır) performans sağlar.

3) Tablo tasarımı: Metin gövdeleri büyükse, embedding’leri ayrı bir tabloda (documents_vec) tutup body’yi object storage’a koymayı değerlendirin; Postgres’te sadece referans saklayın.

4) Bakım: Yoğun yazma/indeks güncellemelerinde VACUUM (ANALYZE) planlayın. Autovacuum ayarlarını (naptime, cost_limit) iş yükünüze göre iyileştirin.

5) IVFFlat ayarları: lists değerini veri büyüklüğüne göre artırmak hatırlama oranını iyileştirir; sorgu anında SET ivfflat.probes = X; ile daha fazla liste tarayıp isabet oranını yükseltebilirsiniz (gecikme artar).

6) HNSW ayarları: SET hnsw.ef_search = 64/128/256 gibi değerlerle kalite/gecikmeyi dengeleyin. Daha yüksek ef_search, daha iyi sonuç ama daha fazla CPU demektir.

7) Sharding/Partitioning: Konu veya müşteri bazlı PARTITION BY LIST ile arama alanını daraltmak ciddi kazanç sağlar.

Güvenlik ve Versiyonlama

Embedding uzayı model güncellemeleriyle değişebilir. Model versiyonunu tabloda saklayın (örn. model_version text) ve farklı versiyonlar için ayrı indeks tutun. Erişim tarafında Row Level Security (RLS) ile müşteri/veri bölümlendirmesini zorunlu kılın.

Hata Ayıklama ve Sık Karşılaşılan Sorunlar

- ERROR: type "vector" does not exist: CREATE EXTENSION vector; komutunun ilgili veritabanında çalıştığından ve eklentinin kurulu olduğundan emin olun.

- IVFFlat “not enough tuples”: İndeksi kurmadan önce yeterli sayıda satır eklenmiş olmalı; aksi halde eğitim yapılamaz.

- Yüksek gecikme: İndeks kullanılmıyor olabilir; EXPLAIN (ANALYZE, BUFFERS) ile planı inceleyin. probes veya ef_search değerlerini ayarlayın.

Sonuç

Pgvector, PostgreSQL’i güçlü bir vektör arama motoruna dönüştürüyor. Doğru indeks ve ayarlarla milyonlarca embedding üzerinde milisaniyeler içinde semantik arama yapılabiliyor. RAG senaryolarında ise hem kaynak yönetimini sadeleştiriyor hem de mevcut Postgres ekosisteminin güvenilirliğinden yararlanmanızı sağlıyor. Küçük bir POC ile başlayıp indeks parametrelerini kademeli ayarlayarak en iyi maliyet/performans noktasını yakalayabilirsiniz.

WebGPU ile Tarayıcıda Yapay Zeka: onnxruntime-web ile Hızlı Görüntü Sınıflandırma (Adım Adım Rehber)

WebGPU nedir ve neden önemli?

WebGPU, modern tarayıcılarda yerel GPU erişimi sunan yeni nesil bir web standardıdır. WebGL’in mirasını devralırken, daha düşük seviyeli ve verimli bir API sağlar. Bu sayede tarayıcı içinde yapay zeka modellerini, özellikle de tensör hesaplamalarını GPU üzerinde çalıştırarak ciddi performans artışları elde edebilirsiniz. Bu yazıda, WebGPU ve onnxruntime-web kullanarak basit bir görüntü sınıflandırma örneğini nasıl hayata geçirebileceğinizi adım adım anlatacağım. Amaç, “kodu kopyala-çalıştır” değil; mantığı kavrayıp kendi projenize uyarlayabilmeniz.

Destekleyen tarayıcılar ve ön koşullar

WebGPU, Chrome 113+ ve Edge gibi Chromium tabanlı tarayıcılarda genel olarak desteklenirken, bazı sistemlerde bayrak (flag) açmanız gerekebilir. Adres çubuğuna chrome://flags/#enable-unsafe-webgpu yazıp etkinleştirip tarayıcıyı yeniden başlatın. Donanım olarak modern bir entegre veya ayrık GPU, güncel sürücüler ve mümkünse 8 GB+ RAM önerilir. Ayrıca, proje dizininde basit bir HTTP sunucu (örneğin live-server veya vite) kullanmanız yerel dosya erişim sorunlarını önler.

Proje iskeleti ve kurulum

Temiz bir klasör oluşturun ve bir paket yöneticisiyle başlangıç yapın. Örnek: “npm init -y” ile bir Node projesi başlatın. Ardından “npm i onnxruntime-web” komutuyla tarayıcı sürümünü ekleyin. Statik dosyalar için index.html, model ve etiket dosyaları için “/public” klasörü, mantık kodu için main.js gibi basit bir yapı işinizi görür. Geliştirme sunucusu için “npx vite” gibi bir araç tercih edebilirsiniz; aksi durumda “npx http-server” da yeterli.

Model seçimi: ONNX ve boyut optimizasyonu

Tarayıcı için düşük gecikme ve sınırlı bellek kritik. Bu nedenle küçük ve verimli görüntü sınıflandırma modelleri (MobileNetV2/V3, EfficientNet-Lite) iyi başlangıç noktalarıdır. ONNX formatında bir model indirin veya dönüştürün. Eğer PyTorch veya TensorFlow modeliniz varsa, ONNX’a export edin. Ardından boyutu ve bellek kullanımını azaltmak için quantization uygulayın. Örnek komut akışı: “pip install onnxruntime-tools” ardından dinamik quantization ile “python -m onnxruntime.quantization.quantize_dynamic model.onnx model-int8.onnx”. Tarayıcıda indirme süresini kısaltmak için 8-bit tamsayı (INT8) genellikle iyi bir dengedir.

WebGPU ile oturum başlatma mantığı

onnxruntime-web, birden fazla çalışma sağlayıcısı (execution provider) sunar. Varsayılan WASM’tan maksimum hız beklemiyorsanız WebGPU sağlayıcısını açın. Temel akış şöyledir: 1) Tarayıcıda navigator.gpu mevcut mu kontrol edin. 2) onnxruntime-web’i import edin. 3) “InferenceSession.create(‘model.onnx’, { executionProviders: [‘webgpu’] })” ile oturumu başlatın. 4) Girdiyi (örneğin 224x224 RGB) ön işleyin: yeniden boyutlandırma, normalize etme (mean/std) ve tensör şeklini NHWC veya NCHW’ye uygun hazırlama. 5) “session.run(feeds)” ile çıkarım yapıp çıktıdan en yüksek olasılıklı sınıfı alın. Çıktıları etiket dosyanızla eşleştirerek kullanıcıya dostu bir sonuç sunun.

Veri ön işleme ve performans nüansları

Tarayıcı tarafında piksel işlemleri için OffscreenCanvas ve ImageBitmap kullanmak, ana iş parçacığını (main thread) bloklamadan dönüşüm yapmanıza yardım eder. Mümkünse işlemleri Web Worker içine taşıyın. Normalize (ör. 0-1 aralığına çekme) ve kanal düzeni dönüşümleri (HWC’den CHW’ye) pahalı olabilir; bu adımları GPU ile yapacak eklentiler henüz yaygın olmasa da, yapılabildiği durumlarda dramatik hızlanma sağlar. Ayrıca “warm-up” için ilk çağrıda boş bir tensörle veya düşük çözünürlüklü bir örnekle modeli çalıştırmak, JIT derlemelerini önden tetikleyerek ilk gecikmeyi azaltır.

Hafıza yönetimi ve kullanıcı deneyimi

Model dosyanız büyükse, indirme süresini iyileştirmek için HTTP/2, CDN ve gzip/br sıkıştırmayı aktif edin. Yükleme sırasında aşamalı geri bildirim (yüzde barı, “model yükleniyor”) sağlayın. Mobil cihazlarda bellek sınırlı olduğu için giriş çözünürlüğünü 160-192 gibi daha küçük değerlere düşürmeyi ve modelin INT8 sürümünü varsayılan yapmayı düşünebilirsiniz. Uzun süren işler için kullanıcıya iptal butonu vermek, UI’ın donduğu algısını ortadan kaldırır.

Geriye dönüş (fallback) stratejisi

Her cihaz WebGPU’yu desteklemeyebilir. Bu nedenle oturum açılışı başarısız olduğunda otomatik olarak WASM sağlayıcısına düşmek iyi bir uygulamadır. Mantık basit: “navigator.gpu” yoksa veya adapter alınamadıysa, “executionProviders: [‘wasm’]” ile yeniden dene. Kullanıcıya küçük bir uyarı vererek performansın sınırlı olabileceğini belirtin. Progressive enhancement yaklaşımıyla en iyi olanı kullanıp, geri kalanları zarifçe destekleyin.

Sık karşılaşılan hatalar

“navigator.gpu is undefined”: Tarayıcınız veya platformunuz WebGPU’yu desteklemiyor; bayrakları kontrol edin, tarayıcıyı güncelleyin veya Edge/Chrome deneyin. “Adapter not found” veya “RequestDevice failed”: Sürücüler eski olabilir, GPU erişimi politikalarla kısıtlanmış olabilir. “Out of memory”: Model boyutu büyük; INT8’e geçin, giriş çözünürlüğünü düşürün, arka planda çalışan sekmeleri kapatın. “CORS hataları”: Model dosyalarını aynı origin’den servis edin veya doğru CORS başlıklarını etkinleştirin.

Gizlilik, offline ve güvenlik boyutu

Tarayıcı içinde yerel çıkarım, verinin cihazi terk etmeden işlenmesini sağlar. Bu, özellikle sağlık veya kişisel görsellerin sınıflandırılması gibi senaryolarda mahremiyet avantajı sunar. Doğru Cache-Control ve Service Worker stratejileriyle model dosyalarını offline kullanılabilir hale getirebilir, ilk kurulumdan sonra çevrimdışı sınıflandırma deneyimi sunabilirsiniz. Güvenlik tarafında ise sadece güvenilir kaynaklardan model ve betik dosyaları alın; tedarik zinciri risklerini azaltmak için bütünlük (integrity) ve imza kontrollerini değerlendirin.

Sonuç ve ileri adımlar

WebGPU, tarayıcıda yapay zekayı pratik ve hızlı kılıyor. onnxruntime-web ile birkaç adımda GPU hızlandırmalı görüntü sınıflandırma çalıştırabilir, küçük cihazlarda dahi akıcı bir deneyim sağlayabilirsiniz. Bir sonraki adım olarak, metinle yönlendirilen görsel arama, gerçek zamanlı kamera akışı üzerinde nesne tespiti veya WebAssembly + WebGPU karma stratejileriyle daha Karmaşık modelleri denemeyi düşünebilirsiniz. Performansı daha da artırmak için model mimarilerini küçültmek, katman füzyonu uygulamak ve akıllı önbellekleme teknikleri kullanmak, projelerinizi üretime hazır hale getirir.