Configurația noastră experimentală: un model de ~83,6 GB care rulează local pe un RTX 3060 de buget

Acest lucru este incredibil!

Qwen3.8-Flash-Next IQ3_S (~83,6 GB) rulează local pe un buget RTX 3060 12 GB cu doar 48 GB de RAM de sistem!

Până la 68 de jetoane/sec decodare, ~916 jetoane/sec procesare prompt și un prompt de 30.000 token procesat în doar 34 de secunde.

Produs de Strata de coldniko. Fără inferență în cloud. Doar hardware de consum accesibil!

Benchmark-uri complete, specificații hardware, optimizări și compromisuri de mai jos.

Puteți sări direct la concluziile cheie din secțiunea finală.

Hardware-ul din spatele acestor rezultate

Fără GPU pentru centru de date, fără server multi-GPU scump și fără configurație RAM masivă.

Întregul experiment a fost efectuat pe un PC de consum/stație de lucru destul de obișnuită.

CPU

• Intel Core Ultra 7 265 (Arrow Lake)
• 20 de miezuri / 20 de fire
• Până la 5,3 GHz
• 30 MB cache L3
• suport AVX-VNNI / BF16; nu AVX-512

Placa de baza

• ASUS Pro Q870I-C
• Chipset Intel Q870, LGA1851
• Factor de formă Mini-ITX

Memorie

• 48 GB DDR5-5600 (2 × 24 GB Micron)
• Aproximativ 46 GiB utilizabili

GPU

• NVIDIA GeForce RTX 3060 12 GB
• GA106, capacitate de calcul 8.6
• PCIe 4.0 ×16
• Limită de putere configurată de 170 W

Depozitare

• Lexar NM1090 PRO 2 TB
• PCIe 5.0 ×4 NVMe

OS

• Ubuntu 24.04.5 LTS
• Nucleul Linux 7.0.0-38
• Driver NVIDIA 615.71.10

Rețea

• Intel 1 GbE Ethernet

Detaliul crucial: modelul este mult mai mare decât VRAM și RAM disponibile combinate.

Exact asta face acest experiment interesant.

Arhitectura modelului, motorului și memoriei

Model

Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S

Două cioburi GGUF:

• 54.82 GB
• 28.80 GB
• Total: 83,62 GB (77,87 GiB)

Componente suplimentare

• Greutăți dense ambalate: ~1,5 GiB
• redactor de decodare speculativă MTP
• Adaptor de viziune BF16: ~866 MB
• Codificator vizual bazat pe CPU (12 fire)

Motor de inferență

• Strata engine 0.1.52
• Backend CUDA 13.0
• Arhitectura CUDA sm_86

Alocarea reală a memoriei

• VRAM GPU: 11,14 GiB folosit
• Experți rezidenți în RAM de sistem: 24 GiB
• Datele de experți rămase transmise în flux din NVMe
• Nicio activitate de schimb în timpul inferenței normale

Setări importante de configurare

--expert-cache auto
--prefill 4096
--spec 4
--spec-min-p 0.5
--mtp mtp/rt
--max-context 32768
--kv int8
--kv-grow
--kv-resident 32768
--vision
--vram-reserve-mib 960
--pool-workers 12
--conversation-cache-mib 1536
--prompt-cache-tail
--prompt-cache-spread
--resident-experts
--resident-budget-gib 24

Aceasta nu este o configurație convențională „încărcați întregul model în memoria GPU”.

Strata utilizează împreună memoria GPU, RAM de sistem, cache expert și stocare NVMe.

Optimizarea importantă este reducerea la minimum a transferurilor costisitoare de experți, menținând în același timp productivitatea GPU-ului.

Rezultate de referință reale

Același model, același hardware, două configurații de rutare.

Modul A: rutare expertă rapidă, orientată spre rezidență (anterior = 1,5)

Timp rece până la primul simbol:

• 1K: 3.7 s
• 4K: 4.9 s
• 8K: 9.7 s
• 16K: 17.3 s
• 30K: 33.9 s

Pentru comparație, Modul B dezactivează rutarea în funcție de rezidență (anterior = 0):

Run generație de 500 de jetoane:

• Rapid: 62 tok/s, 7,1 s total
• Precise: 21 tok/s, 20,8 s total

Măsurătorile vitezei au fost verificate încrucișat cu cronometrele de streaming la nivelul clientului.

Principala observatie:

Dezactivarea rutării părtinitoare în cache poate reduce viteza de decodare cu aproximativ 2–2,4×.

Dar există un motiv important pentru a nu lăsa rutarea agresivă activată pentru fiecare sarcină de lucru. Mai multe despre asta în secțiunea următoare.

