Local LLM Arena #5
Pierwszy prawdziwy test GPT-OSS jako lokalnego agenta programistycznego przyniósł więcej informacji, niż się spodziewałem — tylko niekoniecznie o samym modelu.
Okazało się, że pierwsza wersja testu miała problem z izolacją środowiska Codex CLI. Do kontekstu lokalnego modelu trafiały informacje o wtyczkach i narzędziach, które nie miały nic wspólnego z zadaniem programistycznym.
Dlatego wyniku tego testu nie traktuję jako miarodajnego wyniku GPT-OSS.
Zacząłem więc poprawiać środowisko: czyste sesje, brak chmurowego fallbacku, izolacja hidden testów, kontrola retry, timeouty i dodatkowa diagnostyka.
I tutaj pojawił się kolejny problem.
Sam system testujący zrobił się zbyt skomplikowany.
Kolejne preflighty potrafiły zawieszać procesy na wiele godzin, a podczas ostatniej próby Antigravity doszedł do około 48 GB (?!?!?) zajętej pamięci na MacBooku Air M4 z 16 GB RAM.
System w końcu przestał odpowiadać i potrzebny był twardy restart.
Na szczęście właściwy Trial #2 nigdy nie został uruchomiony, a po restarcie Mac wrócił do normalnego stanu: 0 MB swapu i około 87% wolnej pamięci.
Wniosek jest prosty: nie ma sensu dokładać kolejnych warstw do wadliwego harnessu.
Teraz robię krok wstecz.
Codex ma przeprowadzić audyt całej obecnej infrastruktury i pomóc zaprojektować prostszą wersję V4.
Założenia są już inne:
– każdy proces ma twardy timeout,
– żadnego czekania godzinami,
– test ma własny niezależny System Guard,
– w razie problemów zatrzymywana jest tylko grupa procesów trialu,
– hidden testy są całkowicie poza zasięgiem modelu podczas kodowania,
– iCloud nie jest częścią krytycznej ścieżki,
– Antigravity ma tylko przygotować i uruchomić test, a nie czekać na niego godzinami.
Cel się nie zmienił.
Tym razem jednak najpierw trzeba mieć pewność, że sam test nie jest groźniejszy dla Maca niż model, który ma sprawdzać.
#LocalLLM #LLM #AI #AppleSilicon #MacBookAir #M4 #LMStudio #Codex #GPTOSS #Coding #OpenSourceAI