Show HN: Yavaş bir bilgisayarda GLM 5.2 çalıştırmak

 (github.com/JustVugg)
2 puan yazan GN⁺ 5 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • colibrì, GLM-5.2 744B MoE modelini tüketici sınıfı bir makinede yaklaşık 25GB RAM ile çalıştırmak için yapılmış saf C tabanlı bir motor; yönlendirilen expert’leri diskten akışla okuyarak GPU olmadan çalışıyor
  • Temel yapı, dense kısmın yaklaşık 17B parametresini int4 olarak RAM’de kalıcı tutup 9.9GB kullanıyor; 21.504 yönlendirilmiş expert ise yaklaşık 370GB diskte tutuluyor ve gerektiğinde okunuyor
  • Uygulama; GLM-5.2 forward, MLA attention ve sıkıştırılmış KV-cache, DeepSeek-V3 tarzı router, MTP speculative decoding, int8/int4/int2 quantization kernel’leri ve byte-level BPE tokenizer içeriyor
  • WSL2 12 çekirdek·25GB RAM·NVMe VHDX ortamında yükleme süresi yaklaşık 30 saniye, sohbet sırasında peak RSS yaklaşık 20GB, cold decode ise token başına yaklaşık 11GB disk okumasıyla 0.05~0.1 tok/s düzeyinde
  • Daha hızlı NVMe ve daha büyük RAM’de cache ve pinning önemli; topluluk ölçümlerinde Apple M5 Max 128GB ortamı, MTP kapalıyken 1.06 tok/s kaydetti

colibrì’nin çözmeye çalıştığı sorun

  • colibrì, “Tiny engine, immense model” sloganıyla, GLM-5.2’nin 744B parametreli MoE modelini yaklaşık 25GB RAM’li tüketici sınıfı makinelerde çalıştırmayı hedefleyen bir motor
  • Çalışma zamanı saf C; Python, BLAS veya GPU bağımlılığı yok
  • Motor, c/glm.c adlı tek bir C dosyasında yaklaşık 1.300 satır kod ve küçük header dosyalarından oluşuyor
  • Örnek çalıştırma ./coli chat; örnek çıktı colibrì v1.0 — GLM-5.2 · 744B MoE · int4 · streaming CPU, yaklaşık 32 saniyelik hazırlık süresi ve 9.9GB resident bellek gösteriyor

Diskten akış temelli MoE çalıştırma yöntemi

  • GLM-5.2’nin 744B Mixture-of-Experts modeli, token başına yalnızca yaklaşık 40B parametreyi etkinleştiriyor
  • Her token’da değişen yönlendirilmiş expert’ler yaklaşık 11GB’a karşılık geliyor
  • dense kısım RAM’de kalıyor
    • attention, shared expert’ler ve embedding’leri içeriyor
    • yaklaşık 17B parametre
    • int4 ile yaklaşık 9.9GB RAM kullanıyor
  • yönlendirilmiş expert’ler diskte tutuluyor
    • 75 MoE katmanı × 256 expert ve MTP head dahil
    • toplam 21.504 routed expert
    • expert başına int4 ile yaklaşık 19MB
    • toplam disk kullanımı yaklaşık 370GB
  • expert yükleme, katman başına LRU cache, isteğe bağlı pinned hot-store ve OS page cache kullanıyor

