VEES to wyspecjalizowane środowisko AI dla inżynierii, które w swojej dziedzinie jest pewniejsze niż asystent ogólnego przeznaczenia. Zamiast jednego modelu, który zgaduje, pracuje równolegle wiele modeli, a wynik potwierdza deterministyczne obliczenie. Na wyjściu jedna odpowiedź, której można zaufać.
Pojedynczy model AI potrafi dać różne odpowiedzi przy drobnej zmianie pytania. VEES rozwiązuje to inaczej: pyta wiele modeli naraz, sprawdza ich odpowiedzi prawdziwym obliczeniem i składa z tego jedną, pewną odpowiedź.
Pytanie trafia nie do jednego modelu, lecz do wielu modeli pracujących równolegle. Każdy podchodzi do problemu inaczej, więc słabe i przypadkowe odpowiedzi szybko się ujawniają.
VEES zestawia propozycje modeli i sprawdza je deterministycznym solverem oraz normami ze źródła. Liczby liczy silnik obliczeniowy, a nie zgaduje model. To odcina halucynacje.
Na wyjściu dostajesz jedną, zweryfikowaną odpowiedź wraz z dowodem walidacji, czym dokładnie została policzona. Nie kilka sprzecznych wariantów do oceny, lecz wynik, któremu można zaufać.
VEES jest pomyślane dla profesjonalisty, który podejmuje decyzje na podstawie wyników i nie może pozwolić sobie na zgadywanie. Dziś pierwszym obszarem jest wiertnictwo i przewierty HDD; docelowo to ogólnoinżynierski ekspert w walizce.
Pytanie wchodzi z zewnątrz, orkiestrator rozdziela je między drafterów, deterministyczny solver liczy prawdę, weryfikatorzy sprawdzają, a synteza odsyła odpowiedź z dowodem walidacji - cała maszyneria zamknięta w jednej maszynie.
VEES to nie czat z modelem. To zamknięty, suwerenny silnik ekspercki: na jednej maszynie żyje orkiestrator klasy Kimi (replikacja Abiego), a pod nim rój modeli roboczych. Orkiestrator rozkłada zadanie, rozdziela je w roju, a prawdę bierze z deterministycznego solvera i ze źródeł - nie z „pamięci" modelu.
Orkiestrator definiuje zadanie → rój modeli rozumuje równolegle → solver liczy → weryfikator powtarza obliczenie → strażnik wyrzuca każdą liczbę bez pokrycia. Na wyjściu: odpowiedź eksperta z pełnym dowodem walidacji, czym dokładnie została policzona. Całość w jednej obudowie - model klienta nie opuszcza jego maszyny.
To przewaga Enginetrica trudna do skopiowania: anty-halucynacja jako cecha produktu klasy Enterprise. Audytowalność i suwerenność, których natywne modele językowe nie dają.
Wszystko zamknięte w jednej obudowie - od warstwy rozumowania, przez rój, po osadzenie w prawdzie.
Każda konfiguracja to inny sposób spięcia roju i narzędzi. Testujemy je po kolei i mierzymy, czy realnie podnoszą jakość - czy tylko spalają moc.
Drafter → weryfikator → strażnik na jednym modelu (qwen3.6:35b-a3b) - trzy system-prompty, łańcuch szeregowy. Strażnik realnie koryguje draft.
RdzeńN drafterów liczy niezależnie, bierzemy medianę liczb. Tłumi pojedyncze wpadki - ale nie naprawia błędu wspólnego dla wszystkich.
GłosowanieRole przełączone na programistyczne (autor → reviewer → integrator), głosowanie wyłączone. Produkuje kompletny, uruchamialny kod - nie urywki.
Zweryfikowany ✓Rój nie zgaduje fizyki - woła deterministyczny solver Rust: frac-out, hydraulika, balastowanie, dopasowania reologiczne. Każdy wynik z dowodem walidacji.
Działa ✓Każda norma/wartość tablicowa cytowana ze źródła z korpusu, zamiast „pamięci" modelu. Następny element osadzenia.
W budowieMocniejszy sprzęt → więcej instancji → warstwy równoległe biegną naprawdę równolegle, orkiestrator rozdziela zadania na wolne modele.
RoadmapJednostka mocy to jeden Blackwell - 96 GB pamięci karty (nasz dzisiejszy węzeł). Im więcej kart, tym więcej różnych rodzin modeli pracuje NAPRAWDĘ równolegle i tym większy orkiestrator stać nas utrzymać na własnym sprzęcie, bez chmury. Trzy rozwiązania teoretyczne - poprawność na każdym z nich pilnuje ten sam solver.
Solista osadzony. Jeden mocny model (qwen3.6:35b-a3b) niesie cały łańcuch, różnorodność dokładają 1-2 mniejsze rodziny, a poprawność dźwiga solver.
Dowód: solista + solver = 0,945 na inżynierii HDD - parytet z całym panelem. Suwerennie i tanio na jednej karcie.
Zmierzone ✓Rada heterogeniczna. Rój rozbity po rolach na dwie karty: drafterzy i synteza na jednej, trzy soczewki weryfikacji (Gemma + Mistral + Phi) na drugiej.
Zysk: panel weryfikatorów biegnie realnie równolegle, różne rodziny naraz - lekarstwo na skorelowane błędy. To pełny rada-solver na sprzęcie.
ProjektVEES pełny. Stać nas na duży orkiestrator klasy Kimi na WŁASNYM węźle (NVFP4) + osobna pamięć na drafterów i weryfikatorów + router + obsługa wielu zapytań naraz.
Zysk: koniec zależności od chmury, dane nie wychodzą z maszyny. Docelowe „jedna maszyna, zamknięte modele, jeden orkiestrator".
CelZasada wspólna Na każdym poziomie silnik LICZY, AI ubiera - liczby zawsze z solvera, nigdy z „pamięci" modelu. Przepustowość i jakość NVFP4 to teoria do zmierzenia baterią, nie obietnica.
Twarde liczby z pomiaru, nie z karty katalogowej. Lokalne mierzone na naszym Blackwellu (96 GB), chmurowe jako efektywny tok/s od pytania do odpowiedzi. Najważniejsza lekcja: o szybkości decyduje nie „klasa modelu", tylko czy wagi siedzą w pamięci karty, czy spadają do RAM.
| Model lokalny (Blackwell) | tok/s | status |
|---|---|---|
| qwen3.6:35b-a3b MoE | ~205 | zmierzone ✓ |
| gemma4:26b-a4b MoE | ~184 | zmierzone ✓ |
| gemma4:31b dense | ~43 | zmierzone ✓ |
| deepseek-v4-flash 284B, 151 GB | ~13,5 | offload do RAM |
| Model chmurowy (OpenRouter) | tok/s | uwaga |
|---|---|---|
| MiniMax-M2 | ~54 | najszybszy |
| Qwen3-235B thinking | ~52 | - |
| GLM-4.7 | ~39 | najwyższa jakość |
| Kimi-K2 thinking | ~38 | - |
| DeepSeek-V3.2 | ~35 | - |
Lekcja deepseek-v4-flash (284 mld parametrów, 151 GB) nie mieści się w 96 GB karty - 55 GB liczy się z RAM, stąd ~13,5 tok/s zamiast setek. Pełną prędkość osiąga dopiero drugi Blackwell (192 GB w pamięci karty). Chmura: liczy się jakość na token, nie surowa szybkość - GLM-4.7 jest wolniejszy efektywnie od MiniMaxa, a wygrał. Efektywny tok/s zawiera narzut sieci i rozumowania; część modeli lokalnych jeszcze mierzymy.
Każda topologia to inny pomysł na to, który model rozmawia z którym i po co. Testujemy je po kolei na tej samej baterii pytań i wybieramy najlepszą pod HDDSuite - tę, która najpewniej łapie błąd i najmocniej kotwiczy się w prawdzie solvera.
Spięcie: 3 drafterzy różnych rodzin równolegle (qwen3.6 + gemma4:31b + mistral) -> SOLVER -> 3 weryfikatorzy o różnych soczewkach (phi4 jednostki + gemma4:26b fizyka + qwen-coder wzór) -> synteza gpt-oss.
Dlaczego: Różnorodność rodzin rozbija skorelowane błędy, solver dokłada prawdę. Live: panel złapał niebezpieczny błąd jednego modelu.
Zrobione i przetestowane ✓Spięcie: 1 mocny drafter (gemma4:31b) -> SOLVER -> szeregowy łańcuch weryfikatorów (qwen-coder -> gemma4:26b -> qwen3.6), każdy widzi poprawki poprzednika -> synteza.
Dlaczego: Sekwencyjne pogłębianie zamiast równoległego rozproszenia. Mniej modeli, więcej przejść. Test: czy głębia bije szerokość.
Do testówSpięcie: SOLVER liczy najpierw -> jeden model ubiera wynik w prozę -> jeden weryfikator sprawdza zgodność ze solverem.
Dlaczego: Dla pytań ilościowych: minimalny model, maksymalny solver. Najszybsze i najmocniej zakotwiczone w prawdzie. Czysta forma „silnik LICZY, AI ubiera".
Do testówSpięcie: N drafterów różnych rodzin rozwiązuje niezależnie -> solver jako arbiter liczb -> panel sędziów ocenia każdą całość -> wybór NAJLEPSZEJ + zaszczepienie najlepszych fragmentów.
Dlaczego: Selekcja najlepszej odpowiedzi zamiast uśredniania. Wybrałby model poprawny zamiast mieszać go z błędnym.
Do testówT5 · Router (później): orkiestrator klasyfikuje pytanie i kieruje do najlepszej sub-topologii - najbardziej „VEES".
Tu trzymamy werdykty. Nie „wydaje się" - tylko zmierzone. Zakładki pokazują kolejne testy i to, czy dany kierunek potwierdził się, czy upadł.
Jakości nie da się dołożyć liczbą modeli. Model ręczący za model nie naprawia wspólnego błędu, a głosowanie nie pomaga. Trzeba dołożyć prawdę spoza modelu - solver i retrieval.
Przy generacji kodu z dobrą specyfikacją drafter ma mniej miejsca na konfabulację, a reviewer łapie realne bugi. Wniosek: rój jest mocny tam, gdzie zadanie jest jednoznaczne - i tam ma odciążać.
VEES jest w testach. Ta strona aktualizuje się przy każdym kroku: nowa konfiguracja, nowy benchmark, nowy werdykt - dobra koncepcja czy ślepa uliczka. Bez upiększania, z liczbami.
Most do solvera działa. Następne: solver jako rola „POLICZ" w łańcuchu, retrieval norm, benchmark v2 z twardym progiem, dobór orkiestratora.