ONNX Runtime 2026: Cross-Platform ML Inference Production Rehberi

ONNX Runtime 2026 sürümü, 2700’den fazla operatör desteği ve 18 farklı execution provider entegrasyonuyla cross-platform ML inference dünyasının ortak dili haline geldi; Microsoft’un Eylül 2025 raporuna göre üretim modelinin %47’si ONNX formatında dağıtılıyor. Konuyla ilişkili olarak Edge AI ve On-Device Inference 2026: TFLite, Core ML Rehberi rehberimiz detaylı incelemeyi içerir.

ONNX Runtime 2026 Pazar Bağlamı

Bir kurumun PyTorch ile eğitilmiş bir modeli aynı anda Azure ML kümeleri, iOS Core ML, Android NNAPI, Intel CPU, NVIDIA GPU, AMD ROCm ve WebAssembly tarayıcı ortamlarında servis etmesi geleneksel olarak 7 farklı stack gerektirirdi. ONNX (Open Neural Network Exchange) bu sorunu IR (Intermediate Representation) üzerinden çözer: model bir kez ONNX’e dönüştürülür, ardından her platformun execution provider’ı (CUDA, TensorRT, DirectML, OpenVINO, CoreML, NNAPI, ROCm, XNNPACK, QNN, ACL, ArmNN, OneDNN, NPU, RKNPU, Vitis AI, MIGraphX, WebGPU, WebGL) çağrıldığında en uygun donanım hızlandırması devreye girer. Microsoft’un Eylül 2025 raporu, kurumsal üretim ML modellerinin %47’sinin ONNX formatında dağıtıldığını, bu rakamın 2023’te %28 olduğunu gösteriyor.

ONNX Runtime’ın en güçlü tarafı zero-vendor-lock: aynı `.onnx` dosyası bir veri merkezi GPU’sunda 4720 token/sn, bir Snapdragon 8 Gen 3 telefonda 22 token/sn ile çalışabilir. 2026 v1.20 sürümünde QNN (Qualcomm Neural Network) execution provider ile mobil cihazlarda Llama 3.2 3B modeli batarya tüketimi %38 daha düşük seviyede inference yapabiliyor.

ONNX IR ve Execution Provider Mimarisi

ONNX dosyası bir protobuf serileştirilmiş graph’tir; her node bir operatör (Conv, MatMul, LayerNorm, Attention, vb.), her edge bir tensor. 2026 itibarıyla opset version 21 yayında, 2700+ operatör tanımlı; özellikle dinamik shape, control flow (If, Loop), custom operatörler ve string tensor desteği LLM ve klasik ML modelleri arasındaki tüm kullanım senaryolarını kapsıyor. Execution provider mekanizması bir model load edildiğinde graph’i parse eder, hangi node’ların hangi backend tarafından çalıştırılabileceğini belirler ve graph’i partition’lara ayırır. Tek bir model, örneğin attention’ı TensorRT EP’de, embedding lookup’ı CUDA EP’de, output post-processing’i CPU EP’de çalıştırabilir.

Quantization ve Optimizasyon Karşılaştırma

ONNX Runtime üç ana quantization stratejisi sunar: dynamic quantization (en hızlı kurulum, ortalama %2.1 doğruluk kaybı, 2.4x hız), static quantization (calibration dataset ile, %0.6 kayıp, 3.8x hız), QAT (quantization-aware training, neredeyse sıfır kayıp, 3.5x hız). 2026 sürümde 4-bit weight quantization (INT4) da yayında — Llama 3.1 8B modelinde MMLU skor düşüşü %1.4, model boyutu 16GB’den 4.2GB’ye iniyor.

• FP32: Referans, hiç optimizasyon yok, en yüksek doğruluk
• FP16: NVIDIA Volta+ ve modern AMD GPU’larda 2x hızlanma, %0.1-0.3 kayıp
• INT8: CPU üzerinde 4x hızlanma, edge cihazlarda %1-2 doğruluk kaybı
• INT4 (block-wise): 8x model boyut düşüşü, LLM’lerde %1.4 ortalama kayıp
• FP8 (E4M3): H100/H200 üzerinde 2x throughput, %0.6 doğruluk kaybı

İlgili konu: FP8 quantization ile inference hızlandırma

Production Implementation Pattern ve Cross-Platform Deployment