Viteza vs calitatea modelului: compromisul ascuns

Pe această versiune a motorului Strata, GPU-urile cu ≤13 GB VRAM utilizează automat rutarea părtinitoare de rezidență:

STRATA_ROUTE_PRIOR=1.5

Acest lucru favorizează experții deja disponibili în memoria rapidă, în loc să selecteze întotdeauna experții pe care i-ar prefera routerul original.

Beneficiul este dramatic:

• Rata de accesare a cache-ului expert: 97,2% în modul rapid
• Fără părtinire: 65,3%
• Citiri de stocare în timpul sarcinii de lucru comparate: 5,5 GiB vs 46 GiB
• Viteza de decodare: aproximativ 2x mai rapidă

Dar aceasta NU este o optimizare gratuită.

Modificarea selecției experților poate modifica comportamentul modelului, poate crește divergența față de modelul original și poate afecta raționamentul îndelungat sau fluxurile de lucru ale agenților.

Conform evaluării dezvoltatorului pentru 10 sarcini de agent:

• Ruta anterioară 1.5: 4.5/10
• Rutare înainte de 0: 5.6/10

Rezultatele de referință în sine au variat între curse, deci acesta este un rezultat direcțional, nu o măsurare definitivă a calității.

Propriile mele șase verificări de agent scurt au trecut în ambele moduri.

Cu toate acestea, o serie separată de stres de unicitate a expus repetarea:

• Mod rapid: 205 linii, 96 duplicate
• Mod precis: 209 linii, 79 duplicate

Concluzia este simplă:

• Rutare rapidă pentru chat, utilizare interactivă și sarcini scurte.
• Rutare originală pentru fluxuri de lucru ale agenților mai lungi, sensibile la calitate.

Și viteza de referință nu trebuie confundată niciodată cu calitatea modelului.

Memorarea promptă în cache schimbă totul

Unul dintre cele mai impresionante rezultate nu a fost viteza de decodare. Era timpul de răspuns pentru solicitările repetate folosind același prompt.

Cu un prompt complet în cache:

Aceasta înseamnă cu aproximativ 45–90 de ori mai puțin timp până la primul simbol în aceste curse.

Cache-ul prompt face o diferență enormă atunci când interogați în mod repetat același document lung sau mențineți o conversație cu un context stabil.

Motorul este, de asemenea, configurat pentru memorarea în cache a conversațiilor:

• Bugetul cache de 1.536 MiB
• Minim 4.096 de jetoane pentru parcare
• Pragul minim de memorie liberă: 1.536 MiB

Există o captură: aceste rezultate sunt pentru solicitări identice cu un cache complet reutilizabil.

Ele nu înseamnă că noi solicitări arbitrare de 30.000 token vor procesa într-o jumătate de secundă.

Dar pentru AI local interactiv, un cache cald este un schimbător de joc.

Misterul SSD: PCIe 5.0 nu este blocajul

La început, unitatea NVMe părea suspect de lentă. Am investigat legătura PCIe, topologia de stocare și comportamentul real I/O.

Unitatea: Lexar NM1090 PRO 2 TB, PCIe 5.0 ×4.

Conexiune PCIe verificată:

• Legătura actuală: 32,0 GT/s ×4
• Legătura maximă: 32,0 GT/s ×4
• Port root CPU: 32,0 GT/s ×4

Deci, unitatea funcționează la viteza maximă a conexiunii PCIe 5.0.

Benchmark-uri de citire direct necache:

• Flux unic, blocuri de 1–4 MiB: 2,9–3,4 GB/s
• Patru fluxuri paralele: 10,94 GB/s
• Patru fluxuri, blocuri de 64 KiB: 2,25 GB/s
• Patru fluxuri, blocuri de 4 KiB: 0,26 GB/s (~63K IOPS)

Acest rezultat paralel de 10,94 GB/s este deosebit de important: depășește lățimea de bandă practică a PCIe 4.0 ×4.

De ce debitul de flux unic este mult mai mic?

Deoarece lățimea de bandă PCIe nu este același lucru cu debitul la nivel de aplicație.

Adâncimea cozii, dimensiunea I/O, paralelismul solicitărilor și latența contează.

Modelul de încărcare expert al Strata este mult mai aproape de cazul cu concurență mai mică decât de un benchmark sintetic de debit maxim.

Debitul de stocare a motorului observat:

• Rutare rapidă: ~0,3 GB/s
• Rutare originală: ~2,4 GB/s

