ONNX ile 14 Kat Daha Hızlı Vektör Temsilleri (Embeddings): Manticore'un Optimizasyon Hikayesi

Manticore Search ekibi, veritabanına eklenen metinlerin vektör temsillerini (embeddings) çıkaran "Auto Embeddings" özelliğini yeniden tasarladı. SentenceTransformers ve Candle (Rust) yerine ONNX Runtime (ORT) geçişiyle performans ortalama 14 kat artırıldı. Bu süreç, performans optimizasyonu ve paralel programlama üzerine önemli pratik dersler barındırıyor.

1. Özet (TL;DR)

ONNX geçişiyle yazma hızı 5-11 doküman/saniyeden 70-230 aralığına fırladı.
En yüksek verim, birden fazla istemci thread'i yerine tek bir istemci thread'inde büyük yığınlar (batch size 64-128) kullanıldığında elde edildi.
Geliştirme ekibinin elde ettiği en kritik iki kazanım; intra_op_spinning özelliğini kapatmak ve işçi (worker) thread'ler içinde dokümanları gruplamaktan vazgeçmek oldu.

2. Neden Önemli?

Auto-embeddings özelliğinde veritabanının kendisi her INSERT işleminde modeli çalıştırır. Dolayısıyla vektörleştirme hızı, veri ekleme hızının ta kendisidir. Eski mimaride thread tıkanıklıkları CPU'nun verimli kullanılmasını engelliyordu. Geliştiriciler için çıkarım: Darboğazları tespit etmek için önce sistem kaynaklarının (CPU/Bellek) ne kadar efektif kullanıldığını profiler araçlarıyla analiz etmek gerekir.

3. Neden Candle Değil de ONNX?

ONNX Runtime (ORT), Microsoft tarafından geliştirilen; grafik birleştirme (graph fusion), sabit katlama (constant folding) ve kernel optimizasyonları yapan güçlü bir motordur. HuggingFace'teki popüler modellerin doğrudan ORT uyumlu .onnx dosyaları sunması entegrasyonu kolaylaştırır. Öğrenme çıkarımı: Tekerleği yeniden icat etmek yerine, hedef platforma özel optimize edilmiş çalışma zamanı motorlarını tercih etmek performansı zahmetsizce artırır.

4. Eşzamanlılık Modeli (Concurrency)

Rust geliştiricileri paylaşılan kaynaklarda genelde Mutex kilitlerine ya da havuz (pool) mimarilerine yönelir. Ancak Linux/macOS üzerinde ORT’nin C tabanlı Run() API’sinin thread-safe olduğu keşfedildi. Paylaşılan tek bir oturumu (Session) kilitsiz olarak doğrudan eşzamanlı çağırmak, bellek ayak izini düşürdü ve kilit gecikmesini sıfırladı. Pratik ders: Kullandığınız kütüphanelerin alt katmanlarındaki eşzamanlılık (concurrency) garantilerini iyi inceleyin.

5. Adaptif Paralellik ve Yanılgılar

"Modelleri hızlandırmak için girdileri gruplayın (batching)" kuralı bu senaryoda başarısız oldu:

Dolgu (Padding) Maliyeti: Farklı uzunluktaki metinler en uzun metne göre dolgu karakterleriyle (padding) doldurulur. Bu durum modelin boş işlem yapmasına yol açar. Gerçek metinlerde tekil doküman işleme daha verimlidir.
CPU Döngüleri (Spinning): ORT thread'lerinin iş beklerken CPU'yu meşgul etmesini engellemek için with_intra_op_spinning(false) yapıldı. Bu sayede CPU diğer veritabanı işlerine (HNSW dizinleme vb.) kaynak ayırabildi.

6. Performans Rakamları

Eski yapıda 8 thread ile saniyede 10 doküman işlenirken, yeni yapıda tek thread ve 64 yığın boyutu ile saniyede 233 dokümana ulaşıldı. Yazılım Geliştirme Dersi: Paralelliği istemci seviyesinde koordine etmeye çalışmak overhead yaratır. İş yükünü doğrudan motorun kendi iç paralelleştirme yeteneğine bırakmak daha yüksek verim sağlar.

7. Sırada Ne Var?

Ekip, gelecek planlarında GPU tabanlı çalıştırma yolunu (CUDA provider), Windows işletim sisteminde kilitsiz performans eşitliğini ve T5 gibi daha karmaşık model mimarilerinin ONNX geçişini hedefliyor.

8. Nasıl Denenir?

Manticore Search 27.1.5 ve üzeri sürümlerde ONNX modelleri (örn: Xenova/all-MiniLM-L12-v2) varsayılan olarak aktiftir. Mevcut tablolarda model güncellemek doğrudan yapılamadığından, ALTER TABLE ile yeni bir vektör kolonu ekleyip embeddings alanını REBUILD etmek ve eski kolonu düşürmek (drop) en temiz geçiş yoludur.

Orijinal makaleye buradan ulaşabilirsiniz.