LLM'ler ve Yerel Yapay Zeka Donanımı için Çıkarım Motorları (2026 Sürümü)

Önce bir çıkarım motoru seçmezsiniz. Önce bir donanım stratejisi, bir iş yükü şekli ve bir sunum modeli seçersiniz. Motor onu takip eder.

LLM çıkarım motorlarını düşünmenin en faydalı yolu budur.

Seri notu: Bu, Kendi Kendine Barındırılan LLM'ler / Yerel AI serimin 3. Bölümü.

• Bölüm 1: LLM'ler için GPU Bellek Matematiği (2026 Sürümü).
• Bölüm 2: Yerel AI Donanımı için Bellek Bant Genişliği (2026 Sürümü).

Bu iki yazı, donanım kapasitesi ve bant genişliği matematiğini açıklıyor.

Bu yazı ise, bu donanımı kullanılabilir çıkarıma dönüştüren yazılım katmanını açıklıyor.

Motorlar

Bu araçlar farklı amaçlara hizmet eder / farklı katmanlarda yer alır

• Yerel taşınabilirlik
• Tüketici CUDA
• Apple birleşik bellek iş akışları
• Niceleme ile çıkarım
• Üretim sunumu
• Dağıtık orkestrasyon
• Satıcı tarafından optimize edilmiş veri merkezi yürütme

Kullanışlı bir zihinsel model:

Çıkarım motoru "model" değildir. Trafik polisi, bellek yöneticisi, çekirdek dağıtıcısı, zamanlayıcı, önbellek muhasebecisi, paralellik planlayıcısı, API yüzeyi ve bazen de dağıtım çerçevesidir.

En iyi motor, sizin bellek hiyerarşinize, ara bağlantılarınıza, niceleme biçiminize, gecikme ve iş hacmi hedeflerinize, model mimarinize ve operasyonel olgunluğunuza uyan motordur.

Tek sayfalık karar kılavuzu

• Dizüstü bilgisayar / uç / tuhaf donanım → llama.cpp
• Mac öncelikli iş akışları → MLX / MLX-LM
• Tek RTX yerel çıkarım → ExLlamaV2
• 2-4+ NVIDIA / CUDA GPU → ExLlamaV3
• Genel üretim sunumu → vLLM
• Uzun bağlam / MoE / yönlendirme → SGLang
• NVIDIA maksimum performans → TensorRT-LLM
• Küme orkestrasyonu → NVIDIA Dynamo

Bu kılavuzun geri kalanı nedenini açıklıyor.

Bir çıkarım motoru aslında ne yapar?

Bir çıkarım motoru ağırlıkları yükler, girdiyi tokenleştirir, ileri geçişi çalıştırır, tokenları örnekler, KV önbelleğini korur ve sonuçları akış halinde gönderir. Ciddi motorlar ayrıca toplu işleme, zamanlama, önek önbelleğe alma, niceleme, paralel yürütme, API sunumu, metrikler ve dağıtık yürütmeyi de halleder.

İş yükünün iki aşaması vardır:

Ön doldurma, istemi okur ve ilk KV önbelleğini oluşturur. Hesaplama yoğunlukludur.

Kod çözme, her seferinde bir token üretir, ağırlıkları ve KV önbelleğini tekrar tekrar okur. Bellek bant genişliğiyle sınırlıdır. Kod çözme hızı, en yüksek hesaplamadan çok bellek bant genişliğini takip eder.

Bu ayrım neredeyse her şeyi açıklar:

• Kısa istem, uzun cevap: kod çözme baskındır → bellek bant genişliği ve toplu işleme önemlidir.
• Uzun istem, kısa cevap: ön doldurma baskındır → dikkat çekirdekleri ve parçalı ön doldurma önemlidir.
• Çok sayıda kullanıcı: zamanlayıcı kalitesi önemlidir → sürekli toplu işleme, önbellek sayfalama, adalet.
• Uzun bağlam: KV önbelleği baskındır → sayfalı dikkat, KV niceleme, bellekten taşma.
• MoE: uzman yönlendirme baskındır → uzman paralelliği, ara bağlantı, gruplandırılmış GEMM'ler.
• Çok düğümlü: ara bağlantı baskındır → NVLink, RDMA, hat paralelliği, ayrıştırma.

