Blog

Kimi K3 sunucu optimizasyonu, günümüzün en büyük açık ağırlıklı yapay zekâ modellerinden birini üretim ortamında çalıştırmak isteyen herkes için kritik bir konu haline geldi. Yaklaşık 2,78 trilyon parametreye ve 1,56 TB ağırlık büyüklüğüne sahip bu dev model, doğru donanım, ayarlanmış bir sunum yığını ve sıkı doğrulama süreçleri olmadan vaat ettiği performansı gösteremez. Bu yazıda, büyük bir dil modelini ilk günden itibaren etkin biçimde sunmaya hazırlanırken karşılaşılan teknik zorlukları, donanım seçiminden model doğrulamasına kadar tüm aşamaları kendi bakış açımızla ele alıyoruz.

Donanım Seçimi ve Altyapı Kurulumu

Bir modelin boyutu arttıkça, onu çalıştıracak donanımın da aynı ölçekte güçlü olması gerekiyor. Kimi K3 gibi devasa bir model için bellek kapasitesi, işlem gücü ve düğümler arası iletişim hızı, performansın en belirleyici unsurları arasında yer alıyor. Bu modeli ilk günden itibaren hem NVIDIA hem de AMD platformlarında sorunsuzca çalıştırabilmek, dağıtık yığın katmanında GPU tipi heterojenliğine doğal destek sunan çözümler sayesinde mümkün oluyor.

Kimi K3’ün ağırlıkları toplamda yaklaşık 1,56 TB büyüklüğe sahip ve her GPU başına yaklaşık 195 GiB bellek ayrılması gerekiyor. Bu devasa boyut, modelin tamamını tek bir GPU’ya sığdırmayı imkânsız kılıyor. Bu noktada yüksek hızlı NVLink veya Infinity Fabric gibi düğünler arası bağlantı teknolojileri devreye giriyor. Bu bağlantılar, hem bant genişliğine duyarlı dikkat mekanizmaları hem de uzman paralel hesaplamalar için hayati önem taşıyor.

Pratik bir dağıtım birimi olarak 8x NVIDIA HGX B300 veya AMD Instinct MI350X sunucular öne çıkıyor. Her iki platformada 288 GB VRAM kapasitesi bulunuyor; ağırlıkların yüklenmesinin ardından KV cache ve aktivasyonlar için yeterli bellek boşluğu kalıyor. Bu donanım seçimi, modelin boyutunu ve mimarisiyle uyumlu olacak şekilde optimize edilmiş bir web altyapısı kurulmasına olanak tanıyor.

Model Optimizasyonu: Verimlilik ve Gecikme Dengesi

Bir modeli sunucanın başarılı kılan şey yalnızca donanım değil; aynı zamanda onun üzerinde çalışan yazılım yığınının ne kadar iyi ayarlandığıdır. Kimi K3 için yapılan optimizasyon çalışmaları üç temel boyutta gerçekleştirildi: verimlilik ölçekleme, gecikme ve eşzamanlılık yönetimi ile altyapı hazırlığı.

Verimlilik Ölçekleme

Girdi ve çıktı token işleme hızını maksimize etmek, birim ekonomi değerinden ödün vermeden mümkün olduğunca yüksek bir işleme kapasitesine ulaşmayı hedefler. Bu hedefe ulaşmak içinher üç strateji izlendi:

• Bellek bütçesi ayarı: GPU bellek kullanım oranı ince ayarla ayarlanır ve MXFP4 nicemleme kullanılarak model ağırlıklarının boyutu küçültülür. Böylece KV cache için yeterli bellek alanı ayrılır.
• Daha yüksek batch limiti: Her zamanlama adımında desteklenen maksimum batch token sayısı artırılır. Bu, her GPU başına işleme kapasitesini yükseltir ve düğüm sayısını artırmadan verimliliği artırır.
• Hızlandırılmış prefill yolu: Ön doldurma işlemleri, özel bir dikkat yığını ve prefill sorgu nicemlemesi ile gerçekleştirilir. Bu, modelin bu boyutu için varsayılan yoldan önemli ölçüde daha hızlı bir prefill deneyimi sunar.

Gecikme ve Eşzamanlılık Yönetimi

Eşzamanlılık seviyesinin optimum noktası; yeterli sayıda eşzamanlı istek ile token hacmini sağlıklı tutarken, kullanıcı deneyimini bozulmayacak gecikme değerlerini korumak arasındaki dengeyi içerir. Bu dengeyi kurarken şu stratejiler uygulandı:

• Prompt uzunluğuna göre kademeli TTFT hedefleri: Tek bir sabit TTFT SLA yerine, girdi uzunluğuna göre ölçeklenen hedefler belirlenir. Bu, gerçek dünyadaki karışık iş yükleriyle çok daha iyi bir uyum sağlar.
• İş yüküne özel ITL SLA’ları: Sohbet ve ajan (agentic) iş yükleri farklı token arası gecikme ihtiyaçlarına sahiptir; bu nedenle her biri için ayrı ITL hedefleri belirlenir.
• Kabul edilebilir TPS ve uçtan uca gecikme: Verimlilik artışlarının kullanıcı deneyimini olumsuz etkilememesi için işleme hızının ve toplam gecikmenin makul sınırlarda tutulması sağlanır.

