LLM·2 dk okuma·

DigitalOcean Inference Üzerinde Altı Modeli Yarıştırdım: En Ucuz Olanı Kazandı

Paylaş
DigitalOcean Inference Üzerinde Altı Modeli Yarıştırdım: En Ucuz Olanı Kazandı

Bir yapay zekâ modelini uç noktaya (endpoint) her yerleştirdiğimde aynı tembel kararı veriyordum: Ya en son kullandığımı ya da yeni okuduğum modeli seçip "Daha sonra kapsamlı bir benchmark yaparım" diyordum. Ancak yaklaşan teslim tarihleri nedeniyle o "sonra" hiç gelmiyordu. Gecikmeleri kıyaslamak erteleme gibi hissettirse de mimari verimlilik için kritik bir adımdır.

Bu döngüyü kırmak için beni test yapmaya zorlayacak bir araç geliştirdim: Tek bir prompt'u aynı anda altı modele gönderen, yanıtları sütunlarda yan yana akıtan (streaming), her birinin altında ilk token süresini (TTFT) ve maliyetini gösteren yaklaşık 390 satırlık Python test ortamı. Testi çalıştırdığımda ise planlamadığım üç durumla karşılaştım.

1. İki Satırlık Entegrasyon: En Az İlginç Kısım

DigitalOcean Inference uç noktası doğrudan OpenAI protokolünü destekliyor. Tüm entegrasyon temelde tek bir istemciden ibaret:

client = OpenAI(
    base_url="https://inference.do-ai.run/v1/",
    api_key=os.environ["DIGITAL_OCEAN_MODEL_ACCESS_KEY"],
)

Llama, DeepSeek, Mistral, Qwen ve OpenAI'ın açık ağırlıklı modellerinin tümü bu istemci üzerinden çağrılıyor; yalnızca model parametresi değişiyor.

  • Önemli Ayrım: Buradaki kimlik bilgisi, genel hesap API anahtarı değil; Gradient AI Platform altından oluşturulan özel model erişim anahtarıdır (model access key).

2. Event Loop Olmadan Altı Bağımsız Stream

Modellerin sırayla değil, gerçek zamanlı yarışmasını sağlamak için sunucu tarafında karmaşık bir multiplexing katmanı kurmak yerine basitliği tercih ettim:

  • Tarayıcı, her model için ayrı bir EventSource (SSE) bağlantısı açar (GET /stream?model=id&prompt=text).
  • Altı model, altı bağımsız bağlantı ve yaşam döngüsü demektir.
  • Flask tarafında asenkron karmaşaya girilmeden, yaklaşık 40 satırlık senkron bir streaming yolu inşa edildi.

3. Yanlış Hatayı Tahmin Ettim: Kuyruk Tuzağı

Gunicorn'un varsayılan senkron worker yapısının sorun çıkaracağını biliyordum. Senkron bir süreç, yanıt tamamlanana kadar tek bir bağlantıyı kilitler. Sayfanın donmasını beklerken karşıma gizli bir kuyruk çıktı:

  • mistral-3-14B: 1250 ms
  • openai-gpt-oss-120b: 5326 ms
  • openai-gpt-oss-20b: 7278 ms
  • deepseek-3.2: 8347 ms
  • llama-4-maverick: 9147 ms

Her akışın ilk token'ı, tam olarak bir önceki akış tamamlandığında geldi. Toplam 10.7 saniyelik bu gecikme modellerin yavaşlığından değil, tek bir senkron worker'ın istekleri sıraya dizmesinden kaynaklanıyordu. Çözüm ise basitti: Gunicorn'u threaded worker moduna geçirmek.

Pratik Çıkarımlar

  • Model Seçimi: Varsayımlarla değil; TTFT, token hızı ve birim maliyet metriklerini canlı ölçerek karar verin.
  • Sunucu Mimarisi: Uzun ömürlü streaming (SSE) bağlantılarında senkron worker'lar darboğaz yaratır; asenkron veya threaded sunucu modelleri tercih edilmelidir.

Orijinal kaynağa buradan ulaşabilirsiniz.


Bu konuyu derinlemesine öğrenmek isterseniz: Modeller: Hangisi, Ne Zaman? modülüne göz atın.

Paylaş

Bu konuyu daha derinlemesine öğrenmek ister misin?

Edumints'teki ücretsiz kursları incele ve bugün başla.

Kurslara Göz At →