LFM2.5-230M — evaluare ca preprocesor de rezumat / fallback conversațional (2026-08-21)

Spike de testare: se poate folosi LiquidAI/LFM2.5-230M (230M params, edge-optimized, Liquid AI) ca preprocesor local — rezumă conținut lung (email-uri, transcripturi) înainte să ajungă la Claude, ca să reducem consumul de rate limit (user_anthropic_subscription). Continuare a liniei de spike-uri din cactus-needle-function-calling-eval (acolo: pre-router pentru function calling; aici: sumarizare), aceeași motivație de fond.

Setup

Testat direct în .venv de producție echo-core — transformers 5.12.1 și torch 2.11.0 erau deja instalate (satisfac cerința oficială transformers>=5.0.0), deci fără pip install nou. Script de test și textele de input în /tmp/lfm-test (nu în repo, se pierd la reboot). Checkpoint descărcat în ~/.cache/huggingface/hub/models--LiquidAI--LFM2.5-230M (438MB, rămâne după reboot).

Input real din KB: email RO dens (validare amendament rezoluție scout.ro, ~3000 caractere, cu TL;DR existent de Claude ca reper) + fragment transcript YouTube EN (~3000 caractere, video despre AI trading).

Rezultate

Engleză: surprinzător de bună. Rezumat coerent, factual, parafrazat (nu copy-paste), fără halucinații evidente pe fragmentul testat. Latență ~6.7s/query pe CPU (6 core-uri), fără GPU disponibil pe această mașină.
Română: nefolosibil. Output amestecat cu spaniolă/portugheză și cuvinte inventate ("o spesia se presentă", "respektiv", "Resumen:... el documento solicita...") — chiar și cu prompt integral în română. Nu produce propoziții gramaticale corecte în RO.
Confirmă cardul modelului: limbile suportate oficial sunt EN, AR, ZH, FR, DE, IT, JA, KO, PT, ES — română nu e în listă, spre deosebire de Needle (26M, netestat oficial pe RO dar funcțional empiric — vezi cactus-needle-function-calling-eval). Aici, spre deosebire de Needle, absența suportului oficial s-a confirmat empiric ca blocaj real, nu doar teoretic.
Load model: 1.8-12.6s (variază, prima rulare vs. cache warm). Foarte ușor per dimensiune (438MB pe disc).

Q4_K_M (GGUF, llama.cpp) — testat local (2026-08-21)

La cererea lui Marius: cât de rapid merge quantizat, ca preprocesor CPU-only (fără să crească dimensiunea modelului). Descărcat LiquidAI/LFM2.5-230M-GGUF (fișier LFM2.5-230M-Q4_K_M.gguf, 144MB — 3x mai mic decât BF16). Rulat cu binarul llama-completion deja prezent local (/home/moltbot/prism-llama/llama-prism-b8846-d104cf1/), 6 threads CPU, același fragment EN de test (~3000 caractere, 711 tokeni prompt).

Load: ~1.1s.
Prompt eval: 711 tokeni în 1.06s (670 tok/s).
Generare: 69 tokeni în 0.57s (120 tok/s).
Total end-to-end (load+prompt+generare): ~3s, față de ~8.5s la BF16 prin transformers (load 1.8s + generare 6.7s) — ~2.8x mai rapid. Diferența vine atât din Q4 cât și din backend-ul llama.cpp (mult mai optimizat pe CPU decât transformers eager mode).
Calitate pe engleză neschimbată vizibil față de BF16 — rezumat coerent, fără degradare perceptibilă din quantizare.
Nu s-a retestat pe română — quantizarea nu schimbă cauza blocajului (model neantrenat pe RO), doar viteza; ar reproduce identic amestecul spaniolă/portugheză de la testul BF16.

Test suplimentar — fallback conversațional când Claude atinge rate limit (2026-08-21)

Marius a clarificat cazul real de utilizare: nu preprocesor de sumarizare, ci model de fallback pentru conversație directă cu el, când Claude e blocat pe rate limit. Întrebare: înțelege măcar input în română, chiar dacă generarea e stricată? Testat cu Q4_K_M (llama-completion, 3 prompturi scurte, independente de sumarizare):

Factual simplu ("Care este capitala Franței?") → răspuns halucinat: cuvânt inventat "Căspătrășești", prezentat ca fiind capitala României (nici măcar țara întrebată).
Comprehension extractiv (propoziție scurtă RO + întrebare "ce a uitat X acasă?", răspuns așteptat 1 cuvânt) → nu a răspuns, a ecoat înapoi linia de instrucțiune.
Conversație casual ("Ce mai faci?") → răspuns aproape integral în franceză.