Altyapı Hazırlığı

Kimi K3 gibi büyük bir modelin 8 GPU’lu sunucularda çalıştırılması, her sunucuda aynı anda aktif olan kullanıcı oturumu sayısının nispeten düşük olacağı anlamına geliyor. Eşzamanlılık noktasını ve 1 milyon token bağlam penceresi desteğini belirledikten sonra, başlangıç için gereken kapasitenin planlanması mümkün hale geliyor. Bu süreç, bulut altyapısı sağlayıcılarının güvenilir bir hizmet sunabilmesi için kritik bir öneme sahip.

Model Doğrulama: Açık Ağırlıklı Modellerin Zorlukları

Açık ağırlıklı bir modelin yayınlanan kıyaslama (benchmark) skorları, yalnızca onu sunan tarafın sunum yığını doğru yapılandırması durumunda gerçekçi olur. Kapalı ve sınır modelilerinde tüm süreç tek bir satıcı tarafından uçtan uca doğrulanırken, açık ağırlıklı modellerde bu iş her altyapı sağlayıcısının sorumluluğundadır. Kimi K3’ün açık ağırlıkları, her sağlayıcının çözümleme parametrelerini, ayrıştırma kurallarını ve veri formatı detaylarını bağımsız olarak doğru şekilde uygulamasını gerektirir.

Bu bağlamsal bir modelin performansı, sunucu tarafındaki küçük bir hata nedeniyle beklentilerin çok altında kalabilir. Bu sorunun önüne geçmek için geliştirilen bir doğrulama paketi, altı farklı test kategorisini kapsar: çözme parametresi ön doğrulaması, OCRBench, MMMU Pro, AIME2025, araç çağrısı F1 puanı ve JSON şema doğruluğu ile SWE-Bench. Bu paket, sunucu tarafındaki hataların kullanıcıya ulaşmadan bir önce tespit edilmesini sağlar ve sağlayıcıların performanslarını karşılaştırabilecekleri bir liderlik tablosu sunar.

Doğrulama sürecinde karşılaşılan en ilginç zorluklardan biri, dinamik araç çağrıları oldu. Kimi K3, OpenAI API’sine özgü bazı genişletmeler sunar ve bu genişletmelerden biri olan dinamik araçlar, çok sayıda aracın bulunduğu ortamlarda token israfını önlemek için tasarlanmıştır. Bu özelliğin desteklenmesi, paylaşılan bir çoklu model proxy’si içinde yalnızca bu modele özel bir kod yolunun eklenmesini gerektirir. Bu işlem, diğer modellerin mevcut kod akışını etkilemeden, cerrahi bir müdahale ile gerçekleştirildi.

Dinamik Araç Çağrılarının Entegrasyonu

Dinamik araç çalışma biçimi, istemcinin başlangıçta yalnızca çekirdek birkaç aracı tanımlamasına, konuşma sırasında ise bir sistem mesajına eklenen tools anahtarı ile yeni araçlar eklemesine olanak tanır. Bu mesaj her zaman konuşmanın sonuna eklenir ve mevcut ön eke dokunmaz, böylece ön ek tabanlı içerik önbelleğinin bozulmaması sağlanır. Bu özelliğin doğru çalışması için, proxy katmanında doğrulama ve birleştirme işlemlerinin iki ayrı geçişte yapılması gerektiği tespit edildi: ilk geçiş yalnızca doğrulama yapar, ikinci geçiş ise doğrulama başarılıysa değişiklikleri uygular. Bu yaklaşım, bir mesajda hata olsa bile diğer mesajların değiştirilmemesini garanti eder.

Akış Çıktısı Hataları ve Düzeltmeler

Kimi K3’ün akış (streaming) yanıtları, OpenAI spesifikasyonundan dört farklı noktada sapıyordu. Bu sapmaların her biri için proxy katmanında ayrı düzeltmeler yapıldı:

• Null anahtar eksikli: İçerik, düşünce içeriği ve ret alanları yokken bile açıkça JSON null olarak gönderiliyordu. Bunun yerine, bu alanların omitempty özelliğini kullanacak şekilde şema düzeyinde düzeltildi.
• İçerik ve düşünce içeriği ayrımı: Tek bir SSE çerçevesi hem içerik hem de düşünce içeriği taşıyabiliyordu. Bu durum, çerçeveyi ikiye bölen bir işlemle çözüldü.
• Sınır çerçevesi eklenmesi: Model, düşünceden gerçek içeriğe geçişi belirten standart reasoning_content boş çerçevesini hiç yayınlamıyordu. Bu çerçeve, yalnızca Kimi K3 için devreye alınan bir aşama ile eklendi.
• Araç çağrısı parçaları: Model, araç çağrısının tüm argümanlarını ilk parçada gönderiyordu; bu, API’nin kademeli akış yapısına aykırıydı. Bu veriler, uyumlu bir ilk parça ve devam parçalarına ayrıştırıldı.