PageAttention, KV önbellek parçalanmasını ele aldı. FlashAttention, YBM (Yüksek Bant Genişlikli Bellek) trafiğini azaltmak için G/Ç farkındalıklı döşeme kullandı. Spekülatif kod çözme, ucuz tokenlar taslağı çıkarır ve bunları paralel olarak doğrular. Tekrar eden tema: çıkarım performansı, bellek hareketi artı zamanlamadır.

Gerçek darboğazlar

1. Bellek bant genişliği, sadece VRAM boyutu değil. VRAM sığmayı belirler. Bant genişliği kod çözme hızını belirler. Apple M3 Ultra, 819 GB/s'ye kadar birleşik bellek bant genişliği sunar. NVIDIA H100 SXM, 3,35 TB/s GPU bellek bant genişliği listeler. Birleşik bellek, tüketici VRAM'ine sığmayacak modelleri sığdırmanızı sağlar. YBM, model sığdığında onlara daha hızlı hizmet vermenizi sağlar. Sığma hız değildir. Kapasite bant genişliği değildir.

1. KV önbellek büyümesi. KV önbelleği, toplu iş boyutu ve bağlam uzunluğuyla birlikte büyür. Uzun bağlamlı iş yükleri, ağırlıklar sığsa bile belleği tüketebilir. PageAttention, KV önbelleğini bloklara bölerek kullanımı artırır ve daha büyük toplu işleri destekler.