Uygulanan başlıca özellikler

  • GLM-5.2 forward, glm_moe_dsa yapısına uygun biçimde uygulanmış ve transformers oracle’a göre token düzeyinde birebir doğrulanmış
    • tiny-random modelde teacher-forcing 32/32
    • greedy generation 20/20
  • MLA attention, q/kv-LoRA ve iç içe geçmiş partial RoPE içeriyor
    • sıkıştırılmış KV-cache, token başına 576 float kullanıyor
    • önceki 32.768 float/token’a kıyasla 57 kat daha küçük
    • GLM-5.2’de 64 head var ve GQA yok
  • DeepSeek-V3 tarzı sigmoid router uygulanmış
    • noaux_tc
    • routed_scaling_factor
    • shared expert
    • ilk 3 dense katman
  • Yerel MTP speculative decoding içinde GLM-5.2’nin multi-token-prediction head’i (katman 78) draft token üretirken ana model bunları batch forward ile doğruluyor
    • MTP head’in int8 olması gerekiyor
    • int4’te draft acceptance %0~4’e düştüğü için speculation çalışmıyor
    • int8’de acceptance %39~59, ölçülen değer 2.2~2.8 tokens/forward
    • rejection sampling sayesinde sampling sırasında da lossless kalıyor
    • cold cache durumunda doğrulanan draft’lar ek expert’lere yönlenerek expert-loads/token değerini yaklaşık 660’tan yaklaşık 1100’e çıkarabiliyor
    • bu durumda cache ve pin ısınmadan önce daha uzun sürebileceği için adaptive guard ve DRAFT=0 seçeneği var
  • Gerçek sampling, temperature ve nucleus desteği sunuyor
    • varsayılan değerler 0.7 / 0.90
    • resmi 1.0 / 0.95 ayarlarının int4 ortamında tail kısmındaki quantization gürültüsünü örneklediği belirtiliyor
  • integer-dot kernel, Q8_0 tarzı int8 activation’lar ve AVX2 maddubs kullanıyor
    • int8 matmul 1.4~2.5 kat daha hızlı
    • ölçülen performans 119 GFLOP/s
    • int4 batch içinde 1.8 kat daha hızlı
    • int4 single-row ölçümlerde daha yavaş olduğu için f32 korunuyor
  • MLA weight absorption, decode sırasında token başına k/v reconstruction’ı önlüyor
    • query, kv_b değerini absorbe ediyor; context ise attention sonrası projection alıyor
    • forced absorption ortamında da TF 32/32 ve generation 20/20 ile doğrulanmış
  • expert readahead, bir expert bloğu çarpılırken bir sonraki bloğu WILLNEED ile önceden okuyor
  • quantization kernel’leri int8, packed int4, packed int2, per-row scales, AVX2 ve dequant-on-use desteği veriyor
  • DSA sparse attention üzerinde çalışılıyor
    • lightning-indexer weight’leri FP8 deposundan yaklaşık 108GB çıkarma şeklinde
    • indexer forward bir sonraki adım olarak planlanıyor
    • o zamana kadar attention, context ≤ 2048 token için dense ve birebir doğru
  • prefill ve MTP verification sırasında Batch-union MoE, batch içindeki benzersiz expert’leri yalnızca bir kez okuyor ve o expert’e yönlenen tüm position’lara uyguluyor
  • tokenizer, C ile yazılmış byte-level BPE tokenizer; GPT-2 tarzı Unicode-property regex ve 320k merges kullanıyor
  • RAM güvenlik mekanizması, başlangıçta MemAvailable temel alınarak expert cache boyutunu otomatik ayarlıyor
    • working set, KV, MTP row ve reconstruction buffer için peak projection hesaba katılıyor
    • kernel OOM-killer’ın devreye girmemesi hedefleniyor
  • çevrimdışı dönüştürücü c/convert_fp8_to_int4.py olarak sunuluyor
    • GLM-5.2 FP8 shard’larını birer birer indiriyor
    • 128×128 block scale ile dequantize edip motor konteynerine yeniden quantize ediyor
    • işlem ilerledikçe shard’ları siliyor; böylece 756GB FP8 checkpoint’in tamamının aynı anda diskte bulunması gerekmiyor
    • dönüştürme işlemi kaldığı yerden devam edebiliyor

Ölçülen temel performans ve kısıtlar

  • Geliştirme ortamı WSL2, 12 çekirdek, 25GB RAM, NVMe via VHDX
  • Ölçümler şöyle
    • int4 container model boyutu: yaklaşık 370GB
    • resident RAM: 9.9GB
    • load time: yaklaşık 30 saniye
    • sohbet sırasında peak RSS: yaklaşık 20GB, otomatik sınırlandırılmış
    • cold decode maliyeti: token başına yaklaşık 11GB disk okuması
    • VHDX random disk üst sınırı: yaklaşık 1GB/s
    • cold decode hızı: yaklaşık 0.05~0.1 tok/s
    • MTP speculation: int8 head ile 2.2~2.8 tok/forward
  • Bunun hızlı bir sistem olmadığı özellikle belirtiliyor; warm cache, pinned hot expert’ler ve MTP’nin faydalı yanıt gecikmesini azalttığı söyleniyor
  • SSD ile ilgili iki uyarı var
    • colibrì streaming salt okunur olduğu için okumanın kendisi SSD aşınmasına anlamlı etki yapmıyor
    • RAM yetersiz kalıp swap trafiği oluşursa yazma meydana gelir ve bu sürücüyü yıpratabilir
    • uzun süreli tam okuma yükü, düşük maliyetli sürücüleri ısıtabileceği için sıcaklık ve sağlık izlemesi gerekiyor

