Paikallisesti pyörivät LLM koodausavustimet

[finWeazel]

Pikatestasin laguna-s-2.1:q4_K_M 1adabf138c90 96 GB macbook pro m4 max 128GB promptilla " write a webpage using three.js for showing images" ihan ok näköinen lopputulos. Ei edes kamalan hidas. Pitäs pool:in haarniska asentaa ja testailla enemmän. En osaa arvailla esim. oliko nuo ollaman vakioparametrit fiksut ja mitä pool:in oma haarniska tekee esimerkiksi kontekstin luonnille ja järkeilyn määrälle.

 

[I'maRobot]

Kaksikanavainen DDR5 yhä, rajoittanee menoa kyllä Nova Lakella. Muistikaista taitaisi jäädä karkeasti arvioiden noin puoleen Strix Halosta.

Näinhän se on. Mutta täytyy hyödyntää niitä mitä on. Jos ostaa Halon integroiduilla nopeilla muistella hinta tuplaantuu ja investointi ei ole enää kannattava eikä järkevä.

 

[Halpuuttaja]

Näinhän se on. Mutta täytyy hyödyntää niitä mitä on. Jos ostaa Halon integroiduilla nopeilla muistella hinta tuplaantuu ja investointi ei ole enää kannattava eikä järkevä.

Missasin jotenkin että sulla oli tosiaan paljon muistia jo entisestään.

---

Mira Muratin (ex-OpenAI) Thinking Machinesilta julkaistiin juuri Inkling-Small joka on kooltaan erittäin lähellä DS4 Flashiä, 276B ja 12B aktiivisena tokenia kohden. Pistelin pikaisesti IQ3_S GGUF:n testiin ja 11-12t/s pyörittääpi, tosin toi llama.cpp tuki vähän työn alla vissiin vielä.

Introducing Inkling-Small

An open-weights model that matches Inkling at a quarter of the size: multimodal, Mixture-of-Experts, with controllable reasoning effort. Fine-tune it on Tinker.

thinkingmachines.ai

 

[finWeazel]

Asensin poolsiden haarniskan ja testailen laguna-s-2.1:q4_K_M. Oli ihan helppo saada toimimaan, tuntuu samalta kuin claudecode vajaa vuosi sitten. Kone puhisee kuin viimeistä päivää ja jossain määrin hitaasti etenee. Kyllä tuolla kuitenkin saa aikaiseksi jos ei halua pilvestä maksaa.

haarniska: GitHub - poolsideai/pool: pool is Poolside’s coding agent that runs in your terminal or integrates with any ACP-compatible editor

Tiukille menee, mutta muisti riittää. Ollappa nvfp4:sta tukevaa rautaa isolla muistilla. 5090 ei riitä tän kanssa.

 

[finWeazel]

Ei tullut valmista webbisivusta poolside+laguna-s-2.1:q4_K_M. kompasteli pikku-asioihin niin kuvien katsominen vr-kypärässä ei alkanut toimimaan. Vaikka token/s eval-rate 47token/s niin on niin hidasta iteroida että ennemmin ranteet vedän auki kuin jatkan tuolla iteroimista. Time to first token karkaa avaruuteen kun projektissa on vähänkään enempi koodia. En usko että 5090:enkaan nopeudella jaksaisi tuota käyttää kuin pikkuskriptien tekemiseen missä odotusajat inhimilliset.

Sinällään kyllä hyvä parannus vanhaan lokaaliin mitä saanut ajoon. Hyvinkin samassa tasossa missä pilvi oli vuosi sitten. Vaatii paljon käsin tunkkaamista ja odottelua jos mitään haastavampaa yrittää. Suurin itku enää iteroinnin nopeus ei niinkään se etteikö saisi valmista jos jaksaa iteroida ja tuunata käsin päälle. Onneksi poolsiden tyypit sanoneet, että saavat samankokoiseen malliin vielä paljon lisää älyä. Seuraava versio testiin jahka se joskus tulee ulos.

Tästä voi kehittyä jotain mikä oikeuttaisi rtx 6090 pro:n ostamisen joskus 2028 olettaen että saadaan nopeus kohdalleen ja on aversio pilveä kohtaan että pakko ajaa lokaalisti.

 

[tauntinghistorian]

Tämän projekti on ollut itselle kyllä todella mielenkiintoinen, ja olen sen parissa oppinut paljon uutta nopeasti muuttuvalla AI-kentällä. @finWeazel esiin nostama malli on kyllä erittäin kiinnostava ja hyvä esimerkki näiden huimasta kehitysvauhdista.

<off-topic>
Inspiroiduin itse asiassa tuosta QRSPI:stä jopa siinä määrin että lähdin etsimään myös päivätyöhöni (juridiikkaan) liittyviä projekteja.
Löysinkin yhden varsin lupaavan toteutuksen, jossa lokaalia mallia käyttävä claude code täydennettiin oikeustieteeseen liittyvillä skilleillä, jotka taas kytkeytyvät MCP-servereiden kautta Suomen ajantasaiseen säädöskokoelmaan, esivalmistelutöihin ja ennakkotapauksiin.
Esittelin toteutuksen periaatteita pienehkön toimistomme osakkaille, jotka innostuivat asiasta siinä määrin että seuraavaksi odotamme 2x RTX6000Pro tilauksen saapumista käyttöönottoa varten.


</off-topic>

Jokin aika sitten kirjasin itselleni selvitettäväksi asiaksi kontekstin laajentamisen. Tämän toimituutta ajattelin testailla seuraavaksi.
Kuriositeettina alla on tämän pienen Gemma4-12B:n YaRN-skaalautuvuus vertaillen valitsimia --tensor-parallel-size=2 ja --pipeline-parallel-size=2. Tämän homman järkevyyttä voi helposti kyseenalaistaa, mutta teknisesti kiinnostaa räjähtääkö koko laite ja jollei, testata miten laadullinen suorituskyky käyttäytyy nimellisen maksimirajan jälkeen.

Tässä on vasta kyse käynnistystestistä käyttäen pelkästään kokonaislukuja YaRN-kertoimina sekä sitten serving benchmarkit molemmille, mitoituksena "4 clientia x 5 pyyntöä sekunnissa." Juuri tämän mallin kohdalla pipeline-parallelism näyttää tarvitsevan vähemmän muistia. Tuloksena on suurempi konteksti sujorituskyvyn kustannuksella.

Tensor parallelism
--tensor-parallel-size 2 --hf-overrides '{"rope_type":"yarn","factor":2,"original_max_position_embeddings":131072}'

(APIServer pid=3821) INFO 08-01 12:13:28 [model.py:1725] Using max model len 262144
(EngineCore pid=3879) INFO 08-01 12:14:56 [kv_cache_utils.py:2146] GPU KV cache size: 320,821 tokens
(EngineCore pid=3879) INFO 08-01 12:14:56 [kv_cache_utils.py:2147] Maximum concurrency for 262,144 tokens per request: 1.22x

Vrt. Pipeline parallelism
--pipeline-parallel-size 2 --hf-overrides '{"rope_type":"yarn","factor":4,"original_max_position_embeddings":131072}'

(APIServer pid=8846) INFO 08-01 12:39:36 [model.py:1725] Using max model len 524288
(EngineCore pid=8904) INFO 08-01 12:40:56 [kv_cache_utils.py:2146] GPU KV cache size: 586,940 tokens
(EngineCore pid=8904) INFO 08-01 12:40:56 [kv_cache_utils.py:2147] Maximum concurrency for 524,288 tokens per request: 1.12x

 

[El Toro]

Joko olette testailleet kauan odotettua Qwen3.8? 27B vetää melko hurjia tuloksia:

Aika käsittämätöntä, että tuommoinen pikkumalli päihittää muka jo Opus 4.6, vaikka benchmäxätty olisikin:

Itse olen testaillut 27B IQ4_XS aliagenttina, tuntuu toimivan paljon paremmin kuin 3.6.

Gemma4-12B

Gemmat on kyllä hyviä, 26B A4B ensimmäinen malli, jonka sain kirjoittamaan täydellistä suomea ja jonka kanssa paikallinen, oikeasti toimiva deep research onnistui. Pyöritän noita aina monta kierrosta parantaakseni laatua, ensin haetaan haluttu määrä faktoja, sitten tarkistetaan ne, oma kierros kieliopille jne.

 

[edup]

Joko olette testailleet kauan odotettua Qwen3.8? 27B vetää melko hurjia tuloksia:

Aika käsittämätöntä, että tuommoinen pikkumalli päihittää muka jo Opus 4.6, vaikka benchmäxätty olisikin:

Itse olen testaillut 27B IQ4_XS aliagenttina, tuntuu toimivan paljon paremmin kuin 3.6.


Gemmat on kyllä hyviä, 26B A4B ensimmäinen malli, jonka sain kirjoittamaan täydellistä suomea ja jonka kanssa paikallinen, oikeasti toimiva deep research onnistui. Pyöritän noita aina monta kierrosta parantaakseni laatua, ensin haetaan haluttu määrä faktoja, sitten tarkistetaan ne, oma kierros kieliopille jne.

unsloth/Qwen3.8-27B-GGUF:Q4_K_XL haluaa oletusasetuksilla (reasoning_effort="xhigh") käyttää ihan tolkuttoman määrän reasoning-tokeneita. Veikkaan että se on se millä nuo benchmark-pisteet on saatu ylös. Pitää jatkaa testailua "medium"-asetuksella ja katsoa että onko tuo kelvollinen sillä vai ei. Oletuseffortilla tuntuu että junnaa niin pitkään reasoningia että ei jaksa käyttää.

 

[Juhukka]

qwen3.8 on kyllä pätevä. Pitkästä aikaa lokaalia mallia testailin. Hyvin on kehittynyt suomenkieli.
Ilmaisia pilvipalveluita on niin monta että niillä pärjää hyvin ja jää lokaalit sekoilut vähemmälle. Mutta kyllä laatu on vakuuttavaa. Ihan tolkun suomea puskee ja tuntuu yhtä kyvykkäältä kun pilvi mallit. 16 gigasella näytönohjaimella vähän kestää tulokset. Tuo alkaa jo olla niin hyvä että moni varmaankin alkaa harkitsemaan palvelinkonetta rinnalle. Minäkin harkitsen.
Jään odottamaan tulisiko qwen3.8 coder versio

 

[Terozzz]

Pitää vissiin alkaa ostelemaan RTX 5060ti 16gb malleja nippu. Perskannikat ei kestä 6x 4090, sähköä kuluu niillä turhan paljon ja kun ei ole omakotitaloa missä hukkalämmön voisi kierrättää..

 

[Halpuuttaja]

Web search ja fetch työkaluja käyttäessä Qwen 3.8 27B hakee usein perusteellisesti lähdemateriaaleja ennenkuin vastaa, mistä tykkään. Tykkään myös että kirjoittaa toisinaan parin lauseen välikommentteja tool callien väliin kertoen missä mennään.

Googlen AI studion ilmaisiin malleihin olen yleensä turvautunut jos on vaikeuksia esim. asentaa/buildata joku Github projekti tms. Tämän kanssa on ekaa kertaa vähän sellainen tunne että on Gemini omalla koneella kun saa hyvin toimivia vastauksia. Toki ihan fiilispohjalta kommentoin, en ole samoja kysymyksiä rinnakkain esittänyt myös 3.6 pikkuveljelle ja Geminille ja otanta vielä pieni.

RTX 5090:llä tulee tokeneita sen verran vikkelästi ulos, että xhigh on lähes poikkeuksetta käytössä eikä tunnu hitaalta.

NInfer backendiä ja NVFP4 kvanttia käyttäen tuuttaa vielä tuntuvasti llama.cpp:tä nopeammin tokeneita. Prefill nopeus on parhaimmillaan hurjat ~7500 t/s, tosin putoaa nopeasti kontekstin kasvaessa. Llama.cpp:llä UD-Q5_K_XL:llä jäädään johonkin 3300 t/s maksimeihin, tosin ei putoa yhtä nopeasti kontekstin kasvaessa. Decode karkeasti arvioiden ehkä 50% nopeampi NInferillä kuin llama.cpp:llä (MTP molemmissa tapauksissa käytössä).

DeepSeek Harnessin otin eilen kokeiluun ja pyysin Qwen 3.8 27B:tä porttaamaan NInferin Windowsille ja hyvinhän se runsaassa tunnissa sai tehtävän maaliin asti. Koodauksesta/ohjelmistonkehityksestä en ymmärrä juuri mitään, niin en tiedä oliko haastava tehtävä vai ei. Ehkäpä olisi 3.6:llakin onnistunut yhtä ketterästi.

 

[Ashrakki]

Tuo qwen 3.8 27b thinking on aika mielenkiintoinen, joissain testeissä esim visuaalinen laatu kyllä paranee xhigh asetuksella mutta muutamissa testeissä ei väliä ks alla.
Oletteko muuten löytäneet jotain mielenkiintosia ja hyviä forkkeja?

 

[tauntinghistorian]

Joko olette testailleet kauan odotettua Qwen3.8? 27B vetää melko hurjia tuloksia:

Erinomaista, kiitos vinkistä! Näyttää kyllä mielenkiintoiselle ja [epäilyttävänkin] lupaavalle. Yritän ehtiä jossain vaiheessa tutustua lähemmin.

tool-eval-benchin avulla voi suorittaa vakioituja testejä, joten sen tilastot pitäisi olla verrattavissa.
Jos siis ennätätte ajaa esim. tuolle uudelle Qwenille näitä, viitsittekö ystävällisesti laittaa tuloksia näkyville
Omat 69 vakiotestiä sisältävät testit olen käynnistänyt komennolla tool-eval-bench --backend vllm --base-url http://iii.ppp.vvv.444:8001 --redact-url --api-key <avain> ja toistaiseksi niiden tilastot näyttävät seuraavilta. Coder-versioiden tulokset kannattaa jättää huomiotta sillä ne eivät tukeneet työkalujen käyttöä, joka on koko tool-benchin idea:

Itse ajan tätä erillisellä virtuaalikoneella, johon olen asentanut pythonin virtuaaliympäristön, asennusohjeen "development" vaihtoehdon mukaan, joka listattu myös tähän alle.
Jos kiinnostaa, niin asennus on kevyt n. 595 Mt:

git clone https://github.com/SeraphimSerapis/tool-eval-bench.git
cd tool-eval-bench
python -m venv .venv
source .venv/bin/activate
pip install -e '.[dev,perf]'

 

[tauntinghistorian]

..
Gemmat on kyllä hyviä, 26B A4B ensimmäinen malli, jonka sain kirjoittamaan täydellistä suomea ja jonka kanssa paikallinen, oikeasti toimiva deep research onnistui. Pyöritän noita aina monta kierrosta parantaakseni laatua, ensin haetaan haluttu määrä faktoja, sitten tarkistetaan ne, oma kierros kieliopille jne.

Samaa mieltä. Omalla kohdalla qrspi-workflow on toiminut minulle merkittävänä inspiraationa muihinkin projekteihin, ja sen johdannaisilla olen saanut paikallisille LLM:ille selkeyttä, enemmän faktapohjaisuutta ja tarkemmin fokusoituja työkokonaisuuksia, joista ne tuntuvat suoriutuvan vähintään tyydyttävästi.

 

[tauntinghistorian]

qwen3.8 on kyllä pätevä. Pitkästä aikaa lokaalia mallia testailin. Hyvin on kehittynyt suomenkieli.
Ilmaisia pilvipalveluita on niin monta että niillä pärjää hyvin ja jää lokaalit sekoilut vähemmälle. Mutta kyllä laatu on vakuuttavaa. Ihan tolkun suomea puskee ja tuntuu yhtä kyvykkäältä kun pilvi mallit. 16 gigasella näytönohjaimella vähän kestää tulokset. Tuo alkaa jo olla niin hyvä että moni varmaankin alkaa harkitsemaan palvelinkonetta rinnalle. Minäkin harkitsen.
Jään odottamaan tulisiko qwen3.8 coder versio

Ensimmäinen serve-bench-penkkitesti Qwen3.8-27B-AWQ:lla.
Laitteina siis 2 x 3060 RTX ja yht. 24 Gt VRAM. Mitoitin tämän testin seuraavasti: 4 käyttäjää x 5kys/sek, --max-concurrency 4 --request-rate 5

 

[Halpuuttaja]

Qwen 4 arkkitehtuurin ennakkokappale Qwen3.8-Flash-Next julkaistu avoimena mallina. 125B parametrin MoE, jossa 6B aktiivisena ja lisäksi 51B parametrin n-gram hakutaulukko. Deep-SWE 58,7 (Qwen 3.8 27B:llä 42,2).

4-bittisenä pitäis mahtua 128 Gt muistillisiin laitteisiin kuten Strix Haloon tai DGX Sparkkiin. Alkuperäset painot tosin 16-bittiset.

Qwen

Qwen offers comprehensive functionality spanning chatbot, image and video understanding, image generation, document processing, web search integration, tool utilization, and artifacts.

qwen.ai

edit: Lisätäänpä samaan viestiin, kun heti perään julkaisiin GLM-5.3-Flash.

320B, joista 18B aktiivisena. Menee jo vähän haastavammaksi tuon mahduttaminen kuluttajatason laitteisiin.

https://z.ai/blog/glm-5.3-flash

 

[Matt Damon]

Jukupekka, jos sieltä tulis coder-next-4 ja sitten noi pienemmät 9, 35 ja 27b.

 

[edup]

Qwen3.8-Flash-Next vaikuttaa todella hyvältä. On tosin toistaiseksi vielä yllättävän hidas, mutta toisaalta MTP-tuki on vielä puutteellista (tai olematonta omassa tapauksessa), eikä backendejä ole ehditty optimoida tätä silmällä pitäen. Isolla todennäköisyydellä siirtyy itsellä päivittäiseen käyttöön tämä, kunhan tuo nopeus tuosta vähän vielä nousee.

 

[tauntinghistorian]

Kuvat eivät tietysti kerro kaikkea, mutta kyllä tämä 3.8-27B on omienkin vaatimattomien testien ja mitä olen keksinyt projekteja sille tarjota, perusteella, uskomattoman pätevä apuväline.
(edit) Tällä raudalla normaali on n. 56 tok/s ("vakioiduilla" testiparameterilla). Toistaiseksi olen ajanut kaikki aiemmatkin mallit pelkästään default-arvoilla (mm. temperature, top-p, top-k). Oletusarvolla tämä uusin ehdokas pohdiskelee pitkään {"reasoning_effort": xhigh}, joka ilmenee konkreettisesti alla olevalla 69 skenaarion benchmark-testillä, joka kesti Qwen3.8:lla reilut 29 minuuttia, 2. sijan Gemma4-12B:llä alle 4 minuuttia ja kolmantena oleva Qwen3.5-9B suoritti saman hieman alle 15 minuutissa.

 

[okrasit]

Qwen3.8-Flash-Next vaikuttaa todella hyvältä. On tosin toistaiseksi vielä yllättävän hidas, mutta toisaalta MTP-tuki on vielä puutteellista (tai olematonta omassa tapauksessa), eikä backendejä ole ehditty optimoida tätä silmällä pitäen. Isolla todennäköisyydellä siirtyy itsellä päivittäiseen käyttöön tämä, kunhan tuo nopeus tuosta vähän vielä nousee.

Ihan hyvin tää tuntuu vetävän ja mtp toimii myös?

 

[tauntinghistorian]

Tuossa vielä tarkemmin testikohtaiset hylkäämiset tai vajaatulokset. Kaikki muut, mm. 1-14 olivat vihreällä, "pass."

 

[edup]

Ihan hyvin tää tuntuu vetävän ja mtp toimii myös?

Minkälaisella raudalla sä tuota ajat?

 

[okrasit]

Minkälaisella raudalla sä tuota ajat?

Pari GA100 ja muuta museoromua PLE bf16 offloadattuna rammiin ja kv-kekku bf16.

 

[polarbear62]

Qwen 4 arkkitehtuurin ennakkokappale Qwen3.8-Flash-Next julkaistu avoimena mallina. 125B parametrin MoE, jossa 6B aktiivisena ja lisäksi 51B parametrin n-gram hakutaulukko. Deep-SWE 58,7 (Qwen 3.8 27B:llä 42,2).

4-bittisenä pitäis mahtua 128 Gt muistillisiin laitteisiin kuten Strix Haloon tai DGX Sparkkiin. Alkuperäset painot tosin 16-bittiset.

Qwen

Qwen offers comprehensive functionality spanning chatbot, image and video understanding, image generation, document processing, web search integration, tool utilization, and artifacts.

qwen.ai

edit: Lisätäänpä samaan viestiin, kun heti perään julkaisiin GLM-5.3-Flash.

320B, joista 18B aktiivisena. Menee jo vähän haastavammaksi tuon mahduttaminen kuluttajatason laitteisiin.

https://z.ai/blog/glm-5.3-flash

Latasin tuon eilen ja täytyy sanoa että tämä oli aivan käsittämättömän merkittävä julkaisu. Tuo kaiken lisäksi pyörii tarvittaessa täysin ilman GPU:ta ja osan datasta voi myös offloadata SSD:lle:

unsloth/Qwen3.8-Flash-Next-GGUF · Hugging Face

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

huggingface.co

Itselläni on reilusti RAM mutta GPU on vaatimaton joten sain nyt ajetttua Q4 XL mallin hybridinä niin että VRAM ja RAM on melkein täysin käytössä ja samoin SSD offload on llama.cpp configuraatiossa auto:lla eli tarvittaessa sitäkin hyödynnetään. Kaikki prosessointi tapahtuu 100% CPU:lla ja GPU:lta käytetään vain VRAM:ia.

Saan tuolla jotain 30 tokens/second + koneen ääni ja lämmöntuotto on ehkä 10-15% siitä mitä se oli kun GPU:lla näitä ajoi aikaisemmin. Tämä käytännössä täysin uudelleen määrittelee sen mihin paikallisilla malleilla pystyy ja mitä niiden ajamiseen tarvitsee.

 

[Halpuuttaja]

Itselläni on reilusti RAM mutta GPU on vaatimaton joten sain nyt ajetttua Q4 XL mallin hybridinä niin että VRAM ja RAM on melkein täysin käytössä ja samoin SSD offload on llama.cpp configuraatiossa auto:lla eli tarvittaessa sitäkin hyödynnetään. Kaikki prosessointi tapahtuu 100% CPU:lla ja GPU:lta käytetään vain VRAM:ia.

Olettaisin että kyllä sulla GPU:n laskentatehoa tuossa myös käytetään, jos sinne VRAMiin jotain menee.

Oletusarvona llama-serverissä päällä oleva -fit ominaisuus tyypillisesti laittaa GPU:lle MoE mallista raskaimmat osat + niin paljon eksperttejä kuin VRAMiin sen jälkeen vielä mahtuu ja sitten prossulle kaikki loput ekspertit.

GPU:n käyttöaste ja tehonkulutus pysyy vaan aika matalalla koska prossun laskentateho tai keskusmuistin muistiväylä on pullonkaulana.

 

[iccb]

Onkos joku testaillut ajella Mac Mini M4 16Gb koneella jotain paikallista LLM:ää? Mitä kannattaisi lähteä koittamaan, tuntuu että vaihtoehtoja on vaikka kuinka paljon ja aika hankala muodostaa kuvaa että millä ja miten kannattaisi alotella...

 

[edup]

Latasin tuon eilen ja täytyy sanoa että tämä oli aivan käsittämättömän merkittävä julkaisu. Tuo kaiken lisäksi pyörii tarvittaessa täysin ilman GPU:ta ja osan datasta voi myös offloadata SSD:lle:

unsloth/Qwen3.8-Flash-Next-GGUF · Hugging Face

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

huggingface.co

Itselläni on reilusti RAM mutta GPU on vaatimaton joten sain nyt ajetttua Q4 XL mallin hybridinä niin että VRAM ja RAM on melkein täysin käytössä ja samoin SSD offload on llama.cpp configuraatiossa auto:lla eli tarvittaessa sitäkin hyödynnetään. Kaikki prosessointi tapahtuu 100% CPU:lla ja GPU:lta käytetään vain VRAM:ia.

Saan tuolla jotain 30 tokens/second + koneen ääni ja lämmöntuotto on ehkä 10-15% siitä mitä se oli kun GPU:lla näitä ajoi aikaisemmin. Tämä käytännössä täysin uudelleen määrittelee sen mihin paikallisilla malleilla pystyy ja mitä niiden ajamiseen tarvitsee.

Mulla taitaa nyt olla jotain hämärää tän ajossa, sillä 256 GB DDR5-6800 + RTX 6000 Ada pääsee suunnilleen samoihin ilman ssd-offloadia.

Mikä llama.cpp release sulla on käytössä ja millaisilla parametreilla?

 

[polarbear62]

Olettaisin että kyllä sulla GPU:n laskentatehoa tuossa myös käytetään, jos sinne VRAMiin jotain menee.

Oletusarvona llama-serverissä päällä oleva -fit ominaisuus tyypillisesti laittaa GPU:lle MoE mallista raskaimmat osat + niin paljon eksperttejä kuin VRAMiin sen jälkeen vielä mahtuu ja sitten prossulle kaikki loput ekspertit.

GPU:n käyttöaste ja tehonkulutus pysyy vaan aika matalalla koska prossun laskentateho tai keskusmuistin muistiväylä on pullonkaulana.

Pitää tarkastaa uudelleen kunhan pääsen koneelle. Viimeksi kun katsoin windowsin systeemin kulutusta niin GPU oli käytännössä idlenä ja kaikki 16c32t prossun ydintä oli ahkerasti töissä.

Käänsin myös llama aikaisemmin ilman CUDA eli GPU käyttö ei ole edes teoreettisesti mahdollista ja silloinkin tuo pääsi suhteellisesti erittäin kovaan 13 tks. Tuo tosin ei ole suoraan verrattavissa tuohon aikaisempaan lukuun koska tuossa llama setupissani oli muitakin puutteita.

Mulla taitaa nyt olla jotain hämärää tän ajossa, sillä 256 GB DDR5-6800 + RTX 6000 Ada pääsee suunnilleen samoihin ilman ssd-offloadia.

Mikä llama.cpp release sulla on käytössä ja millaisilla parametreilla?

SSD offload ei nosta vaan itseasiassa laskee nopeutta mutta mahdollistaa isompien mallien ajon silloin kun muisti on loppumassa.

Ajelen useita versioita. Alunperin käänsin llama version joka oli PR joka toi tuen tälle uudelle arkkitehtuurille. Nyttemmin se on jo lyöty mukaan llama pääbranchiin. Viimeksi taisin ajella Unsloth Desktop:n käyttämää sisäänrakennettua llama.cpp eli varmaan viimeisin release.

Parametrit pitää tarkastaa kunhan pääsen takaisin koneelle. Taisin viimeksi käyttää lähes Unsloth Desktopin defaultteja mutta käytin Q8 cachea ja 100k kontekstia.

 

[edup]

Käänsin myös llama aikaisemmin ilman CUDA eli GPU käyttö ei ole edes teoreettisesti mahdollista ja silloinkin tuo pääsi suhteellisesti erittäin kovaan 13 tks. Tuo tosin ei ole suoraan verrattavissa tuohon aikaisempaan lukuun koska tuossa llama setupissani oli muitakin puutteita.

SSD offload ei nosta vaan itseasiassa laskee nopeutta mutta mahdollistaa isompien mallien ajon silloin kun muisti on loppumassa.

Ajelen useita versioita. Alunperin käänsin llama version joka oli PR joka toi tuen tälle uudelle arkkitehtuurille. Nyttemmin se on jo lyöty mukaan llama pääbranchiin. Viimeksi taisin ajella Unsloth Desktop:n käyttämää sisäänrakennettua llama.cpp eli varmaan viimeisin release.

Parametrit pitää tarkastaa kunhan pääsen takaisin koneelle. Taisin viimeksi käyttää lähes Unsloth Desktopin defaultteja mutta käytin Q8 cachea ja 100k kontekstia.

Joo tiedän ettei ssd-offload nosta nopeutta vaan laskee sitä. Pointti vain oli että jotain kummallista tässä nyt mun koneella selvästi tapahtuu, koska GPU kyllä tekee työtä, ssd-offloadia ei ole vaan kaikki mahtuu RAMiin/VRAMiin, jne., eli nopeuden kuvittelisi olevan jotain vähän muuta kuin pelkällä CPU:lla ajettuna.

Itse ajanut Lemonaden kautta viimeisimmällä pre-release llama.cpp (cuda):lla.

Testasin nyt huvikseni myös viimeisimmällä cpu-releasella (b10679), ja pp tippuu täysin käyttökelvottomaan n. 50-60 t/s tasoon ja tg n. 7 t/s tasoon. Tämä unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q4_K_XL:llä.

Tämä siis Windows + Lemonade + llama.cpp, rautana 7965WX + 256 GB DDR5-6800 + RTX 6000 Ada.

Joku siis on solmussa tämän ko. mallin kohdalla, mutta mikä?

 

[finWeazel]

Onkos joku testaillut ajella Mac Mini M4 16Gb koneella jotain paikallista LLM:ää? Mitä kannattaisi lähteä koittamaan, tuntuu että vaihtoehtoja on vaikka kuinka paljon ja aika hankala muodostaa kuvaa että millä ja miten kannattaisi alotella...

Lähtisin ollama appsilla liikkeelle. Se ei ole paras/nopein/... mutta se on helpoin. Ollama täältä näkee listan malleista mitä ollamaan saa tällä hetkellä: Ollama

 

[Halpuuttaja]

Joku siis on solmussa tämän ko. mallin kohdalla, mutta mikä?

Mitkä pp & tg lukemat on kun GPU käytössä?

Ihan hatusta heitettynä koska ite taistelen tähän liittyvän ongelman kanssa juuri tällä hetkellä: kokeile --load-mode none

Oletuksena load-modelle on mmap joka tuhoaa suorituskykyä ainakin mun raudallani (5090 + 7600X + 96GB DDR5-6000)

-lm dio (none ajaa saman asian):

  Device 0: NVIDIA GeForce RTX 5090, compute capability 12.0, VMM: yes, VRAM: 32579 MiB
| model                          |       size |     params | backend    | ngl |  fa |         lm | lazy_mode  |       fitt |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | --: | ---------: | ---------- | ---------: | --------------: | -------------------: |
| qwen4exp A3B Q3_K - Medium     |  87.66 GiB |   176.94 B | CUDA       |  -1 |   1 |        dio | off        |        512 |   pp512 @ d8192 |      1256.06 ± 28.45 |
| qwen4exp A3B Q3_K - Medium     |  87.66 GiB |   176.94 B | CUDA       |  -1 |   1 |        dio | off        |        512 |   tg128 @ d8192 |         38.95 ± 0.30 |

Ilman --load-modea

  Device 0: NVIDIA GeForce RTX 5090, compute capability 12.0, VMM: yes, VRAM: 32579 MiB
| model                          |       size |     params | backend    | ngl |  fa | lazy_mode  |       fitt |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | --: | ---------- | ---------: | --------------: | -------------------: |
| qwen4exp A3B Q3_K - Medium     |  87.66 GiB |   176.94 B | CUDA       |  -1 |   1 | off        |        512 |   pp512 @ d8192 |       519.83 ± 11.19 |
| qwen4exp A3B Q3_K - Medium     |  87.66 GiB |   176.94 B | CUDA       |  -1 |   1 | off        |        512 |   tg128 @ d8192 |         32.89 ± 4.27 |

Oma murheen kryyni että vaikka llama-benchillä UD-Q4_K_XL voi ajaa tuon -lm dio päällä (pp ~900, tg ~30), niin llama-server ei suostu käynnistymään sillä asetuksella vaan vain mmap kehissä. Benchissä näkyvä pienempi Q3_K käynnistyy kyllä nätisti. Taitaa alkaa tulla 128 Gt rajat tossa jotenkin vastaan, vaikka muistia jääkin vielä yli 10 Gt vapaaksi kun UD-Q4_K_XL ladattuna mmap kehissä.

 

[edup]

Mitkä pp & tg lukemat on kun GPU käytössä?

Ihan hatusta heitettynä koska ite taistelen tähän liittyvän ongelman kanssa juuri tällä hetkellä: kokeile --load-mode none

Oletuksena load-modelle on mmap joka tuhoaa suorituskykyä ainakin mun raudallani (5090 + 7600X + 96GB DDR5-6000)

-lm dio (none ajaa saman asian):

  Device 0: NVIDIA GeForce RTX 5090, compute capability 12.0, VMM: yes, VRAM: 32579 MiB
| model                          |       size |     params | backend    | ngl |  fa |         lm | lazy_mode  |       fitt |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | --: | ---------: | ---------- | ---------: | --------------: | -------------------: |
| qwen4exp A3B Q3_K - Medium     |  87.66 GiB |   176.94 B | CUDA       |  -1 |   1 |        dio | off        |        512 |   pp512 @ d8192 |      1256.06 ± 28.45 |
| qwen4exp A3B Q3_K - Medium     |  87.66 GiB |   176.94 B | CUDA       |  -1 |   1 |        dio | off        |        512 |   tg128 @ d8192 |         38.95 ± 0.30 |

Ilman --load-modea

  Device 0: NVIDIA GeForce RTX 5090, compute capability 12.0, VMM: yes, VRAM: 32579 MiB
| model                          |       size |     params | backend    | ngl |  fa | lazy_mode  |       fitt |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | --: | ---------- | ---------: | --------------: | -------------------: |
| qwen4exp A3B Q3_K - Medium     |  87.66 GiB |   176.94 B | CUDA       |  -1 |   1 | off        |        512 |   pp512 @ d8192 |       519.83 ± 11.19 |
| qwen4exp A3B Q3_K - Medium     |  87.66 GiB |   176.94 B | CUDA       |  -1 |   1 | off        |        512 |   tg128 @ d8192 |         32.89 ± 4.27 |

Oma murheen kryyni että vaikka llama-benchillä UD-Q4_K_XL voi ajaa tuon -lm dio päällä (pp ~900, tg ~30), niin llama-server ei suostu käynnistymään sillä asetuksella vaan vain mmap kehissä. Benchissä näkyvä pienempi Q3_K käynnistyy kyllä nätisti. Taitaa alkaa tulla 128 Gt rajat tossa jotenkin vastaan, vaikka muistia jääkin vielä yli 10 Gt vapaaksi kun UD-Q4_K_XL ladattuna mmap kehissä.

Noin 500 t/s pp, ja n. 30 t/s tg. Mutta riippuu kontekstin määrästä.

Itsellä on myös tuo "--load-mode none" käytössä, mutta oon nyt jumpannut näitä asetuksia niin monta kertaa edestakaisin, että pitää varmaan testata vielä mmap päällä myös.

 

[Matt Damon]

Latasin tuon eilen ja täytyy sanoa että tämä oli aivan käsittämättömän merkittävä julkaisu. Tuo kaiken lisäksi pyörii tarvittaessa täysin ilman GPU:ta ja osan datasta voi myös offloadata SSD:lle:

unsloth/Qwen3.8-Flash-Next-GGUF · Hugging Face

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

huggingface.co

Itselläni on reilusti RAM mutta GPU on vaatimaton joten sain nyt ajetttua Q4 XL mallin hybridinä niin että VRAM ja RAM on melkein täysin käytössä ja samoin SSD offload on llama.cpp configuraatiossa auto:lla eli tarvittaessa sitäkin hyödynnetään. Kaikki prosessointi tapahtuu 100% CPU:lla ja GPU:lta käytetään vain VRAM:ia.

Saan tuolla jotain 30 tokens/second + koneen ääni ja lämmöntuotto on ehkä 10-15% siitä mitä se oli kun GPU:lla näitä ajoi aikaisemmin. Tämä käytännössä täysin uudelleen määrittelee sen mihin paikallisilla malleilla pystyy ja mitä niiden ajamiseen tarvitsee.

Tämä tässä täytyisi nyt vähän avata, kun kuulostaa kalajutulta.

Onkos joku testaillut ajella Mac Mini M4 16Gb koneella jotain paikallista LLM:ää? Mitä kannattaisi lähteä koittamaan, tuntuu että vaihtoehtoja on vaikka kuinka paljon ja aika hankala muodostaa kuvaa että millä ja miten kannattaisi alotella...

Toi 16gb on aika tiukka saada tungettua mitään tähtitieteellistä. Tämä teki aika kivasti testi pyyttonin, kunhan vain harnesissa on nettihakumahdollisuus: nitrai-research/Polaris-V1. Ilman nettihakua tulee millä vaan pikkumallilla ihan puuta heinää. Tuolta Q6: mradermacher/Polaris-V1-i1-GGUF. Malli on pikkukoodaukseen tehty tuunaus Qwen/Qwen3.5-4B:stä. Qwen/Qwen3.5-9B pohjaiset mallit on hyvä seuraava askel.

$ ./llama.cpp/build/bin/llama-server -m ~/Downloads/Polaris-V1-APEX-Balanced.gguf --host 0.0.0.0 --port 8092 -ctk q8_0 -ctv q8_0 -kvu --temp 0.6 --top-k 20 --top-p 0.95 --jinja --chat-template-file ~/Downloads/chat_template_froggeric.jinja -cram 2048 --alias Default-Mac -c 128000 -np 1 -b 2048 --batch-size 256 --ubatch-size 64 --parallel 1 --metrics.

Sitten selain http://localhost:8092/v1. Exa search mcp päälle. Ja juttelemaan. Oma macbook air m4 16gb suoltaa 22t/s lyhyellä sisällöllä.

Ja, jos toi kuulosti liian velhokieleltä niin sitten vain: Ollama.
$ ollama run NitrAI/polaris-v1

 

[Jumputin]

Tein pikaista testiä unslotin omalla apilla. 64GB ja rtx 5090. Täytyy testata q2:lla jotain projektia.

Malli ja tila	PP	TG	618 tokenin ajo
Q2 Auto → none	390,4 t/s	38,8 t/s	4,53 s
Q2 mmap	125,2 t/s	35,8 t/s	7,46 s
Q2 DirectIO	408,6 t/s	39,6 t/s	4,41 s
Q4 Auto → mmap	10,6 t/s	11,0 t/s	57,96 s
Q4 DirectIO	Ei käynnisty	–

 

[tauntinghistorian]

Pieni tilastolistaus tähän saakka (laadullisesti mitattuna) parhaista testaamistani malleista.
Parametrien lähde:

vLLM GPU Benchmark 2026: How to Measure Real Throughput | Markaicode

A verified, reproducible guide to benchmarking vLLM throughput, latency, and VRAM usage on RTX 4090 and A100 — with vLLM v0.24 requirements, official CLI commands, and no invented numbers.

markaicode.com

On tietysti olemassa raja-arvo käytettävyydelle, niin tässäkin projektissa, mutta nopeutta tärkeämpää ovat vastausten ja tool-kutsujen laadukkuus.
Toistaiseksi ainoastaan Qwen3.8-27B on ollut näistä ainoa, joka on kyennyt ratkaisemaan täysin oikein erään (kahdeksasta avoimesta vihjeketjusta koostuvan) loogisen päättelykyvyn testin, jossa varhaisia olettamia on täytynyt voida avata uudelleen. Kyseisessä testissä mallien pitää osata palata aiempiin johtopäätöksiin ja olla valmis muuttamaan niitä.
Tämä on tuntunut olevan erityisen haastavaa näille pienille malleille, ja Qwen3.8:a lukuun ottamatta kaikki muut listalla olevat ovat toisinaan jumittaneet pitkänkin ajan päättelyissään (wait, no, wait, wait, ...) ennen väärää vastausta.

 

[Leatherman]

Onkos joku saanut qwen 3.8 toimimaan järkevästi AMD:n 9070 kortilla?

Kokeilen Qwen3.8-27B-i1-IQ4_XS, eli hieman pienempi kuin originaali ja mahtuu sopivasti näyttiksen vrammiin. Mutta outputti tuntuu olevan vain about 8 tok/s. Kokeiltu myös muilla vastaavilla malleilla ja sama tulos. Kokeilin myös vaihtaa vulcan -> ROCm LM studiossa sekä disabloida MTP:n, mutta silti sama tulos.

Nuo gemma4:t pyörii tosi äkäisesti mutta ne taas on tyhmiä kuin kivi verrattuna tuohon Qwenniin...

 

[Matt Damon]

Ei ole amd itsellä, mutta toi rocm taitaa olla se taikasana. Esim toi: kingjones777/Qwen3.8-27B-ROCmFP4-STRIX-MTP-GGUF on rocm quantti. Varmaan kannattaa kääntää llama.cpp itse myös kaikki optimoinnit päällä. Ei ilman niitä tee mitään nopeammin.

 

[El Toro]

Onkos joku saanut qwen 3.8 toimimaan järkevästi AMD:n 9070 kortilla?

Pyöritin IQ4_XS heti julkaisussa n. 20 t/s, lama.cpp käänsin Codexin ohjeiden mukaan. Eli kyllä sieltä potkua löytyy lisää.

 

[TietotekniikanJermu]

Onko täällä porukalla kokemusta EXO clusterista? Itse olen aika vihreä näiden paikallisten tekoälyjen kanssa.

Minulla olisi jouten kaksi Macbook Pro M1 konetta joissa molemmissa 32GB muistia, eli nuo kun laittaisi klusteriin niin eikös siinä olisi silloin teoriassa 64GB muistia josta sitten käyttiksen tarvitsema muisti pois niin sillähän voisi saada esim. 40-50GB kokoista paikallista mallia pyörittää ja kokeilla pystyykö se auttamaan koodaamisessa ja ehkäpä jopa toimimaan agenttina jolle voi antaa koodaustehtäviä niinkuin Claudelle?

Kommentteja ja vinkkejä kaivataan, eli kannattaisiko tuota kokeilla? Ja jos niin mitä sudenkuoppia en tuossa huomannut?

 

[finWeazel]

Onko täällä porukalla kokemusta EXO clusterista? Itse olen aika vihreä näiden paikallisten tekoälyjen kanssa.

Minulla olisi jouten kaksi Macbook Pro M1 konetta joissa molemmissa 32GB muistia, eli nuo kun laittaisi klusteriin niin eikös siinä olisi silloin teoriassa 64GB muistia josta sitten käyttiksen tarvitsema muisti pois niin sillähän voisi saada esim. 40-50GB kokoista paikallista mallia pyörittää ja kokeilla pystyykö se auttamaan koodaamisessa ja ehkäpä jopa toimimaan agenttina jolle voi antaa koodaustehtäviä niinkuin Claudelle?

Kommentteja ja vinkkejä kaivataan, eli kannattaisiko tuota kokeilla? Ja jos niin mitä sudenkuoppia en tuossa huomannut?

Sudenkuoppa on se miten paljon liikennettä tulee koneiden/kiihdyttimien välille. Mallista ja jakamisen tavasta riippuen liikenne voi olla pullonkaula tai sitten ei. Tän takia nvidian dgx spark:ssa on ConnectX-7 NIC 200Gbps kahden koneen yhdistämiseksi.

 

[jkaart]

Ornith 1.5 9B on osottautunut oikein hyväksi malliksi RTX 3060 12GB ohjaimelle.
Tai ainakin oikein nättiä C koodia vääntää ESP32:lle/Arduinolle. Mikään järin nopeahan tuo ei nyt ole, mutta on se kuitenkin paljon nopeampi mitä ite olisin.
Gemma 4 12B on täys idiotti eikä saa oikein mitään muuta aikaa kuin LM Studion kaatumisen ja Qwen 3.8 9B on nopeampi kuin tuo Ornith, mutta tyhmempi.

Ja näin persaukisena ei oikein ole varaa mihinkäään 20€ tai 100€ kuukausi maksullisiin pilvi malleihin niin näillä paikallisillä on nyt mentävä...

Edit: ja on siitä paljon tultu, kun ChatGPT ei 3-4 vuotta sitten osanut sanoa C kielellä kirjotetusta koodista, että mitä lukee jollain tietyllä rivillä. Nyt paikallinen pikku malli vääntää koodia ilman mitään ongelmaa.

 

[Leatherman]

Ja näin persaukisena ei oikein ole varaa mihinkäään 20€ tai 100€ kuukausi maksullisiin pilvi malleihin niin näillä paikallisillä on nyt mentävä...

Itse siirryin noista lokaaleista noihin Opencode ilmaisiin AI malleihin omassa kevyessä käytössä. Tuo Big pickle on erinomainen ja hoitaa saman työn 100x nopeempaa mitä esim tollainen paikallinen Qwen jauhaisi omalla 9070:lla.

Eli suosittelen testaamaan noita ilmais pilvimalleja:

Codexilla on toi GPT 5.6 Terra ilmaisena, mutta se resettaa vain kerran kuussa ja tokenit menee turhan nopeasti. Mutta noilla Opencode:n Big Picklellä ei ole vielä kertaakaan Tokenit loppuneet, luulis kuitenkin että joku limitti siinä olisi.

 

[jkaart]

Itse siirryin noista lokaaleista noihin Opencode ilmaisiin AI malleihin omassa kevyessä käytössä. Tuo Big pickle on erinomainen ja hoitaa saman työn 100x nopeempaa mitä esim tollainen paikallinen Qwen jauhaisi omalla 9070:lla.

Eli suosittelen testaamaan noita ilmais pilvimalleja:

Codexilla on toi GPT 5.6 Terra ilmaisena, mutta se resettaa vain kerran kuussa ja tokenit menee turhan nopeasti. Mutta noilla Opencode:n Big Picklellä ei ole vielä kertaakaan Tokenit loppuneet, luulis kuitenkin että joku limitti siinä olisi.

Tulipahan tässä nyt testattua nyt tuota Big Picklea samoilla agenteilla kuin tota Ornithia.
Tosiaan hoitaa saman työn + kasan extraa ja välistä jättää noteeraamatta sille annettuja ohjeita.

 

[MiikkaIii]

Tulipahan tässä nyt testattua nyt tuota Big Picklea samoilla agenteilla kuin tota Ornithia.
Tosiaan hoitaa saman työn + kasan extraa ja välistä jättää noteeraamatta sille annettuja ohjeita.

Muse Spark 1.3 (raha)maksuton jos maksat no datallasi

 

[tauntinghistorian]

Ornith 1.5 9B on osottautunut oikein hyväksi malliksi RTX 3060 12GB ohjaimelle.
Tai ainakin oikein nättiä C koodia vääntää ESP32:lle/Arduinolle. Mikään järin nopeahan tuo ei nyt ole, mutta on se kuitenkin paljon nopeampi mitä ite olisin.
Gemma 4 12B on täys idiotti eikä saa oikein mitään muuta aikaa kuin LM Studion kaatumisen ja Qwen 3.8 9B on nopeampi kuin tuo Ornith, mutta tyhmempi.

Ja näin persaukisena ei oikein ole varaa mihinkäään 20€ tai 100€ kuukausi maksullisiin pilvi malleihin niin näillä paikallisillä on nyt mentävä...

Edit: ja on siitä paljon tultu, kun ChatGPT ei 3-4 vuotta sitten osanut sanoa C kielellä kirjotetusta koodista, että mitä lukee jollain tietyllä rivillä. Nyt paikallinen pikku malli vääntää koodia ilman mitään ongelmaa.

Kuulostaa mielenkiintoiselle tuo Ornith-1.5. Olisiko mahdollista ajaa sille tool-eval-bench miel. näillä parametreilla , tietysti sitten oikealla backendillä.
Qwen 3.8-9B:stä en ollutkaan tietoinen

 

[jkaart]

Kuulostaa mielenkiintoiselle tuo Ornith-1.5. Olisiko mahdollista ajaa sille tool-eval-bench miel. näillä parametreilla , tietysti sitten oikealla backendillä.
Qwen 3.8-9B:stä en ollutkaan tietoinen

Mites tosta benchmarkista saa tuon leaderborading näkyviin?
tool-eval-bench --leaderboard komento tulostaa mulla vaan: No valid results found.

Edit: ja siinä tolle Qwenille:

 

[Plasmid]

En vielä kysele vinkkejä mutta onhan tää paikallinen käyttö sekava soppa.. eri googletukset, youtube, gemini kyselyt antaa vaikka mitä työkalua.. hankala erottaa mitä tarvii mihinkin. LLM stdiolla helppo leikkiä mutta unsloth studio tuntuu enemmän saavan aikaan.. mutta se konteksti pituus tuntuu olevan pullonkaula tässä yksinkertasesessa käpistelyssä oikeiden asetusten kanssa (esim. mikä balanssi 96gig päämuisti ja 16gig rtx5060ti.. toivon että se jossain esitelty nvme - perusmuisti - vram putki alkaisi nostaa päätään.. ei jumisi niin nykyiseen monoliitti ajatusmaailmaan)

 

[jal88]

Ei noissa tietääkseni oikein ole sellaista suoraa laskukaavaa että mikä toimii parhaiten milläkin eri kokoonpanolla, kokeilemalla sen joutuu vielä melkeenpä tekemään.

Yksi mitä voit koettaa on llamacpp, sitä itse käytän pelkästään. LM studio on kai rajapinta sille? Voit komentoriviltä käynnistää millä asetuksilla vaan llama-server, tahi etenkin tuohon hyvien asetusten etsintään llama-bench. Voit esim claudecode tai opencode agentin laittaa testaamaan eri variaatiot läpi ja tekemään sinulle selkeät taulukot. Eli siis käytän niin että llama-server tarjoilee mallin localhostissa openai yhteensopivana rajapintana, sen kanssa voit käyttää ihan mitä vaan mikä tukee standardia rajapintaa, opencode, openclaw jne

llama.cpp/tools/server/README.md at master · ggml-org/llama.cpp

LLM inference in C/C++. Contribute to ggml-org/llama.cpp development by creating an account on GitHub.

github.com

 

[tauntinghistorian]

Kiitokset tuloksista.
Kuvissa pisti silmään neljä molemmilla malleilla samalla tavoin väliin jäänyttä skenaariota. "(infrastructure failure)." Näkyiköhän testin aikana selitettä tai syytä näille?
Tuon jälkimmäisen testaamasi mallin (Qwen) tapauksessa suosittelen tsekkaamaan seuraavat chat-templatet. Niistä voi olla hyötyä etenkin agentic-ajossa ja siten myös tässä benchmarkissa. Kokeilu on ainakin nopeaa. Jälkimmäisessä linkissä näkyi olevan ohjeet llama.cpp, llama-server, LM studio, SGLang, MLX, vLLM:

(1) vLLM-Qwen3-3.5-3.6-chat-template-fix
(2) Fixed jinja chat templates for Qwen 3.5, 3.6 & 3.8 (v22.5)

Ornith taitaa käyttää omaa räätälöityä chat-templatea, mutta jos olen ymmärtänyt oikein, sekin olisi Qwenin johdannainen? Näin ollen ym. templatet saattaisivat olla yhteensopivia myös sen kanssa.

 

[lemale01]

Ohjattiin tänne kysymään tekoäly keskustelusta aiva vaan vähä tollasta kuvien analysointia, tyyliin ku laittaa kuvia, niin esimerkiksi pelissä ”miten, mikä, miksi, mistä ja mitä” tyyppisesti, että kunhan niitä kuvia sais vähä enemmän ku ilmasella gpt:llä. Mulla ei oo kyllä harmaata hajuakaan mistää koodausjutuista, niin voi olla, että turhaan kyselen Mutta meinattiin, että "Nopeasti kerrottuna omalla koneella saat tuon aikaiseksi ns. loputtomasti tokeneita pelkällä sähkön hinnalla."

Entiä tarviiko koneen specsejä antaa, mutta

32gb ram cl30
9070xt oc,
9800x3d