Diferența vine de la câți experți trebuie aduși, nu de la un downgrade PCIe.

Încă un detaliu util: RTX 3060 în sine este un dispozitiv PCIe 4.0. Vederea legăturii sale la Gen1 în timp ce este inactiv este un comportament normal de gestionare a energiei.

Verificați întotdeauna ce dispozitiv măsurați înainte de a diagnostica o problemă PCIe.

O lecție importantă: nu lăsați Linux să memoreze în cache un model de 83,6 GB pe o mașină de 48 GB

Am întâlnit o problemă serioasă în timpul pornirii inițiale.

Prima configurație a permis încărcarea în buffer a fișierelor model.

Modelul este de ~83,6 GB, în timp ce sistemul are doar 48 GB de memorie RAM fizică.

Sub această încărcătură de lucru, Linux a intrat în presiune severă de recuperare a memoriei. Mașina a devenit aproape fără răspuns, inclusiv conectivitatea SSH și a necesitat o repornire forțată.

Soluția a fost schimbarea strategiei de încărcare și introducerea unor protecții de memorie.

Setări curente:

• STRATA_UNBUFFERED_LOAD=1
• STRATA_RESIDENT_HEADROOM_GIB=10
• Buget de expert rezident de 24 GiB
• Disponibilitatea memoriei a fost verificată înainte de lansare
• 12 GiB marjă de siguranță suplimentară în politica de lansare

După aceste modificări:

• Nicio activitate de schimb în timpul inferenței normale
• Aproximativ 34,6 GiB RAM în uz la punctul observat
• Aproximativ 12,7 GiB disponibile
• Generare stabilă sub sarcină

Lecția:

Este posibil să rulați un model mai mare decât memoria fizică, dar contabilizarea memoriei este absolut critică.

Presiunea din memoria cache a paginii, datele modelului fixate, experții rezidenți și memoria cache KV trebuie luate în considerare împreună.

Nu copiați orbește steaguri de performanță maximă de pe mașini cu configurații RAM mult mai mari.

Consumul de energie, costurile termice și deducția

Aceasta este o altă surpriză plăcută.

Puterea măsurată a componentelor:

Inactiv cu modelul încărcat:

• CPU: ~5.8 W
• GPU: 15–18 W

În timpul generației:

• CPU: ~62.8 W
• GPU: 152–167 W
• Scurte vârfuri GPU în jurul valorii de 174 W

Puterea totală estimată a sistemului la perete (nu măsurată folosind un contor de perete):

• Inactiv: ~54 W
• Generație: ~280 W

Temperaturi observate:

• GPU sub sarcină: 62–68°C
• GPU la inactiv: ~40°C
• NVMe: 38–47°C

Nu s-a observat nicio limitare termică.

La un preț estimat de energie electrică de 0,25 EUR/kWh:

• 24 de ore inactiv: ~0,32 EUR
• 30 de zile inactiv continuu: ~9,72 EUR
• O oră de generare activă: ~0,07 EUR

Acest lucru face ca operarea unui endpoint local AI capabil, care păstrează confidențialitatea, este complet realistă acasă.

Desigur, acestea sunt costuri estimate ale energiei electrice, nu costul total de proprietate. Sunt excluse amortizarea hardware-ului, răcirea și întreținerea.

Unde configurarea RTX 3060 nu mai are sens

Această configurație este excelentă pentru solicitări interactive scurte, dar are limite.

Cel mai important:

• Context maxim: 32.768 de jetoane
• Un prompt aproape de 32K lasă spațiu insuficient pentru generare
• Plafonul practic de referință a fost de ~30.165 de jetoane de intrare
• Gândirea/raționamentul poate consuma sute de jetoane suplimentare generate
• Sesiunile de agenți de lungă durată devin rapid constrânse

Pentru comparație, am rulat același model pe un sistem local mai puternic, cu un GPU de 24 GB.

Performanța măsurată pe acel sistem:

• Precompletare promptă 4K: 1.339 tok/s
• Decodare 4K: 94 tok/s
• Precompletare promptă 16K: 2.956 tok/s
• Decodificare 16K: 125 tok/s
• Context maxim: 262.144 de jetoane
• 15 fire de lucru

Sistemul RTX 3060 oferă un debit de pre-umplere mult mai mic și aproximativ jumătate din decodare în cazuri comparabile, cu o opteme din contextul disponibil.

Cu toate acestea, cardul de 12 GB este mult mai accesibil și rămâne impresionant de util.

Abordarea mea actuală:

• Hardware mai puternic pentru agenți complexi, de lungă durată
• GPU-uri accesibile de 12 GB pentru chat, fluxuri de lucru scurte, experimente și inferențe de rezervă