Bu düzeltmeler, tüm parçaların birbirinin çıktısını tüketen sıralı bir boru hattına (chatStreamShaper) dönüştürülerek birleştirildi. Bu sayede, bir düzeltmenin diğerinin garantisini bozma olasılığı yapısal olarak engellendi.

Prompt Token Sapması

Kimi K3’ün API yanıtlarında, sistem mesajı olarak eklenen 67-70 token, prompt token kullanımında görünüyordu. Bu sorun, düşünce alanının vLLM chat_template_kwargs ile eşlenmesi ve sistem mesajı enjeksiyonunun proxy katmanında doğru şekilde işlenmesiyle çözüldü. Geriye yalnızca üç tokenlık bir sapma kaldı; bu tokenlar, modelin doğru şekilde çözümlemeye başlaması için gerekli olan bir açık, yanıt, ayırıcı dizisidir. Bu dizinin kaldırılması, modelin yanıt üretmemesine neden olur.

Parametre Doğrulama Düzeltmeleri

Kimi K3 için proxy başlangıçta temperature değerinin yalnızca 1.0 olmasına izin veriyordu. Ancak modelin aslında temperature değerinden bağımsız olarak dahili olarak sabit 1.0 ile örnekleme yaptığı belirlendi. Bu nedenle, [0, 1] aralığındaki tüm değerlerin kabul edilmesi gerektiği anlaşıldı. Bu düzeltme, uyumluluk doğrulamasını kıran bir hatayı giderdi.

Gelecek Adımlar ve Öneriler

Kimi K3 gibi modellerin üretim ortamında etkin şekilde çalıştırılması, yalnızca donanım gücüyle değil, aynı zamanda yazılım yığınının ince ayarlanması ve doğrulama süreçlerinin titizlikle uygulanmasıyla mümkün. Bu süreçte, açık ağırlıklı model ekosistemine güven inşa etmek için sağlayıcılar arası şeffaflık ve standartlaştırılmış doğrulama büyük önem taşıyor.

Bu tür büyük modellerin dağıtımı için güçlü bir altyapı seçmek, performansın ilk adımıdır. Ancak altyapının sürekliliği kadar, modelin doğru çalıştırıldığından emin olmak da aynı derecede kritik. Sağlayıcıların, bu süreçlerde karşılaştıkları zorlukları paylaşması, açık ağırlıklı modellerin daha da olgunlaşmasını sağlayacaktır. Linux tabanlı web hosting çözümleri, bu tür yoğun işlemci ve bellek gerektiren uygulamalar için sıkça tercih edilen bir temel oluşturur.

Kimi K3 gibi modellerin güvenli ve verimli bir şekilde çalıştırılması, aynı zamanda güvenilir bir güvenlik katmanı ve düzenli yama yönetimi gerektirir. Bu, yalnızca performansı değil, aynı zamanda hizmetin sürekliliğini de doğrudan etkiler.

SSS

Kimi K3 nedir?

Kimi K3, yaklaşık 2,78 trilyon parametreye sahip, çok büyük bir açık ağırlıklı dil modelidir. Yüksek kapasiteli GPU sunucularında, özel bir dağıtık çıkarım yığınıyla çalıştırılabilir.

Kimi K3’ü çalıştırmak için hangi donanım gereklidir?

Modelin ağırlıkları tek bir GPU’ya sığmaz. Bu nedenle, 288 GB VRAM kapasiteli 8 GPU’lu sunucular (örneğin NVIDIA HGX B300 veya AMD Instinct MI350X) pratik bir dağıtım birimi olarak öne çıkar. Yüksek hızlı düğümler arası bağlantı (NVLink / Infinity Fabric) da şarttır.

Kimi K3’ün performansı neden düşük olabilir?

Modelin açık ağırlıkları, doğru sunu yığını yapılandırması olmadan düşük performans gösterebilir. Çözme parametreleri, ayrıştırma kuralları ve akış spesifikasyonları doğru ayarlanmalıdır. Bu yüzden sağlayıcılar, model üreticisinin yayınladığı doğrulama araçlarını kullanmalıdır.

Dynamic tools (dinamik araçlar) nedir?

Dinamik araçlar, API isteğinde yalnızca birkaç temel aracı tanımlayıp, konuşma sırasında sistem mesajına eklenen tools alanıyla daha fazla araç eklemeye olan tanır. Bu, araç tanımı şişkinliğini önler ve token harcamasını azaltır.

Kimi K3’ü kendi altyapımda çalıştırmak için ne gerek?

Kendi altyapınızda çalıştırmak için güçlü GPU sunucuları ve dağıtık çıkarım yapabilecek bir yazılım yığınına sahip olmanız gerekir. Ayrıca, modelin tüm API uyumluluk ayrıntılarını ve doğrulama süreçlerini eksiksiz şekilde uygulamanız önemlidir.