Kimi K3’ü 29 GB RAM’de 0,50 tok/sn hızla çalıştırmak

 (github.com/sqliteai)
1 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • WASTE, 2,78 trilyon parametreli tam Kimi K3 açık ağırlık modelini küçültmeden 982 GiB’lik bir konteynere dönüştürüp tüketici sınıfı dizüstü bilgisayarlarda çalıştıran C tabanlı bir inference motorudur
  • Modelin yerleşik trunk kısmını bellekte tutar; her token’da etkinleşen yaklaşık %4’lük uzman ağırlıklarını NVMe’den okur ve kalan RAM’i boyutu sınırlı bir uzman önbelleği olarak kullanır
  • Kimi K3, 4K bağlamda en az 29,05 GB RAM ile açılabilir; ancak pratik yapılandırma, 64 GB MacBook Pro’da 46 GB bütçedir ve burada 0,45~0,62 tok/sn kaydedilir
  • Uzman okuma ve hesaplamayı örtüştürerek yaklaşık 1,6 kat iyileşme sağlar; sonraki katman router’ını bir residual önceden çalıştırarak önbellek isabet oranını %14’ten %38’e çıkarır, toplam okuma miktarını ve logit’leri değiştirmez
  • İnternet bağlantısı, token başına maliyet veya dışarıya veri aktarımı olmadan çok büyük modelleri yerelde çalıştırabilir; ancak dahili NVMe ve yaklaşık 1 TB depolama gerekir, RAM bütçesi 52 GB ve üzerindeyse işletim sistemi paging’i nedeniyle aksine keskin biçimde yavaşlayabilir

WASTE’in hedefi ve uygulama biçimi

  • WASTE (Weight-Aware Streaming Tensor Engine), çalışma zamanında dış bağımlılığı olmayan, gömülebilir bir C inference motorudur
    • Yalnızca libwaste.a ve waste yürütülebilir dosyasını kullanır; libc ve pthreads dışında BLAS, CUDA, ONNX veya Python gerektirmez
    • Python yalnızca model dönüştürme ve PyTorch referans doğrulaması için kullanılır; inference yoluna girmez
    • Açık API 26 fonksiyondan oluşur ve model açma, RAM üst sınırı ayarlama, üretim, oturum kaydetme ve kapatmayı destekler
  • Şu anda doğrulanan hedef, Kimi K3 2.78T tam modelidir
    • Açık kaynak orijinal 1,42 TB’tır; dönüştürmeden sonra konteyner 982 GiB’dir
    • Distillation, pruning veya küçültülmüş bir sürüm değildir
    • Kimi-Linear 48B de aynı motor ve formatla 19 GiB konteyner, minimum 1,87 GB RAM ve 10,7 tok/sn kaydeder
  • Proje adı, masaüstündeki donanımda çalıştırılabilecek modelleri bulut veri merkezlerinde çalıştırıp token maliyeti ve elektriği birlikte tüketme durumunu azaltma hedefinden gelir

Disk streaming mimarisi

  • Mixture of Experts mimarisindeki K3, token başına modelin yalnızca yaklaşık %4’ünü etkinleştirdiği için etkin olmayan ağırlıkları RAM’de yerleşik tutmak gerekmez; ihtiyaç duyulan anda erişilebilecek şekilde yerleştirir
  • .waste konteyneri JSON manifest, yerleşik trunk ve katman bazlı uzman bankalarından oluşur
    • Her uzman kaydı 4 KiB hizalanır
    • gate, up ve down matrisleri bitişik yerleştirilerek bir uzman tam olarak tek bir pread ile okunur
    • Sayfa önbelleği macOS’ta F_NOCACHE, Linux’ta O_DIRECT, Windows’ta FILE_FLAG_NO_BUFFERING ile baypas edilir
  • Sayfa önbelleği baypas edilmezse RAM’den küçük test konteyneri işletim sistemi önbelleğine girerek 982 GiB’lik modelde tekrarlanamayacak isabet oranları oluşturabilir
  • Kayıt okunurken magic, uzman ID’si ve offset aralığı her zaman kontrol edilir; böylece kesilmiş veya yanlış birleştirilmiş bankaların hatalı ağırlıklarla yanıt vermesi engellenir
    • Payload için crc32 kontrolü --verify ile etkinleştirilir
    • Doğrulama maliyeti Kimi-Linear’da yaklaşık %5, K3’te yaklaşık %1’dir ve varsayılan olarak kapalıdır
    • Kopyalanmış, indirilmiş veya güvenilmeyen bir diskte tutulan konteynerin bir kez doğrulanması önerilir
    • Trunk ve codebook’larda checksum yoktur