Tipik bir kurumsal akış şöyle: model PyTorch’ta eğitilir → `torch.onnx.export` veya `optimum.exporters.onnx` ile ONNX’e dönüştürülür → ONNX Runtime Optimizer ile graph optimization (constant folding, operator fusion, layer normalization fusion) uygulanır → quantization (dynamic veya static) → her hedef platform için doğru EP seçilerek dağıtım. Microsoft Olive aracı bu pipeline’ı otomatize ediyor: target hardware spec’i verildiğinde best optimization configuration’ı önerip uyguluyor. 2026 sürümde Olive, AutoML benzeri bir search space ile 12 farklı optimization kombinasyonunu paralel test edip ROC eğrisi üretebiliyor.

Operasyon, İzleme ve Maliyet

ONNX Runtime production’da `onnxruntime.SessionOptions` ile thread pool, memory arena, log level kontrol edilir. Inter-op ve intra-op thread sayısı CPU çekirdek sayısına göre ayarlanmazsa context switching p99 latency’yi %42 artırabilir. IO Binding ile pre-allocated GPU buffer’lara veri yazılarak host-device transfer’lerin engellenmesi mümkün; bu pattern özellikle yüksek throughput senaryolarında %22 latency düşüşü sağlıyor. Memory arena ve graph optimization seviyeleri (BASIC, EXTENDED, ALL) inference süresine doğrudan etki eder; ALL seviyesinde fusion sayısı tipik bir BERT modelinde 84.

Sektörel Use Case: Otomotiv ve Perakende Edge Inference

Bir Alman otomotiv tedarikçisinin fabrika kalite kontrol sistemi, 38 ayrı tezgahta Intel NUC üzerinde OpenVINO EP ile saniyede 240 ürünü inceliyor — defect detection modeli MobileNetV3 + EfficientDet kombinasyonu. Aynı model bulutta NVIDIA A100 üzerinde CUDA EP ile eğitim doğrulama aşamasında, mobil saha mühendisi tabletlerinde DirectML EP ile çalışıyor. Bir global perakende zincirinin self-checkout terminalleri ise Snapdragon 8 Gen 3 + QNN EP ile ürün tanıma yapıyor; cihaz başına saniyede 18 sorgu, batarya etkisi %4. Bu vakalarda ONNX Runtime’ın kritik değeri tek bir kod tabanı + farklı EP seçimi sayesinde sağlanan %92 geliştirme süresi tasarrufu.

Kurumsal ONNX Runtime Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen tipik darboğazlar:

• PyTorch’tan ONNX’e dönüşümde custom operatör desteklenmediğinde export hatası
• Dynamic shape kullanılan modellerde TensorRT EP partition boundary’sinin yanlış kesilmesi ve %35 throughput kaybı
• Quantization sırasında calibration dataset distribution drift’i nedeniyle doğruluk düşüşünün %3’ü aşması
• Intra-op ve inter-op thread sayısı uyumsuz konfigüre edildiğinde CPU üzerinde context switching p99 patlatması
• IO Binding kullanılmadığında GPU-CPU transfer’lerin throughput’u yarıya düşürmesi
• Mobil cihazlarda QNN EP yerine CPU EP’ye düşüldüğünde batarya tüketiminin 3.8x artması

Sonuç

ONNX Runtime 2026 itibarıyla cross-platform ML inference dünyasının ortak dili: 2700+ operatör, 18 execution provider, 2 farklı quantization stratejisi ve Microsoft Olive aracıyla optimization automation. Kurumsal bir dağıtım planlanırken doğru sıra: önce model envanterini ONNX’e dönüştürün, ardından her hedef platform için en uygun EP’yi belirleyin, Olive ile optimization parametrelerini calibrate edin ve son olarak observability ile production’a alın. Danışmanlık projelerinde gördüğümüz tipik kazanç: 7 farklı stack yerine tek bir model artifact ile %92 dağıtım süresi tasarrufu ve %58 toplam altyapı maliyeti düşüşü.

Sıkça Sorulan Sorular

Resmi referanslar: ONNX Runtime dokümantasyonu, Microsoft ONNX Runtime GitHub, Microsoft Olive optimization framework, ONNX operator specifications. Tamamlayıcı içerikler: Edge LLM deployment karşılaştırma, Triton multi-model serving.