Pierwsza faza projektu zakładała ekonomiczne wejście — wykorzystanie sprzętu z rynku wtórnego jako bazy do eksperymentowania z lokalnymi LLM.

Platforma LGA1150 z procesorem Intel Core i7-4790 stanowiła rozsądny punkt startowy: cztery rdzenie Haswell z obsługą Hyper-Threading, stabilna platforma DDR3, dostępność używanych komponentów. Dwie karty NVIDIA GeForce RTX 3060 zostały dobrane jako wydajne, dwunastogigabajtowe jednostki zdolne do uruchamiania modeli 7B–14B w pełni z VRAM.

The first phase aimed for cost-effective entry — leveraging second-hand hardware as a base for experimenting with local LLMs.

The LGA1150 platform with an Intel Core i7-4790 was a sensible starting point: four Haswell cores with Hyper-Threading support, stable DDR3 platform, abundant used component availability. Two NVIDIA GeForce RTX 3060 cards were chosen as capable 12 GB units able to run 7B–14B models fully from VRAM.

Migracja na platformę AMD AM4 z zachowaniem obu kart GPU. Nowa płyta główna, procesor i pamięć RAM przy minimalnych kosztach przejścia.

Kluczowym celem fazy 2 było odblokowanie ograniczeń poprzedniej platformy bez wymiany kart graficznych. ASUS PRIME X570-PRO z Ryzenem 7 3700X dostarcza PCIe 4.0, 8 fizycznych rdzeni i obsługę do 128 GB DDR4 — zostawiając duży margines na dalszy rozwój. Jednym z wyzwań fazy był błąd negocjacji PCIe przy dwóch kartach, naprawiony przez aktualizację BIOS do wersji 5044 (AGESA ComboV2PI 1.2.0.Cc).

Faza 2 przyniosła również migrację backendu z Ollama na llama.cpp — co w połączeniu z podwojeniem RAM do 64 GB otworzyło dostęp do zupełnie nowej klasy modeli. Architektury MoE (Mixture of Experts) takie jak Gemma4 czy Qwen3.6-35b wymagają znacznie więcej pamięci RAM niż wskazuje rozmiar pliku modelu — eksperci nieaktywni w danym forward pass muszą rezydować w RAM, nie w VRAM. 32 GB z fazy 1 było dla nich za małe; 64 GB odblokowuje je w całości.

Migration to AMD AM4 platform while retaining both GPU cards. New motherboard, CPU and RAM at minimal transition cost.

The key goal of phase 2 was to remove the bottlenecks of the previous platform without replacing the graphics cards. ASUS PRIME X570-PRO with Ryzen 7 3700X delivers PCIe 4.0, 8 physical cores and support for up to 128 GB DDR4 — leaving significant room for further development. One challenge was a PCIe negotiation bug with two cards installed, resolved by updating BIOS to version 5044 (AGESA ComboV2PI 1.2.0.Cc).

Phase 2 also brought a backend migration from Ollama to llama.cpp — which, combined with doubling RAM to 64 GB, unlocked an entirely new class of models. MoE (Mixture of Experts) architectures like Gemma4 and Qwen3.6-35b require far more RAM than their model file size suggests — inactive experts must reside in RAM, not VRAM, during each forward pass. The 32 GB from phase 1 was insufficient; 64 GB unlocks them fully.

Faza 2 ujawniła ważną prawidłowość: przy konfiguracjach multi-GPU szyna PCIe jest krytycznym wąskim gardłem, którego wpływ jest niewidoczny w benchmarkach modeli małych (7B-14B mieszczących się w VRAM jednej karty), ale dramatyczny dla modeli wymagających spanu. Dopiero qwen3.5:27b — zmuszony przesyłać tensory między kartami przez szynę PCIe podczas każdego forward pass — ujawnił degradację Gen1 jako 34% regresję.

Diagnostyka wymagała pełnego przejścia przez warstwy problemu: od podejrzenia konfiguracji Ollamy, przez analizę drzewa PCIe (lspci -tv), po ustalenie że obie karty wiszą bezpośrednio na CPU root complexie 03.1 i 03.2 — co wykluczyło chipset jako przyczynę i wskazało na znany bug AGESA przy dwóch urządzeniach PCIe 4.0 na tym samym root porcie.

Druga obserwacja: podwojenie RAM (32→64 GB) miało większy praktyczny wpływ niż zmiana CPU. Czasy ładowania modeli spadły o 75-96% — nie dlatego że RAM jest szybszy, ale dlatego że modele przestały wymagać swap i trafiły w całości do pamięci operacyjnej skąd są ładowane przez DMA do VRAM. To efekt ilości, nie prędkości.

