yoklateknik mülakat
GelişimGeçmiş

AI Engineer Inference Serving Mülakat Soruları

75 doğrulanmış AI Engineer Inference Serving mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

Inference ServingZorluk 1
LLM inference'ta 'time to first token' (TTFT), toplam yanıt gecikmesinden farklı olarak neyi ölçer?
  • aYanıttaki tüm output token'ların üretilmesi için geçen toplam süreyi.
  • bRequest alındıktan sonra ilk output token'ın client'a döndüğü ana kadar geçen süreyi.✓
  • cSunucunun, request payload'ını modele ulaşmadan önce doğrulamak için harcadığı süreyi.
  • dYanıt boyunca ardışık iki output token arasındaki ortalama gecikmeyi.
Açıklama:TTFT, prompt işleme süresinin baskın olduğu, ilk token gelene kadar geçen gecikmedir; toplam latency ise kalan tüm token'ların üretimini de içerir. a şıkkı TTFT değil toplam latency'yi anlatır; d, ayrı bir metrik olan inter-token latency'yi anlatır; c ise ilgisiz bir ön-işleme adımıdır.
Inference ServingZorluk 2
Bir ekip, tek cümlelik cevap isteyen request'lerin bir saniyeden kısa sürede döndüğünü, ama aynı modelden 2000 kelimelik bir rapor yazmasını isteyen request'lerin çok daha uzun sürdüğünü fark ediyor; input prompt uzunluğu iki durumda da benzer. Bunu en iyi ne açıklar?
  • aModel, her output adımında tüm input prompt'u yeniden tokenize eder.
  • bUzun yanıtlar, kısa yanıtların atladığı ekstra rate-limit kontrollerini tetikler.
  • cSunucu uzun yanıtları sıkıştırır ve client tarafındaki açma işlemi gecikme yaratır.
  • dÜretim gecikmesi büyük ölçüde, birer birer üretilen output token sayısıyla orantılıdır.✓
Açıklama:Token üretimi autoregressive'dir: her decode adımında bir token üretilir. Output token sayısı arttıkça sıralı adım sayısı da orantılı artar, bu yüzden input uzunluğu benzer olsa bile latency output uzunluğuyla büyür. a yanlıştır çünkü input prompt bir kez işlenir, her output token için yeniden tokenize edilmez; b ve c gerçek serving mekanizmasını yansıtmayan uydurma açıklamalardır.
Inference ServingZorluk 1
Birçok LLM uygulaması, tam yanıtı bekleyip tek seferde göndermek yerine token'ları üretildikçe kullanıcıya neden stream eder?
  • aÇıktı ilk token'lar hazır olur olmaz göründüğü için algılanan bekleme süresini azaltır.✓
  • bModelin aynı cevap için üretmesi gereken toplam token sayısını azaltır.
  • cStream edilmeyen bir yanıta göre request başına daha düşük toplam maliyeti garanti eder.
  • dModelin önceki, ilgisiz bir request'te ürettiği token'ları tekrar üretmesini atlamasını sağlar.
Açıklama:Streaming, toplam üretim süresi ve toplam token sayısı değişmese bile kullanıcının ilk token'ları (TTFT) hızlıca görmesi sayesinde algılanan gecikmeyi azaltır. b, c ve d, streaming'in token sayısını, maliyeti ya da request'ler arası yeniden kullanımı nasıl etkilediği konusunda yanlış iddialar içerir.
Inference ServingZorluk 2
Bir client, aşağıdaki pseudocode ile streaming bir completion response'unu tüketiyor:
full_text = ""
for chunk in stream_response():
    full_text += chunk.token
    render_to_user(chunk.token)
return full_text

Bu döngü, iyi bir kullanıcı deneyimi için neye dayanır?
  • aHerhangi bir render işleminden önce her chunk'ı önce full_text içinde toplamak zorundadır.
  • bstream_response(), tüm yanıt üretilene kadar bloklanır, her chunk cevabın tamamını içerir.
  • cGelen her chunk, geldiği anda kullanıcıya render edilir.✓
  • drender_to_user, her iterasyonda full_text'i sıfırdan yeniden hesaplar.
Açıklama:Döngü, her chunk'ı aldığı iterasyonda render_to_user(chunk.token) çağırır, yani çıktı aşamalı olarak görünür. a ve b streaming'in amacına ters düşer (düşük gecikme faydasını ortadan kaldırır); d ise kodda olmayan gereksiz bir yeniden hesaplamayı anlatır.
Inference ServingZorluk 2
Self-hosted bir inference server'ı şu config'i açığa çıkarıyor:
max_batch_size: 16
batch_timeout_ms: 20

Bu config muhtemelen neyi kontrol eder?
  • aZorla kesilmeden önce tek bir request'in maksimum output uzunluğunu.
  • bSunucunun kaç request'i tek bir forward pass'te gruplayacağını ve o grubu doldurmak için ne kadar bekleyeceğini.✓
  • cSunucunun rate-limit hatası döndürmeden önce deneyeceği retry sayısını.
  • dSunucunun request başına kabul ettiği maksimum payload boyutunu (megabayt).
Açıklama:Batching, birden fazla eşzamanlı request'i tek bir forward pass'te compute paylaşacak şekilde gruplar; batch_timeout_ms ise sunucunun request'leri toplamak için ne kadar bekleyip yine de batch'i çalıştıracağını sınırlar. a, c ve d aynı alan adlarına ilgisiz anlamlar yüklüyor.
Inference ServingZorluk 2
Bir inference server, throughput'u artırmak için agresif request batching'i devreye alıyor. Bir batch işlenmeye başladıktan hemen sonra gelen tekil bir request için en olası dezavantaj nedir?
  • aKendi batch'i başlayabilmeden önce mevcut batch'in bitmesini beklemek zorunda kalabilir.✓
  • bHiçbir batch'e eklenmeden sessizce düşürülür.
  • cBatching o request için token olasılıklarını değiştirdiği için output kalitesi düşer.
  • dKuyruğu atlayıp zaten çalışan batch'in önüne geçerek işlenir.
Açıklama:Batching, daha yüksek toplam throughput karşılığında bazı request'ler için ekstra latency'ye (sıradaki batch'e katılmayı/başlamayı bekleme) neden olur; tipik implementasyonlarda request'leri düşürmez, output kalitesini anlamlı biçimde değiştirmez (request başına aynı ağırlıklar ve matematik uygulanır; batching çok küçük floating-point farkları doğurabilir ama bu bir kalite değişimi değildir) ve öncelik tanımaz.

Uzmanlığa göre

LLM/RAG 450MLOps 450Python 450

Kıdeme göre

AI Engineer JuniorAI Engineer MidAI Engineer Senior

Diğer alanlar

BackendFrontendFullstackDevOps / CloudVeritabanıMobilGüvenlikQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

2025 soruluk AI Engineer bankasında kendini sına.

Mülakata başla