Kurumsal agentic AI yolculuğu nadiren doğrudan veri merkezi BasePOD ile başlar. Çoğu organizasyon önce fikri doğrular, ajan davranışını ölçer, model ve quantizasyon seçimini netleştirir — sonra production kapasitesine taşır. DGX Spark, bu "öncesi dönem" için NVIDIA'nın masaüstü sınıfı giriş kapısıdır. Bu playbook, pillar rehberindeki mimari süreklilik ilkesini uygulanabilir adımlara indirger: çoklu ajan tasarımı, yerel inference optimizasyonu ve veri merkezine kontrollü geçiş.
Öncesi Dönemin Tanımı ve Çıkış Kriterleri
Öncesi dönem, production SLA ve çok kullanıcılı serving olmadan agentic sistemin iş değerini kanıtladığı fazdır. Tipik süre 8-16 hafta; ekip büyüklüğü 2-8 kişidir. Bu fazın çıkış kriterleri net tanımlanmalıdır; aksi halde Spark ortamında kalma veya erken BasePOD alımı riski doğar.
**Çıkış kriteri örnekleri:** Hedef use case'de %X otomasyon veya verimlilik artışı kanıtlandı. Seçilen model ailesi ve quantizasyon seviyesi benchmark raporunda onaylandı. Tool-calling başarı oranı kabul eşiğinin üzerinde (ör. %95+ doğru araç seçimi). Güvenlik ve KVKK-nvidia-dgx) kontrolleri tasarım dokümanında imzalandı. Eşzamanlı oturum hedefi Spark kapasitesini aşıyor (genellikle 5-10 üzeri sürekli oturum).
Bu kriterler sağlandığında veri merkezi taşıma playbook'u tetiklenir; sağlanmadan taşıma yapılmaz.
Çoklu Ajan Mimarisi: Spark Üzerinde Tasarım İlkeleri
Agentic sistem tek bir LLM çağrısı değildir. Rol tabanlı ajanlar (planlayıcı, araştırmacı, yürütücü, denetçi) orkestrasyon katmanı üzerinden iletişim kurar. Spark'ta mimari tasarımda şu ilkeler uygulanır.
**Ayrıştırma:** Her ajanın sistem prompt'u, araç seti ve bellek bağlamı ayrıdır. Monolitik "tek süper ajan" yerine sınırlı sorumluluk prensibi hata yayılımını azaltır.
**Durum yönetimi:** Oturum durumu (conversation state, plan adımları, ara sonuçlar) harici hafif store'da (SQLite, Redis lokal) tutulur. GPU belleği yalnızca inference için ayrılır.
**Orkestrasyon çerçevesi:** LangGraph, CrewAI, NeMo Agent Toolkit veya AutoGen benzeri çerçevelerden biri standartlaştırılır. Çerçeve seçimi veri merkezine taşınırken değişmemelidir.
**Araç sözleşmesi:** Her tool OpenAPI veya JSON schema ile tanımlanır. Spark'ta mock araçlarla başlanır; entegrasyon aşamalı olarak gerçek internal API'lere bağlanır.
**İnsan-onayı döngüsü:** Yüksek riskli işlemler (finansal işlem, kişisel veri güncelleme) human-in-the-loop checkpoint içerir. Bu desen production'da da korunur.
Spark'ın unified memory mimarisi, küçük ölçekli çoklu ajan simülasyonlarında CPU-GPU veri transferi gecikmesini düşürür. Yine de eşzamanlı ajan sayısı GPU bellek tavanıyla sınırlıdır; paralel ajan yerine sıralı pipeline tercih edilebilir.
Yerel Inference Optimizasyonu
Spark'ta inference performansı, veri merkezi taşıma kararlarının temel girdisidir. Aşağıdaki optimizasyon sırası önerilir.
**Model seçimi:** Use case için minimum yeterli model (7B-70B arası tipik). Daha büyük model her zaman daha iyi agentic davranış vermez; tool-calling için orta boy modeller sık yeterlidir.
**Quantizasyon:** FP8 veya INT4 AWQ/GPTQ ile bellek ve throughput iyileştirmesi. Her quantizasyon seviyesinde tool-calling regresyon testi zorunludur.
**Çalışma zamanı:** vLLM, TensorRT-LLM veya llama.cpp (küçük modeller) karşılaştırmalı benchmark. Spark'ta seçilen runtime BasePOD'da aynı kalır; yalnızca tensor parallel derecesi artar.
**Batching:** Geliştirme fazında continuous batching genellikle kapalıdır; production hedefi için ayrı benchmark koşulur.
**Bağlam yönetimi:** Sliding window, özetleme ajanı veya RAG ile efektif bağlam kısaltma. KV cache büyüklüğü izlenir.
Benchmark metrikleri dokümante edilir: TTFT, tokens/s, tur başına gecikme, bellek tepe kullanımı. Bu rapor TCO ve BasePOD boyutlandırmasına girdi olur.
[RAG](/products/knowledge) ve Vektör Katmanının Spark'ta Prototiplenmesi
Agentic sistemlerin çoğu kurumsal bilgi kaynaklarına dayanır. Spark'ta RAG pipeline üç bileşenle test edilir: embedding modeli, vektör indeks (Chroma, Milvus lokal, FAISS), ve generation modeli.
Embedding ve generation aynı Spark üzerinde çalışabilir; kaynak çekişmesi için sıralı işlem veya küçük embedding modeli tercih edilir. İndeks boyutu büyüdükçe harici NVMe depolama gerekebilir.
Veri merkezine taşırken vektör DB cluster ayrı düğümlere taşınır; embedding pipeline'ı batch job olarak yeniden indeksleme zamanlar. Spark'ta kullanılan chunking stratejisi ve metadata şeması değişmeden kalır.
Güvenlik ve [KVKK](/blog/kvkk-air-gap-nvidia-dgx): Erken Tasarım Gereksinimleri
Öncesi dönemde ihmal edilen güvenlik kontrolleri production'da pahalıya patlar. Spark ortamında bile uygulanması gerekenler:
Kişisel veri içermeyen veya anonimleştirilmiş veri setleri. Secret yönetimi (Vault veya kurumsal secret store); API anahtarları kod deposunda tutulmaz. Araç allowlist ve URL kısıtlaması. Çıktı filtreleme (PII tespiti). Denetim logu iskeleti.
Pillar ve cluster2 içeriklerindeki KVKK/air-gap gereksinimleri bu aşamada tasarım dokümanına referans olarak eklenir; tam uygulama veri merkezi fazında tamamlanır.
Veri Merkezine Taşıma Playbook'u
Taşıma altı fazda yürütülür. Her fazın giriş/çıkış kriterleri ve sorumlu rolü tanımlıdır.
Faz 0 — Hazırlık ve Freeze
Kod deposu tag'lenir. Model ağırlıkları ve LoRA adaptörleri model registry'ye yüklenir. Konteyner imajları CI pipeline ile OCI registry'ye build edilir. Taşıma takvimi ve rollback planı onaylanır.
Faz 1 — Hedef Altyapı Provizyonu
Tek DGX B200 düğümü veya küçük BasePOD slice provizyon edilir. Kubernetes cluster (veya Slurm) GPU operatörü ile hazırlanır. Ağ segmentasyonu ve depolama mount'ları yapılandırılır.
Faz 2 — Parite Deploy
Spark'taki stack birebir hedefe deploy edilir: aynı konteyner imajları, aynı Helm değerleri (replica hariç). Smoke test ve tool-calling regresyon suite çalıştırılır. Metrik paritesi doğrulanır (latency farkı %10 içinde hedef).
Faz 3 — Veri ve İndeks Migrasyonu
Vektör indeksleri ve gerekli statik veri depolamaya aktarılır. Kişisel veri içeren veriler KVKK prosedürüne uygun transfer edilir. Checksum ve satır sayısı doğrulaması.
Faz 4 — Kademeli Trafik Kaydırma
Internal kullanıcılardan başlayarak trafik yüzdesi artırılır (10% → 50% → 100%). Her kademede hata oranı ve latency izlenir. Spark yedek olarak bir süre paralel tutulur.
Faz 5 — Operasyonel Devralma
Monitoring dashboard'ları, alerting kuralları ve on-call rotasyonu devreye alınır. Runbook'lar SRE ekibine devredilir. Spark cihazı geliştirme veya DR cold standby olarak yeniden konumlandırılır.
Taşınabilir Artefakt Envanteri
Mimari sürekliliği sağlayan artefaktlar:
OCI konteyner imajları (immutability). Helm chart'lar veya Kustomize overlay'ler. Terraform/Ansible IaC modülleri. Model registry kayıtları (versiyon, quantizasyon, checksum). Benchmark raporları ve SLA hedefleri. Ajan orkestrasyon kodu ve tool schema'ları. CI/CD pipeline tanımları. Observability dashboard JSON export'ları.
Bu envanter taşıma öncesi checklist olarak imzalanır; eksik artefakt taşımayı geciktirir.
Sık Hatalar ve Önleme
**Erken ölçekleme:** Spark'ta kanıtlanmamış mimariyi BasePOD'a taşımak utilization israfı üretir. Çıkış kriterlerini bekleyin.
**Runtime değiştirme:** Taşıma sırasında farklı inference motoru seçmek regresyon riski yaratır. Spark'taki runtime'ı koruyun.
**Gizli durum:** Spark diskinde kalan oturum durumu taşınmaz; durum harici store'da olmalıdır.
**Ağ varsayımları:** Spark'ta localhost olan servisler veri merkezinde DNS ve service discovery gerektirir.
**Bellek yanılsaması:** Tek Spark'ta çalışan model boyutu, çok replika production'da farklı boyutlandırma ister.
Ölçüm ve Sürekli İyileştirme
Taşıma sonrası ilk 30 gün: günlük GPU utilization, P99 latency, tool-calling hata oranı, oturum başına maliyet. Spark dönemi metrikleriyle karşılaştırma.
Ajan mimarisi evrimi: yeni araçlar, yeni ajan rolleri Spark veya staging namespace'te test edilir; production'a CI/CD ile alınır.
Pillar Katman Haritasıyla Hizalama
Bu playbook, pillar rehberindeki "birinci aşama Spark, ikinci aşama B200 düğümü, üçüncü aşama BasePOD" yol haritasının operasyonel uygulamasıdır. Cluster1 TCO matrisi taşıma zamanlamasının finansal gerekçesini sağlar; cluster2 KVKK kontrollerini production zonuna taşır.
Çoklu Ajan Desen Kataloğu
Spark prototipleme aşamasında aşağıdaki desenlerden biri veya kombinasyonu seçilmelidir.
**Hiyerarşik planlayıcı-yürütücü:** Üst ajan görevi alt görevlere böler; alt ajanlar paralel veya sıralı çalışır. Karmaşık iş süreçleri otomasyonu için uygundur.
**Peer review:** Bir ajan üretir, ikinci ajan denetler. Finansal raporlama ve hukuki özet gibi yüksek riskli çıktılarda kullanılır.
**ReAct döngüsü:** Düşün-eylem-gözlem döngüsü; araç çağrılarıyla dış dünyaya bağlanır. Teknik destek ve IT operasyon senaryolarında yaygındır.
**Uzman konsensüsü:** Birden fazla domain ajanı aynı soruya yanıt verir; birleştirici ajan sentezler. Çok disiplinli karar destek sistemlerinde etkilidir.
Desen seçimi veri merkezine taşınırken değişmemelidir; yalnızca replika sayısı ve model boyutu ölçeklenir.
Performans Profilleme ve Darboğaz Analizi
Spark'ta her ajan turu için süre profili çıkarılmalıdır: LLM inference, embedding sorgusu, tool execution, serileştirme. Darboğaz bileşen veri merkezi boyutlandırmasına yön verir. Inference ağırlıklı profilde GPU sayısı artırılır; RAG ağırlıklı profilde vektör DB ve depolama IOPS önceliklendirilir.
Profiling araçları: NVIDIA Nsight, PyTorch profiler, custom OpenTelemetry span'leri. Taşıma öncesi ve sonrası profil karşılaştırması parite doğrulamasının parçasıdır.
Ekip Yapısı ve RACI
Öncesi dönemde minimum ekip: ML mühendisi (ajan mimarisi), backend geliştirici (tool entegrasyonu), ürün sahibi (use case), ve IT güvenlik danışmanı (KVKK tasarımı). Taşıma fazında SRE ve ağ mühendisi eklenir.
RACI matrisi taşıma playbook'unun ekinde olmalıdır: kim konteyner build eder, kim production deploy onaylar, kim rollback kararı verir. Belirsiz sahiplik production kesintisinin en yaygın nedenidir.
Test Stratejisi: Birimden Üretime
Spark aşamasında test piramidi üç katmandır. Birim testleri: tool schema validasyonu, ajan durum geçişleri, mock LLM ile deterministik davranış. Entegrasyon testleri: gerçek model ile uçtan uca senaryo, RAG doğruluğu, latency bütçesi. Regresyon suite: her commit'te çalışan otomatik testler.
Veri merkezine taşırken aynı test suite CI pipeline'a taşınır; staging ortamında production ile aynı GPU nesli kullanılmalıdır. Spark'ta geçen testin BasePOD staging'de fail etmesi taşıma blokajıdır. Load test ayrı fazda: hedef eşzamanlı oturumun %120'si ile stres testi.
Maliyet ve Kapasite Projeksiyonu
Spark dönemi benchmark'ları taşıma boyutlandırmasının girdisidir. Oturum başına GPU saniyesi ölçülür; hedef eşzamanlı oturum sayısıyla çarpılarak toplam GPU kapasitesi hesaplanır. %30 headroom operasyonel buffer olarak eklenir.
Cluster1 TCO şablonundaki break-even analizi, taşıma zamanlamasını finansal olarak doğrular. Erken taşıma düşük utilization, geç taşıma SLA ihlali üretir; çıkış kriterleri bu dengeyi kodlar.
Üretim Sonrası İlk 90 Gün
Taşıma sonrası structured review uygulanır. Gün 1-7: günlük war room, latency ve hata oranı. Gün 8-30: haftalık utilization raporu, cost per session trendi. Gün 31-90: aylık mimari retrospektif, yeni use case pipeline değerlendirmesi.
Spark cihazı bu süreçte fallback olarak hazır tutulur. Tam güven sağlandığında geliştirme rolüne alınır veya ikinci Spark ile ekip genişletilir.
Ajan Güvenliği: Prompt Injection ve Politika Katmanı
Spark prototipleme aşamasında güvenlik testleri ihmal edilmemelidir. Prompt injection, tool hijacking ve veri sızıntısı senaryoları için kırmızı takım egzersizi yapılır. Politika katmanı (guardrails, output filter, input sanitizer) production'a taşınmadan önce Spark'ta doğrulanır.
NVIDIA NeMo Guardrails veya eşdeğer çerçeveler ajan pipeline'ına entegre edilir. Politika ihlali loglanır ve otomatik oturum sonlandırma tetiklenebilir. Bu kontroller cluster2 KVKK denetim izi gereksinimleriyle örtüşür.
Dokümantasyon ve Bilgi Transferi
Taşıma sonunda runbook, mimari karar kaydı (ADR) ve operasyon el kitabı güncellenir. Spark döneminde öğrenilen dersler retrospektif toplantısında kayıt altına alınır. Bilgi transferi oturumu SRE ve uygulama ekibi arasında zorunludur.
Eksik dokümantasyon, taşımanın teknik başarısına rağmen operasyonel başarısızlığa yol açar. Her ajan rolü, tool ve model versiyonu konfigürasyon yönetiminde versiyonlanmış olmalıdır.
Gelecek use case'ler için Spark ortamı sürekli inovasyon laboratuvarı olarak kalır. Yeni model ailesi veya ajan deseni önce Spark'ta doğrulanır; production cluster'ı yalnızca kanıtlanmış iş yüklerini barındırır. Bu disiplin, pillar rehberindeki mimari süreklilik ilkesinin uzun vadeli uygulamasıdır.
Taşıma başarı kriterleri sayısal olarak tanımlanmalıdır: P95 gecikme hedefi, hata oranı tavanı, GPU utilization bandı ve oturum başına maliyet üst sınırı. Bu KPI'lar 90 günlük review'da iş birimi ve IT tarafından birlikte değerlendirilir.
Ajan orkestrasyon kodunda feature flag kullanımı, production'da kademeli özellik açılımını mümkün kılar. Spark'ta test edilen yeni ajan rolü flag arkasında production'a alınır; sorun halinde anında kapatılır.
İzleme ve alarm eşikleri taşıma öncesi Spark benchmark'larından türetilir. Beklenmedik latency artışı veya tool-calling hata sıçraması otomatik rollback tetikleyicisi olarak yapılandırılabilir. Operasyon ekibi rollback prosedürünü taşıma gününden önce en az bir kez tatbik etmelidir. Bu hazırlık, üretim kesintisi süresini dakikalarla sınırlar ve iş sürekliliğini korur.
Sonuç
Agentic AI öncesi dönem, DGX Spark ile düşük riskli deney ve kanıt üretimi dönemidir. Çoklu ajan mimarisi, yerel inference optimizasyonu ve disiplinli taşıma playbook'u, veri merkezi yatırımını iş değeri kanıtlandıktan sonra ölçeklendirir.
Kurumunuz için ajan mimarisi değerlendirmesi, benchmark tasarımı ve taşıma planı hazırlığında Lama Yazılım, NVIDIA DGX ekosistemi ve kurumsal agentic AI deneyimiyle AI çözüm ortağı olarak yanınızda olabilir.