Yerel LLM.
Uygun boyutlandırılmış.
Uygun modelden yönetilen yapay zekâ hizmetine: DAXS, yerel LLM altyapısını planlar, donanımı gerçek yük altında test eder ve çözümü mevcut BT'nize entegre eder.
Bir yapay zekâ sunucusu yük profiliyle başlar.
Yerel bir dil modeli dahili metinleri hazırlayabilir, kod taslaklarını destekleyebilir veya bilgi aramasının parçası olarak çalışabilir. Kullanılabilir bir çözüm için model kalitesi, izin verilen veri yolları ve beklenen kullanım birbiriyle uyumlu olmalıdır. DAXS bu gereksinimleri kaydeder, altyapıyı planlar ve kurulumu, entegrasyonu ve kararlaştırılan işletimi üstlenir; BT biriminizle birlikte veya kapsamı belirlenmiş bir hizmet olarak.
Görev ve kalite
Çözüm hangi soruları, dilleri, belgeleri veya kod görevlerini karşılamalı? Kısa bir sohbet ve uzun belgelerin analizi farklı modeller ve bağlamlar gerektirir.
Kullanım ve bekleme süresi
Aynı anda kaç istek geliyor? İlk yanıt ne kadar hızlı başlamalı ve tam bir yanıt en fazla ne kadar sürmeli? Ara sıra gelen tekil isteklerle sürekli kullanılan ekip hizmeti farklı kapasite payları gerektirir.
Veriler ve işletim
Hangi kaynaklara ve işlevlere izin verilmiş? Model, arama dizini, günlükler ve yedekler nerede bulunabilir? Güncellemelerle ve hatalarla kim ilgilenir, hangi geri dönüş yolu gerekir?
Uygulamayı, çıkarımı ve işletimi düzenli bağlamak.
Kullanıcı arayüzü yalnızca bir parçadır. Önünde kimlik ve erişim kontrolleri; arkasında çıkarım hizmeti, model deposu ve gerektiğinde bilgi araması veya şirket arayüzleri çalışır. İzleme, güncellemeler ve kurtarma aynı plana dahildir.
Çizim, olası bir mimariyi gösterir; gerçek bir müşteri ağı değildir. Reverse proxy, TLS'i ve giriş noktasını koruyabilir. Buna rağmen uygulama kullanıcı haklarını uygulamalıdır. Model API'leri gerekli ağlar ve işlevlerle sınırlandırılır; erişilebilir bir çıkarım portu henüz hazır bir kurumsal hizmet değildir.
Model dosyasının boyutundan fazlası.
Seçimde ağırlıkları, çalışma zamanı ihtiyacını, bağlamı, eşzamanlılığı ve tüm veri yolunu değerlendiririz. Bir GPU yeterli belleğe sahip olup istenen yanıt süresi için yine de uygun olmayabilir. Buna karşılık iyi seçilmiş daha küçük bir model görevi daha ekonomik çözebilir.
| Bileşen | Neyi inceliyoruz? | Neden önemli? |
|---|---|---|
| GPU ve VRAM | Mimari, sürücüler, çıkarım arka ucu, desteklenen hesaplama biçimleri, bellek kapasitesi ve bant genişliği. | Ağırlıklar ve KV önbelleği alan gerektirir. İşlem gücü ve bellek aktarımları farklı çalışma aşamalarını etkiler; tanıtılan bir TOPS değeri tek başına uygulamayı tanımlamaz. |
| Bir veya birden fazla GPU | Modelin bölünmesi, GPU'lar arası bağlantı, PCIe bağlantısı, enerji ve soğutma. | VRAM kendiliğinden serbestçe kullanılabilen ortak belleğe dönüşmez. Bölme ve eşzamanlama seçilen yazılım yığını tarafından desteklenmelidir; ek GPU'lar yeni darboğazlar yaratabilir. |
| CPU ve sistem RAM'i | Çalışma zamanı, tokenleştirme, veri hazırlama, paralel süreçler ve gerektiğinde CPU çıkarımı veya offloading. | Offloading, bir modeli çalıştırılabilir hale getirebilir ancak performans profilini değiştirir. RAM ile GPU arasındaki aktarımlar yanıtı yavaşlatabilir. GPU sunucusunun da uygun CPU ve RAM kapasite paylarına ihtiyacı vardır. |
| NVMe ve depolama | Model sürümleri, yükleme süreleri, arama dizini, içe aktarılacak veriler, günlükler, boş kapasite ve yedekler. | Hızlı NVMe SSD'ler model yüklemede ve belirli veri işlemlerinde yardımcı olur. Tamamen GPU belleğinde bulunan bir modelin token üretimini esas olarak hesaplama, bellek ve çalışma zamanı etkenleri belirler. |
| Ağ ve besleme | Bağlantı, izin verilen veri yolları, alan, güç ihtiyacı, atık ısı ve bakım erişimi. | Hizmet gerçek yük altında ısıl, kurumsal veya veri erişimi açısından sınırlandığında, en iyi tekil hesaplama bileşeni pek yarar sağlamaz. |
Hesaplama yardımcısı; satın alma önerisi değildir.
Yalnızca ağırlıklar için alt sınır kabaca şu formülle Parametre sayısı × ağırlık başına bit ÷ 8 değerlendirilebilir. Sekiz milyar parametreli ve ağırlık başına dört bit kullanan varsayımsal bir model, hesaplamayla dört gigabayt, yani yaklaşık 3,73 GiB eder.
Buna nicemleme metaverileri, gerektiğinde daha yüksek hassasiyetli model parçaları, KV önbelleği, çalışma alanları ve çalışma zamanı eklenir. Bu nedenle bu değer, uygulamanız için hangi VRAM kapasitesinin yeterli olduğunu kesinlikle söylemez. Uzman mimarili modellerde etkin hesaplama bölümleriyle toplamda hazır tutulması gereken ağırlıklar da ayrılmalıdır.
Kısa bir yanıt, ekip hizmetinden farklı bir testtir.
Bağlam penceresi, modelin bir istek için dikkate alabileceği bilgileri kapsar. Uygulamaya göre talimatlar, görüşme geçmişi, getirilen belge parçaları ve planlanan çıktı buna dahildir. Nominal olarak büyük bir bağlam penceresi ne uygun donanımı ne de bilginin güvenilir kullanımını garanti eder.
KV önbelleği
Key-Value önbelleği, dikkat mekanizmasının ara durumlarını saklar. İhtiyacı; model mimarisine, veri türüne, fiilen kullanılan bağlama ve aynı anda etkin dizilere bağlıdır. Daha fazla bağlam ve eşzamanlılık çoğu zaman bellek ihtiyacını belirgin artırır.
Prefill ve decode
Prefill aşamasında model giriş bağlamını işler; decode aşamasında yeni tokenler üretilir. İki aşama donanımı farklı yükler. Uzun belgeler, sonraki çıktı akıcı görünse bile ilk tokene kadar geçen süreyi artırabilir.
Toplu işleme ve kuyruk
Birlikte işleme toplam verimi artırabilir. Aynı zamanda tekil kullanıcılar daha uzun bekleyebilir. Bu nedenle ayrılmış kapasite, kuyruklar, sınırlar ve uygun eşzamanlılık planlaması tasarıma dahildir.
Gerçek kullanım senaryosunu ölçeriz.
Bir pilot, tipik kısa ve uzun istekleri ve eşzamanlı erişimleri kapsar. Bu sırada İlk tokene kadar geçen süreyi, tam yanıt süresini, çıktı hızını, kuyruğu, hata oranını ve bellek kullanımını değerlendiririz. Saniyedeki token sayıları ancak model sürümü, nicemleme, bağlam, yük ve ölçüm koşullarıyla birlikte anlamlı biçimde karşılaştırılabilir.
Yazılım yığını, modele ve kullanıma göre seçilir.
Ollama, llama.cpp ve vLLM olası yapı taşlarıdır. Seçim ve yapılandırma; model desteğine, donanıma, istenen eşzamanlılığa, işletime ve entegrasyona göre belirlenir. Genel bir kurulum komutunu üretim mimarisi saymak yerine somut sürümü inceleriz.
Ollama
Model yönetimi ve yerel sunum için olası bir başlangıç. Model deposu, izin verilen modeller, bağlam, eşzamanlılık ve hizmetin korunması ortama uygun olmalıdır.
llama.cpp
Farklı CPU/GPU arka uçlarında uygun modeller için nicemlenmiş biçimler ve sunucu işletimi sunan esnek bir bileşen. Donanım desteği, bölme ve gerçekten gerekli API işlevleri uygulamada test edilir.
vLLM
Uygun sunucu tarafı çıkarım ve yük profilleri için bir seçenek. Zamanlama, KV önbelleği, toplu işleme ve gerektiğinde birden fazla GPU birlikte uyarlanır. Daha yüksek toplam verim, her isteğin daha kısa beklemesi anlamına gelmez.
Konteyner, sanal makine veya ayrı sunucu?
Konteynerler yazılım sürümlerini tekrarlanabilir biçimde paketleyebilir. Sanal makine, ortamı kurumsal ve teknik açıdan ayrıca ayırabilir. Uygun yol; cihaz aktarımına, sürücülere, bakıma ve mevcut işletim süreçlerine bağlıdır. Uyumlu bir API bağlantıyı kolaylaştırır ancak uygulamanızla işlev testinin yerini tutmaz.
GPU passthrough ile Proxmox ne zaman uygundur?
GPU passthrough, uygun bir fiziksel GPU'yu bir sanal makineye atar. Bunun için platform ve ürün yazılımı, IOMMU grupları, ana ve konuk sistem sürücüleri ve cihazın sıfırlama davranışı uyumlu olmalıdır. Taahhütten önce somut bileşimi test ederiz.
Atanmış bir GPU, kendiliğinden birden fazla VM arasında esnek paylaşılabilir değildir. vGPU ve doğrudan aktarım; kendi ön koşulları ve gerektiğinde lisans koşulları olan farklı kavramlardır. Bakım, yedekleme ve olası ana sunucu değişimi de uygun süreç gerektirir; genel bir canlı geçiş taahhüdü uygun olmaz.
Uygun model görevi karşılamalıdır.
Modelleri sonraki kullanımdan izin verilen örneklerle karşılaştırırız: Almanca uzmanlık soruları, belge alıntıları, çok dilli istekler veya somut bir betik görevi gibi. Kodlama modeli ve embedding modeli farklı görevler yürütür. Bilgi aramasında arama, embedding'ler ve yanıt modeli birbiriyle uyumlu olmalıdır.
Nicemleme çoğu zaman bellek ihtiyacını azaltır. Yanıt kalitesine, araç çağrılarına ve hıza etkileri seçilen biçimde test edilir. Daha büyük bir model kendiliğinden daha iyi veya daha ekonomik seçim değildir. Uzun azami bağlam da modelin içindeki her bilgiyi güvenilir kullandığını kanıtlamaz.
- Lisans: Seçilen model ağırlıklarını, ticari kullanımı, dağıtımı ve gerekli bildirimleri somut olarak incelemek; kolay indirme bu incelemenin yerini tutmaz.
- Sürüm: Modeli, nicemlemeyi, tokenizer'ı ve çalışma zamanını izlenebilir biçimde kaydetmek.
- Kabul: Uzmanlık açısından uygunluğu, kabul edilemez yanıtları, dil kalitesini ve hata durumlarını tekrarlanabilir bir soru kümesiyle test etmek.
- Değişiklikler: Yeni model sürümlerini önce test etmek, kullanılabilir geri dönüş yolunu korumak ve embedding'ler değiştiğinde arama dizinlerini uygun biçimde yeniden oluşturmak.
Yerel, harici veya uygun bir bileşim.
Kendi donanımı; uygun kullanım oranı, açık veri gereksinimleri ve mevcut işletim çerçevesiyle anlamlı olabilir. Harici hizmet; değişken kullanımda, özel model yeteneklerinde veya sınırlı iç işletim kapasitesinde daha uygun olabilir. Hibrit, sınırları açık görevleri ve veri yollarını hedefli birleştirir.
Karşılaştırma; satın alma veya kullanımı, elektrik ve soğutmayı, lisansları, entegrasyonu, güncellemeleri, desteği, yedek kapasiteyi ve kesinti sonuçlarını kapsar. Yerel işleme kendiliğinden güvenlik veya GDPR garantisi değildir: modeller, embedding'ler, telemetri, güncellemeler, harici araçlar ve günlükler de kararlaştırılan veri konseptine uygun olmalıdır.
Önce ölçülebilir gereksinimleri olan sınırlı bir pilot planlarız. Sonuçtan genişletme, uyarlama veya daha basit bir alternatif kararı çıkar. Diğer temel bilgileri şu adreste bulabilirsiniz: Bulut ve SaaS.
Yönetilen bir hizmet izlenebilir sorumluluklar gerektirir.
DAXS; donanım ve yazılımı planlayabilir, kurabilir, mevcut kimliklere ve uygulamalara bağlayabilir ve kararlaştırılan sürekli işletimi üstlenebilir. Erişilebilirlik ve kaynak izleme, sürüm bakımı, hata yönetimi ve belgeleme buna dahildir. Gerekli kullanılabilirlik ve müdahale yolları somut olarak kararlaştırılır.
Hangi yapılandırmaların, uygulama bileşenlerinin, dizin verilerinin ve gerektiğinde uyarlanmış modellerin yedekleneceğini belirleriz. Yeniden temin edilebilen model ağırlıkları ve korunması gereken işletme verileri farklı yedekleme gereksinimlerine sahiptir. Kurtarma testi uygun işletim konseptine dahildir.
Gereksinim kaydı, mimari öneri, model/yük testi, belgelenmiş veri yolları ve donanım, işletim biçimi ve sonraki entegrasyon adımları için anlaşılır öneri.
Bunları görüşmede netleştiririz.
Yerel bir LLM ne kadar VRAM gerektirir?
Bu; modele, nicemlemeye, çalışma zamanına, bağlama ve eşzamanlı isteklere bağlıdır. Model dosyası tek başına yeterli temel değildir. Somut donanım önermeden önce istenen görevi uzun istekler ve yük zirveleri dahil test ederiz.
İkinci GPU kendiliğinden daha mı hızlıdır?
Hayır. Seçilen yazılım yığını bölmeyi desteklemelidir. GPU'lar arası bağlantılar, eşzamanlama ve model mimarisi sonucu etkiler. Daha fazla bellek, her yanıtı hızlandırmadan çalışmayı mümkün kılabilir.
Mevcut bir Proxmox sunucusu kullanılabilir mi?
Donanım, IOMMU grupları, sürücüler ve GPU aktarımı uygunsa kullanılabilir. Ayrıca diğer hizmetler için kapasite payları ve bakım, yedekleme ve kurtarma süreçleri uygun olmalıdır. Mevcut platformu somut olarak inceleriz.
Dahili belgelerle model eğitilir mi?
Bilgi aramasında bu çoğu zaman gerekli değildir. RAG, uygun ve izin verilen belge parçalarını arar ve bağlam olarak modele verir. Model ağırlıklarını uyarlamak farklı bir işlemdir ve ayrıca gerekçelendirilir.
Harici hizmet ne zaman daha ekonomiktir?
Düşük veya çok değişken kullanımda, özel model gereksinimlerinde veya işletim kapasitesi eksikliğinde harici hizmet daha uygun olabilir. Planlanan kullanım süresi boyunca maliyetleri, veri yollarını, kaliteyi ve işletimi karşılaştırırız.
Modelleri, yükü ve maliyetleri birlikte izlemek.
GPU kullanımı ve yanıt süresinin yanında kullanılabilir görev başına maliyeti değerlendiririz. Bir model güncellemesi, kullanımdan önce onaylı test kümesiyle karşılaştırılır. Hata oranları, kuyruklar, bellek sınırları ve kesintiler için belirlenmiş sorumlular ve geri dönüş yolu gerekir. Harici yedek hizmet ancak veri sınıfı ve onay izin veriyorsa değerlendirilebilir.
Model yönlendirmesini ve toplam maliyetleri ayrıntılandırmak
Kullanım senaryonuzu görüşelim.
Ne kolaylaşmalı, hangi veriler söz konusu ve hangi sistemler zaten mevcut? Buradan anlamlı bir başlangıç ve sınırlı bir sonraki adım geliştiririz.