Model indirme ve çalıştırma

  • Önceden dönüştürülmüş GLM-5.2 int4 model Hugging Face’te sunuluyor
  • Önceden dönüştürülmüş model alınırsa FP8 → int4 dönüştürme adımı atlanabiliyor
  • Çalıştırmak için COLI_MODEL model dizinine ayarlanıyor
COLI_MODEL=/path/to/GLM-5.2-colibri-int4 ./coli chat
  • quick start için c dizininde ./setup.sh, gcc/OpenMP denetimi, derleme ve self-test yapıyor
  • Doğrudan dönüştürmek için ./coli convert --model /nvme/glm52_i4 kullanılıyor
    • yaklaşık 400GB boş alana sahip ext4/NVMe yolu gerekiyor
    • dönüştürme için Python ve torch, safetensors, huggingface_hub, numpy gerekli
    • çalışma zamanı motorunun kendisi saf C; Python yalnızca tek seferlik dönüştürücü için kullanılıyor
  • Faydalı seçenekler şöyle
    • --temp T: sampling temperature; varsayılan 0.7 ve nucleus 0.90, 0 ise greedy
    • --topp 0.7: uyarlamalı expert top-p, disk kullanımını %30~40 azaltıyor
    • --ngen N: yanıt başına maksimum token sayısı
    • AUTOPIN=0: learning cache auto-pin’i kapatır
    • THINK=1: GLM-5.2 reasoning block’u etkinleştirir
    • DRAFT=n: MTP draft depth
    • TF=1: teacher-forcing doğrulaması

Learning cache ve donanıma göre beklentiler

  • Learning cache, gerçek kullanımda yönlendirilen expert’leri modelin yanındaki .coli_usage dosyasına kaydediyor
  • Başlangıçta boş RAM alanına en sıcak expert’leri otomatik olarak pin’liyor
  • Proje açıklaması, kullanım biriktikçe colibrì’nin hızlandığını belirtiyor
  • Gereksinimler: Linux veya WSL2, OpenMP destekli gcc, AVX2, en az 16GB RAM ve yaklaşık 370GB int4 modelin bulunduğu yerel NVMe
    • ext4 yolu öneriliyor
    • network/9p mount kullanılmaması tavsiye ediliyor
  • Test sırası; derleme ve self-test, iobench ile disk ölçümü, chat içinde tok/s·expert hit-rate·RSS kontrolü, expert kullanımının kaydı sonrası pinning ve kalite benchmark’larının çalıştırılması
  • Donanıma göre beklenen değerler ölçüm değil, tahmin niteliğinde
    • geliştirme makinesi WSL2 VHDX, yaklaşık 1GB/s, 25GB RAM: cold durumda 0.05~0.1 tok/s
    • native Linux, PCIe4 NVMe 3~5GB/s random, 32GB: 0.5~1 tok/s
    • PCIe5 NVMe veya 2×NVMe RAID0 8~12GB/s, 64GB, PIN yaklaşık 40GB: 2~4 tok/s
    • 128~256GB RAM, 12 çekirdek, hot expert’ler cache’de: 2~4 tok/s
    • aynı RAM ile 24~32 çekirdek veya AVX-512/VNNI kernel’leri: 5~15 tok/s

Topluluk benchmark’ları

  • Intel Core Ultra 7 270K Plus, 24 thread, WSL2, 24GB RAM, NVMe VHDX ortamında varsayılan ayarlar 0.07 tok/s kaydetti
    • disk iobench: 1.96GB/s buffered, 2.74GB/s O_DIRECT
    • expert hit: %3~4
    • RSS: 14.1GB
  • Aynı ortamda --topp 0.7, 0.11 tok/s kaydetti
    • expert hit: %11
    • RSS: 14.7GB
    • uçtan uca hız 1.6 kat arttı
  • Apple M5 Max, 18 çekirdek, macOS, 128GB unified memory, dahili SSD ortamı 1.06 tok/s kaydetti
    • disk iobench: 14.2GB/s O_DIRECT
    • varsayılan ayarlar, MTP kapalı
    • expert hit: %23
    • RSS: 21.8GB
  • 24GB RAM’li makinelerde expert cache, katman başına 2 slot ile otomatik sınırlandığı için disk geliştirme makinesinden 2~2.7 kat hızlı olsa da decode cold kalıyor
  • Küçük RAM’li makinelerde darboğaz disk değil, RAM sınırı oluyor
  • M5 Max sonucu, 744B modelin dizüstü SSD’sinde yaklaşık 1 tok/s verebildiğini gösteriyor; 14GB/s disk ise darboğazı yeniden RAM bütçesi ve kernel tarafına taşıyor