Verdict: nu doar generarea e stricată — modelul nu procesează corect input în română la niciun nivel (factual, extractiv, conversațional), indiferent de tip de task. Mai grav decât la testul de sumarizare: aici halucinează fapte complet greșite (țară greșită), nu doar gramatică stricată.

Concluzie

Nu e viabil ca preprocesor general și nici ca fallback conversațional pe română — a se vedea și testul suplimentar de mai sus, care exclude complet acest caz de utilizare (fallback la rate limit Claude). — traficul Echo e majoritar în română (conversații Discord/Telegram/WhatsApp cu Marius), iar modelul degradează în text amestecat spaniolă/portugheză pe input RO, indiferent de limba promptului. L-ar face utilizabil doar pe un subset îngust (conținut deja în engleză — unele transcripturi YouTube, email-uri EN), care nu acoperă cazul principal de reducere a rate limit-ului.

Decizie: nicio integrare în echo-core. Nu s-a modificat cod de producție.

Dacă se reia pe viitor: varianta de rezolvat ar fi un model LFM2 mai mare (700M/1.2B) din aceeași familie, dacă lista de limbi suportate se extinde la română — de verificat pe cardul modelului înainte de a relua testul, ca să nu se repete același blocaj.

Continuare — căutare model RO pentru fallback la rate-limit Claude (2026-08-21)

Marius a cerut integrare reală (nu doar spike): un model local RO-capabil ca fallback conversațional când Claude CLI dă Error: Claude CLI error (exit 1): You've hit your session limit · resets HH:MMam (UTC) (posibil și limită totală de abonament, nu doar sesiune — de confirmat pe teren). Vezi și project_lfm2_230m_ro_fallback_eval.

Prima variantă propusă (EuroLLM-1.7B) s-a dovedit insuficientă pe context: native doar 4096 tokeni (nu 8192 cum arăta default-ul llama.cpp la load, nici 32K cum sugera raportul tehnic — aia e doar la 9B/22B, extins prin RoPE scaling). Testate două alternative Qwen3.5 (context nativ 262144 pe toată familia, GGUF oficial unsloth/Qwen3.5-*-GGUF, aceeași baterie de 3 prompturi RO):

Qwen3.5-0.8B (Q4_K_M, 508MB)

Comprehension: corect ("portofelul").
Conversațional: fluent gramatical, dar greșește calculul zilei ("Luni → Duminică" — greșit, corect ar fi marți).
Factual: eșec grav — "Care este capitala Franței?" → "Capoala Franței este București." (halucinație completă, confundă țara).
Viteză: ~32 tok/s generare, cel mai rapid dintre cele testate.

Qwen3.5-2B (Q4_K_M, 1.2GB) — cel mai bun rezultat până acum

Factual: "Capitala Franței este Paris." — corect.
Comprehension: "portofel" — corect semantic (fără articol hotărât).
Conversațional: fluent, dar aceeași greșeală de calcul zi ("Luni → Duminică") — pattern comun tuturor modelelor mici testate (LFM2.5 nu a ajuns până aici, EuroLLM a zis "miercuri", Qwen3.5-0.8B și 2B au zis "duminică"), pare limitare generică de raționament la scară mică, nu problemă specifică românei.
Context nativ: 262144 tokeni.
Viteză: load 3-11s (cold/warm), generare ~17 tok/s, sub 4s pentru răspunsuri normale.
Disponibil direct în biblioteca oficială Ollama: ollama pull qwen3.5:2b (2.7GB, tag oficial, 256K context) — zero setup manual de GGUF/Modelfile, spre deosebire de EuroLLM care ar necesita import manual.

Corecție infrastructură — Ollama nu e pe LXC 104

Marius a presupus Ollama pe LXC 104 (10.0.20.104), dar config.json → ollama.url arată http://10.0.20.161:11434 — deja folosit pentru embeddings (nomic-embed-text) și are câteva modele mici instalate (llama3.2:3b, llava:7b, smollm:135m). Ținta reală de deploy pentru fallback e .161, nu .104.

Concluzie provizorie: qwen3.5:2b via Ollama pe 10.0.20.161 e candidatul recomandat pentru fallback conversațional RO — precizie factuală comparabilă cu EuroLLM-1.7B, context 64x mai mare, deja disponibil fără import manual. Integrarea în router.py/claude_session.py (detectare rate-limit + apel către Ollama) e pas separat, nefăcut încă.

8.3 KiB Raw Blame History