Önceden okuma ve router tahmini

  • Bir katmanın router’ı 16 uzman ID’sini belirlediğinde her okuma ayrı bir iş parçacığında istenir ve hesaplama gelen verileri sırayla tüketir
    • Okuma ve hesaplamanın örtüşmesi K3’te yaklaşık 1,6 kat iyileşme sağlar
    • Yapılan iş ve önbellek istatistikleri, özellik etkinleştirilmeden önce ve sonra aynıdır
  • Sonraki katmanın gerçek hidden state’i oluşmadan önce, bellekte yerleşik olan sonraki router mevcut hidden state ile çalıştırılıp 6 uzman önceden getirilir
    • Bir residual önden yapılan tahmin rank 1’de %92, ilk 6’da %81 doğrudur
    • Nihai uzmanları gerçek router belirlediği için çıktı tam olarak doğru kalır
    • Demand hit rate %14’ten %38’e yükselir ve toplam okunan bayt değişmez
    • WASTE_LOOKAHEAD=0 ile devre dışı bırakılabilir
  • Aynı tekniğin prefill’e uygulandığı implementasyon kaldırıldı
    • Decode katmanı 16 önbellek slotu işgal ederken chunk katmanı yaklaşık 550 slot işgal eder
    • Önceden okunan kayıtlar kullanılmadan önce dışarı atıldığı için okuma miktarı %6,9 arttı ve süre azalmadı

Quantization ve doğruluk

  • Uzman ağırlıkları, 8 boyutlu vektörler için 256 öğeli codebook’un 3 aşamalı artık vektör quantization yöntemiyle saklanır ve ağırlık başına 3,00 bit kullanır
    • Tüm matrisi geri yüklemeden kısmi iç çarpım tabloları oluşturur, ardından her satırı 3 tablo sorgusu ve 2 toplamayla işler
  • Trunk 4 bit ve 8 bit olarak korunur
    • Model yalnızca uzmanlar için quantization-aware training gördüğünden 3 bit trunk’ta çıktı çöker
    • Önbellek tahmini doğruydu, ancak throughput da iyileşmediği için kaldırıldı
  • Tüm katmanlar PyTorch referans implementasyonuyla karşılaştırılır
    • Nihai logit farkı 3.6e-06
    • Vision tower, kendi referansıyla 2.3e-06
    • Latent KV cache dönüşümü 1.2e-05 düzeyinde aynı logit’leri korur

RAM bütçesi ve dar performans aralığı

  • K3, 92 katmanın her birinde 16 uzman kullanarak token başına 17,0 GB’lık working set oluşturur
    • Önbellek bu boyuttan küçükse bir token’da saklanan uzman, sonraki token’dan önce atılır ve isabet oranı %0 olur
  • 64 GB sistemde yapılan ölçümler, daha fazla RAM ayırmanın her zaman hızlandırmadığını gösterir
    • 32 GB bütçe·3,32 GB önbellek: isabet oranı %0, 0,50 tok/sn
    • 46 GB bütçe·17,32 GB önbellek: mevcut isabet oranı %17, 0,53~0,55 tok/sn
    • 52 GB bütçe·23,32 GB önbellek: 0,04~0,15 tok/sn, tekrarlanabilir değil
    • 58 GB bütçe·29,32 GB önbellek: 0,02~0,03 tok/sn
  • Router lookahead, 46 GB’ta isabet oranını yaklaşık %14’ten %38’e çıkarır; ancak 52 GB ve üzerindeki çöküş cache miss değil, işletim sistemi paging’i nedeniyledir
    • 58 GB’ta isabet oranı daha yüksek olsa da 46 GB’tan yaklaşık 20 kat daha yavaştır
    • Büyük bir bütçeyle sistemi paging durumuna soktuktan sonra 46 GB ölçümü de 0,02 tok/sn’ye kadar düşebilir
  • Varsayılan bütçe, fiziksel RAM’in 7/8’inin altında token working set birimleriyle aşağı yuvarlanarak seçilir
    • 64 GB MacBook Pro’da 46,24 GB kullanır ve 17,56 GB’ı uzman önbelleğine ayırır
    • Belirtilen bütçe minimumdan küçükse swapping ile ilerlemez, başlatmayı reddeder
    • 128 GB sistemde trunk ve working set’in 3 katına karşılık gelen tam önerilen bütçe kullanılabilir