1. Ara bağlantı. Bir model GPU sınırlarını (çoklu GPU'lar) geçtiği anda iletişim maliyeti ödersiniz. Tensör paralelliği sık sık tümünü indirge topluluklarına ihtiyaç duyar. Hat paralelliği, aşama sınırlarında iletişim kurar. Uzman paralelliği, MoE için herkese-herkese trafiğine ihtiyaç duyar. vLLM'nin belgeleri, NVLink olmadan hat paralelliğinin tensör paralelliğinden daha iyi performans gösterebileceğini not eder.

1. Zamanlayıcı kalitesi. İyi bir zamanlayıcı, hangi isteklerin toplu işe gireceğine, ön doldurma ve kod çözmenin hızlandırıcıyı nasıl paylaşacağına, uzun istemlerin kısa kod çözmeleri engelleyip engellemeyeceğine ve açlığın nasıl önleneceğine karar verir. Toplu işlemeyi desteklemek, üretime hazır bir zamanlayıcı gibi davranmakla aynı şey değildir.

1. Çalışma zamanı yükü. CUDA grafikleri, çekirdek birleştirme, örnekleme yükü, tokenleştirici yükü, HTTP yükü, LoRA geçişi ve yapılandırılmış kod çözmenin hepsi önemlidir. Yüksek ölçekte, can sıkıcı %2'lik yükler bir birleşim oluşturur ve ilgi gerektirir (kelime oyunu amaçlanmamıştır).

Motor aileleri

<payload-block id="blk_3" type="upload"">

Dört geniş aile vardır:

Taşınabilir yerel çalışma zamanları: llama.cpp, MLC LLM, ONNX Runtime GenAI, OpenVINO, Ollama tarzı araçlar. Bunlar "burada çalıştır" ile ilgilenir.

Apple/birleşik bellek çalışma zamanları: MLX ve MLX-LM. Bunlar "büyük paylaşımlı belleği ve Apple'ın yığınını iyi kullan" ile ilgilenir.

Tüketici CUDA niceleme motorları: ExLlamaV2 ve ExLlamaV3. Bunlar "3090/4090/5090 kutumu düşük bitli ağırlıklarla çığlık attır" ile ilgilenir.

Üretim sunum motorları: vLLM, SGLang, TensorRT-LLM, TGI, LMDeploy. Bunlar eşzamanlı kullanıcılar, KV önbelleği, toplu işleme, paralellik, gözlemlenebilirlik ve token başına maliyet ile ilgilenir.

Ayrıca, motorların üstünde yer alan ve filoları, ayrıştırılmış ön doldurma/kod çözmeyi, yönlendirmeyi ve otomatik ölçeklendirmeyi koordine eden Dynamo gibi orkestrasyon katmanları da vardır.

llama.cpp: taşınabilirlik kralı

llama.cpp, donanım tuhaf, kısıtlı, çevrimdışı, CPU ağırlıklı, uç odaklı veya düzenli bir NVIDIA veri merkezi düğümü olmadığında başvurulacak cevaptır.

Apple Silicon'u ARM NEON, Accelerate ve Metal aracılığıyla; x86'yı AVX/AVX2/AVX512/AMX aracılığıyla; RISC-V'yi; düşük bitli nicelemeyi; CUDA'yı; AMD'yi HIP aracılığıyla; MUSA'yı; Vulkan'ı; SYCL'i ve CPU+GPU hibrit bellekten taşmayı destekler. Bu yüzden llama.cpp "sadece çalıştır" şeridine sahiptir.

HTTP sunucusu, "oyuncak bir yerel çalıştırıcıdan" daha yeteneklidir. llama-server; OpenAI uyumlu yollar, Anthropic Messages API uyumluluğu, yeniden sıralama, sürekli toplu işleme, çok modlu destek, JSON şeması kısıtlamaları, fonksiyon çağırma, spekülatif kod çözme ve bir web arayüzü sağlar.

Kritik sınırlama: llama.cpp ciddi çok düğümlü üretim sunumu için uygun değildir. RPC arka ucu, açıkça kavram kanıtı, kırılgan ve güvensiz olarak belgelenmiştir.

Karar: Taşınabilirlik, çevrimdışı çalışma, GGUF veya hibrit bellekten taşıma, filo ölçeğinde sunumdan daha önemli olduğunda llama.cpp kullanın.

Çoklu GPU'lar ile KULLANMAYIN

MLX ve MLX-LM: Apple Silicon silahı

MLX, Apple Silicon için Apple'ın dizi çerçevesidir ve MLX-LM de onun üzerine inşa edilmiş LLM paketidir. Bu bir Mac öncelikli ML yığınıdır.

Anahtar donanım gerçeği birleşik bellektir. Apple Silicon, CPU ve GPU'ya aynı bellek havuzuna doğrudan erişim sağlar. MLX dizileri birleşik bellekte yaşar ve işlemi çalıştırırken cihazı siz seçersiniz, dizileri ayrı bellek alanları arasında taşımak yerine.

Bu, yerel çıkarım dengesini değiştirir. Ayrık bir GPU sisteminde soru "VRAM'e sığıyor mu?"dur. Büyük birleşik belleğe sahip bir M serisi Mac'te soru "belleğe sığıyor mu ve bellek sistemi GPU'yu yeterince hızlı besleyebilir mi?" olur. Büyük nicelemeli modeller, aynı modelin 24 GB tüketici GPU'sunda imkansız olacağı makinelere sığabilir.

Ancak, aynı zamanda daha yavaştır.

MLX-LM, Hugging Face Hub entegrasyonu, niceleme, LoRA ve tam ince ayar, dağıtık çıkarım ve geniş bir MLX Topluluğu model ekosistemi ekler. MLX artık yalnızca Mac'e özel değil: Linux için CUDA ve yalnızca CPU paketleri sunar. Dağıtık iletişim, MPI, TCP üzerinden Ring, Thunderbolt üzerinden RDMA için JACCL ve CUDA için NCCL'yi destekler.

MLX-LM'nin sunucusu, yalnızca temel güvenlik kontrolleri uyguladığı için üretim için önerilmediği konusunda uyarır.

Karar: Mac öncelikli ML ve LLM iş akışları için MLX kullanın. Yüksek eşzamanlılıklı genel sunum için gerçek bir sunum yığını ile başlayın.

ExLlamaV2 ve V3: tüketici CUDA, ayarlanmış ve hızlı

ExLlamaV2, tüketici NVIDIA GPU'sunun kendi ağırlığının üzerinde yumruk atmasını isteyenler için yerel CUDA niceleme motorudur. Sayfalı dikkat, dinamik toplu işleme, istem önbelleğe alma, KV önbellek yineleme silme, toplu üretim, akış ve spekülatif kod çözmeyi destekler. Hatırlanması gereken kelime yereldir. Nicelemeli modelleri modern CUDA GPU'larında, özellikle tüketici kartlarında hızlı hale getirir.

En uygun: tek RTX 3090/4090/5090 kutusu, yerel kodlama asistanı, yerel sohbet, EXL2 nicelemeli modeller ve profesyonel tüketici iş istasyonu kullanımı.

ExLlamaV3 felsefeyi çoklu GPU ve MoE-yerel çıkarıma doğru genişletir. QTIP tabanlı EXL3 niceleme biçimini, tüketici donanımı için esnek tensör-paralel ve uzman-paralel çıkarımı, TabbyAPI aracılığıyla OpenAI uyumlu bir sunucu, sürekli dinamik toplu işleme ve çok modlu desteği ekler.

V3, 2-4+ tüketici NVIDIA GPU'suna sahip olduğunuzda veya yerel MoE istediğinizde ilgi çekicidir. Bazı modellerin ExLlamaV3'te tensör veya uzman paralelliğini desteklemediğini unutmayın.

Karar: ExLlamaV2, meraklının yerel CUDA motorudur. ExLlamaV3, çoklu GPU (2-4) yerel kurulumlar için sınırdır. Daha iyi yetenek için daha pürüzlü kenarlar bekleyin.

vLLM: varsayılan açık kaynak üretim sunucusu

vLLM, çoğu ekibin ciddi açık kaynak LLM sunumu için değerlendirmesi gereken ilk motordur.

PageAttention tabanlı KV bellek yönetimi, sürekli toplu işleme, parçalı ön doldurma, önek önbelleğe alma, CUDA/HIP grafikleri, kapsamlı niceleme (FP8, MXFP8/MXFP4, NVFP4, INT8, INT4, GPTQ, AWQ, GGUF), optimize edilmiş dikkat ve GEMM/MoE çekirdekleri, spekülatif kod çözme, torch.compile ve ayrıştırılmış ön doldurma/kod çözme/kodlama sunar.

Ayrıca esnektir: tensör/hat/veri/uzman/bağlam paralelliği, akış, yapılandırılmış çıktılar, araç çağırma, OpenAI uyumlu ve Anthropic Messages API'leri, gRPC, çoklu LoRA ve NVIDIA, AMD, x86/ARM/PowerPC CPU'ları ile TPU'lar, Gaudi, Ascend, Apple Silicon ve daha fazlası için eklentileri destekler.

vLLM'nin belgeleri, çok düğümlü dağıtımların genellikle Ray kullandığını ve NVLink olmadan hat paralelliğinin tensör paralelliğini yenebileceğini not eder. Tuzak, vLLM'nin sistem düşüncesi ihtiyacını ortadan kaldırdığını varsaymaktır. Yine de toplu işlemeyi, bağlam uzunluğunu, GPU bellek kullanımını, paralellik düzenini ve yönlendirmeyi ayarlamanız gerekir. vLLM size çok iyi bir motor verir; yine de iyi bir Sistem Tasarımı gerektirir.

Karar: Birisi "açık modelleri üretimde sunmamız gerekiyor" derse, vLLM varsayılan başlangıç noktasıdır.

SGLang: vLLM'nin sistem beyinli kuzeni

SGLang, sunum iş yükü çirkin olduğunda başvurduğunuz şeydir: yapılandırılmış çıktılar, uzun bağlam, MoE, ayrıştırma ve yönlendirme.

RadixAttention önek önbelleğe alma, ön doldurma-kod çözme ayrıştırması, spekülatif kod çözme, sürekli toplu işleme, sayfalı dikkat, tensör/hat/uzman/veri paralelliği, yapılandırılmış çıktılar, parçalı ön doldurma ve çoklu LoRA toplu işlemesi sunar. NVIDIA, AMD, Intel Xeon, Google TPU'ları, Ascend NPU'ları ve daha fazlasını destekler.

SGLang'ın farklılaştırıcı özelliği sunum mimarisidir. Ön doldurma-kod çözme ayrıştırması, hesaplama yoğun ön doldurmayı bellek yoğun kod çözmeden ayırarak özel örneklere aktarır ve aralarında KV önbelleğini aktarır. Bu, uzun ön doldurma toplu işlerinin kod çözmeyi kesmesini ve token gecikmesini artırmasını önler.

Karar: SGLang, darboğazı artık "modeli çalıştırabilir miyiz?" değil, "onu düşmanca trafik altında, gecikmeyi, belleği ve maliyeti yakmadan çalıştırabilir miyiz?" olan ekipler içindir.

TensorRT-LLM: maksimum NVIDIA performansı

TensorRT-LLM, NVIDIA-maksimum-performans yığınıdır. Optimize edilmiş, uzmanlaşmış, güçlüdür ve taşınabilir olduğunu iddia etmez.

Son teknoloji optimizasyonlarla TensorRT motorları oluşturmak için Python API'leri ve ayrıca Python ve C++ çalışma zamanları sağlar. Dikkat, GEMM'ler ve MoE için özel çekirdekler içerir; ön doldurma-kod çözme ayrıştırması, Geniş Uzman Paralelliği, spekülatif kod çözme; ve NVIDIA Dynamo ve Triton Inference Server ile entegre üst düzey bir Python API'si içerir.

B200 GPU'lar, optimize edilmiş çekirdeklerle FP4 ağırlıklarını yükleyebilir. H100 ve sonrası, 16-bit'e kıyasla minimum doğruluk kaybıyla performansı ikiye katlayabilen ve bellek tüketimini yarıya indirebilen FP8 nicelemesini destekler.

Parladığı yer: H100/H200/B200/GB200/GB300 sınıfı filolar, yalnızca NVIDIA veri merkezleri, FP8/FP4 dağıtımı, çok düğümlü sunum ve ölçekte MoE. Zor olduğu yer: AMD, Apple veya Intel taşınabilirliği; hızla değişen deneysel modeller; küçük yerel kurulumlar; ve "her şeyde çalışır"a ihtiyaç duyan ekipler.

Karar: NVIDIA'ya bağlıysanız ve mutlak performansı önemsiyorsanız, TensorRT-LLM karşılaştırmaya dahil edilmelidir. Taşınabilirliği performansla takas edersiniz. Ayarlanmış uzmanlaşma ancak daha az özellik.

Alanın geri kalanı

TGI, Hugging Face'in izleme, metrikler, tensör paralelliği ve sürekli toplu işleme sahip üretim sunucusudur. HF entegrasyonu ve basitlik önemli olduğunda kullanın.

MLC LLM, REST, Python, JavaScript, iOS ve Android'de OpenAI uyumlu API'ler sunan, derleyici öncelikli evrensel dağıtım motorudur. En iyisi "LLM'leri her yere göndermek", özellikle tarayıcı, mobil ve yerel uygulamalar için.

ONNX Runtime GenAI, ONNX Runtime üzerinde tam üretken döngüyü uygular ve Foundry Local, Windows ML ve VS Code AI Toolkit'i güçlendirir. CPU, CUDA, DirectML, TensorRT-RTX, OpenVINO, QNN, WebGPU ve AMD GPU'yu destekler. En iyisi uygulama dağıtımı ve ONNX iş akışları için.

OpenVINO GenAI, Xeon CPU'lar, Arc GPU'lar, Core Ultra ve NPU'lar için Intel tarafından optimize edilmiş hikayedir. Sürekli toplu işleme ve sayfalı dikkat ile OpenAI uyumlu sunum sunar. En iyisi Intel donanımı için.

LMDeploy, performans için TurboMind ve erişilebilirlik için PyTorch ile CUDA odaklı bir araç setidir. vLLM/SGLang/TensorRT-LLM'ye alternatif arayan CUDA kullanıcıları için en ilginç olanıdır.

NVIDIA Dynamo, vLLM, SGLang ve TensorRT-LLM gibi motorların üzerinde, ayrıştırmayı, akıllı yönlendirmeyi ve çok katmanlı KV önbelleğe almayı destekleyen dağıtık bir orkestrasyon katmanıdır. Tek motorlu sunum artık yeterli olmadığında kullanın.

Not: Ollama KULLANMAYIN.

Donanım stratejisi tarifleri

Yalnızca CPU sunucu: Önce llama.cpp. Intel Xeon için OpenVINO. Uygulama/ONNX dağıtımı için ONNX Runtime GenAI.

MacBook / Mac Studio: Mac yerel iş akışları için MLX / MLX-LM. GGUF taşınabilirliği için llama.cpp.

Tek RTX 3090 / 4090 / 5090: EXL2 yerel çıkarım için ExLlamaV2. GGUF veya taşınabilirlik için llama.cpp. Birden çok kullanıcıya hizmet veriyorsa vLLM.

Çift veya dörtlü tüketici RTX kutusu: Çoklu GPU nicelemeli çıkarım veya MoE için ExLlamaV3. Sunum davranışı önemliyse vLLM. Yönlendirme veya uzun bağlam desenlerini test ediyorsa SGLang.

8×H100 / H200 düğümü: vLLM veya SGLang ile başlayın. Yalnızca NVIDIA ise ve performans ayarlamayı haklı çıkarıyorsa TensorRT-LLM ile kıyaslama yapın. Çok düğümlü orkestrasyon gerekli hale geldiğinde Dynamo kullanın.

B200 / GB200 / GB300 sınıfı altyapı: TensorRT-LLM, SGLang ve vLLM ile kıyaslama yapın. Filo düzeyinde orkestrasyon, KV farkındalıklı yönlendirme ve otomatik ölçeklendirme için Dynamo ekleyin.

AMD MI300 / MI325 / MI350 / MI355: ROCm üzerinde vLLM veya SGLang ile başlayın. NVIDIA kıyaslamalarının temiz bir şekilde aktarıldığını varsaymayın.

Intel Xeon / Core Ultra / Arc: OpenVINO GenAI veya OpenVINO Model Server. Uygulama yerleştirme önemliyse ONNX Runtime GenAI.

Tarayıcı, mobil, uygulama yerel: MLC LLM / WebLLM veya ONNX Runtime GenAI.

Kıyaslama: ne ölçülmeli

Kötü kıyaslama: "180 tok/s aldım."

İyi kıyaslama şunları içerir:

Model: tam model, mimari, parametre sayısı, aktif MoE parametreleri.

Ağırlıklar: veri türü, niceleme biçimi, grup boyutu, kalibrasyon.

Motor: sürüm, commit, arka uç, işaretler.

Donanım: GPU SKU'su, bellek kapasitesi, bant genişliği, ara bağlantı, CPU, RAM.

İş yükü: girdi/çıktı uzunluğu dağılımları, eşzamanlılık, akış, paylaşılan önekler, yapılandırılmış çıktı.

Metrikler: TTFT, TPOT, uçtan uca gecikme, p50/p95/p99, saniyedeki token sayısı, saniyedeki istek sayısı, GPU bellek kullanımı, KV önbellek isabet oranı, ön doldurma verimi, kod çözme verimi, 1M token başına maliyet.

Kıyaslama Kuralları:

1. Motorları asla yalnızca tek kullanıcılı saniyedeki token sayısını kullanarak karşılaştırmayın.
2. Gerçek isteminizi ve çıktı dağılımınızı test edin.
3. Gerçekçi eşzamanlılıkla test yapın.
4. Ön doldurmayı kod çözmeden ayırın.
5. Yalnızca ortalamaları değil, p95 ve p99'u da takip edin.
6. Hedef bağlam uzunluğunda bellek payını ölçün.
7. Uygulamanızda tekrarlanan önekler varsa önbellek yeniden kullanımını test edin.
8. Yapılandırılmış çıktıyı ayrı olarak kıyaslayın; dil bilgisi ek yük getirir.
9. LoRA ve çoklu LoRA'yı ayrı olarak kıyaslayın.
10. Sürücü, CUDA, ROCm, model veya motor yükseltmelerinden sonra yeniden test edin.

Yaygın hatalar

Yalnızca VRAM kapasitesine göre seçim yapmak. VRAM sığmayı belirler. Bant genişliği ve zamanlayıcı hızı belirler. Büyük bir birleşik bellek makinesi büyük modelleri sığdırabilir, ancak bir H100, model sığdığında çok daha yüksek YBM bant genişliği nedeniyle daha hızlı kod çözer.

Zayıf ara bağlantıda tensör paralelliği kullanmak. NVLink veya NVSwitch olmadan, hat paralelliğini test edin. vLLM'nin belgeleri bunu L40S benzeri kurulumlar için belirtir.

KV önbelleğini göz ardı etmek. Uzun bağlam ve eşzamanlılık, KV önbelleğini sınırlayıcı faktör haline getirebilir. PageAttention, önek önbelleğe alma, KV niceleme ve ayrıştırma, ölçekte isteğe bağlı değildir.

Yerel motorlara üretim sunucuları muamelesi yapmak. llama.cpp sunucusu yeteneklidir. MLX-LM sunucusu kullanışlıdır. Ollama hoştur ancak KULLANILMAMALIDIR.

Ancak üretim, güvenlik, gözlemlenebilirlik, geri basınç, yönlendirme, otomatik ölçeklendirme ve SLA davranışı anlamına gelir. MLX-LM'nin kendisi, sunucunun üretim için önerilmediği konusunda uyarır.

Her niceleme biçiminin taşınabilir olduğunu varsaymak. GGUF, EXL2, EXL3, AWQ, GPTQ, FP8, FP4, MLX biçimleri ve ONNX birbirinin yerine kullanılamaz. Doğru biçim, motorunuzun optimize edilmiş çekirdeklere sahip olduğu biçimdir.

Model mimarisini göz ardı etmek. Yoğun modeller, MoE, hibrit dikkat, çok modlu modeller ve uzun bağlam çeşitleri, motorun farklı bölümlerini zorlar. Geniş destek, her optimizasyonun eşit şekilde çalıştığı anlamına gelmez.

İş yükü şekli olmadan kıyaslama çizelgelerine güvenmek. Llama 3.1 8B için 1K girdi / 128 çıktıdaki bir çizelge, 80K bağlamda Qwen 3.6 27B / Gemma 4 26B-A4B çalıştıran bir kodlama ajanı veya 500 eşzamanlı kullanıcılı bir RAG hizmeti hakkında çok az şey söyler.

Fikir belirten son harita

Yerel AI kullanıcısı: Kolaylık için LM Studio veya Harbor. Kontrol için llama.cpp. Mac'te MLX. CUDA yerel performansı için ExLlamaV2/V3.

Yerel bir ajan oluşturma: Herhangi biri işe yarar, ancak çoğu insanın kullandığı düşünülürse; taşınabilirlik için llama.cpp. Kullanıcılar Apple Silicon'daysa MLX. Yerel olarak üretim sunumunu simüle ediyorsa vLLM.

Bir iç ekibe hizmet verme: vLLM ile başlayın. Yapılandırılmış çıktılar, uzun bağlam, çoklu LoRA, MoE veya yönlendirme önemliyse SGLang kullanın.

Müşterilere ölçekte hizmet verme: vLLM, SGLang ve TensorRT-LLM ile kıyaslama yapın. Yönlendirme ve ayrıştırma önemliyse, SGLang ve Dynamo dikkate değerdir.

NVIDIA veri merkezi: Maksimum performans için TensorRT-LLM. Esneklik için vLLM. Karmaşık sunum için SGLang. Filo orkestrasyonu için Dynamo.

Apple Silicon: Yerel geliştirme için MLX. GGUF için llama.cpp. Birleşik bellek, bant genişliği ödünleşimleri olan bir kapasite süper gücüdür, YBM değildir.

Uç, uygulama, tarayıcı veya Windows yerel: Yığına bağlı olarak llama.cpp, MLC LLM, ONNX Runtime GenAI veya OpenVINO.

Nihai ilke

Çıkarım Motorlarının sonuçları vardır.

Motoru şu soruları cevapladıktan sonra seçin:

1. Gerçekte hangi donanıma sahibim?
2. Model hızlı belleğe mi yoksa yalnızca sistem/birleşik belleğe mi sığıyor?
3. Kod çözme mi yoksa ön doldurma mı darboğaz?
4. Hangi bağlam uzunluğu ve eşzamanlılık önemli?
5. İstemler önek önbelleğe alma için yeterince paylaşılıyor mu?
6. Model yoğun, MoE, çok modlu veya hibrit mi?
7. Yerel kolaylığa, üretim sunumuna mı yoksa filo orkestrasyonuna mı ihtiyacım var?
8. Hedef motorumda hangi niceleme biçiminin optimize edilmiş çekirdekleri var?
9. Ara bağlantım PCIe, NVLink, NVSwitch, Ethernet, RDMA veya Thunderbolt mu?
10. Gecikmeyi, verimi, maliyeti, gizliliği, taşınabilirliği veya geliştirici hızını mı optimize ediyorum?

Motor, cevapları takip eder.

Bir sonrakine kadar.

-Ahmad