> ## Content Index
> Fetch the complete content index at: https://globalfeed.ai/llms.txt
> Use this file to discover other available public pages before exploring further.

# Perplexity, pplx-embed'i çalıştıran GPU yığınını anlattı: Ivy, Tulip ve ROSE
- URL: https://globalfeed.ai/perplexity-pplx-embedi-calistiran-gpu-yiginini-anlatti-ivy-tulip-ve-rose/
- Published: 2026-09-06T13:43:55.000Z
- Updated: 2026-09-06T13:43:55.000Z
- Description: Perplexity mühendislik ekibi, arama motorunun arkasındaki gömme ve sıralama modellerini nasıl servis ettiğini yazdı. Yığın üç bileşenden oluşuyor: Ivy, Tulip ve ROSE. Ana bulgu, küçük gömme modellerinde gecikmenin dizi sayısına değil jeton sayısına bağlı olması.
- Author: GlobalFeed Editor
- Tags: Perplexity, gömme modelleri, GPU, arama altyapısı, vLLM, x-perplexity_ai, dil-tr, video

Perplexity mühendislik ekibi, arama motorunun arkasındaki gömme ve sıralama modellerini nasıl servis ettiğini ["Fast Embeddings on GPUs" başlıklı yazıda](https://www.perplexity.ai/hub/blog/fast-embeddings-on-gpus?ref=globalfeed.ai) anlattı. 4 Eylül'de yayımlanan yazı üç bileşenli bir yığını tarif ediyor: Ivy, Tulip ve ROSE. Ana bulgu, küçük gömme modellerinde gecikmenin dizi sayısına değil jeton sayısına bağlı olması; bir milyar parametrenin altındaki bir modelde yaklaşık 512 jeton GPU'yu doyuruyor.

## Yığın

- **Ivy**: Rust ile yazılmış HTTP geçidi. JSON ayrıştırma, jetonlama, girdi şablonlama ve toplu istekleri parçalara bölme onun işi; istekleri özel bir gRPC protokolüne çevirip kopyalar arasında dengeliyor. Şirkete göre kendi unigram jetonlayıcısı, hazır jetonlayıcılara göre gecikmeyi ciddi biçimde düşürdü.
- **Tulip**: Rust, tokio ve tonic ile yazılmış gRPC sunucusu; istekleri ilk gelen ilk işlenir sırasıyla zamanlıyor, toplu hale getirip ROSE'a veriyor.
- **ROSE** (Runtime-Optimized Serving Engine): ağırlıkla Python ile yazılan çıkarım motoru. Gömme servisinde KV önbelleği kurulmuyor, dolgu istemeyen ragged dikkat çekirdekleri kullanılıyor; şirketin ifadesiyle pplx-embed servisi ile Qwen3.5 çözümlemesi aynı çekirdeklerden geçiyor.

## Kazanç nereden geliyor

Küçük toplu işlerde CPU tarafındaki çekirdek başlatma maliyeti GPU işinden ağır basabiliyor; ekip ileri geçişin tamamını tek bir CUDA graph olarak yakalayıp tek çağrıyla başlatıyor. Yapılandırma ızgarası geniş olduğundan binlerce graph çıkıyor ve yakalama dakikalar sürebiliyor, bu yüzden graph'lar servis sırasında tembel yakalanıyor: ilk isabette ısınma, ikincide yakalama, sonrasında tekrar oynatma. LazyTensor adlı soyutlama ise sonucu beklemek yerine sayfa kilitli bir tampona yapılan asenkron kopyayı izliyor; sonraki toplu iş, öncekinin bitmesini beklemeden kuyruğa giriyor.

## Ölçüm

Karşılaştırma vLLM v0.22.0'a karşı, BF16 ve gerçek model ağırlıklarıyla dört senaryoda yapılmış. Perplexity daha düşük gecikme ve daha yüksek verim bildiriyor, ancak sayılar yalnızca grafiklerde; yazının metninde rakam yok. Bağımsız test yok, ölçüm şirketin kendi düzeninden.

## Kurumsal okur için

Kendi arama ya da RAG altyapısını kuran kurum için ders, kazancın modelden çok kabuktan gelmesi: jetonlama, toplu işleme, CPU ile GPU işinin örtüşmesi. Küçük bir gömme modelinde toplu işi büyütmek verim getirmiyor; eşik yaklaşık 512 jeton. Ölçüm düzeni yazıda açık, kurum aynı senaryoları kendi yükünde tekrarlayabilir. Yazıda yığının açık kaynak olduğuna dair bir bildirim yok.

## Kaynaklar

- Perplexity Engineering, "Fast Embeddings on GPUs", 4 Eylül: [perplexity.ai/hub/blog/fast-embeddings-on-gpus](https://www.perplexity.ai/hub/blog/fast-embeddings-on-gpus?ref=globalfeed.ai)
- MarkTechPost aktarımı, 5 Eylül.