K3 performansı ve donanım gereksinimleri

  • Ölçüm sistemi 64 GB MacBook Pro M5 Pro ve dahili SSD’dir
    • 4K bağlam için minimum RAM: 29,05 GB
    • 32K: 30,54 GB, 128K: 35,63 GB, 1M: 83,21 GB
    • Yerleşik trunk: 27,28 GB
    • Model yükleme: 20 saniye
    • Decode: varsayılan bütçede 0,45~0,62 tok/sn
    • Prefill: chunked 0,47 tok/sn, sıralı 0,29 tok/sn
  • Model minimum 29,05 GB ile açılabilir; ancak 32 GB sistemler ciddi paging yaşayabileceğinden gerçekte önerilen özellik 64 GB’tır
  • Cold durumda token başına 17,0 GB uzman verisi okur; lookahead’in %38 isabet oranında 10,5 GB okur
  • Dahili SSD 12,78 GB/sn, harici USB kutusu 0,94 GB/sn olarak ölçülmüştür
    • Bir token 17 GB uzman verisi okuduğu için aynı işlem harici depolamada yaklaşık 13 saniye sürer
    • Orijinal indirme harici diskte tutulabilir; ancak dönüştürülmüş konteyner dahili NVMe’de olmalıdır
  • Dönüştürme konteyneri için 982 GiB ve orijinal shard staging için 1,42 TB gerekir; staging alanı dönüştürmeden sonra serbest bırakılabilir

Attention ve multimodal işleme

  • K3 attention, Kimi Delta Attention ile gated multi-head latent attention’ı 3:1 oranında birleştirir
    • KDA, büyüyen KV cache yerine sabit boyutlu recurrent state tutar
    • MLA, head başına key/value genişletmeden 512 genişliğinde latent önbelleğe alır
  • kv_b_proj, query ve output’a absorbe edilerek 4K context cache’i 11,25 GB’tan 0,21 GB’a düşürülür
    • Öncekine göre 53 kat azalma sağlar
    • 128K’da genişletilmiş layout 360 GB, latent layout 7,2 GB gerektirir
  • Multimodal yol, 401M parametreli, 27 katmanlı, patch 14 ViT’yi destekler
    • 1024 patch görüntü kodlama 15,7 saniyedir
    • 896×896 görüntü varsayılan ayarda 256 sequence position kaplar
    • Görüntü embedding’leri de 92 MoE katmanından geçtiği için maliyetin büyük kısmı vision tower’dan çok text prefill ile aynıdır
    • vision.json içindeki max_patches yarıya indirilirse prompt pozisyonlarının sayısı da yarıya iner
  • PNG, JPEG, GIF, BMP, TGA, PSD desteklenir; run, chat, eval içinde görüntü kullanılabilir
    • Sohbet sırasında kodlanmış görüntü pozisyonları attention state’te kalır ve sonraki turda yeniden kodlanmaz
    • Vision tower yalnızca görüntü olduğunda yüklenir; ağırlıklar için 434 MB ve toplam ayrılmış bellek olarak 1,12 GB kullanır

Dönüştürme, çalıştırma ve sunucu

  • Derleme yalnızca C11 compiler ve make gerektirir
    • make check, gerçek model olmadan sentetik konteynerle 23 testi geçer ve 11 testi atlar
    • İki gerçek konteyner varsa toplam test sayısı 36’dır
  • K3 dönüştürme, herkese açık moonshotai/Kimi-K3 içindeki 96 safetensors shard’ını olduğu gibi kullanır
    • 3 process ile M5 Pro’da yaklaşık 4,7 saat sürer
    • Saf PyTorch encoder 23,7 saat sürer
    • Katman bazında devam edebilir; kesinti olursa yalnızca işlemdeki katman yeniden işlenir
    • Downloader kısmi dosya devamı, exponential backoff ve jitter, Content-Length kontrolü, tamamlanan shard durum kaydını destekler
  • CLI run, chat, eval, plan vb. sunar; --json ile eval, tokenize, plan, info, bench sonuçlarını makine tarafından okunabilir şekilde çıktı verir
  • serve/, açık C API’yi ctypes ile çağıran OpenAI uyumlu HTTP sunucusudur
    • /v1/chat/completions, /v1/completions, /v1/models, /health sunar
    • Streaming, araç tanımları ve sonuçları, typed call arguments, JSON yanıt şeması, tool_choice, think channel, thinking_effort ve görüntüleri işler
    • Prompt renderer, K3 sürümündeki encoding_k3.py dosyasını taşımıştır; ağırlık dizini varsa 38 konuşmayı segment bazında karşılaştırır