Ideea nu este să pretindem că un GPU ieftin înlocuiește o mașină de ultimă generație.

Ideea este cât de multă AI locală utilă poate rula deja pe hardware ieftin.

Ce ar mai putea fi optimizat?

Sistemul funcționează deja bine, dar există câteva căi interesante pentru experimente ulterioare.

Inferență concomitentă

Opțiunea --slots 2 ar putea îmbunătăți debitul total cu două conversații simultane.

Un randament total estimat de +10–12% este posibil pentru acest volum de lucru, dar are nevoie de validare.

Acest lucru nu înseamnă că o singură conversație devine cu 12% mai rapidă.

Loturi mai mari de pre-umplere

Curent: --prefill 4096

Candidat: --prefill auto:16384

Ferestrele mai mari de precompletare ar putea îmbunătăți procesarea promptă îndelungată, dar VRAM-ul disponibil este deja limitat.

Cu aproximativ 11,14 GiB din cei 12 GiB ai GPU-ului ocupați, comportamentul memoriei trebuie măsurat cu atenție.

Mai multă memorie RAM de sistem

Utilizarea --ple-io ram ar putea aduce mai multe date de model în memoria sistemului și poate reduce citirile de stocare.

Documentația dezvoltatorului sugerează:

• +16–31% performanță de pre-umplere
• +3–11% performanță de decodare

Dar această configurație ar necesita substanțial mai multă RAM, aproximativ 72+ GiB pentru aspectul măsurat.

Nu este practic pe configurația actuală de 48 GB.

Decodare speculativă

Decodificarea speculativă MTP este deja activată.

Acceptarea observată: ~33–41 de jetoane acceptate din 50–60 redactate, sau aproximativ 65–70%.

Context mai lung

Limita actuală de 32K este o limită de configurare operațională, nu o dovadă că modelul în sine acceptă doar 32K.

Creșterea acesteia necesită reverificarea capacității de memorie, a comportamentului cache-ului KV, a latenței și a stabilității.

Pentru această încărcătură de lucru, reducerea lecturilor costisitoare de experți și îmbunătățirea tiparelor de acces pot conta mai mult decât creșterea lățimii de bandă secvențială maximă a unității.

Ca întotdeauna: comparați volumul de lucru real, nu doar cifrele de marketing hardware.

Gânduri finale

Iată ce demonstrează acest experiment.

Un model MoE cuantificat de ~83,6 GB poate rula local pe:

• RTX 3060 12 GB
• 48 GB DDR5 RAM
• CPU Intel de consum
• PCIe 5.0 NVMe SSD
• Ubuntu + Strata

Cu rezultate măsurate până la:

• Decodare caldă de 68 tok/s
• 916 tok/s procesare promptă
• Solicitare la rece de 30.000 de simboluri în ~34 de secunde
• Solicitare de 30K în cache complet: ~0,44 s până la primul simbol
• Fără schimbare în condiții normale de funcționare

Dar există avertismente importante.

• Contextul maxim configurat este de 32K
• Rutarea rapidă expertă modifică comportamentul modelului
• Cea mai mare viteză nu este neapărat cea mai înaltă calitate
• Performanța stocării depinde de tiparele de acces
• Gestionarea memoriei necesită o reglare atentă
• Agenții de lungă durată beneficiază de un hardware mai puternic

Sunt interesat în special de economia practică a IA locală.

Nu doar valoarea de referință maximă pentru un sistem de 10.000 EUR, ci și performanța utilă atinsă pe mașinile de consum și configurații accesibile începând cu aproximativ 1.000 EUR.

Confidențialitatea, independența, costurile de operare controlate și utilitatea în lumea reală contează mai mult decât urmărirea unor cifre de referință impresionante.

Acesta este încă un experiment în evoluție și voi continua să împărtășesc măsurătorile, eșecurile, modificările configurației și îmbunătățirile.

Viitorul AI local devine deja surprinzător de accesibil.

Adăugiri ulterioare

Oh, am uitat să menționez că GPU-ul rulează cu NVIDIA Unlock, care a fost lansat cu doar câteva zile în urmă, săptămâna trecută.

Acum i-am cerut agentului meu AI să ruleze aceleași benchmark-uri fără deblocare, așa că vom putea compara rezultatele în aproximativ 15-20 de minute.

În următoarele câteva zile, deși nu astăzi, voi instala acest GPU într-un sistem care costă mai puțin de 1.000 USD și voi vedea cum funcționează acolo.

Firul original pe X · Toate noutățile