Kalite benchmark’ları ve eksik ölçümler

  • int4 quantization’ın doğruluğa maliyeti henüz ölçülmedi
  • benchmark harness uygulanmış olsa da, geliştirme makinesindeki yaklaşık 1GB/s disk nedeniyle tam çalıştırma günün büyük bölümünü alıyor
  • Sunulan benchmark komutları hellaswag, arc_challenge, mmlu çalıştırıyor
cd c
./coli bench
./coli bench hellaswag --limit 200
./coli bench mmlu arc_challenge --ram 100
  • Çıktı, görev bazında accuracy; log-likelihood scoring ve EleutherAI-harness tarzı kullanılıyor
  • full-precision GLM-5.2’nin kamuya açık skorlarının bu görevlerde yaklaşık %85~95 olduğu belirtiliyor
  • Eğer int4 container yalnızca birkaç puan farkla kalırsa quantization doğrulanmış olacak; aksi halde mixed veya grouped-scale quantization’a yatırım yapmak için gerekçe oluşacak

Depo yapısı ve lisans

  • Başlıca dosyalar şöyle
    • c/glm.c: GLM-5.2 forward, streaming MoE, MTP ve serve mode içeren motor
    • c/st.h: pread ve fadvise tabanlı safetensors okuyucu, mmap kullanmıyor
    • c/tok.h: C byte-level BPE tokenizer
    • c/coli: chat, run, bench, convert, info CLI
    • c/iobench.c: motorun hissettiği parallel disk microbenchmark
    • c/convert_fp8_to_int4.py: disk-safe FP8 → int4 dönüştürücü
    • c/make_glm_oracle.py: doğrulama için tiny-random oracle üretici
    • c/olmoe.c: Stage-A motoru ve ilk doğrulama hedefi
  • colibrì adı, az ağırlıkla havada asılı kalabilen ve bir günde çok sayıda çiçeği ziyaret eden sinek kuşundan geliyor
  • Proje lisansı Apache 2.0; GLM-5.2 weight’leri ise Z.ai tarafından MIT ile yayımlanıyor

İlgili okumalar