Anomalia prompt eval dla qwen2.5:7b (spadek z 1823 do 836 tok/s między fazą 1 a 2) pozostaje niewyjaśniona. Hipoteza: w fazie 1 Ollama mogła ładować ten model na oba GPU jednocześnie zwiększając throughput prompt eval, podczas gdy w fazie 2 zmiana konfiguracji PCIe spowodowała że model trafia tylko na jeden GPU. Nie wpływa to na praktyczne użycie (generowanie jest szybsze), ale warto zbadać przy okazji fazy 3.

Phase 2 revealed an important pattern: in multi-GPU configurations, the PCIe bus is a critical bottleneck that's invisible in benchmarks of small models (7B-14B fitting in a single card's VRAM), but dramatic for models requiring spanning. Only qwen3.5:27b — forced to transfer tensors between cards via PCIe on every forward pass — exposed the Gen1 degradation as a 34% regression.

Diagnosis required traversing all problem layers: from suspecting Ollama configuration, through PCIe tree analysis (lspci -tv), to establishing that both cards hang directly on CPU root complex 03.1 and 03.2 — ruling out the chipset as cause and pointing to a known AGESA bug with two PCIe 4.0 devices on the same root port.

Second finding: doubling RAM (32→64 GB) had greater practical impact than the CPU change. Model load times dropped 75-96% — not because RAM is faster, but because models no longer required swap and fit entirely in memory, loaded via DMA to VRAM. This is a capacity effect, not a speed effect.

The prompt eval anomaly for qwen2.5:7b (drop from 1823 to 836 tok/s between phase 1 and 2) remains unexplained. Hypothesis: in phase 1, Ollama may have loaded this model across both GPUs simultaneously increasing prompt eval throughput, while in phase 2 the PCIe configuration change caused the model to land on only one GPU. Doesn't affect practical usage (generation is faster), but worth investigating in phase 3.

Wymiana dwóch kart NVIDIA RTX 3060 (2× 12 GB) na pojedynczą AMD Radeon RX 7900 XTX z 24 GB VRAM. Eliminacja problemu multi-GPU span, trzykrotny wzrost bandwidth, dostęp do modeli 35B z pojedynczej karty.

Przejście na RDNA3 i stos ROCm/Ollama okazało się przełomowe. Karta uruchomiona 19 maja 2026 — benchmarki przeprowadzono tego samego dnia przy użyciu llama.cpp jako backendu.

Replacing two NVIDIA RTX 3060 cards (2× 12 GB) with a single AMD Radeon RX 7900 XTX with 24 GB VRAM. Elimination of multi-GPU span issues, threefold bandwidth increase, access to 35B models from a single card.

The transition to RDNA3 and the ROCm/Ollama stack proved transformative. Card installed on 19 May 2026 — benchmarks run the same day using llama.cpp as backend.

Przejście na pojedynczą kartę 24 GB VRAM okazało się bardziej transformacyjne niż zmiana CPU i płyty w fazie 2. Kluczowym wnioskiem jest to, że dla lokalnych LLM przepustowość VRAM (bandwidth) ma znacznie większe znaczenie niż TFLOPS — stąd wzrost z ~360 GB/s (RTX 3060) do 960 GB/s (7900 XTX) bezpośrednio przekłada się na 3-4× szybsze generowanie dla modeli mieszczących się w VRAM.

Eliminacja spanu między kartami okazała się jeszcze ważniejsza niż oczekiwano. qwen3.5:27b wzrósł z 11.5 do 37.3 tok/s (+224%) — nie tylko dlatego że karta jest szybsza, ale przede wszystkim dlatego że zniknął koszt transferu tensorów przez szynę PCIe podczas każdego forward pass. To potwierdza tezę z fazy 2: multi-GPU span z PCIe jest drogi nawet przy Gen4.

Anomalia reasoning models: qwen3.5-27b i qwen3.6-27b osiągają tylko 37 i 36 tok/s pomimo że 24 GB VRAM powinno wystarczyć i bandwidth jest trzykrotnie wyższy. Powodem jest architektura thinking/CoT tych modeli — generują długie wewnętrzne łańcuchy rozumowania przed każdą odpowiedzią, co samo w sobie jest powolne niezależnie od sprzętu. Model qwen3.5-28b-reap (ta sama baza z obciętym thinking) osiąga 78.3 tok/s — 2× szybciej. To nie jest ograniczenie sprzętowe, lecz architektoniczne.

Nowa klasa możliwości: qwen3.6-35b działa na 118 tok/s — model tej wielkości był wcześniej niemożliwy do uruchomienia w rozsądnej jakości na dwóch RTX 3060. 24 GB VRAM na jednej karcie odblokowuje całą klasę modeli 30B-35B w dobrych kwantyzacjach (Q5/Q6), które oferują zauważalnie lepszą jakość niż 14B przy wciąż wysokiej prędkości.