Platformlar ve mevcut sınırlamalar

  • macOS arm64, Linux arm64, Linux x86_64 aynı modelden bağımsız testlerde 23 pass·11 skip kaydeder; sanitizer ve 400 fuzz testi de geçer
  • Windows x86_64, MinGW-w64 ile çapraz derlenerek sentetik konteyner, CLI ve forward pass doğrulanmıştır; ancak gerçek model konteyneriyle çalıştırılmamıştır
    • MSVC ve Windows ARM64 desteklenmez
    • Windows’ta page-cache baypası yalnızca CI dosya sisteminde doğrulanmıştır; RAM’den büyük gerçek konteyner yükünde doğrulanmamıştır
  • x86 SIMD, CPUID’ye göre AVX-512 veya AVX2 seçer; ancak AVX-512 yolu gerçek destekli CPU’da henüz çalıştırılmamıştır
  • Metal backend doğru çalışır, ancak iş biçimi yüzlerce küçük bağımlı matvec içerdiği için CPU’dan %22 daha yavaştır ve varsayılan olarak devre dışıdır
  • API henüz sabitlenmemiştir ve chat format otomatik dönüşümü şu an yalnızca K3’ü destekler
    • Kimi-Linear şablonu tahmin etmez, raw modda çalışır
  • Uzman başına eşitsiz bit tahsisi getirilmeyecektir
    • Üçüncü bitin değeri katman içindeki uzmanlar arasında en fazla 1,15 kat, katmanlar arasında 1,01 kat değiştiği için optimum tahsisin getirisi yoktu
    • Routing frequency tabanlı tahsis depolama alanını azaltsa da darboğaz olan I/O’yu neredeyse azaltamaz
  • Lisans Apache 2.0’dır

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Hacker News yorumları

  • Gerçekten harika. Şu anda bulut sağlayıcılarından daha pratik olmayı hedefleyen bir proje değil; olasılığın sınırlarını gösteren bir proje.
    Model verimliliğindeki iyileşmeler ile yerel donanım performansındaki artışlar birleşirse, bir gün yüksek kaliteli yerel modeller ekonomik olarak işletilebilir hale gelebilir.

  • Saniyede 0,5 token uzun işler için bile işe yaramaz bence. Onun yerine para harcayıp iki adet 16 GB 4060 Ti alır, tensör paralelleştirme uygularım.
    20 yıl sonra güneş enerjisiyle çalışan, çim biçerken ya da kaldırımları temizlerken ilerleyen siberpunk tarzı yavaş robotlara; ya da bahçede bir bonsainin büyüme hızına ancak yetişip dallarını budayan robotlara uygun olabilir.

    • Şu anda neredeyse kullanılamaz, ama bu tür projelerin gelişmeye devam etmesi sonuçta pratik bir sürüme ulaşmayı sağlayacağı için sevindirici.

  • Token ücreti ödeyip çıkarım sağlayıcısının elektrik parasını ödemesinin israf olduğu söyleniyor; salatalık satın aldığınızda çiftçinin su ve gübre masrafını ödemesinden ne farkı var, anlamıyorum. Umarım bu, LLM’in sonradan uydurduğu bir gerekçedir.
    Fikrin kendisi ilginç ve daha küçük modellerle denemek isterim. Saniyede 0,5 token üretirken SSD’den her saniye birkaç GB okuyorsa, sıradan tüketici dizüstüleri için hâlâ fazla büyük; ama 250–500 GiB modeller hedeflendiğinde aksine pratik olabilir.

    • Kendi domatesinizi yetiştirirseniz bedava domates elde edebilirsiniz. BLT yapmaya yetmese de süpermarketten alınmış olmadığı için dünyayı biraz kurtarmış sayılırsınız /s

  • Sürekli 42 W harcadığını ve elektriğin kWh başına 20 sent olduğunu varsayarsak, 1 milyon token başına yaklaşık 5 dolar eder; donanım ve diğer maliyetler buna dahil değil.

    • Bir ay yaklaşık 2,6 milyon saniyedir; saniyede 0,5 token ise ayda 1,3 milyon token üretir. Yan maliyetleri de hesaba katınca, aylık donanım işletme maliyetini 1 milyon token başına maliyet diye almak kabaca doğru olur.
    • Güneş enerjisi varsa hesabın nasıl değişeceğini merak ediyorum.

  • Standart llama.cpp de GGUF’yi mmap edebiliyor; belleğe sığmayan kısımlar diskte kalıyor ve kernel sayfa önbelleği sık kullanılan kısım olan yerleşik gövdeyi tutuyor. Bunu ayrıca uygulamanın avantajı ne, merak ediyorum.

    • Birkaç gün önce benzer bir projede de aynı soru gelmişti; önce mmap denediklerini, sonra kendileri uygulayıp 10 kat hızlandığını söylemişlerdi.
      Veritabanı motorlarının kendi önbelleklerini uygulamasının nedeni de aynı. Kernel sayfalaması genel amaçlı ve istek temelli; ama gerçek erişim desenini bilirseniz gereken veriyi önceden okuyup pipeline’a alabilirsiniz.
    • Bu ölçekte SSD’yi takas alanı olarak kullanırsanız, yalnızca birkaç ay içinde kümülatif yazma dayanımını tüketmek kolaydır. Kısa süreli denemelerin ötesinde çalıştırıldığında SMART’ın kümülatif yazma miktarını ve aşınma istatistiklerini görmek isterim.
      Tamamı RAM’e sığan bir model için llama-server’ı --no-mmap ile çalıştırmak daha iyiydi. Elbette tüm Kimi K3’ü ve 1 milyon token bağlamı yüklemek için 2 TB’lık bir sunucu gerekir.

  • README güçlü biçimde LLM tarafından yazılmış hissi veriyor; kod tabanının da LLM tarafından yazılıp yazılmadığını merak ediyorum.

    • Yüzeysel biçimde küçümsemek istemem, ama belge, modeli gerçekten özgün hassasiyette çalıştırıp çalıştırmadığı konusunda kendi içinde çelişiyor. İddia edilen 3 bit kuantalama ilginç olabilir; ancak K3’ün özgün hassasiyetteki yoğun parametreleri tek başına yaklaşık 115 GB, token başına etkin seyrek uzmanları yaklaşık 25 GB ve buna KV cache de ekleniyor. Bu yüzden 29 GB RAM’de token başına 2 saniye iddiasını anlamak zor.
    • Yazılımın çoğunu kendim yazdım ve bir programlama dili de geliştirdim: https://github.com/marcobambini/gravity
      Artık LLM’leri ve ajanları koordine etmek için becerilerimi kullanarak çok daha hızlı, daha iyi kod yazıyorum. Geliştiriciler ya yeni teknolojiye uyum sağlamak ya da geride kalmak arasında seçim yapmak zorunda.
    • Yazarların en azından LLM’in ürettiği README’yi bizzat okuyup gözden geçirmelerini isterdim. LLM, okur bakışını kavramakta zayıf; dışarıdan okurun da projenin tüm bağlamını ve karar alma sürecini bildiğini varsayıyor.
      Kullanıcı için önemli olup bitmiş ürüne bakan okur için ilgisiz kalan iç kararlar ve Claude’a özgü anlaşılması güç terimler aynen kalıyor. LLM’leri sık kullandığımı ve karmaşık kod yazmada çok faydalı olduklarını kabul ediyorum, ama metin taslağı kalitesi berbat.
    • Katkıda bulunanlar listesinde claude var; tahmin etmeye gerek yok. Claude’a commit atmayı bile emanet ediyorlarsa kodu bizzat gözden geçirmiş olma ihtimalleri de düşük görünüyor.
    • README’de Claude’a özgü üslup en yoğun hissediliyor. İnsanların yazı tarzlarını tanıdığımız gibi, artık Claude’un varsayılan olarak ürettiği kısa, kesik ve ritmi gereğinden fazla abartılı üslup da zihnimde ayrı bir tür olarak yer ediyor gibi.

  • Yapılacak işe uygun modeli doğru seçebilecek kadar teknoloji gelişirse değeri artabilir. Otomatik keşif sürecinde büyük modeli günde yalnızca 30 dakika çalıştırıp geri kalan zamanda küçük model kullanan bir gelecek hayal edilebilir.

    • Böyle bir gelecek gelmeyecek gibi. Backlog maddelerinde bile harcanacak süreyi ancak bitirdikten sonra öğrenebiliyoruz; işi gerçekten yapmadan iş karmaşıklığını önceden bilmenin bir yolu yok.