1 yorum

 
GN⁺ 5 시간 전
Hacker News yorumları

  • Asıl merak ettiğim, bunun pratikte token/saniye düzeyinde mi çalıştığı, yoksa dakikada 1 token’a mı daha yakın olduğu
    Yerel bir LLM 1 token/saniye kadar yavaş olsa bile, projeyi gece boyunca bırakıp 6–8 saat sonra sonuca bakma tarzında kullanımda epey faydalı olmuştu
    Buna karşılık, bağlantıda geçen en düşük donanım özelliklerinde 0.05–0.1 token/saniye neredeyse işe yarar hiçbir kullanım alanı bırakmıyor gibi görünüyor
    Yine de genel fikir harika ve sıradan insanların karşılayabileceği donanımda 350B~900B sınıfı modelleri yerelde, 1 token/saniye olsa bile çalıştırmaya yönelik daha fazla girişim görmeyi umuyorum
    “Hızlı okuma performansına sahip bir NVMe SSD ve yerel diskte devasa bir model varsa, hepsini yüklemek yerine gerektiğinde token başına 11GB okuyalım” yaklaşımı hoşuma gitti

    • Claude Cowork sayesinde yanıt süresi beklemeye alışmış olmam komik
      En geç 2028 gibi bunu yerelde çalıştırıyor olacağımızı düşünüyorum
      Bütçeyi 10 bin doların altında tutup, bugünün en iyi modelleriyle boy ölçüşebilecek bir modeli çalıştırmak istiyorum
    • Yavaş yerel modellerde ya da bazı projelerde sohbet arayüzü yanlış yaklaşım olabilir; belki de bilet sistemi benzeri bir yapı daha uygundur
      Mac Studio ya da GPU’ya para harcamadan önce, şu an elimdeki donanımla bu fikri doğrulamanın bir yolunu buldum ve bu hafta bir kavram kanıtı çıkarabilirim gibi görünüyor
      Bu yeni bir fikir değil, sadece benim çalışma biçimime uyan şekilde işlemesini sağlamak için zamana ihtiyacım var
    • README’de çeşitli donanımlarda Colibrì çalıştırılmış benchmark sonuçları var ve oldukça iyi süreler gördüm
      Bunu daha da geliştirmeye devam ediyorum
    • Çoğu proje için GLM 5.2’yi ücretsiz sunan bulut kullanmak daha pratik
      Dakikada 1 token, ücretsiz kullanım kotalarıyla kıyaslayınca bile fazla düşük
    • Bugünlerde “sıradan” birinin 24GB RAM ve 0.5TB NVMe SSD karşılayıp karşılayamayacağını düşünüyorum

  • Apple Silicon üzerinde macOS’u hedefleyen benzer bir şey yapıyorum
    Yönelimim Unsloth split GGUF, birleşik bellekte sıkıştırılmış kısmi kalıcılık, yerel Metal çekirdekleri ve yalnızca RAM kullanan yerel sıkıştırılmış KV tarafında
    Sanırım bu, 64GB yerine 128GB’ta daha anlamlı olacak ve hazır olduğunda GitHub’a koymayı planlıyorum

    • 128GB MacBook Pro M4 bekliyor; memnuniyetle test ederim

  • Görüntü/video üretim tarafında da https://github.com/cretz/thinfer ile benzer bir strateji denedim
    video dalında çok iş var
    Gerektiği anda ağırlıkları LRU yöntemiyle içeri alıp dışarı çıkarabilen bir çıkarım motoruna sürekli ihtiyaç duyuyordum; sonunda --vram-budget alan ve bunun içinde kalan bir aracı vibe coding ile yaptım
    mmap’lenmiş baytları VRAM içine ve dışına taşımanın maliyetinin, hesaplamaya kıyasla oldukça düşük olduğu ortaya çıktı; hattı borulama ve çift tamponlamayla birleştirince neredeyse her zaman bellek darboğazı değil, hesaplama darboğazı oluyordu
    Tabii çok daha küçük modeller kullanıyorum

    • Sanırım içine krea, wan, hunyan gibi gerçekten çok sayıda model eklemişsin
      Hepsini çalıştırabilen ortak bir harness mi oluşturdun, merak ediyorum
      Hangi modellerin VRAM bütçesi içinde daha tutarlı kaldığını da merak ediyorum

  • llama.cpp çeşitli 4 bit ve altı nicelemeleri destekliyor ve modeli varsayılan olarak mmap ile açıyor; yani tüm ağırlıkları bellekte tutmak gerekmiyor
    İşletim sistemi gerektiğinde depolamadan getiriyor
    Bunu bağımlılık olmadan çok az kodla uygulamış olman etkileyici ama gerçekten performans avantajı sağlayıp sağlamadığını merak ediyorum

  • Oldukça havalı
    Bu hafta GLM 5.2 ile biraz uğraştım, ben de etkileyici buldum
    Şirkette, bir sonraki projeye başlamadan önce aşırı pahalı donanımda yerel çalıştırmayı test ediyoruz; bu dev açık kaynak model sürümünü ortalama makinelerde çalıştıran insanlar görmek güzel
    Henüz çok pratik olmasa da iyi iş

    • Ne tür bir donanım olduğunu merak ettim

  • LLM’lerin iç mimarisini çok iyi bilmiyorum ama “katmanları” olan diğer modellerde de benzer bir yapı kullanılıp kullanılamayacağını merak ediyorum
    Bir katman işini bitirdiğinde onu RAM’den atıp, sonraki katmanı diskten yükleyip birinci katmanın çıktısı üzerinde etkinleştirmek mümkün olur mu diye düşünüyorum

  • 64GB RAM ve 24GB VRAM olan bir makinem var; bunu daha fazla RAM kullanacak şekilde ayarlamak mümkün mü, merak ediyorum
    Ya da GPU’da Gemma/Qwen çalıştırıp GLM-5.2’nin daha küçük işleri ona devretmesini sağlayabilirim gibi geliyor
    Belki GLM-5.2’yi bir miktar yeniden eğitmek gerekir
    Birden fazla diski paralel kullanarak bant genişliğini artırmanın hızı yükseltip yükseltmeyeceğini de merak ediyorum
    SSD aşınma uyarısında, soğuk başlangıcın yaklaşık 11GB/token rastgele okumayla ağır olduğu; okumaların kendisinin güvenli olduğu ama işletim sistemi sayfa önbelleğinin yazma oluşturabileceği ve aşırı kullanımın ucuz SSD’lerde aşınmayı hızlandırabileceği yazıyor
    Güvenli bir yöntem olarak, model ağırlıkları için ayrı bir bölüm oluşturup onu salt okunur ayarlamak mümkün olabilir
    Sayfa önbelleğinin bölüm bazlı mı yoksa disk bazlı mı çalıştığını bilmiyorum ama disk bazlıysa, salt okunur data.iso dosyasını bölüm gibi biçimlendirip disk olarak bağlamak da bir seçenek olabilir

    • Küçük bir dizüstü kullanıyorum
      Daha fazla diskim olsaydı gerçekten test edebilirdim
      Bir benchmark çıktığında bunu pull request ya da issue olarak paylaşırsan birlikte çalışabiliriz
    • “İşletim sistemi sayfa önbelleği yazma oluşturabilir” ifadesinin halüsinasyon olup olmadığını merak ediyorum
      Burada neyi kaçırıyorum? Büyük miktarda okuma neden yazma üretsin?
    • İyi bir fikir olabilir, birlikte çalışabiliriz

  • Sayfada bir SSD aşınma uyarısı var https://github.com/JustVugg/colibri#ssd-wear-warning
    Kendi topladığın masaüstü PC kullanıyorsan SSD değiştirilebilir ama lehimli SSD kullananlar ne yapacak?
    Bu tür uygulamalardan kaçınmak mı gerekir, yoksa depolamanın erken ölme ihtimalini kabul edip devam mı etmek gerekir?
    Harici depolamayı sarf malzemesi SSD gibi kullanmak gerekecek gibi duruyor

    • Kaçınmak daha doğru
      Lehimli SSD’li dizüstü kullananların kullanım miktarını gerçekten takip edip dikkatli olması gerekir
      Bu proje herkesin çalıştıracağı bir şeyden çok bir deneye benziyor ama yine de oldukça etkileyici
    • Benim anladığım kadarıyla uyarı, aşırı bellek kullanımı sırasında swap out ile ilgili
      Burada batıl inançla yaklaşmaya gerek yok
      Disk etkinliği, özellikle yazmalar, ölçülebilir
      Örneğin Linux’ta iostat ya da vmstat kullanılabilir
    • Oldukça muhafazakâr bir uyarı
      Uygulama yazma yapmıyor, dolayısıyla uygulamanın kendisi SSD’yi gerçekten aşındırmıyor
      Geri kalanı uygulamadan bağımsız, genel yönetim tavsiyelerine daha yakın
    • Böyle bir kullanım için harici sürücü mantıklı görünüyor

  • Teknik olarak etkileyici ama gerçekten pratikte kullanılabilir olup olmadığını merak ediyorum

  • Ben de aslında aynı şeyi yapıyordum ama ek RAM kullanımından kaçınmak için tüm modeli belleğe mmap’leme yoluna gittim
    Ayrıca Claude’a, modele Medusahttps://arxiv.org/abs/2401.10774 eklemesini sağladım; böylece belleğe ek model yüklemeden çoklu token tahmininin faydasını almaya çalıştım
    Eve yeni geldim, ekleyeyim: tüm değişiklikleri llama.cpp üzerinde yapıyorum ve nihai hedefim bunu NVMe üzerinden mmap dosyalarını işleyen tek kartlı bilgisayar benzeri bir yerde çalıştırmak
    Önceki testlerime göre mevcut kurulumun teorik sınırı yaklaşık 1.8 token/saniye gibi görünüyor ama ek Medusa head’leri tamamen eğitilmiş değil ve bunun üretilen token’lara göre mi hesaplandığından da açıkçası emin değilim
    Sonuçta fikirler benziyor ama ben hâlâ sıfırdan bir LLM ayrıştırıcısı/çalıştırıcısı yazmayı bilmiyorum; bu yüzden bellekte neyin kalacağına kendim karar vermek yerine bunu Linux çekirdeğine bıraktım
    Son olarak llama.cpp kullanımını 32GB’lık sistemimde 16GB ile sınırlandırdım; yani daha da düşürmek mümkün olabilir

    • Colibrì’nin daha da iyileşmesi gerekiyor; fikirlerin ya da başka katkıların varsa pull request, issue ve benchmark’ların hepsi memnuniyetle karşılanır
    • Benim merak ettiğim yaklaşım tam olarak buydu