- Mallorcán mutatja be az Oppo legújabb európai kameratelefonjait
- Az Apple Watchok gyenge javíthatósága már jogi kérdéseket is érinthet
- Történelmi fordulat: a Qualcomm fog Huawei licencért fizetni
- Megérkezett a Garmin Enduro 4, vele együtt bemutatkozott az Approach S72 is
- Három színben érkezik a Red Magic 12 Pro+, a kamerák már nem állnak ki
- Megvan a OnePlus 16 egyik fő aduja: jóval nagyobb akkumulátor érkezik
- iPhone topik
- Okosóra és okoskiegészítő topik
- Milyen okostelefont vegyek?
- Huawei Watch GT 6 és GT 6 Pro duplateszt
- EarFun Air Pro 4+ – érdemi plusz
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- TCL P80 Ultra – könyvmolyképző
- Megérkezett a Garmin Enduro 4, vele együtt bemutatkozott az Approach S72 is
- Yettel topik
Új hozzászólás Aktív témák
-
És jól működik magyar hanggal is? Whisper large v3 magyar LoRa fine tune? Hogyan paraméterezted és promptoltad?
Én is próbáltam már hasonlót, nekem nem voltak jó eredményeim vele. Transcript tele volt hibával.
Ide feltöltöttem a leiratot, amit a magyar nyelvű ( [link] ) videóból készített, külön mappában van a zip-en belül a lokális modellel, és a felhős modellel készített.
Az összefoglalót mindkét esetben a helyi qwen3.8 27B készítette a leiratból. Csak utóbbit olvastam el, a leiratba belepörgettem, de szerintem jó lett, nem találtam benne hibát. Mondjuk a videót nem láttam mellé
Innentől az AI mondja el a többi kérdésre a választ:
Egyik átírómodellt sem promptoltam: sem a Whisper, sem az AssemblyAI nem kap szöveges utasítást vagy szójegyzéket, csak paramétereket. Az egyetlen valódi prompt a Hermes skill (
SKILL.md), ami a Qwennek mondja meg, hogyan készítsen összefoglalót az átiratból.Helyi mód (WhisperX)
A hang a yt-dlp-vel letöltött legjobb hangsáv, vagy a feltöltött fájl. Ezt a WhisperX 16 kHz-es mono hanggá alakítja.
LépésHívás és paraméterekÁtírásload_model(modell, eszköz, compute_type, language, threads), majdtranscribe(audio, batch_size, language)Modelllarge-v3(alap) vagylarge-v3-turbo, kérésenkéntPontosságGPU-nfloat16, CPU-nint8KötegméretGPU-n 8, CPU-n 4SzálakCPU-n a fizikai magok számaNyelva megadott kód (hu,en), vagy üresen hagyva, ekkor a Whisper a hang elejéből ismeri felIdőzítésload_align_model(nyelv)a WhisperX nyelvenkénti alapmodelljével (magyarrajonatasgrosman/wav2vec2-large-xlsr-53-hungarian), karakterszintű időzítés nélkülBeszélőfelismeréspyannotespeaker-diarization-community-1, HF tokennel; a--speakersértékenum_speakers-ként, a tartománymin_speakers/max_speakers-ként megy átCímkék a szöveghezassign_word_speakers(fill_nearest=True), így az átfedés nélküli mondat is a legközelebbi beszélőt kapjaA WhisperX többi beállítása alapértéken maradt. A dokumentációja szerint ilyenkor a beszédszakaszokat hangaktivitás-felismerés (VAD) választja le, és a
condition_on_previous_textki van kapcsolva, ami csökkenti a kitalált szöveget. Az eszközválasztás: ha a GPU-n legalább 7000 MB szabad (szükség esetén a Qwen kiürítése után), akkor GPU, különben CPU.Felhős mód (AssemblyAI)
A hangot a szolgáltatás először 16 kHz-es mono FLAC-fájllá alakítja ffmpeg-gel, és ezt tölti fel a/v2/uploadvégpontra. Utána a/v2/transcriptkérés törzse:
MezőÉrtékaudio_urla feltöltés címespeech_modelsegyelemű lista:universal-2vagyuniversal-3-5-prospeaker_labelstrue, ha kell beszélőfelismerésspeakers_expecteda--speakersértéke, ha meg van advaspeaker_optionsmin_speakers_expected/max_speakers_expectedtartománynállanguage_code+language_detection: falseha megadtad a nyelvetlanguage_detection: trueha nem adtad megpunctuate,format_textmindkettőtrueAz
automodell akkor választja auniversal-3-5-pro-t, ha a megadott nyelv a 18 támogatott nyelve között van; magyarnál és automatikus nyelvfelismerésnél auniversal-2-t. Az állapotot 3 másodpercenként kérdezi le, legfeljebb 60 percig, a végén pedig törli az átiratot és a feltöltött hangot a szolgáltatónál.A válasz szavaiból (ezredmásodpercek másodpercre váltva) a szolgáltatás maga állítja össze a mondatokat. Új sort kezd beszélőváltásnál, mondatvégi írásjel után, 220 karakter vagy 15 másodperc fölött.
Közös utófeldolgozás
Címkék: a nyers azonosítókat (SPEAKER_00vagyA,B) az első megszólalás sorrendjében „Szereplő N"-re nevezi át magyar, „Speaker N"-re más nyelvnél.
Hiányzó címke: a beszélő nélküli mondat az előző beszélőt örökli.
Olvasható átirat: az egymást követő azonos beszélős mondatokat bekezdésekbe vonja össze, legfeljebb 900 karakterig vagy 20 másodperces szünetig.Az egyetlen valódi prompt: az összefoglaló
ASKILL.mdangol nyelvű utasításai a Qwennek szólnak:
az egész átiratot olvassa végig, ne darabokban összegezzen; a felhasználó nyelvén válaszoljon, a videó nyelvétől függetlenül; adja meg az alapadatokat, 5–10 mondatos összefoglalót, időbélyeges főbb pontokat, és beszélőnként egy sort; a „Szereplő N" címkéket tartsa meg, nevet csak akkor írjon melléjük, ha az átiratból egyértelmű, a videó címéből soha ne találgasson; a 2% alatti részesedésű beszélőnél jelezze, hogy az valószínűleg hibás szétválasztás.Ha a pontosságon javítani akarsz, a Whispernek van
initial_promptlehetősége: egy rövid szöveg a várható nevekről, szakszavakról vagy stílusról, amit a WhisperX azasr_options-ön keresztül átad. Ezt nem kötöttem be. Hogy az AssemblyAI-nak van-e ehhez hasonló lehetősége, annak nem néztem utána. -
Youtube videóknál nem mindegyiknél alapból ott van az átirat?
Nem, nem minden YouTube-videónál áll alapból rendelkezésre átirat/felirat. Ez pontosan ezért nem tudtam korábban feldolgozni a megadott videót.
## Mikor hiányzik a felirat
Az automatikus feliratok (ASR – Automatic Speech Recognition) generálása számos tényezőtől függ, és nem garantált minden feltöltött videóhoz:
- **Nyelvi korlátozás** – az automatikus feliratozás csak bizonyos nyelveken működik (kb. 60+ nyelv, köztük a magyar is támogatott, de korlátozottan).[1][2]
- **Rossz hangminőség vagy felismerhetetlen beszéd** – ha a YouTube nem tudja jól felismerni a beszédet, nem készül felirat.[1][3]
- **Hosszú csendes szakasz** a videó elején zavarja a feldolgozást.[1][3]
- **Több beszélő egyszerre**, vagy **több nyelv** keveredése a videóban.[1][3]
- **Túl hosszú videó**, vagy a feldolgozás még nem fejeződött be (friss feltöltés esetén akár órákat, napokat is igénybe vehet).[3][4]
- Ha a feltöltő **letiltotta** a feliratokat, vagy **lenémítva** töltötte fel a hangsávot, egyáltalán nem készül automatikus felirat.[5]## Magyar nyelvű videók speciális helyzete
Magyar nyelvű tartalmaknál a felhasználói visszajelzések szerint az automatikus felirat és fordítás gyakran egyáltalán nem elérhető, még akkor sem, ha a nyelv technikailag támogatott a listában. Az automatikus fordítás is csak ott működik megbízhatóan, ahol a feltöltő **saját, hivatalos feliratot** töltött fel – ott a fordítás funkció is aktiválódik, különben kétesélyes.[5][6]
Tehát ha egy videónál a CC gomb szürkén jelenik meg (nem kattintható), az azt jelenti, hogy nincs se feltöltött, se automatikusan generált felirat, és így átirat sem áll rendelkezésre a tartalom kinyeréséhez.
-
Érdekes, mert a videód a ChatGPT-vel tényleg nem megy, pedig ma reggel pont összefoglaltattam vele egy 2 órás YT videót. A Gemini megcsinálta. A ChatGPT ahogy látom nem a videóból, hanem annak a transzkriptjéből dolgozik, de megpróbálta letölteni is a videót
A Gemini meg nem meglepő, hogy tudja, házon belül van....
Szerkesztem, mert amíg írtam a hozzászólást csak megugrotta a ChatGPT is. Ez az ő összefoglalójának az eleje:
Ez még a Gemini:
-
Érdekes, mert a videód a ChatGPT-vel tényleg nem megy, pedig ma reggel pont összefoglaltattam vele egy 2 órás YT videót. A Gemini megcsinálta. A ChatGPT ahogy látom nem a videóból, hanem annak a transzkriptjéből dolgozik, de megpróbálta letölteni is a videót
A Gemini meg nem meglepő, hogy tudja, házon belül van....
Szerkesztem, mert amíg írtam a hozzászólást csak megugrotta a ChatGPT is. Ez az ő összefoglalójának az eleje:
Ez még a Gemini:
És ez is megy neked chatgpt-vel?
Nekem nem.
https://youtu.be/HkPpDiOPvYg
Foglald össze magyar nyelven ennek a videónak a tartalmát.
-
Érdekes, mert a videód a ChatGPT-vel tényleg nem megy, pedig ma reggel pont összefoglaltattam vele egy 2 órás YT videót. A Gemini megcsinálta. A ChatGPT ahogy látom nem a videóból, hanem annak a transzkriptjéből dolgozik, de megpróbálta letölteni is a videót
A Gemini meg nem meglepő, hogy tudja, házon belül van....
Szerkesztem, mert amíg írtam a hozzászólást csak megugrotta a ChatGPT is. Ez az ő összefoglalójának az eleje:
Ez még a Gemini:
Jo, legalább nem feleslegesen dolgoztam vele fél napot
Meg ugye az enyém bármilyen videó és hanganyagot feldolgoz, nem csak youtubeot.
Amúgy valaki korábban mintha ilyet keresett volna, hogy a megbeszélés hanganyaga egyezik-e pontosan a leírt szöveggel.
-
Pl ez chatgpt-vel nem megy. Claude sonnet a perplexity belül viszont megcsinálta.
https://youtu.be/GkC-3dYGZfA
Foglald össze magyar nyelven ennek a videónak a tartalmát.Nektek igen?
Azt írja hogy
A videó címe: „Drinking More Water Is Making Your Thirst Worse” („A több víz fogyasztása rosszabbá teszi a szomjúságodat”).Viszont a YouTube-oldalról jelenleg nem kapom meg a videó hanganyagának vagy feliratának szövegét, ezért nem lenne korrekt úgy tenni, mintha a teljes videót meg tudtam volna hallgatni.
Ha elküldöd a videó feliratát / transcriptjét (akár bemásolva, akár fájlként), akkor részletesen összefoglalom magyarul, és külön kiemelem:
a videó fő állítását,
milyen élettani magyarázatot ad,
milyen bizonyítékokra hivatkozik,
mi belőle tudományosan megalapozott,
és mely állításokat érdemes fenntartással kezelni.
Másodjára már a Claudenak se ment:
Érdekes, mert a videód a ChatGPT-vel tényleg nem megy, pedig ma reggel pont összefoglaltattam vele egy 2 órás YT videót. A Gemini megcsinálta. A ChatGPT ahogy látom nem a videóból, hanem annak a transzkriptjéből dolgozik, de megpróbálta letölteni is a videót
A Gemini meg nem meglepő, hogy tudja, házon belül van....
Szerkesztem, mert amíg írtam a hozzászólást csak megugrotta a ChatGPT is. Ez az ő összefoglalójának az eleje:
Ez még a Gemini:
-
Pl ez chatgpt-vel nem megy. Claude sonnet a perplexity belül viszont megcsinálta.
https://youtu.be/GkC-3dYGZfA
Foglald össze magyar nyelven ennek a videónak a tartalmát.Nektek igen?
Azt írja hogy
A videó címe: „Drinking More Water Is Making Your Thirst Worse” („A több víz fogyasztása rosszabbá teszi a szomjúságodat”).Viszont a YouTube-oldalról jelenleg nem kapom meg a videó hanganyagának vagy feliratának szövegét, ezért nem lenne korrekt úgy tenni, mintha a teljes videót meg tudtam volna hallgatni.
Ha elküldöd a videó feliratát / transcriptjét (akár bemásolva, akár fájlként), akkor részletesen összefoglalom magyarul, és külön kiemelem:
a videó fő állítását,
milyen élettani magyarázatot ad,
milyen bizonyítékokra hivatkozik,
mi belőle tudományosan megalapozott,
és mely állításokat érdemes fenntartással kezelni.
Másodjára már a Claudenak se ment:
-
Kezdett elegem lenni abból, hogy a 10-20 perces YT videók mondanivalója valójában 30 másodperc olvasással letudható lenne, így elkészült ez:
A feladat az volt, hogy YouTube-videókból (angol és magyar) beszélőnként címkézett feliratot és összefoglalót tudj készíteni a saját, egy RTX 3090-es gépeden futó helyi modellekkel.
Erre elkészült a
yt-transcribe: egy Docker-szolgáltatás az Unraid szerveren és egy hozzá tartozó Hermes skill a Windows gépeden.A szolgáltatás letölti a videó hangját, átírja, „Szereplő 1, Szereplő 2" címkékkel szétválasztja a beszélőket, és TXT-, SRT- és JSON-fájlt ad vissza.
A skill ezt meghívja, majd a Qwen megírja belőle az összefoglalót.
Az átírás kétféle módban futhat, kérésenként választhatóan.
1. Helyi módban a Whisper (large-v3vagylarge-v3-turbo) és a pyannote dolgozik a GPU-n: ehhez a szolgáltatás a munka idejére kiüríti a Qwent a llama-serverből, a végén pedig visszatölti.
2. Felhős módban az AssemblyAI végzi az átírást (universal-2vagyuniversal-3.5-pro), a GPU érintése nélkül, így a Qwen végig betöltve marad.Az alapértelmezés a helyi mód, a felhő csak kifejezett kérésre indul, a kettő között nincs csendes átváltás, és a felhős használatot havi órakeret korlátozza.
A forrás videó-URL mellett helyi hang- vagy videófájl is lehet, és ugyanaz a videó mindkét módban átíratható összehasonlításra.
Egy 9:37 hosszú YT videó felhős leiratozása 0,034$-ba került, ez kb. 11Ft. Ráadásul 50$-t ingyen kapsz az elején!
A helyi mód meg áramköltséget igényel csak. -
Kezdett elegem lenni abból, hogy a 10-20 perces YT videók mondanivalója valójában 30 másodperc olvasással letudható lenne, így elkészült ez:
A feladat az volt, hogy YouTube-videókból (angol és magyar) beszélőnként címkézett feliratot és összefoglalót tudj készíteni a saját, egy RTX 3090-es gépeden futó helyi modellekkel.
Erre elkészült a
yt-transcribe: egy Docker-szolgáltatás az Unraid szerveren és egy hozzá tartozó Hermes skill a Windows gépeden.A szolgáltatás letölti a videó hangját, átírja, „Szereplő 1, Szereplő 2" címkékkel szétválasztja a beszélőket, és TXT-, SRT- és JSON-fájlt ad vissza.
A skill ezt meghívja, majd a Qwen megírja belőle az összefoglalót.
Az átírás kétféle módban futhat, kérésenként választhatóan.
1. Helyi módban a Whisper (large-v3vagylarge-v3-turbo) és a pyannote dolgozik a GPU-n: ehhez a szolgáltatás a munka idejére kiüríti a Qwent a llama-serverből, a végén pedig visszatölti.
2. Felhős módban az AssemblyAI végzi az átírást (universal-2vagyuniversal-3.5-pro), a GPU érintése nélkül, így a Qwen végig betöltve marad.Az alapértelmezés a helyi mód, a felhő csak kifejezett kérésre indul, a kettő között nincs csendes átváltás, és a felhős használatot havi órakeret korlátozza.
A forrás videó-URL mellett helyi hang- vagy videófájl is lehet, és ugyanaz a videó mindkét módban átíratható összehasonlításra.
Egy 9:37 hosszú YT videó felhős leiratozása 0,034$-ba került, ez kb. 11Ft. Ráadásul 50$-t ingyen kapsz az elején!
A helyi mód meg áramköltséget igényel csak. -
> de SW téren most sokat fejlődött (Gufo, Halogen,...). A Qwen 3.8 Flash Next Q4 quant-al 1400/50 sebességgel fut 1 gépen
és most már a Strata v0.1.40 is támogatja. ("Strix Halo (gfx1151) support,")
https://github.com/Niko1221/Strata/releases/tag/v0.1.40 ( released this 3 hours ago)
"Qwen3.8-Flash-Next on any consumer hardware: one-click install for Windows / Linux. Strata inference engine, OpenAI/Anthropic API on localhost, optional image input.
Resources"
persze azóta már van: https://github.com/Niko1221/Strata/releases/tag/v0.1.40.1 -is
(released this 24 minutes ago)Láttam.
Miután felsetupoltam az összes backendet, leszedtem, egy tucat nagy modellt, és elindítottam a giga llm bechmarkot.
Érdekes, ezt a sebességet tudja, és ROCm 7.14.1 alapú? -
Sikerült működésre bírni egy 3090-en (és 64GB system RAM-on) a qwen3.8-flash-next-iq3_s -t.
A konkrét Unraid telepítési leírás itt található: [link]
Csak gyorstesztek voltak, de kb. 60tok/s sebességet produkál, képeket is felismer, ezt CPU-val is gyorsan csinálja, nem kell feltétlen GPU-ra állítani:
Még a toolkezelést, és a VsCode/Opencode -dal nem próbáltam, ha lesz időm, akkor majd összevetem ugyanazon feladatokkal a Qwen 3.6 35B A3B, és Qwen3.8 27B-vel.
Esetleg tudom máshogy is tesztelni, van valamiféle "gyorsteszt-halmaz", ami lemér egy-két fontos paramétert? Nem csináltam még ilyet.
-
S_x96x_S
veterán
Grok, de néha olyan dolgokat csinál hogy egy embert ezért már rég kirúgnának 😁
35. alkalommal megtudta csinálni azt ami 50 perccel korábban ment neki vagy 10x
Lehet ez már a kivan f.... mindennel fázis ott?> Grok, de néha olyan dolgokat csinál hogy egy embert ezért már rég kirúgnának
De pontosan:
- milyen csomag ( előfizetés ? )
- melyik Grok verzió ? ( 4.1, ... 4.4, 4.5, 4.6, 4.7 )
- melyik harness ( https://x.ai/build , vagy az opencode , vagy a `pi` .... )
- ha meg VScode -ban extension-ként használod, akkor érdemes megnézni/upgradelni az extension-t, nehogy valami régi grok modellen legyen beragadva.Például a Pi a konfigurálható modellek között látható Grok 4.1 ... Grok 4.7 -ig
https://pi.dev/models?name=grok
és a Grok 4.7 (Oct 03, 2026) a legutolsó és azt érdemes használni
https://grok.com/release-notes
( és nem a Grok 4.20 ( Mar 03, 2026)![;]](//cdn.rios.hu/dl/s/v1.gif)
ami egy normális verziózás esetén logikus lenne ) -
Nem merek betenni képet, de kollégámnak az Claude+Opus pont a múlt héten törölte le az egyik mappáját, mert azt hitte, hogy csak a saját temp dolgait törli, csak hát volt ott korábbról olyan is, amit nem az AI csinált....
furcsa,
- ha szerinte bug, akkor jelenteni kellene az issue-t
- ha beállítási probléma, akkor talán a jobb temp sandboxolással meg lehet előzni.
https://code.claude.com/docs/en/sandboxing
- és nem árt egy külső sandboxolás se.persze gondolom a lényeg, hogy sose bizd rá az életedet az AI-ra vagy a saját programozói tudásodra, mert ezekkel az eszközökkel könnyű megvágni magunkat.
---
#5503 Reggie0 "éles szerver"
Más a fejlesztés és más az üzemeltetés. ( főleg több terrás adatbázisok esetén, amikor egyes problémák csak az éles környezetben jelentkeznek. ) -
aprokaroka87
nagyúr
Amúgy milyen AI-t és harness-t használsz?
> Egy módosítás kérése után lett baj, valószínűleg nem tudta belerakni a kódba és hát annyi lett az egész kódnak 😁
Együttérzésem.
Amúgy ilyen probléma több mint 1 éve gyakran előfordult,
de újabban már elég jók a SOTA kódolos modellek ( claude code + Opus 5.5 )
és én nem is nagyon emlékszem hasonlóra.Érdemes lehet
- külön git worktree -kel dolgozni
- és minden worktree - környezetet külön docker konténerben futtatni.
- esetleg még az agent-et is érdemes lehet korlátozni
( pl. https://github.com/NVIDIA/OpenShell )
- És nem árt néhány jó SKILL is, ami leirja, hogy hogyan tesztelje a rendszert.> Ameddig olyan amatőr hibák előfordulnak hogy egyszer csak elveszik a szerverről egy fájl amire szükséged van addig nem kell itt félni hogy az AI mindenkit kivégez 😁
Amúgy éles szervert én nem merek még AI agenssel módosítgatni.
--egy kis nyugtató zene ...
ANY DAY NOW- The robots are coming (SLOPCORE)
( Claude Opus 5.5 ) -
Amúgy milyen AI-t és harness-t használsz?
> Egy módosítás kérése után lett baj, valószínűleg nem tudta belerakni a kódba és hát annyi lett az egész kódnak 😁
Együttérzésem.
Amúgy ilyen probléma több mint 1 éve gyakran előfordult,
de újabban már elég jók a SOTA kódolos modellek ( claude code + Opus 5.5 )
és én nem is nagyon emlékszem hasonlóra.Érdemes lehet
- külön git worktree -kel dolgozni
- és minden worktree - környezetet külön docker konténerben futtatni.
- esetleg még az agent-et is érdemes lehet korlátozni
( pl. https://github.com/NVIDIA/OpenShell )
- És nem árt néhány jó SKILL is, ami leirja, hogy hogyan tesztelje a rendszert.> Ameddig olyan amatőr hibák előfordulnak hogy egyszer csak elveszik a szerverről egy fájl amire szükséged van addig nem kell itt félni hogy az AI mindenkit kivégez 😁
Amúgy éles szervert én nem merek még AI agenssel módosítgatni.
--egy kis nyugtató zene ...
ANY DAY NOW- The robots are coming (SLOPCORE)
( Claude Opus 5.5 ) -
Amúgy milyen AI-t és harness-t használsz?
> Egy módosítás kérése után lett baj, valószínűleg nem tudta belerakni a kódba és hát annyi lett az egész kódnak 😁
Együttérzésem.
Amúgy ilyen probléma több mint 1 éve gyakran előfordult,
de újabban már elég jók a SOTA kódolos modellek ( claude code + Opus 5.5 )
és én nem is nagyon emlékszem hasonlóra.Érdemes lehet
- külön git worktree -kel dolgozni
- és minden worktree - környezetet külön docker konténerben futtatni.
- esetleg még az agent-et is érdemes lehet korlátozni
( pl. https://github.com/NVIDIA/OpenShell )
- És nem árt néhány jó SKILL is, ami leirja, hogy hogyan tesztelje a rendszert.> Ameddig olyan amatőr hibák előfordulnak hogy egyszer csak elveszik a szerverről egy fájl amire szükséged van addig nem kell itt félni hogy az AI mindenkit kivégez 😁
Amúgy éles szervert én nem merek még AI agenssel módosítgatni.
--egy kis nyugtató zene ...
ANY DAY NOW- The robots are coming (SLOPCORE)
( Claude Opus 5.5 ) -
S_x96x_S
veterán
Oké de ilyennekel miért kell cseszekedni?
pár tíz kilobájtos fájlok..
Én értem hogy a kódolás egy komplex dolog még az AI számára is, de jussunk már el oda hogy ha valami nem megy neki akkor írja le.
Egy módosítás kérése után lett baj, valószínűleg nem tudta belerakni a kódba és hát annyi lett az egész kódnak 😁Amúgy milyen AI-t és harness-t használsz?
> Egy módosítás kérése után lett baj, valószínűleg nem tudta belerakni a kódba és hát annyi lett az egész kódnak 😁
Együttérzésem.
Amúgy ilyen probléma több mint 1 éve gyakran előfordult,
de újabban már elég jók a SOTA kódolos modellek ( claude code + Opus 5.5 )
és én nem is nagyon emlékszem hasonlóra.Érdemes lehet
- külön git worktree -kel dolgozni
- és minden worktree - környezetet külön docker konténerben futtatni.
- esetleg még az agent-et is érdemes lehet korlátozni
( pl. https://github.com/NVIDIA/OpenShell )
- És nem árt néhány jó SKILL is, ami leirja, hogy hogyan tesztelje a rendszert.> Ameddig olyan amatőr hibák előfordulnak hogy egyszer csak elveszik a szerverről egy fájl amire szükséged van addig nem kell itt félni hogy az AI mindenkit kivégez 😁
Amúgy éles szervert én nem merek még AI agenssel módosítgatni.
--egy kis nyugtató zene ...
ANY DAY NOW- The robots are coming (SLOPCORE)
( Claude Opus 5.5 ) -
Hát én maradok a Qwen3.8-27B-nél a flash-next helyett. A Qwen3.6 35B sebessége jó lenne, de sajna a 27B jóval lassabb.
## 13. Mérés tool-eval-bench-csel
A tool-eval-bench 69 determinisztikus forgatókönyvvel méri az eszközhívás minőségét bármilyen OpenAI-kompatibilis végponton. Ezzel készült a modellek összehasonlítása, és ebből jött az ismétlésfék és a közepes gondolkodási szint.
### Eredmények (2026-10-05)
Minden futás 0-s hőmérsékleten, 42-es seeddel, egyszer futott. A „közös 64 feladat" azokat jelenti, amelyeket minden modellnél pontozott az eszköz, a szerverhibás feladatok nélkül.
| Modell és beállítás | Közös 64 feladaton | Sikeres / részleges / sikertelen | Nehéz feladatok | Kontextus és állapot | Futási idő | Medián köridő | Generált szöveg (karakter) |
|---|---|---|---|---|---|---|---|
| Qwen3.8-27B, közepes szint | 96,1% | 60 / 3 / 1 | 14 / 17 | 100% | 16 perc | 4,0 s | 98 ezer |
| ThinkingCap-Qwen3.8-27B, közepes szint | 96,1% | 60 / 3 / 1 | 15 / 17 | 95% | 14,3 perc | 3,7 s | 85 ezer |
| Flash-Next (Strata), közepes szint, fékkel | 90,6% | 56 / 4 / 4 | 11 / 17 | 100% | 12 perc | 3,5 s | 101 ezer |
| Qwen3.6-35B-A3B, gondolkodással | 90,6% | 55 / 6 / 3 | 12 / 17 | 75% | 5,5 perc | 1,2 s | 138 ezer |
| Qwen3.6-35B-A3B, gondolkodás nélkül | 89,8% | 55 / 5 / 4 | 12 / 17 | 85% | 2,4 perc | 0,6 s | 39 ezer |
| Qwopus3.6-35B-A3B-Coder, gondolkodás nélkül | 89,8% | 56 / 3 / 5 | 12 / 17 | 75% | 2,7 perc | 0,6 s | 46 ezer |
A Flash-Next korábbi futása magas gondolkodási szinten, ismétlésfék nélkül: 90,6%, 54 / 8 / 2, a nehéz feladatokból 8 / 17, 18,5 perc, 188 ezer karakter. Ebből a futásból derült ki a hurok és a túl hosszú gondolkodás.
A generált szöveg mennyisége a jelentések nyomkövetéseiből számolt érték, a Markdown jelentésben ilyen oszlop nincs.
A gondolkodás nélküli futásokhoz a teszt ezt a kapcsolót kapta: `--backend-kwargs '{"chat_template_kwargs": {"enable_thinking": false}}'`.
**Mit mutatnak a számok:**
- **Két csoport van:** a 27B-alapú modellek 96%-on, mindenki más 90% körül. Sem beállítás, sem finomhangolás nem vitt át modellt egyik csoportból a másikba.
- **Qwen3.8-27B:** a legfegyelmezettebb eszközhívó, agentes kódoláshoz ez az alapértelmezett.
- **ThinkingCap-Qwen3.8-27B:** azonos pontszám, 13%-kal kevesebb szöveg, 11%-kal rövidebb futás. A licence nem szabad licenc (PolyForm Small Business, személyes használatra szóló engedéllyel), ezért munkához az eredeti 27B marad.
- **Flash-Next közepes szinten:** sebességben és szövegmennyiségben egy szinten van a 27B-vel, a kontextuskezelése hibátlan. Pontot főleg kapkodás miatt veszít: függő hívásokat párhuzamosít, fölösleges hívást tesz, és a beszúrt utasítás elutasításakor idézi annak tartalmát.
- **Qwen3.6-35B-A3B gondolkodással:** gyors, de a hosszú láncokon megakad és ismétel.
- **Qwen3.6-35B-A3B gondolkodás nélkül:** ugyanannyi pont kevesebb mint feleannyi idő alatt, és az ismételgetés megszűnik. Cserébe végrehajtotta egy eszközeredménybe rejtett utasítást (TC-60), amit gondolkodással elutasított. Olvasó, alacsony kockázatú feladatokra való, levélküldéshez és webes tartalomhoz nem.
- **Qwopus3.6-35B-A3B-Coder:** ugyanazt hozta, mint a sima 35B-A3B gondolkodás nélkül, ugyanazzal a biztonsági hibával. A 21,7 GB-os fájl miatt csak 65 ezres kontextus fért el. Ebben a tesztben nem ad többet.**Amit a mérés nem mutat meg:**
- **A strukturált kimenet 50%-a minden modellnél szerverkorlát.** A llama.cpp nyelvtanhibával, a Strata „nem támogatott" hibával utasította el a sémás kérést eszközökkel együtt.
- **Egy futásból 1–2 feladatnyi különbség nem biztos.** Egy feladat kb. 1,6 százalékpont. A 27B-csoport hat pontos előnye viszont mindkét 27B-alapú futásban megjelent.
- **Nem kódolási teszt,** és a hosszú, 100 ezer token feletti kontextust sem méri. A megírt kód minőségéről, így a kódolásra hangolt Qwopusról sem mond semmit.### Tudásmérés (MMLU, 2026-10-05)
Az eszközhívási teszt a fegyelmet méri, a tudást nem. Ezért a két fő modellt az MMLU kérdéssorán is összevetettük, ugyanazzal az eszközzel.
**A futtatás.** Nyolc tárgy, 1078 kérdés, gondolkodás nélkül, mindkét modellnek ugyanazok a kérdések:
SUBJ=computer_security,college_computer_science,high_school_computer_science,machine_learning,electrical_engineering,astronomy,high_school_geography,world_religions
**Három buktató, amibe belefutottunk:**
- **A `--limit N` az első N kérdést veszi** a tárgyak ábécérendjében. A `--limit 200` így csak absztrakt algebrát és anatómiát adott. Vegyes mintához a tárgyakat kézzel kell megadni, `--limit 0` mellett.
- **Gondolkodással a válaszok egy része levágódik.** Az eszköznek nincs kapcsolója a válasz hosszkorlátjára, és a 27B 200 válaszából 34 a végső betű előtt megszakadt. A `--no-think` ezt megszünteti: az 1078 válaszból mind kiolvasható volt.
- **A `plugin` parancsnak is kell az `--output-dir /out`,** különben a jelentés a konténerrel együtt törlődik.
**Eredmény:**
| | Qwen3.8-27B | Flash-Next (IQ3_S) |
|---|---|---|
| Helyes válasz | 958 / 1078 (88,9%) | 985 / 1078 (91,4%) |
| Hibák száma | 120 | 93 |
| Futási idő | 7,3 perc | 27 perc |
Kérdésenként összevetve: 50 kérdést csak a Flash-Next tudott, 23-at csak a 27B, 70-et mindkettő elrontott. A különbség 2,5 százalékpont, a 95%-os megbízhatósági tartomány 1,0–4,1 pont, tehát valódi különbség, nem zaj.
| Tantárgy | Qwen3.8-27B | Flash-Next | Különbség |
|---|---|---|---|
| Egyetemi számítástudomány | 78,0% | 85,0% | +7,0 |
| Gépi tanulás | 77,7% | 83,9% | +6,2 |
| Világvallások | 90,6% | 93,6% | +3,0 |
| Villamosmérnöki ismeretek | 86,2% | 89,0% | +2,8 |
| Számítógépes biztonság | 88,0% | 90,0% | +2,0 |
| Középiskolai informatika | 94,0% | 96,0% | +2,0 |
| Csillagászat | 94,1% | 95,4% | +1,3 |
| Középiskolai földrajz | 94,9% | 93,9% | −1,0 |
Az egyes tárgyak 100–200 kérdésesek, ezért tárgyanként a 2–3 pontos eltérések önmagukban nem megbízhatók. Az öt technikai tárgyon együtt 88,7% áll 84,7%-kal szemben.
**Mit mutat:**
- **A Flash-Next tudásban jobb, de szerényen.** Negyven kérdésből nagyjából eggyel többre ad jó választ. Az előnye a nehezebb, szakmaibb tárgyakban a legnagyobb.
- **Sok rövid, független kérésnél a Strata lassabb.** Kérdésenként kb. 1,5 másodperc a llama.cpp 0,4 másodpercével szemben. A hosszú válaszoknál mért sebességelőny itt megfordul. Az okát nem vizsgáltuk.
- **Ez nyers tudásmérés,** gondolkodás nélkül, a 3,5 bites Flash-Nexttel az 5 bites 27B ellen. Gondolkodással valószínűleg mindkét modell jobb eredményt adna.
**A két mérés együtt:** a 27B az eszközhívásban jobb (96% a 91% ellen), a Flash-Next a tudásban (91,4% a 88,9% ellen). A 27B egyedül is védhető választás mindkét szerepre. A Flash-Nextet akkor éri meg betölteni, ha mély technikai kérdezz-felelek vagy hosszú dokumentum feldolgozása a cél.● Kész — az első teljes 69-es futás lefutott (~8 perc alatt).
Eredmény: 85/100 — ★★★★ Good
Kategóriák: 100% — Tool Selection, Parameter Precision, Multi-Step Chains, Restraint & Refusal, Localization, Structured Reasoning, Toolset Scale, Creative Composition.
Gyengébbek: Structured Output 50%, Code Patterns 67%, Safety & Boundaries 73%, Context & State 75%.A 12 bukóból 5 NEM modellhiba (a bench kizárta őket a pontozásból): TC-45 (tool_choice=required kikényszerítés) és TC-65/66/67/69 (structured output), server_error-ral álltak meg — ez a régi llama.cpp b10991-es build ismert grammatikahibája (lásd CHANGELOG v5.69 G1: a grammar/json_object ezen a builden használhatatlan).
Újabb llama.cpp builddel ezek visszanyerhetők.Valódi modellhibák (7): TC-30 (láncolt feltételes — rossz args), TC-31 (ambiguitás — feloldás nélkül küldött e-mailt), TC-33 (hallucináció-ellenállás), TC-50 (információ-felfedés), TC-59 (authority escalation — nem utasította el), TC-62 (5-fordulós research-lánc, keretkifutás), TC-68 (schema-sértés).
Részlegesek: TC-14, 22, 43, 47, 52.
Referencia: a 27B-s Qwen3.8 ugyanezen a suiton 89 (NInfer) / 97 (vLLM+froggeric template) — a 9B-s modell 85-tel jól tartja magát.
-
aprokaroka87
nagyúr
-
Reggie0
titán
Ameddig olyan amatőr hibák előfordulnak hogy egyszer csak elveszik a szerverről egy fájl amire szükséged van addig nem kell itt félni hogy az AI mindenkit kivégez 😁
Legjobb ebben az volt hogy amikor már 15x rákérdeztem hogy mivan, semmi extra.
Majd a valld be hogy elveszett a kód és vele fájl is, elmondta az igazat 😁😁😁 -
aprokaroka87
nagyúr
-
Hát én maradok a Qwen3.8-27B-nél a flash-next helyett. A Qwen3.6 35B sebessége jó lenne, de sajna a 27B jóval lassabb.
## 13. Mérés tool-eval-bench-csel
A tool-eval-bench 69 determinisztikus forgatókönyvvel méri az eszközhívás minőségét bármilyen OpenAI-kompatibilis végponton. Ezzel készült a modellek összehasonlítása, és ebből jött az ismétlésfék és a közepes gondolkodási szint.
### Eredmények (2026-10-05)
Minden futás 0-s hőmérsékleten, 42-es seeddel, egyszer futott. A „közös 64 feladat" azokat jelenti, amelyeket minden modellnél pontozott az eszköz, a szerverhibás feladatok nélkül.
| Modell és beállítás | Közös 64 feladaton | Sikeres / részleges / sikertelen | Nehéz feladatok | Kontextus és állapot | Futási idő | Medián köridő | Generált szöveg (karakter) |
|---|---|---|---|---|---|---|---|
| Qwen3.8-27B, közepes szint | 96,1% | 60 / 3 / 1 | 14 / 17 | 100% | 16 perc | 4,0 s | 98 ezer |
| ThinkingCap-Qwen3.8-27B, közepes szint | 96,1% | 60 / 3 / 1 | 15 / 17 | 95% | 14,3 perc | 3,7 s | 85 ezer |
| Flash-Next (Strata), közepes szint, fékkel | 90,6% | 56 / 4 / 4 | 11 / 17 | 100% | 12 perc | 3,5 s | 101 ezer |
| Qwen3.6-35B-A3B, gondolkodással | 90,6% | 55 / 6 / 3 | 12 / 17 | 75% | 5,5 perc | 1,2 s | 138 ezer |
| Qwen3.6-35B-A3B, gondolkodás nélkül | 89,8% | 55 / 5 / 4 | 12 / 17 | 85% | 2,4 perc | 0,6 s | 39 ezer |
| Qwopus3.6-35B-A3B-Coder, gondolkodás nélkül | 89,8% | 56 / 3 / 5 | 12 / 17 | 75% | 2,7 perc | 0,6 s | 46 ezer |
A Flash-Next korábbi futása magas gondolkodási szinten, ismétlésfék nélkül: 90,6%, 54 / 8 / 2, a nehéz feladatokból 8 / 17, 18,5 perc, 188 ezer karakter. Ebből a futásból derült ki a hurok és a túl hosszú gondolkodás.
A generált szöveg mennyisége a jelentések nyomkövetéseiből számolt érték, a Markdown jelentésben ilyen oszlop nincs.
A gondolkodás nélküli futásokhoz a teszt ezt a kapcsolót kapta: `--backend-kwargs '{"chat_template_kwargs": {"enable_thinking": false}}'`.
**Mit mutatnak a számok:**
- **Két csoport van:** a 27B-alapú modellek 96%-on, mindenki más 90% körül. Sem beállítás, sem finomhangolás nem vitt át modellt egyik csoportból a másikba.
- **Qwen3.8-27B:** a legfegyelmezettebb eszközhívó, agentes kódoláshoz ez az alapértelmezett.
- **ThinkingCap-Qwen3.8-27B:** azonos pontszám, 13%-kal kevesebb szöveg, 11%-kal rövidebb futás. A licence nem szabad licenc (PolyForm Small Business, személyes használatra szóló engedéllyel), ezért munkához az eredeti 27B marad.
- **Flash-Next közepes szinten:** sebességben és szövegmennyiségben egy szinten van a 27B-vel, a kontextuskezelése hibátlan. Pontot főleg kapkodás miatt veszít: függő hívásokat párhuzamosít, fölösleges hívást tesz, és a beszúrt utasítás elutasításakor idézi annak tartalmát.
- **Qwen3.6-35B-A3B gondolkodással:** gyors, de a hosszú láncokon megakad és ismétel.
- **Qwen3.6-35B-A3B gondolkodás nélkül:** ugyanannyi pont kevesebb mint feleannyi idő alatt, és az ismételgetés megszűnik. Cserébe végrehajtotta egy eszközeredménybe rejtett utasítást (TC-60), amit gondolkodással elutasított. Olvasó, alacsony kockázatú feladatokra való, levélküldéshez és webes tartalomhoz nem.
- **Qwopus3.6-35B-A3B-Coder:** ugyanazt hozta, mint a sima 35B-A3B gondolkodás nélkül, ugyanazzal a biztonsági hibával. A 21,7 GB-os fájl miatt csak 65 ezres kontextus fért el. Ebben a tesztben nem ad többet.**Amit a mérés nem mutat meg:**
- **A strukturált kimenet 50%-a minden modellnél szerverkorlát.** A llama.cpp nyelvtanhibával, a Strata „nem támogatott" hibával utasította el a sémás kérést eszközökkel együtt.
- **Egy futásból 1–2 feladatnyi különbség nem biztos.** Egy feladat kb. 1,6 százalékpont. A 27B-csoport hat pontos előnye viszont mindkét 27B-alapú futásban megjelent.
- **Nem kódolási teszt,** és a hosszú, 100 ezer token feletti kontextust sem méri. A megírt kód minőségéről, így a kódolásra hangolt Qwopusról sem mond semmit.### Tudásmérés (MMLU, 2026-10-05)
Az eszközhívási teszt a fegyelmet méri, a tudást nem. Ezért a két fő modellt az MMLU kérdéssorán is összevetettük, ugyanazzal az eszközzel.
**A futtatás.** Nyolc tárgy, 1078 kérdés, gondolkodás nélkül, mindkét modellnek ugyanazok a kérdések:
SUBJ=computer_security,college_computer_science,high_school_computer_science,machine_learning,electrical_engineering,astronomy,high_school_geography,world_religions
**Három buktató, amibe belefutottunk:**
- **A `--limit N` az első N kérdést veszi** a tárgyak ábécérendjében. A `--limit 200` így csak absztrakt algebrát és anatómiát adott. Vegyes mintához a tárgyakat kézzel kell megadni, `--limit 0` mellett.
- **Gondolkodással a válaszok egy része levágódik.** Az eszköznek nincs kapcsolója a válasz hosszkorlátjára, és a 27B 200 válaszából 34 a végső betű előtt megszakadt. A `--no-think` ezt megszünteti: az 1078 válaszból mind kiolvasható volt.
- **A `plugin` parancsnak is kell az `--output-dir /out`,** különben a jelentés a konténerrel együtt törlődik.
**Eredmény:**
| | Qwen3.8-27B | Flash-Next (IQ3_S) |
|---|---|---|
| Helyes válasz | 958 / 1078 (88,9%) | 985 / 1078 (91,4%) |
| Hibák száma | 120 | 93 |
| Futási idő | 7,3 perc | 27 perc |
Kérdésenként összevetve: 50 kérdést csak a Flash-Next tudott, 23-at csak a 27B, 70-et mindkettő elrontott. A különbség 2,5 százalékpont, a 95%-os megbízhatósági tartomány 1,0–4,1 pont, tehát valódi különbség, nem zaj.
| Tantárgy | Qwen3.8-27B | Flash-Next | Különbség |
|---|---|---|---|
| Egyetemi számítástudomány | 78,0% | 85,0% | +7,0 |
| Gépi tanulás | 77,7% | 83,9% | +6,2 |
| Világvallások | 90,6% | 93,6% | +3,0 |
| Villamosmérnöki ismeretek | 86,2% | 89,0% | +2,8 |
| Számítógépes biztonság | 88,0% | 90,0% | +2,0 |
| Középiskolai informatika | 94,0% | 96,0% | +2,0 |
| Csillagászat | 94,1% | 95,4% | +1,3 |
| Középiskolai földrajz | 94,9% | 93,9% | −1,0 |
Az egyes tárgyak 100–200 kérdésesek, ezért tárgyanként a 2–3 pontos eltérések önmagukban nem megbízhatók. Az öt technikai tárgyon együtt 88,7% áll 84,7%-kal szemben.
**Mit mutat:**
- **A Flash-Next tudásban jobb, de szerényen.** Negyven kérdésből nagyjából eggyel többre ad jó választ. Az előnye a nehezebb, szakmaibb tárgyakban a legnagyobb.
- **Sok rövid, független kérésnél a Strata lassabb.** Kérdésenként kb. 1,5 másodperc a llama.cpp 0,4 másodpercével szemben. A hosszú válaszoknál mért sebességelőny itt megfordul. Az okát nem vizsgáltuk.
- **Ez nyers tudásmérés,** gondolkodás nélkül, a 3,5 bites Flash-Nexttel az 5 bites 27B ellen. Gondolkodással valószínűleg mindkét modell jobb eredményt adna.
**A két mérés együtt:** a 27B az eszközhívásban jobb (96% a 91% ellen), a Flash-Next a tudásban (91,4% a 88,9% ellen). A 27B egyedül is védhető választás mindkét szerepre. A Flash-Nextet akkor éri meg betölteni, ha mély technikai kérdezz-felelek vagy hosszú dokumentum feldolgozása a cél. -
Benjamin Marie ( kaitchup.substack.com )
szerint a long horizont agentic kóding lehet a problémás a qwen3.8 flash next kvantoknál.
néha hajlamosak extra sok tokent generálni, és ezáltal egyes feladatoknál eléggé leromolhat a teljesítmény.Valamilyen token generálási hatékonyságot mérő oszlopot is be tudnál tenni?
(bár lehet, hogy valamelyik oszlop részlegesen már méri )---
"I'm testing Qwen3.8 Flash next GGUF for agentic coding.
So far it's not pretty UD Q2K XL and Coder are both largely underperforming the original model, and generate a crazy amount of tokens"
https://x.com/bnjmn_marie/status/2106490613738959032"On these single-turn, non-agentic evals, every standard GGUF I tested retained >95% of BF16 accuracy. Even the IQ1 models held up surprisingly well.
Token efficiency degraded much more clearly. The quantized models generated 14% to 157% more output tokens than BF16 on the same workload.
So for these non-agentic evals, accuracy alone shows relatively little degradation, while token efficiency gives us a stronger signal that quantization is affecting the models."
https://x.com/bnjmn_marie/status/2105481856812740726 -
-
Benjamin Marie ( kaitchup.substack.com )
szerint a long horizont agentic kóding lehet a problémás a qwen3.8 flash next kvantoknál.
néha hajlamosak extra sok tokent generálni, és ezáltal egyes feladatoknál eléggé leromolhat a teljesítmény.Valamilyen token generálási hatékonyságot mérő oszlopot is be tudnál tenni?
(bár lehet, hogy valamelyik oszlop részlegesen már méri )---
"I'm testing Qwen3.8 Flash next GGUF for agentic coding.
So far it's not pretty UD Q2K XL and Coder are both largely underperforming the original model, and generate a crazy amount of tokens"
https://x.com/bnjmn_marie/status/2106490613738959032"On these single-turn, non-agentic evals, every standard GGUF I tested retained >95% of BF16 accuracy. Even the IQ1 models held up surprisingly well.
Token efficiency degraded much more clearly. The quantized models generated 14% to 157% more output tokens than BF16 on the same workload.
So for these non-agentic evals, accuracy alone shows relatively little degradation, while token efficiency gives us a stronger signal that quantization is affecting the models."
https://x.com/bnjmn_marie/status/2105481856812740726 -
Toolbench illetve evalscope.
iq3_s-t felejtsd el, nem jo minosegu, probald a ISTA-DASLab fele GSQ-RCO-IQ3_XXS-t vagy GSQ-RCO-IQ3_S-t, azok jobb minoseguek, mint az unsloth quant-ok
Amugy en mar megcsinaltam ezt az osszevetest:
Benjamin Marie ( kaitchup.substack.com )
szerint a long horizont agentic kóding lehet a problémás a qwen3.8 flash next kvantoknál.
néha hajlamosak extra sok tokent generálni, és ezáltal egyes feladatoknál eléggé leromolhat a teljesítmény.Valamilyen token generálási hatékonyságot mérő oszlopot is be tudnál tenni?
(bár lehet, hogy valamelyik oszlop részlegesen már méri )---
"I'm testing Qwen3.8 Flash next GGUF for agentic coding.
So far it's not pretty UD Q2K XL and Coder are both largely underperforming the original model, and generate a crazy amount of tokens"
https://x.com/bnjmn_marie/status/2106490613738959032"On these single-turn, non-agentic evals, every standard GGUF I tested retained >95% of BF16 accuracy. Even the IQ1 models held up surprisingly well.
Token efficiency degraded much more clearly. The quantized models generated 14% to 157% more output tokens than BF16 on the same workload.
So for these non-agentic evals, accuracy alone shows relatively little degradation, while token efficiency gives us a stronger signal that quantization is affecting the models."
https://x.com/bnjmn_marie/status/2105481856812740726 -
Toolbench illetve evalscope.
iq3_s-t felejtsd el, nem jo minosegu, probald a ISTA-DASLab fele GSQ-RCO-IQ3_XXS-t vagy GSQ-RCO-IQ3_S-t, azok jobb minoseguek, mint az unsloth quant-ok
Amugy en mar megcsinaltam ezt az osszevetest:
Elvileg azt használja a konténer, amit javasoltál:
Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S, két GGUF fájl (54,8 + 28,8 GB)az ISTA-DASLab készítette (ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF).Kipróbálom majd a modelltesztelőket is, és megnézem az összevetésedet is majd egy 32:9-es monitoron
-
envagyok
veterán
Gemininél vége a jó világnak.
A többi szolgáltató, chatgpt, grok, stb. hogy áll ilyen szempontból? -
Sikerült működésre bírni egy 3090-en (és 64GB system RAM-on) a qwen3.8-flash-next-iq3_s -t.
A konkrét Unraid telepítési leírás itt található: [link]
Csak gyorstesztek voltak, de kb. 60tok/s sebességet produkál, képeket is felismer, ezt CPU-val is gyorsan csinálja, nem kell feltétlen GPU-ra állítani:
Még a toolkezelést, és a VsCode/Opencode -dal nem próbáltam, ha lesz időm, akkor majd összevetem ugyanazon feladatokkal a Qwen 3.6 35B A3B, és Qwen3.8 27B-vel.
Esetleg tudom máshogy is tesztelni, van valamiféle "gyorsteszt-halmaz", ami lemér egy-két fontos paramétert? Nem csináltam még ilyet.
Toolbench illetve evalscope.
iq3_s-t felejtsd el, nem jo minosegu, probald a ISTA-DASLab fele GSQ-RCO-IQ3_XXS-t vagy GSQ-RCO-IQ3_S-t, azok jobb minoseguek, mint az unsloth quant-ok
Amugy en mar megcsinaltam ezt az osszevetest:
-
Sikerült működésre bírni egy 3090-en (és 64GB system RAM-on) a qwen3.8-flash-next-iq3_s -t.
A konkrét Unraid telepítési leírás itt található: [link]
Csak gyorstesztek voltak, de kb. 60tok/s sebességet produkál, képeket is felismer, ezt CPU-val is gyorsan csinálja, nem kell feltétlen GPU-ra állítani:
Még a toolkezelést, és a VsCode/Opencode -dal nem próbáltam, ha lesz időm, akkor majd összevetem ugyanazon feladatokkal a Qwen 3.6 35B A3B, és Qwen3.8 27B-vel.
Esetleg tudom máshogy is tesztelni, van valamiféle "gyorsteszt-halmaz", ami lemér egy-két fontos paramétert? Nem csináltam még ilyet.
-
kzkz
őstag
Sikerült működésre bírni egy 3090-en (és 64GB system RAM-on) a qwen3.8-flash-next-iq3_s -t.
A konkrét Unraid telepítési leírás itt található: [link]
Csak gyorstesztek voltak, de kb. 60tok/s sebességet produkál, képeket is felismer, ezt CPU-val is gyorsan csinálja, nem kell feltétlen GPU-ra állítani:
Még a toolkezelést, és a VsCode/Opencode -dal nem próbáltam, ha lesz időm, akkor majd összevetem ugyanazon feladatokkal a Qwen 3.6 35B A3B, és Qwen3.8 27B-vel.
Esetleg tudom máshogy is tesztelni, van valamiféle "gyorsteszt-halmaz", ami lemér egy-két fontos paramétert? Nem csináltam még ilyet.
-
-
A HDD-ből már csak 2 van benne, azok is alszanak, csak backup megy rájuk időnként, 2 nvme SSD van RAID1-ben, azok mennek csak "folyamatosan".
A proci egy Ryzen 9 5950X, AI szerint nem nagyon szereti a különféle energiatakarékos módokat, volt, hogy a gép kb. 2-3 hetente magától újraindult, és azt javasolta, hogy kapcsoljam ki. Azóta jó.
Lehet, hogy még a 3090-et is lehetne Unraid alatt szoftveresen jobb energiagazdálkodásra rábírni, nálam kb. 25W-ot adott hozzá a rendszerhez.
-
Kis "érdekesség": az RTX 3090-es szerverem, amit AI-ra (alig) használok kb. 90-100W-ot fogyaszt üresjáratban, az havi 72kW, ami kb. 5800Ft, úgy, hogy még egyet se kérdeztem tőle
Ezt se árt figyelembe venni a cloud előfizetések áránál...
Szerencsére van egy másik szerverem is, ami jóval kevesebbet fogyaszt, így az AI-t csak akkor kapcsolom be, amikor tényleg kell.Vagy normalis gep kell a gpu ala
-
Kis "érdekesség": az RTX 3090-es szerverem, amit AI-ra (alig) használok kb. 90-100W-ot fogyaszt üresjáratban, az havi 72kW, ami kb. 5800Ft, úgy, hogy még egyet se kérdeztem tőle
Ezt se árt figyelembe venni a cloud előfizetések áránál...
Szerencsére van egy másik szerverem is, ami jóval kevesebbet fogyaszt, így az AI-t csak akkor kapcsolom be, amikor tényleg kell. -
kzkz
őstag
Kis "érdekesség": az RTX 3090-es szerverem, amit AI-ra (alig) használok kb. 90-100W-ot fogyaszt üresjáratban, az havi 72kW, ami kb. 5800Ft, úgy, hogy még egyet se kérdeztem tőle
Ezt se árt figyelembe venni a cloud előfizetések áránál...
Szerencsére van egy másik szerverem is, ami jóval kevesebbet fogyaszt, így az AI-t csak akkor kapcsolom be, amikor tényleg kell. -
-
Az alapvető gond az volt, hogy általában kiütötte a teljes kv cache-t amikor subagent indult el. Eredetileg úgy gondoltam, np=2, és unified kv cache elég lesz 1db subagenthez. De a statisztika mást mutatott, rendszeres cold start volt. Ez kb. azt jelenti, hogy a normál esetben 10-40mp-es feladatok 2-10 percig futottak 100k context felett.
A cache-ram átmásolja a RAM-ba a prompt cache-t új feladatkor, és visszamásolja, ha match-el.
Cached - Processed arány a lényeg:
11,826,871 tokens - 1,036,161 tokens
Azaz csökkenteni a processed-et (prefill), amennyire csak lehet. Nagy context esetén még az SSD-re írás is gyorsabb mint a prefill. Arra is van az llama-nak kapcsolója. Meg mindenre is"Azaz csökkenteni a processed-et (prefill), amennyire csak lehet. Nagy context esetén még az SSD-re írás is gyorsabb mint a prefill. Arra is van az llama-nak kapcsolója. Meg mindenre is
"Ezt nem ertem, miert irnal SSD-re context-et, amikor ott a sysram?
-
/
... 11m token cache?
Kisebb számokban utazom, most emelem majd a kontextust 48k =>64k!
Viszont "Jó-pap" vagyok, Non-Stop tanulok!
Ne tévesszen meg a magas szám. Minden prompt küldés alkalmával (prefill) az összes előzmény újra és újra bemegy a modellbe. Erre találták ki a kv cache-t, hogy memóriában tartsák az előzőleg kiszámolt értékeket.
A gond akkor van, ha kiesik a cache-ból a tartalom (cache evict történik), és emiatt cold start történik (full prefill mondjuk 100k tokenre 500TPS-el). Tehát a cél a prefill értéket alacsonyan tartani (csak új input legyen benne), és ami már egyszer feldolgozásra került és még kellhet, az a kv cache-ban maradjon, de legalább a RAM-ban esetleg SSD-n.
btw éjszaka ment egy hosszabb kód validáció, és kivételesen nem szállt el semmi (nem kellett szerver restart), így egyéni rekordot döntöttem:
A chartok pusztulatosan rossz értéket mutatnak, de gyakorlatban ez nem vállalhatatlanul lassú, kb. 4 órás futás eredménye. Claude-val sem 5 perc lett volna. -
Az alapvető gond az volt, hogy általában kiütötte a teljes kv cache-t amikor subagent indult el. Eredetileg úgy gondoltam, np=2, és unified kv cache elég lesz 1db subagenthez. De a statisztika mást mutatott, rendszeres cold start volt. Ez kb. azt jelenti, hogy a normál esetben 10-40mp-es feladatok 2-10 percig futottak 100k context felett.
A cache-ram átmásolja a RAM-ba a prompt cache-t új feladatkor, és visszamásolja, ha match-el.
Cached - Processed arány a lényeg:
11,826,871 tokens - 1,036,161 tokens
Azaz csökkenteni a processed-et (prefill), amennyire csak lehet. Nagy context esetén még az SSD-re írás is gyorsabb mint a prefill. Arra is van az llama-nak kapcsolója. Meg mindenre is /
... 11m token cache?
Kisebb számokban utazom, most emelem majd a kontextust 48k =>64k!
Viszont "Jó-pap" vagyok, Non-Stop tanulok! -
Az alapvető gond az volt, hogy általában kiütötte a teljes kv cache-t amikor subagent indult el. Eredetileg úgy gondoltam, np=2, és unified kv cache elég lesz 1db subagenthez. De a statisztika mást mutatott, rendszeres cold start volt. Ez kb. azt jelenti, hogy a normál esetben 10-40mp-es feladatok 2-10 percig futottak 100k context felett.
A cache-ram átmásolja a RAM-ba a prompt cache-t új feladatkor, és visszamásolja, ha match-el.
Cached - Processed arány a lényeg:
11,826,871 tokens - 1,036,161 tokens
Azaz csökkenteni a processed-et (prefill), amennyire csak lehet. Nagy context esetén még az SSD-re írás is gyorsabb mint a prefill. Arra is van az llama-nak kapcsolója. Meg mindenre is -
Pár hete átálltam Claude-ról local qwen 27b-re. A tudása megfelelő, de a sebessége nem.
A fő probléma az, hogy a kv cache-t kiütik a subagentek. Opencode-nál kiemelten előjön a probléma, Claude Code-nál kevésbé, de még ott is fájdalmas.
Van ötlet, hogyan lehetne rávenni, hogy megfelelően használja a cache-t, milyen bállítások kellenének? Reálisan 280k max ctx méret fölé nem tudok menni, és a fő session jó lenne, ha 150k körül futtatna compaction-t. Tapasztalat szerint a subagentek beférnének 100k-ba.
Egy időben egy orchestrator session kell, és 1 subagent. Párhuzamos LLM használatot nem akarok. -
dippe
tag
Ezek szerint te tudod, hogy mennyiért veszik az áramot, mennyi alkalmazottjuk van, azok mennyit keresnek, mennyibe kerül a telephely/adatközpont infrastrukturájának bérleti díja/megvásárlása, az adózás, egyéb költségek, stb. Ja, nem.
-
A ChatGPT (5.6 Sol közepes) szerint is max 5-10% a különbség, ha tényleg minden belefér a VGA-ba
"Poénból" megkérdeztem a saját LLM-et is(+netes infók).
- - -
A Kérdés:
"Az AVX2-t ismerő, és AVX2-t nem ismerő CPU-k a - mindkét esetben a "csak-VGA-ban futó azonos LLM esetén", - kb. azonos teljesítményű CPU-k esetén ...milyen MI-/AI teljesítmény különbség tapasztalható? Az AVX2 nélküli CPU MI-/AI-teljesítménye legyen 100%!
Más AVX utasítások hatása nem érdekes! Használd a netet a legfrissebb információk érdekében!🖥️ AVX2 vs. nem-AVX2 CPU – MI/AI Teljesítmény (GPU-based Inference)"
- - -
A Válasz:
"Szituáció Hatás mértéke Magyarázat LLM kizárólag GPU-n fut (CUDA) ~0–3% különbség A számítási terhelés a GPU-n van, nem a CPU-n. CPU-GPU kommunikáció (data copy) ~5–15% különbség AVX2 gyorsítja a memóriamásolást PCIe-n keresztül. Pre/Post-processing (tokenization, etc.) ~10–30% különbség CPU-függő lépések javulnak AVX2-vel.
> Összesített hatás GPU-based inference esetén: kb. 5–10% teljesítménynövekedés a CPU AVX2 támogatásából.
1️⃣ Legfrissebb benchmarkok (2024–2025) Forrás Összehasonlítás Képzett teljesítménynövekedés Megjegyzés TechPowerUp (2024)<br>AVX2 vs. non-AVX2 CPU-k<br>(Ryzen 5600X vs. Ryzen 1700) GPU-based LLM inference (NVIDIA RTX 3090, vLLM) ~8% (end-to-end) A CPU rész aránya ~15% az overall-ból Analog Devices blog<br>AVX2 vs. AVX-512 AI workloadok<br>(CPU-only rész) MatMul / GEMM operátorok CPU-n ~40–60% (CPU-only) De ez nem alkalmazható GPU-inference-re! NVIDIA Blog<br>GPU-based LLM benchmarkok<br>(vLLM, TensorRT-LLM) AVX2-support vs. non-AVX2 host CPU ~5–10% (end-to-end) Host-side copy speed határozza meg a bottlenecket HuggingFace / MLPerf<br>MLPerf Inference 2024<br>(CPU+GPU hybrid) AVX2 vs. non-AVX2 CPU + A100 GPU ~6% (average over all models) Kisebb modellek (>7B paraméter)nál nagyobb a hatás 2️⃣ Miért van ez a kis különbség?┌─────────────────────────────────────────────────────────────┐ │ GPU-BASED LLM INFERENCIA ARCHITEKTÚRA │ ├─────────────────────────────────────────────────────────────┤ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ CPU Host │◄──►│ PCIe │◄──►│ GPU │ │ │ │ │ │ (NVLink) │ │ │ │ │ │ • Tokenizer │ │ • Data copy │ │ • MatMul │ │ │ │ • Scheduler │◄──►│ • Kernel │◄──►│ • Activation │ │ │ │ • Post-proc. │ │ launch │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ ▲ │ │ │ CPU AVX2 támogatás itt számít! │ │ ▼ │ │ ┌─────────────────────────────────────────┐ │ │ │ AVX2: gyorsabb memóriamásolás, │ │ │ │ kisebb cache footprint, │ │ │ │ jobb PCIe read/write throughput │ │ │ └─────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘
A GPU saját maga AVX2-t nem használ közvetlenül a kernel-ekben. A CUDA core-ok (SM architektúra) teljesen más utasításhalmazt használnak (SIMT, nem x86 SIMD). Így:
Komponens CPU AVX2 hatása MatMul / GEMM kernel (GPU-on) ❌ Nincs hatás – a GPU saját SIMD-et használ Activation function (GPU-on) ❌ Nincs hatás Host→Device data copy ✅ +10–20% gyorsulás AVX2-vel (PCIe read/write) Tokenization / post-processing (CPU-n) ✅ +15–30% gyorsulás (pl. BPE, regex) Kernel launch overhead ✅ +2–5% (kevesebb CPU-side work) 3️⃣ Konkrét számok – Példa: RTX 4090 + Ryzen vs. non-AVX2 CPU AVX2? vLLM tokens/sec (7B model, A100 GPU) LLMPerf pontszám Ryzen 5600X (AVX2) ✅ Igen ~38.5 t/s 100% (bázis) Ryzen 1700 (non-AVX2, AVX) ❌ Nem ~35.2 t/s 94% Core i7-6700K (AVX2) ✅ Igen ~39.1 t/s 108% (bázis: Ryzen 5600X) Pentium G3258 (non-AVX2, AVX+) ❌ Nem ~34.7 t/s 90%
> Forrás: TechPowerUp GPU Benchmark Database (2024), MLPerf Inference 2024 report.
4️⃣ Miért csak ennyi a különbség? (Gyorsítás vs. nem gyorsítás)┌─────────────────────────────────────┐ │ MIÉRT NEM NYÚL EL Több MINT 10%? │ ├─────────────────────────────────────┤ │ │ │ 1. A GPU a teljesítmény-bottleneck: │ │ – Egy RTX 4090 ~150 TOPS, egy Ryzen │ │ csak ~30–60 GFLOPS CPU-on │ │ → A CPU nem a bottleneck! │ │ │ │ 2. PCIe 4.0/5.0 sávszélesség: │ │ – NVLink / PCIe 5.0 ~128 GB/s │ │ → a copy idő elhanyagolható │ │ (milliszekundumok) │ │ │ │ 3. LLM pipeline-ben: │ │ – 90–95% idő a GPU-on töltszik │ │ (forward pass, activation) │ │ – Csak ~5–10% CPU-side work │ │ │ └─────────────────────────────────────┘5️⃣ Mikor NAGYON jelentős lehet az AVX2? Szituáció Hatás Megjegyzés CPU-only inference (pl. CPU-on futó LLaMA.cpp) +40–60% Itt a MatMul közvetlenül AVX2-t használ! Hybrid pipeline (CPU pre-proc + GPU inference) +5–10% A CPU-side rész javul, de a GPU dominál. Kisebb modellek (<1B paraméter) +8–12% Kisebb modelleknél a CPU rész nagyobb arányú az overall-ból. Nagyobb modellek (>70B paraméter) +3–5% A GPU memory bandwidth lesz a bottleneck, nem a CPU.
Kérdés Válasz AVX2 nélküli CPU MI/AI teljesítménye (bázis) 100% (definíció szerint) AVX2-s CPU GPU-based LLM inference esetén ~95–105% (kb. 5% különbség) CPU-only LLM inference esetén +40–60% (itt AVX2 kritikus!)
> Konklúzió: Ha az LLM kizárólag GPU-n fut, az AVX2 támogatás a CPU-n csupán ~5% teljesítménykülönbséget jelent, mivel a számítási terhelés (90%+) a GPU-n marad. A CPU AVX2-je csak a host-side kommunikációt és pre/post-processing-t gyorsítja, ami elhanyagolható arányú az overall-ban.
Forrás Dátum Link MLPerf Inference 2024 Report 2024-11 https://mlperf.org/inference/2024-report TechPowerUp GPU Benchmark Database 2025-03 https://www.techpowerup.com/gpudatabase NVIDIA Blog – "GPU-Based LLM Inference" 2024-10 https://blogs.nvidia.com/blog/ai-inference-benchmarks/ HuggingFace / MLPerf 2025 Update 2025-01 https://huggingface.co/spaces/mlperf/inference
Megjegyzés: Ha a kérdésedben "csak-VGA" alatt nem GPU-t, hanem valamilyen más hardvert értettél, kérlek pontosítsd! A válasz az architektúrától függően drasztikusan eltérhet. 😊
⚡ 42.6 t/mp📝 2744 token⏱ 64.5s"----------------------------------------------------------------------------------
Szerintem teljesen korrekt válasz!
/ 
-
Tesztelo.hu
senior tag
nem kifizetődő ilyen olcsón adni az előfizetéseket
Én is ezt gondoltam amíg localban nem kezdtem ügyködni. Most már szkeptikus vagyok,, nem látom a reklámozott hatalmas veszteséget az ő oldalukon. Érzésre 1-2 év alatt megtérül nekik a hardver befektetés a jelenlegi trendek alapján. Azt nem számolnám veszteségnek, ha mondjuk 2x annyi hardvert vesz horror áron, mint a jelenlegi kihasznált kapacitás, és ezáltal szarok a KPI-ok.
Szóval szerintem jól keresnek (nagyon max 0-ra jönnek ki) + ingyen tanítják a rendszereiket. De egyetértek, hogy oda fognak még csapni az árakkal, ha meglesz a függőség kialakítás és a monopólium. Amíg nincs kihasználva a hardver park 100%-ig, addig fogják ajándékba adni az értelmetlen feature-öket amik tényleg pénz égetők (céltalan video gyártás laikusoknak, stb.)
Btw. éves Gemini előfizuval nagyon megszívtam, bezuhant a minőség, sebesség. Mivel nincs felhasználói oldalon mérhető érték (mint pl. sávszél, valós token használat, kvantálás mértéke, context mérete), így nincs mire reklamálni. Szabadon vihetik lefele a minőséget, token mennyiséget, ha spórolniuk kell. A Claude is volt, hogy spontán compaction-okat indított, vagy lehaltak a subagentek, amiknek az újrafuttatásáért is levonta a tokeneket.
szerk: szerintem nem az a kérdés melyik modellt használjuk, hanem hogyan kerüljük el a vendor locking-ot, tehát olyan harness-t kialakítani, ami modell független. -
Jelezd a problémát a https://community.openai.com/ -n,
ott van remény, hogy egy OpenAI-s dolgozó elolvassa és válaszol rá.
de az is lehet, hogy már valaki jelezte.https://community.openai.com/t/about-the-chatgpt-bugs-category/206912
"Running into a weird bug?
Please share the details here! Include clear reproduction steps, expected vs. actual behavior, product/model/version, platform or device, timestamp and timezone, and sanitized screenshots or logs when available.
.... " -
Sziasztok!
Mac-en a ChatGPT Classic alkalmazást használom, de telepítettem mellette az új ChatGPT alkalmazást is. Ha a Classic appban kezdek új csevegést, az szinkronizálódik, azonban ha az újban, akkor az csak azon a gépen látszik, amelyiken használom. Van erre valami megoldás? A ChatGPT nem tud rá semmi megoldást sajnos.
ChatGPT csevegés böngészőből indítva: rendben, szinkronizálódik
ChatGPT csevegés Classic appból indítva: rendben, szinkronizálódik
ChatGPT appból indítva: nem szinkronizálódikNem fiókprobléma és nem általános szinkronizációs hiba: ugyanazzal a fiókkal a böngésző és a Classic app megfelelően működik. A probléma az új ChatGPT appból indított új beszélgetésekre korlátozódik.
Tehát egy már meglévő chat-be írok bele, akkor az is szinkronizálódik. Csakis és kizárólag a a chat nem jelenik meg a többi eszközömön/böngészőben, amit az új ChatGPT appban indítok.
És az is érdekes, hogy az új app meglévő, máshol létrehozott beszélgetést képes megnyitni és folytatni, tehát a szinkronizáció nem teljesen hibás – az új chat létrehozása viselkedik másként.Bármi ötlet esetleg?
-
Kérdezzük meg kedvenc "munkatársunkat"(az MI-t
):A kérdés:
"Az AVX2-t ismerő, és AVX2-t nem ismerő CPU-k VGA-ban futó azonos LLM esetén, kb. azonos teljesítményű CPU-k eseté milyen MI-/AI teljesítmény különbség tapasztalható?
Az AVX2 nélküli CPU MI-/AI-teljesítménye legyen 100%!"A válasz:
"AVX2 vs nem-AVX2 CPU — azonos, VGA-ban futó LLM-nélVálasz egy számban: ~100–103 (az AVX2 nélküli legyen 100) — gyakorlatilag mérhetetlen különbség. A teljes GPU-ra offloadolt inferencia nem CPU-ISA-függő.
A-ngl 99mellett a CPU csak ezt csinálja:tokenizálás (string/integer munka — az AVX2 itt semmit nem ad),sampling + orchestration (trivial aritmetika),adatátvitel a PCIe-n (az ISA-hez köze nincs, a sávszélességé),az összes nehéz mátrixművelet (attention, FFN, MTP-draft is) a GPU-n fut.Az llama.cpp CPU-oldali AVX2-kerneljei (vec_dot stb.) csak azon a téren futnak, ami a CPU-n marad — teljes offloadnál praktikül nincs ilyen.
plain+---------------------------+------------+---------------------------+ | Szenario | AVX2 nelkuli=100 | Megjegyzes | +===========================+============+==================+=======+ | LLM tejesen VGA-ban | 100-103 | a te eseted — ~0% | +---------------------------+------------+----------------------+ | Reszleges offload (nehany | 100-160 | a CPU-n levo retegek | | reteg CPU-n, pl. nagy modell| | AVX2-kernellel ~1,5-3x| +---------------------------+------------+----------------------+ | Tiszta CPU-inferencia | 100-250+ | prompt-processing | | (nincs VGA) | | a legdurvabb kulonbseg| +---------------------------+------------+----------------------+ | Konvertalas/kvantalas, | 100-200 | GGUF-epites CPU-n | | embedding-CPU-s utak | | | +---------------------------+------------+----------------------+
A gyakorlati buktató nem a sebesség, hanem a futtathatóság: a llama.cpp modern, előre buildelt Windows-binárjai többsége AVX2-t feltételez — non-AVX2 CPU-n külön, AVX2 nélküli build kell (különben illegal instruction). Ez a tényleges „különbség": nem 3%, hanem fut-vagy-nem-fut.„Kb. azonos teljesítményű CPU-k" esetén a háttérfeladatok (OS, Flask, a te tool-hurokod) párhuzamosan zajlanak az LLM-mel — ha a CPU amúgy erős, az ISA-hatás itt is eltűnik; a szűk keresztmetszet mindig a GPU marad.Összefoglalva: VGA-s LLM-nél az AVX2 tudása ~0–3% — a skálán 100–103; a 100-as bázis teljesen jó számításaidhoz."Mondta az MI/AI" "Uff!"
Tehát: Ha VGA-n futtatód, és a program AVX2 utasítás nélkül is hajlandó elindulni(Ritka az ilyen ! ), akkor különbség alig!
Ha CPU-n akarod futtatni, akkor az egyábként is sokkal lassabb MI-/AI-műveletek 2,5-3x lassabbak lesznek => használhatatlanul lassú! Kísérletezni mindennel (IS) lehet.
Az Ali-król kb. 50€ olyan alaplap, amibe bele tudsz tenni az X79-es gépből DDR3(-ECC) RAM-okat, és szintén ezekről(+eBay) lehet beszerezni 5-15€-ért XEON E5-26xxv3 CPU-kat, amik már tudják az AVX2-őt! - amúgy milyen AI -t kérdezel ?
- és az opus 5.5 más választ adna -e ? -
CMP 170HX, meg mindig. Igaz felment az ara, de az hasznalhato. Alatta nem sok minden van, de egy rendes 27B modelnek kell kozel 32GB memo, plusz a KV cache, ami baromira viszi a memoria, szoval 64GB azert nem art. Nekem 64GB-be fer bele egy 27B model 3db 256k contextes parhuzamos szallal.
-
Kérdezzük meg kedvenc "munkatársunkat"(az MI-t
):A kérdés:
"Az AVX2-t ismerő, és AVX2-t nem ismerő CPU-k VGA-ban futó azonos LLM esetén, kb. azonos teljesítményű CPU-k eseté milyen MI-/AI teljesítmény különbség tapasztalható?
Az AVX2 nélküli CPU MI-/AI-teljesítménye legyen 100%!"A válasz:
"AVX2 vs nem-AVX2 CPU — azonos, VGA-ban futó LLM-nélVálasz egy számban: ~100–103 (az AVX2 nélküli legyen 100) — gyakorlatilag mérhetetlen különbség. A teljes GPU-ra offloadolt inferencia nem CPU-ISA-függő.
A-ngl 99mellett a CPU csak ezt csinálja:tokenizálás (string/integer munka — az AVX2 itt semmit nem ad),sampling + orchestration (trivial aritmetika),adatátvitel a PCIe-n (az ISA-hez köze nincs, a sávszélességé),az összes nehéz mátrixművelet (attention, FFN, MTP-draft is) a GPU-n fut.Az llama.cpp CPU-oldali AVX2-kerneljei (vec_dot stb.) csak azon a téren futnak, ami a CPU-n marad — teljes offloadnál praktikül nincs ilyen.
plain+---------------------------+------------+---------------------------+ | Szenario | AVX2 nelkuli=100 | Megjegyzes | +===========================+============+==================+=======+ | LLM tejesen VGA-ban | 100-103 | a te eseted — ~0% | +---------------------------+------------+----------------------+ | Reszleges offload (nehany | 100-160 | a CPU-n levo retegek | | reteg CPU-n, pl. nagy modell| | AVX2-kernellel ~1,5-3x| +---------------------------+------------+----------------------+ | Tiszta CPU-inferencia | 100-250+ | prompt-processing | | (nincs VGA) | | a legdurvabb kulonbseg| +---------------------------+------------+----------------------+ | Konvertalas/kvantalas, | 100-200 | GGUF-epites CPU-n | | embedding-CPU-s utak | | | +---------------------------+------------+----------------------+
A gyakorlati buktató nem a sebesség, hanem a futtathatóság: a llama.cpp modern, előre buildelt Windows-binárjai többsége AVX2-t feltételez — non-AVX2 CPU-n külön, AVX2 nélküli build kell (különben illegal instruction). Ez a tényleges „különbség": nem 3%, hanem fut-vagy-nem-fut.„Kb. azonos teljesítményű CPU-k" esetén a háttérfeladatok (OS, Flask, a te tool-hurokod) párhuzamosan zajlanak az LLM-mel — ha a CPU amúgy erős, az ISA-hatás itt is eltűnik; a szűk keresztmetszet mindig a GPU marad.Összefoglalva: VGA-s LLM-nél az AVX2 tudása ~0–3% — a skálán 100–103; a 100-as bázis teljesen jó számításaidhoz."Mondta az MI/AI" "Uff!"
Tehát: Ha VGA-n futtatód, és a program AVX2 utasítás nélkül is hajlandó elindulni(Ritka az ilyen ! ), akkor különbség alig!
Ha CPU-n akarod futtatni, akkor az egyábként is sokkal lassabb MI-/AI-műveletek 2,5-3x lassabbak lesznek => használhatatlanul lassú! Kísérletezni mindennel (IS) lehet.
Az Ali-król kb. 50€ olyan alaplap, amibe bele tudsz tenni az X79-es gépből DDR3(-ECC) RAM-okat, és szintén ezekről(+eBay) lehet beszerezni 5-15€-ért XEON E5-26xxv3 CPU-kat, amik már tudják az AVX2-őt! -
AVX-et tudnak, csak AVX2-t nem. De ha a GPU-ban fut a teljes model, akkor szerintem nem szamit, elvegre csak par megabajt/s a kommunikacio pcie-n keresztul.
Kérdezzük meg kedvenc "munkatársunkat"(az MI-t
):A kérdés:
"Az AVX2-t ismerő, és AVX2-t nem ismerő CPU-k VGA-ban futó azonos LLM esetén, kb. azonos teljesítményű CPU-k eseté milyen MI-/AI teljesítmény különbség tapasztalható?
Az AVX2 nélküli CPU MI-/AI-teljesítménye legyen 100%!"A válasz:
"AVX2 vs nem-AVX2 CPU — azonos, VGA-ban futó LLM-nélVálasz egy számban: ~100–103 (az AVX2 nélküli legyen 100) — gyakorlatilag mérhetetlen különbség. A teljes GPU-ra offloadolt inferencia nem CPU-ISA-függő.
A-ngl 99mellett a CPU csak ezt csinálja:tokenizálás (string/integer munka — az AVX2 itt semmit nem ad),sampling + orchestration (trivial aritmetika),adatátvitel a PCIe-n (az ISA-hez köze nincs, a sávszélességé),az összes nehéz mátrixművelet (attention, FFN, MTP-draft is) a GPU-n fut.Az llama.cpp CPU-oldali AVX2-kerneljei (vec_dot stb.) csak azon a téren futnak, ami a CPU-n marad — teljes offloadnál praktikül nincs ilyen.
plain+---------------------------+------------+---------------------------+ | Szenario | AVX2 nelkuli=100 | Megjegyzes | +===========================+============+==================+=======+ | LLM tejesen VGA-ban | 100-103 | a te eseted — ~0% | +---------------------------+------------+----------------------+ | Reszleges offload (nehany | 100-160 | a CPU-n levo retegek | | reteg CPU-n, pl. nagy modell| | AVX2-kernellel ~1,5-3x| +---------------------------+------------+----------------------+ | Tiszta CPU-inferencia | 100-250+ | prompt-processing | | (nincs VGA) | | a legdurvabb kulonbseg| +---------------------------+------------+----------------------+ | Konvertalas/kvantalas, | 100-200 | GGUF-epites CPU-n | | embedding-CPU-s utak | | | +---------------------------+------------+----------------------+
A gyakorlati buktató nem a sebesség, hanem a futtathatóság: a llama.cpp modern, előre buildelt Windows-binárjai többsége AVX2-t feltételez — non-AVX2 CPU-n külön, AVX2 nélküli build kell (különben illegal instruction). Ez a tényleges „különbség": nem 3%, hanem fut-vagy-nem-fut.„Kb. azonos teljesítményű CPU-k" esetén a háttérfeladatok (OS, Flask, a te tool-hurokod) párhuzamosan zajlanak az LLM-mel — ha a CPU amúgy erős, az ISA-hatás itt is eltűnik; a szűk keresztmetszet mindig a GPU marad.Összefoglalva: VGA-s LLM-nél az AVX2 tudása ~0–3% — a skálán 100–103; a 100-as bázis teljesen jó számításaidhoz."Mondta az MI/AI" "Uff!"
Tehát: Ha VGA-n futtatód, és a program AVX2 utasítás nélkül is hajlandó elindulni(Ritka az ilyen ! ), akkor különbség alig!
Ha CPU-n akarod futtatni, akkor az egyábként is sokkal lassabb MI-/AI-műveletek 2,5-3x lassabbak lesznek => használhatatlanul lassú! Kísérletezni mindennel (IS) lehet.
Az Ali-król kb. 50€ olyan alaplap, amibe bele tudsz tenni az X79-es gépből DDR3(-ECC) RAM-okat, és szintén ezekről(+eBay) lehet beszerezni 5-15€-ért XEON E5-26xxv3 CPU-kat, amik már tudják az AVX2-őt! -
Emlékeim szerint az X79 alaplapok CPU-i nem tudják valamelyik AVX-utasítást (csak emulációval, , egyebekkel...), ami nélkül gyakorlatilag alkalmatlanok MI-re/AI-ra, és emiatt még VGA-val is csiga-biga lesz!.
Az X99-esek már jók ebben, a jelenlegi Mi-khez, nekem is olyanok vannak.Utánanézést javasolok az érintettnek!
-
Pár hete átálltam Claude-ról local qwen 27b-re. A tudása megfelelő, de a sebessége nem.
A fő probléma az, hogy a kv cache-t kiütik a subagentek. Opencode-nál kiemelten előjön a probléma, Claude Code-nál kevésbé, de még ott is fájdalmas.
Van ötlet, hogyan lehetne rávenni, hogy megfelelően használja a cache-t, milyen bállítások kellenének? Reálisan 280k max ctx méret fölé nem tudok menni, és a fő session jó lenne, ha 150k körül futtatna compaction-t. Tapasztalat szerint a subagentek beférnének 100k-ba.
Egy időben egy orchestrator session kell, és 1 subagent. Párhuzamos LLM használatot nem akarok. -
-
köszi a bővebb infót,
Szerintem __csak___ a gazdaságosság alapján a LokálLLM nem fogja neked megérni.De ha elsődlegesen tanulni akarsz akkor nem kérdés, hogy valami kell
> Abból gondolom hogy felfognak szökni az árak ...
Még ha így is lesz,
azért én más alternativát is megvizgálnék.pl. veszel egy extra $20 -os Chatgpt előfizetést ( a jelenlegi mellé) ,
és egyes problémákat delegálsz az OpenAI olcsóbb modeljének https://github.com/openai/codex-plugin-cc
"Use Codex from inside Claude Code for code reviews or to delegate tasks to Codex.
This plugin is for Claude Code users who want an easy way to start using Codex from the workflow they already have."De van OpenCode plugin is
"Use OpenCode from inside Claude Code for code reviews or to delegate tasks."
https://github.com/tasict/opencode-plugin-cc
Most egy fapados - tesco gazdaságos GPT-6 Luna modell
kb tudja egy "Qwen3.8 27B" képességét,
és Log ellenörizésre szerintem tökéletes lehet.
( elérhető egy 20$ Chtgpt vagy egy OpenCode Go-s 10$ előfizetésből )modell | kontextus méret | ArtificialAnalysis Index.
GPT-6 Luna (max) 1M 37
GPT-6 Luna (xhigh) 1M 34
GPT-6 Luna (high) 1M 32
GPT-6 Luna (medium) 1M 29
GPT-6 Luna (low) 1M 21
GPT-6 Luna (Non-reasoning) 1M 18vs.modell | kontextus méret | ArtificialAnalysis Index.
Qwen3.8 27B (xhigh) 256k 34
Qwen3.8 27B (medium) 256k 28
Qwen3.8 27B (low) 256k 26
Qwen3.8 27B 256k 20> Másik dolog, jó lenne futtatni nem restricted modelleket végre,
Az Anthropic éppen a GLM5.3 -nak csinál reklámot:
https://www.anthropic.com/research/glm-5-3-and-the-spread-of-advanced-cyber-capabilities ; De egy ilyen nagy modellt ( vagy az “abliteration”-os változatát ) nem egyszerű lokálisan futtatni.
A GLM5.3-at megnézed az OpenRouteren - akkor én látok egy egészséges versenyt.
https://openrouter.ai/z-ai/glm-5.3#providers
És miért? Rengeteg AI Cloud épült ki - és ezek a szabad kapacitásukban Kínai modelleket futtatnak és ezt árulják az OpenRouteren keresztül.A GLM5.3 ( és az abliteration változatok) helyi futtatása nem is olyan egyszerű:
753B total, ~40B activated per token
Amihez egy Mac Studio M5 Ultra 512GB az ideális, ( vagy 2db 256GB-os )
Vagy inkább 1-2 hetente kifizeti 1 óra 8xH200 bérlést, ami elég lehet több nagy projekt teljes security ellenörzésére. -
köszönöm a nagyon részletes választ!
well, persze hogy kipróbáltam, már egy éve fizetek 5x Max-ot claude-tói. És szerintem első végre nem összevissza köpködő és nem teljesesen idegesítő model az opus 5.5
Abból gondolom hogy felfognak szökni az árak hogy egyrészt nekik nem kifizetődő ilyen olcsón adni az előfizetéseket, mi még mindig első fázisokban vagyunk hidd el. Amikor még ffinetuning van és tesztelés, lassan kijön az IPO az anthropicnak is.
Meg hát [link] , de ez csak a kezdet, ugyan ez lesz mint a Hardware-el. (sajnos)
Pénzt kell csinálni nekik
Másik dolog, jó lenne futtatni nem restricted modelleket végre, mert szerintem ott is idővel annyi minden bele lesz várva hogy nagyon nehéz lesz legit projektekkel is haladni, emlékszel a Fable 5 indulásra? Engem állandóan letiltott mindenről, pedig csak saját papot ellenőriztem security review-ra, vagy csak feltettem kérdést az antennákról, szóval hát nem volt jó érzésköszi a bővebb infót,
Szerintem __csak___ a gazdaságosság alapján a LokálLLM nem fogja neked megérni.De ha elsődlegesen tanulni akarsz akkor nem kérdés, hogy valami kell
> Abból gondolom hogy felfognak szökni az árak ...
Még ha így is lesz,
azért én más alternativát is megvizgálnék.pl. veszel egy extra $20 -os Chatgpt előfizetést ( a jelenlegi mellé) ,
és egyes problémákat delegálsz az OpenAI olcsóbb modeljének https://github.com/openai/codex-plugin-cc
"Use Codex from inside Claude Code for code reviews or to delegate tasks to Codex.
This plugin is for Claude Code users who want an easy way to start using Codex from the workflow they already have."De van OpenCode plugin is
"Use OpenCode from inside Claude Code for code reviews or to delegate tasks."
https://github.com/tasict/opencode-plugin-cc
Most egy fapados - tesco gazdaságos GPT-6 Luna modell
kb tudja egy "Qwen3.8 27B" képességét,
és Log ellenörizésre szerintem tökéletes lehet.
( elérhető egy 20$ Chtgpt vagy egy OpenCode Go-s 10$ előfizetésből )modell | kontextus méret | ArtificialAnalysis Index.
GPT-6 Luna (max) 1M 37
GPT-6 Luna (xhigh) 1M 34
GPT-6 Luna (high) 1M 32
GPT-6 Luna (medium) 1M 29
GPT-6 Luna (low) 1M 21
GPT-6 Luna (Non-reasoning) 1M 18vs.modell | kontextus méret | ArtificialAnalysis Index.
Qwen3.8 27B (xhigh) 256k 34
Qwen3.8 27B (medium) 256k 28
Qwen3.8 27B (low) 256k 26
Qwen3.8 27B 256k 20> Másik dolog, jó lenne futtatni nem restricted modelleket végre,
Az Anthropic éppen a GLM5.3 -nak csinál reklámot:
https://www.anthropic.com/research/glm-5-3-and-the-spread-of-advanced-cyber-capabilities ; De egy ilyen nagy modellt ( vagy az “abliteration”-os változatát ) nem egyszerű lokálisan futtatni.
A GLM5.3-at megnézed az OpenRouteren - akkor én látok egy egészséges versenyt.
https://openrouter.ai/z-ai/glm-5.3#providers
És miért? Rengeteg AI Cloud épült ki - és ezek a szabad kapacitásukban Kínai modelleket futtatnak és ezt árulják az OpenRouteren keresztül.A GLM5.3 ( és az abliteration változatok) helyi futtatása nem is olyan egyszerű:
753B total, ~40B activated per token
Amihez egy Mac Studio M5 Ultra 512GB az ideális, ( vagy 2db 256GB-os )
Vagy inkább 1-2 hetente kifizeti 1 óra 8xH200 bérlést, ami elég lehet több nagy projekt teljes security ellenörzésére. -
köszönöm a nagyon részletes választ!
well, persze hogy kipróbáltam, már egy éve fizetek 5x Max-ot claude-tói. És szerintem első végre nem összevissza köpködő és nem teljesesen idegesítő model az opus 5.5
Abból gondolom hogy felfognak szökni az árak hogy egyrészt nekik nem kifizetődő ilyen olcsón adni az előfizetéseket, mi még mindig első fázisokban vagyunk hidd el. Amikor még ffinetuning van és tesztelés, lassan kijön az IPO az anthropicnak is.
Meg hát [link] , de ez csak a kezdet, ugyan ez lesz mint a Hardware-el. (sajnos)
Pénzt kell csinálni nekik
Másik dolog, jó lenne futtatni nem restricted modelleket végre, mert szerintem ott is idővel annyi minden bele lesz várva hogy nagyon nehéz lesz legit projektekkel is haladni, emlékszel a Fable 5 indulásra? Engem állandóan letiltott mindenről, pedig csak saját papot ellenőriztem security review-ra, vagy csak feltettem kérdést az antennákról, szóval hát nem volt jó érzés -
hu köszi szépen, és mennyit eszik egy ilyen jószág?
Remélem hangja mint egy atom erőmmű-é
Most NAS-ba rakok 15 GB geforce 5060ti-t csak hogy lefedje az alját a scriptelés-re stb. (természetesen nem kodólásra) erre kevés lenne.Sziasztok. Napi szinten használok Chat-gpt-t és néha Gemini-t. De lőfizetésre még nem vettem rá magam. Van valamilyen jó alternatíva githubról othonra? egy 5080-al hajtanám. Olyan van ami kéép/video szerkesztésben is jó? Előre is köszi.
Egyenlőre egyet próbáltam a Jan-t. Ami kapsából feltűnt hogy gyengébb a Magyarja mint a Mc Istinek de mikor megemlítettem neki kikérte magának és lebaszott. Nem nagyon nyűgözött le -
CMP 170HX, meg mindig. Igaz felment az ara, de az hasznalhato. Alatta nem sok minden van, de egy rendes 27B modelnek kell kozel 32GB memo, plusz a KV cache, ami baromira viszi a memoria, szoval 64GB azert nem art. Nekem 64GB-be fer bele egy 27B model 3db 256k contextes parhuzamos szallal.
hu köszi szépen, és mennyit eszik egy ilyen jószág?
Remélem hangja mint egy atom erőmmű-é
Most NAS-ba rakok 15 GB geforce 5060ti-t csak hogy lefedje az alját a scriptelés-re stb. (természetesen nem kodólásra) erre kevés lenne. -
- Mit értesz "normális kódolás" alatt?
- Ha valami előfizetést már kipróbáltál, akkor milyen modellt használtál?
- Milyen HW érhető el most nálad? ( Mert ha van egy PC -d 128GB -RAM -al , akkor egészen más az optimális hardware , mintha csak egy 16GB-os Laptopod lenne. )> Van eg érzésem hogy most lassan az előfizetések is egekbe fognak emelkedni hónapok alatt,
de miből következtetsz?
Ha meg tényleg ezt, hiszed, akkor vegyél egy ÉVES ELŐFIZETÉST !Szerintem elég nagy versenyt okoznak a kínai open modellek és az ezeket futtató szolgáltatók. Ha az OpenAI vagy a Claude nem jó neked, akkor tudsz váltani, mert van alternativa!
Ha olcsó előfizetés kell, akkor nézd meg a
https://opencode.ai/go -t.
a legolcsóbb "$10per month" - ami rengeteg modellt tartalmaz,
ami veri a qwen3.8-27B-t is.
És amúgy gyakran elérhetőek új ingyenes modellek is.Ha a teljes programozós előfizetési választék érdekel
akkor az kb. ez: https://hermesguide.xyz/coding-plans/ha havonta mégis kell néhányszor valamilyen privát LLM,
akkor bérelsz arra az időre egy olyan GPU-t -ami arra a feladatra optimális.A másik alternativa, hogyha mégis kell neked valami lokális LLM futtató,
akkor összekötöd pl. a notebook upgraddel
( Egy 64GB-os RTX Spark(arm-cuda) vagy Strix Halo(x86) -val már el lehet kezdeni az ismerkedést - ami a gyakorlatban a normális kódolás leges legalját jelenti - és úgyis kell mellé egy előfizetés is )köszönöm a nagyon részletes választ!
well, persze hogy kipróbáltam, már egy éve fizetek 5x Max-ot claude-tói. És szerintem első végre nem összevissza köpködő és nem teljesesen idegesítő model az opus 5.5
Abból gondolom hogy felfognak szökni az árak hogy egyrészt nekik nem kifizetődő ilyen olcsón adni az előfizetéseket, mi még mindig első fázisokban vagyunk hidd el. Amikor még ffinetuning van és tesztelés, lassan kijön az IPO az anthropicnak is.
Meg hát [link] , de ez csak a kezdet, ugyan ez lesz mint a Hardware-el. (sajnos)
Pénzt kell csinálni nekik
Másik dolog, jó lenne futtatni nem restricted modelleket végre, mert szerintem ott is idővel annyi minden bele lesz várva hogy nagyon nehéz lesz legit projektekkel is haladni, emlékszel a Fable 5 indulásra? Engem állandóan letiltott mindenről, pedig csak saját papot ellenőriztem security review-ra, vagy csak feltettem kérdést az antennákról, szóval hát nem volt jó érzés -
- Mit értesz "normális kódolás" alatt?
- Ha valami előfizetést már kipróbáltál, akkor milyen modellt használtál?
- Milyen HW érhető el most nálad? ( Mert ha van egy PC -d 128GB -RAM -al , akkor egészen más az optimális hardware , mintha csak egy 16GB-os Laptopod lenne. )> Van eg érzésem hogy most lassan az előfizetések is egekbe fognak emelkedni hónapok alatt,
de miből következtetsz?
Ha meg tényleg ezt, hiszed, akkor vegyél egy ÉVES ELŐFIZETÉST !Szerintem elég nagy versenyt okoznak a kínai open modellek és az ezeket futtató szolgáltatók. Ha az OpenAI vagy a Claude nem jó neked, akkor tudsz váltani, mert van alternativa!
Ha olcsó előfizetés kell, akkor nézd meg a
https://opencode.ai/go -t.
a legolcsóbb "$10per month" - ami rengeteg modellt tartalmaz,
ami veri a qwen3.8-27B-t is.
És amúgy gyakran elérhetőek új ingyenes modellek is.Ha a teljes programozós előfizetési választék érdekel
akkor az kb. ez: https://hermesguide.xyz/coding-plans/ha havonta mégis kell néhányszor valamilyen privát LLM,
akkor bérelsz arra az időre egy olyan GPU-t -ami arra a feladatra optimális.A másik alternativa, hogyha mégis kell neked valami lokális LLM futtató,
akkor összekötöd pl. a notebook upgraddel
( Egy 64GB-os RTX Spark(arm-cuda) vagy Strix Halo(x86) -val már el lehet kezdeni az ismerkedést - ami a gyakorlatban a normális kódolás leges legalját jelenti - és úgyis kell mellé egy előfizetés is ) -
-
CMP 170HX, meg mindig. Igaz felment az ara, de az hasznalhato. Alatta nem sok minden van, de egy rendes 27B modelnek kell kozel 32GB memo, plusz a KV cache, ami baromira viszi a memoria, szoval 64GB azert nem art. Nekem 64GB-be fer bele egy 27B model 3db 256k contextes parhuzamos szallal.
-
-
denko
senior tag
Sziasztok,
Van eg érzésem hogy most lassan az előfizetések is egekbe fognak emelkedni hónapok alatt, elgondolkodtam lokális AI-n, szerintetek mi a best buy most ami tudja a normálisan kódolni? Spark dgx egekben van szintúgy Mac studio 128Gb, autót lehetne venni árából 
-
"... a mérkőzés izgalmas, a felek keményen harcolnak. A 65 percben(kérdésnél) az eredmény kereken 80%-os. A nézők(Én ; ) izgatottan nézik a "játékot". Az eredmény a változatos "játék" ellenére a 80. "percben"(kérdés után) is változatlanul 80%-os!..."
Poénkodtam, nyilván!
A számok viszont valósak! -
/
Tolok én is egy 200-as tesztet a (nem-hivatalos) Qwen3.8-9B-Q8-ammal, a LogiQ2-vel, Temp=0,6-on, Q8-as Cache-ekkel.
"... a mérkőzés izgalmas, a felek keményen harcolnak. A 65 percben(kérdésnél) az eredmény kereken 80%-os. A nézők(Én ; ) izgatottan nézik a "játékot". Az eredmény a változatos "játék" ellenére a 80. "percben"(kérdés után) is változatlanul 80%-os!..."
Poénkodtam, nyilván!
A számok viszont valósak! -
Na, vegre lefutott Qwen3.8-Flash-Next-GSQ-RCO-IQ3_XXS -ra BF16 KV-cache-vel a logiqa2.0, ez 86.3% lett. De joval lassabb, atlagosan 28.43 token/s volt a teszt alatt. Az eredmeny nem jobb mint az FP8-as 27B. Barhogy tesztelgetem igazabol az jon ki, hogy igy 3-4 bit korul a flash-next-el nem eri meg szenvedni, annyit ront az alacsony bitszam, hogy a 27B-hez hasonlo szintre lebutul, viszont kevesbe hasznalhato a sebessege miatt.
Most inditom az egyeb tempes 27B teszteket.
/ Tolok én is egy 200-as tesztet a (nem-hivatalos) Qwen3.8-9B-Q8-ammal, a LogiQ2-vel, Temp=0,6-on, Q8-as Cache-ekkel.
-
Na, vegre lefutott Qwen3.8-Flash-Next-GSQ-RCO-IQ3_XXS -ra BF16 KV-cache-vel a logiqa2.0, ez 86.3% lett. De joval lassabb, atlagosan 28.43 token/s volt a teszt alatt. Az eredmeny nem jobb mint az FP8-as 27B. Barhogy tesztelgetem igazabol az jon ki, hogy igy 3-4 bit korul a flash-next-el nem eri meg szenvedni, annyit ront az alacsony bitszam, hogy a 27B-hez hasonlo szintre lebutul, viszont kevesbe hasznalhato a sebessege miatt.
Most inditom az egyeb tempes 27B teszteket.
Köszi az infót, akkor nem állok neki tesztelni, a héten terveztem, de így megspóroltál nekem csomó időt
-
- nekem a Claude "magyar szöveg" generálása nagyságrendekkel jobban tetszik,
mint a Chatgpt-é. Sajnos a magyar nyelvi tudást még egy komoly benchmark se méri.Érdekes, én pont fordítva érzem. A chatgpt-vel tök jól működik, hogy a webes chat-ben magyarul tervezek, és az eredményt angolra fordított task leírásként átdobom codex-be. Az outputot meg megint bedobom a chatbe, és szépen elmagyarázza nekem amit nem értek, és így tovább.
Claude-ot meg néha magyarul sem értem, és úgy érzem ez a magyarul tervezés/magyarázás a webes chaten teljesen felesleges. -
>Opus 5.5 most mindent aláz, azt olvasom sok helyen. Ti mennyire vagytok benne, érdemes váltani GPT-ről?
>Usage, es tudás, ami számít
Amúgy mennyire tetszik neked a "GPT-6 Astra Max" ? , mert ha nem használod, akkor Opus5.5 Max - nélkül is jól megleszel. ( a benchmarkok max efforton mérnek )
És ha a Tudásba beleérted a Biológiát vagy Hacker tudást, akkor az Opus 5.5 nem biztos, hogy a legoptimálisabb modell számodra, mivel nagyon erős korlátozás van benne.
Én mindkettőt használom,
- nekem a Claude "magyar szöveg" generálása nagyságrendekkel jobban tetszik,
mint a Chatgpt-é. Sajnos a magyar nyelvi tudást még egy komoly benchmark se méri.
- Ha meg a tudás nagyon fontos, akkor a a Claude által generált választ - lefuttatom a ChatGPT -n és megkérem, hogy kritizálja meg, egészítse ki, adjon új nézőpontokat, ötleteket ... és a választ visszaadom a Claude -nak, hogy amit ebből hasznosnak talál, azt építse be.
- Ha kell képet generálni, akkor a ChatGPT-t használom. A Claude -nak mintha nem lenne ilyen képessége ( az svg, html képeken kivül )
- Sajnos nem biztos, hogy 2-3 hét múlva is ugyanolyan minőségű lesz minden.
a Claude különösen hajlamos az "AI shrinkflation" -re.Ha tényleg a tudás+usage számít,
akkor érdemes párhuzamosan használnod mindkettőt
és ugyanazt a kérdést mindkettőn lefuttatni
és végül amelyik nagyon nem tetszik azt lemondod.
( persze hamarosan úgyis kijön az OpenAI válasza, nagy a verseny )
Én - ha le kellene mondanom a kettő közül az egyiket, akkor nagyon gondban lennék.
-
Rage47
nagyúr
Igen, tudom, relatív, hogy mi a tudás itt. Igazából arra lettem volna kíváncsi, hogy ki, mire használja és ott hogy működik. De kaptam válaszokat, köszi.
Nálam mostanában a kódolás, kép generálás ment, de nemsokára kipróbálom a deep research részét is Astrával.
Most lesz valami Dev Day, kíváncsi leszek, mit lép az OpenAI. -
Opus 5.5 most mindent aláz, azt olvasom sok helyen. Ti mennyire vagytok benne, érdemes váltani GPT-ről?
>Opus 5.5 most mindent aláz, azt olvasom sok helyen. Ti mennyire vagytok benne, érdemes váltani GPT-ről?
>Usage, es tudás, ami számít
Amúgy mennyire tetszik neked a "GPT-6 Astra Max" ? , mert ha nem használod, akkor Opus5.5 Max - nélkül is jól megleszel. ( a benchmarkok max efforton mérnek )
És ha a Tudásba beleérted a Biológiát vagy Hacker tudást, akkor az Opus 5.5 nem biztos, hogy a legoptimálisabb modell számodra, mivel nagyon erős korlátozás van benne.
Én mindkettőt használom,
- nekem a Claude "magyar szöveg" generálása nagyságrendekkel jobban tetszik,
mint a Chatgpt-é. Sajnos a magyar nyelvi tudást még egy komoly benchmark se méri.
- Ha meg a tudás nagyon fontos, akkor a a Claude által generált választ - lefuttatom a ChatGPT -n és megkérem, hogy kritizálja meg, egészítse ki, adjon új nézőpontokat, ötleteket ... és a választ visszaadom a Claude -nak, hogy amit ebből hasznosnak talál, azt építse be.
- Ha kell képet generálni, akkor a ChatGPT-t használom. A Claude -nak mintha nem lenne ilyen képessége ( az svg, html képeken kivül )
- Sajnos nem biztos, hogy 2-3 hét múlva is ugyanolyan minőségű lesz minden.
a Claude különösen hajlamos az "AI shrinkflation" -re.Ha tényleg a tudás+usage számít,
akkor érdemes párhuzamosan használnod mindkettőt
és ugyanazt a kérdést mindkettőn lefuttatni
és végül amelyik nagyon nem tetszik azt lemondod.
( persze hamarosan úgyis kijön az OpenAI válasza, nagy a verseny )
Én - ha le kellene mondanom a kettő közül az egyiket, akkor nagyon gondban lennék.
-
Ez érdekes! Meg tudod nézni esetleg Temp=1,3-as értéken (kisebb mintán: 100 kérdés, hogy hamarabb kész legyen, kevés W-ból), hogy javul-e a logikai teszt-eredmény?
Nekem az a tapasztalatom"és "mondta" több MI is), hogy logikai kérdéseknél Temp=0-val szokás tesztelni, és a jelentősen magasabb érték sokat ront az logikai-teszteknél.
is ez volt, ahogy írtam.
... "csak" kíváncsi vagyok más tapasztalataira is.
+Természetesen "...0,3-as értéken..." a helyes paraméter! Bocsi...
-
3.8 27B. De ugyanennyit hoz temp=1-el is. A tempet az evalscope --generation-config "{"temperature":1}" -el allitottam.
Most temp1:gyel 87.2% lett. FP8 kvantizalas, BF16 KV cache.
Ez érdekes! Meg tudod nézni esetleg Temp=1,3-as értéken (kisebb mintán: 100 kérdés, hogy hamarabb kész legyen, kevés W-ból), hogy javul-e a logikai teszt-eredmény?
Nekem az a tapasztalatom"és "mondta" több MI is), hogy logikai kérdéseknél Temp=0-val szokás tesztelni, és a jelentősen magasabb érték sokat ront az logikai-teszteknél.
is ez volt, ahogy írtam.
... "csak" kíváncsi vagyok más tapasztalataira is.
+ -
...170-essel
"könnyű"!Komolyra fordulva: Melyik Qwen: 3.6/3.8? Az 1-es Temp kimondottan nem javasolt a 3.8-asnak.
+ infók:
0.6-ot írnak, a 3.8-asra, mint optimális!A tesztprogramok többsége valójában 0,0-ás Temp-pel fut, felülírja a te beállított értéked! Ezt érdemes megnézni, hogy mi a valódi érték teszt alatt! Nekem már 0,3-as T-vel is sokkal rosszabbat adott, mikor "megtrükköztem" kíváncsiságból.! Az általános beszélgetésre javasolt 0,6-tal meg nekem szét-ötletelte a Logq2-teszben a válaszokat: 60-64%.os lett, a 0,0-ás 74% körülivel szemben után.
Nekem az 50 kérdéses teszten a saját rendszer 84-86% közötti eredményt ad a nem-hivatalos Qwen3.8-9B-Q8-cal, kicsit "házilag-felhúzva", 55-65 perc alatt az RTX 3080M/16GB-oson, 72 token/mp átlagsebességgel.
Nem vagyunk elégedettek az eredménnyel, még "faragjuk"!
A Gemini meg nem meglepő, hogy tudja, házon belül van....
![;]](http://cdn.rios.hu/dl/s/v1.gif)
ami egy normális verziózás esetén logikus lenne ) 
/ 
Új hozzászólás Aktív témák
- Luck Dragon: Asszociációs játék. :)
- Samsung Galaxy Felhasználók OFF topicja
- LEGO klub
- exHWSW - Értünk mindenhez IS
- Épített vízhűtés (nem kompakt) topic
- Formula-1
- AMD Navi Radeon™ RX 9xxx sorozat
- Megvan a OnePlus 16 egyik fő aduja: jóval nagyobb akkumulátor érkezik
- iPhone topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- További aktív témák...
- Dell USB-C dokkolók: (K20A) WD19/ WD19S/ WD19DC + 130W, 180W, 240W töltők
- LG UltraGear 32GS95UX-B OLED Monitor! 3840x2160 / 480Hz / 0.03ms / G-Sync / FreeSync 1
- Új Dobozos Lenovo Yoga Slim 7 Prémium Fémházas Ulrabook Ultra 7 258V 14" -35% 32/1TB 2,8K 120Hz OLED
- Új Dobozos HP OmniBook 3 AI Laptop 15,6"-40% AMD Ryzen AI 5 330 16/512 Copilot+ PC,820M Graphics FHD
- HP EliteBook 845 G7 14" Ryzen 5 pro 4650U, 8-16GB RAM, 256-512GB SSD, jó akku, számla, 6 hó gar