The transition to a single 24 GB VRAM card proved more transformative than the CPU and motherboard change in phase 2. The key finding is that for local LLMs, VRAM bandwidth matters far more than TFLOPS — hence the increase from ~360 GB/s (RTX 3060) to 960 GB/s (7900 XTX) directly translates to 3-4× faster generation for models fitting in VRAM.

Eliminating inter-card spanning proved even more significant than expected. qwen3.5:27b jumped from 11.5 to 37.3 tok/s (+224%) — not just because the card is faster, but primarily because the cost of transferring tensors across the PCIe bus on every forward pass disappeared. This confirms the phase 2 hypothesis: multi-GPU PCIe spanning is expensive even with Gen4.

Reasoning model anomaly: qwen3.5-27b and qwen3.6-27b achieve only 37 and 36 tok/s despite 24 GB VRAM being sufficient and bandwidth being threefold higher. The reason is the thinking/CoT architecture of these models — they generate long internal reasoning chains before each response, which is inherently slow regardless of hardware. Model qwen3.5-28b-reap (same base with thinking stripped) achieves 78.3 tok/s — 2× faster. This is an architectural constraint, not a hardware one.

New capability class: qwen3.6-35b runs at 118 tok/s — a model of this size was previously impossible to run with reasonable quality on two RTX 3060 cards. 24 GB VRAM on a single card unlocks an entire class of 30B-35B models in good quantizations (Q5/Q6), which offer noticeably better quality than 14B while still achieving high speeds.

Druga karta AMD Radeon RX 7900 XTX — 48 GB VRAM lacznie. Przejscie z basic chat na agentic AI: kontekst 131k-480k zamiast 8k, obsluga modeli 70B-80B, embedding na CPU. TPS spadl o ~40%, ale context urósł 16-32x — to zmiana kategorii, nie regresja.

Faza 4 miala jeden cel: odblokowanie agentic AI. Narzedzia takie jak opencode, opendesign, roo/zoo - wlasne serwery MCP wymagaja minimum 64k kontekstu — czesto 131k+. W fazie 3 benchmarki pokazywaly 100-140 tok/s, ale na domyslnym kontekscie ~8k (maksymalnie wyciagalem do 32k, co wystarczalo tylko do prostych i krotkich zadan agentowych). Przy 8k kontekscie agent nie jest w stanie przeanalizowac calego projektu, przetworzyc dlugiej rozmowy ani utrzymac spojnego stanu. Faza 4 to swiadomy kompromis: TPS spadl, ale kontekst urósł 16-32x, odblokowujac klase zastosowan wczesniej niedostepna na tym sprzecie.

Architektura dual-GPU rozni sie fundamentalnie od fazy 1 (2x RTX 3060). Dzieki HIP_VISIBLE_DEVICES kontrolujemy per-model która karta jest uzywana: male modele (7B-35B) dzialaja na jednym GPU z pelna predkoscia bez narzutu PCIe, a tylko ciezkie modele (48B-80B) spanuja obie karty. Embedding (nomic-embed-text) zostal przeniesiony na CPU — ~50ms zamiast 14ms na GPU, ale zero VRAM i zero contention z chat modelami.

A second AMD Radeon RX 7900 XTX — 48 GB total VRAM. The transition from basic chat to agentic AI: context 131k-480k instead of 8k, 70B-80B model support, CPU-based embedding. TPS dropped ~40%, but context grew 16-32x — this is a category change, not regression.

Phase 4 had one goal: unlocking agentic AI. Tools like opencode, opendesign, roo/zoo - custom MCP servers require a minimum of 64k context — often 131k+. In phase 3, benchmarks showed 100-140 tok/s, but with default context ~8k (max 32k - weak agentic, simple tasks only). At 8k context, an agent cannot analyze an entire project, process long conversations, or maintain coherent state. Phase 4 is a conscious trade-off: TPS dropped, but context grew 16-32x, unlocking a class of applications previously unavailable on this hardware.

The dual-GPU architecture fundamentally differs from phase 1 (2x RTX 3060). Using HIP_VISIBLE_DEVICES we control per-model which card is used: small models (7B-35B) run on a single GPU at full speed with no PCIe overhead, while only heavy models (48B-80B) span both cards. Embedding (nomic-embed-text) was moved to CPU — ~50ms instead of 14ms on GPU, but zero VRAM usage and zero contention with chat models.

Trzy modele, które nie miescily sie w 24 GB VRAM pojedynczej karty. Dzieki drugiej 7900 XTX sa w pelni odblokowane — kazdy z inna charakterystyka:

Three models that did not fit in 24 GB VRAM of a single card. Thanks to the second 7900 XTX, they are fully unlocked — each with different characteristics:

nomic-embed-text (~260 MB, 137M params) zostal przeniesiony na CPU. Efekt: embedding dziala w ~50ms (vs 14ms na GPU) — roznica pomijalna w pipeline RAG gdzie chat trwa ~3.5s. Zysk: 0 MB VRAM uzyte, zero contention z modelami chat. Testy potwierdzaja brak regresji TPS przy równoleglym dzialaniu embedding + chat.

nomic-embed-text (~260 MB, 137M params) was moved to CPU. Result: embedding runs in ~50ms (vs 14ms on GPU) — a negligible difference in a RAG pipeline where chat takes ~3.5s. Benefit: 0 MB VRAM used, zero contention with chat models. Tests confirm no TPS regression when running embedding + chat simultaneously.

Druga karta to nie tylko wiecej VRAM — to zmiana kategorii uzycia. Faza 3 z single GPU 24 GB byla wystarczajaca dla basic chatu na malym kontekscie (8k). Faza 4 z 48 GB umozliwia realna prace agentowa: analize calego repozytorium kodu, dlugie sesje RAG, wieloetapowe pipeliney reasoning. Dla narzedzi takich jak opencode, opendesign, roo/zoo, które wymagaja 64k-131k kontekstu, faza 3 byla po prostu niekompatybilna. Faza 4 to odblokowuje.

HIP_VISIBLE_DEVICES eliminuje koszt PCIe dla malych modeli. W fazie 1 modele 7B-14B musialy byc spanowane miedzy dwoma RTX 3060 przez PCIe Gen3, co kosztowalo 30-40% TPS. W fazie 4 male modele dzialaja na jednym GPU (0), bez narzutu miedzygpu. Tylko ciezkie modele spanuja obie karty — i robia to przez PCIe 4.0, które jest 2x szybsze niz w fazie 1.

Embedding na CPU to wlasciwa decyzja. Model embeddingu wazy 260 MB i na CPU dziala w ~50ms — wystarczajaco szybko dla RAG pipelineu. Zwalnia to GPU calkowicie dla modeli chat, eliminujac contention, który byl widoczny w fazie 3 gdy embedding i chat walczyly o ten sam GPU.

Kimi-Linear-48B to najciekawszy model fazy. Hybrydowa architektura (KDA + MLA + MoE) z 48B total / 3B active params, natywny kontekst 1M. Na 2x 7900 XTX stabilnie dziala do 480k tokenow przy ~48 tok/s. Model wymagal builda llama.cpp z wsparciem kimi-linear (PR #18755, wbudowany w build 8849), a cache-type-v q4_0 nie dziala z n_embd_head_v=72 — trzeba uzyc domyslnego f16 dla V cache.

A second card is not just more VRAM — it is a category change. Phase 3 with single GPU 24 GB was sufficient for basic chat at small context (8k). Phase 4 with 48 GB enables real agentic work: full repository code analysis, long RAG sessions, multi-step reasoning pipelines. For tools like opencode, opendesign, roo/zoo, which require 64k-131k context, phase 3 was simply incompatible. Phase 4 unlocks this.

HIP_VISIBLE_DEVICES eliminates PCIe cost for small models. In phase 1, 7B-14B models had to be spanned across two RTX 3060 cards via PCIe Gen3, costing 30-40% TPS. In phase 4, small models run on a single GPU (0), with no cross-GPU overhead. Only heavy models span both cards — and they do so via PCIe 4.0, which is 2x faster than in phase 1.

CPU embedding is the right call. The embedding model weighs 260 MB and runs on CPU in ~50ms — fast enough for RAG pipelines. This frees GPU entirely for chat models, eliminating the contention visible in phase 3 when embedding and chat fought for the same GPU.

Kimi-Linear-48B is the most interesting model of this phase. Hybrid architecture (KDA + MLA + MoE) with 48B total / 3B active params, native 1M context. On 2x 7900 XTX it runs stably up to 480k tokens at ~48 tok/s. The model requires a llama.cpp build with kimi-linear support (PR #18755, built into build 8849), and cache-type-v q4_0 does not work with n_embd_head_v=72 — use default f16 for V cache.

Koncepcja docelowej platformy dla projektu — przejście na architekturę klasy workstation z AMD Threadripper PRO, oferującą przepustowość PCIe i pamięci nieosiągalną na platformach konsumenckich.

To wczesna wizja, nie konkretny plan. Decyzja o migracji będzie zależeć od tego, czy platforma AM4 okaże się wystarczająca po fazach 3 i 4, oraz od dostępności i cen sprzętu Threadripper w czasie decyzji.

The concept for the project's ultimate platform — migration to a workstation-class architecture with AMD Threadripper PRO, offering PCIe and memory bandwidth unachievable on consumer platforms.

This is an early vision, not a concrete plan. The migration decision will depend on whether the AM4 platform proves sufficient after phases 3 and 4, and on Threadripper hardware availability and pricing at decision time.