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