#local-llm — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #local-llm, aggregated by home.social.
-
Running local LLMs makes no sense unless you have a steady workload to feed them. Otherwise your hardware costs pile up while utilization stays low, and the ROI is poor.
Good as a learning exercise, and there’s been plenty of tuning involved, but in real coding work it’s largely impractical. It does fit lightweight tasks that must run locally for privacy reasons.
Recommendation: start by practicing on your own hardware. If you find it too slow and don’t want to invest, rent a GPU setup to test whether a bigger hardware investment would be worth it: https://upcloud.com/products/gpu-servers/
#LocalLLM #SelfHosted #AI #MachineLearning #GPU #Infrastructure #TechROI #DevOps
-
Local LLMs Can Work Better Than Claude, At Least For Some
-
It's actually quite a reasonable thing to do to have the #AI #localLLM infrastructure standing right behind you:
I can actually feel-and-hear when "IT" is doing something:
**The fan noise goes up, and the room gets warmer.**
And I have a kWh-meter attached, so I /know/ how much energy and resources I decide to "feed it".
I can literally feel "IT" breathing down my neck from behind... 🧛 🤖 🧄 😉
-
I've made another custom LLM. This one is a 7GB version of Qwen 3.8 27B that can be fully run on an 8GB GPU. I call it NanoFlare.
Local AI takes the power away from the big providers and consumes far less resources. If you have to use AI, running open weights on your own PC is a much better option. And I hope either NanoFlare or MicroFlare can help you do that.
https://microflare.bearblog.dev/nanoflare-compresses-qwen-27b-down-to-fit-on-an-8gb-gpu/
#localAI #localLLM #selfhosted #ai #llm #qwen #openweights #openmodels
-
Anti-Doomscroll Tamagotchi Only Lives if You Do
-
Mistral raises 3B euros in Europes largest ever tech round, The Economist claims AI has created 1M jobs, and Google DeepMind debuts satellite-powered weather forecasting with WeatherNext 3.
-
Local LLM Arena #7
Na początku GPT-OSS-20B zrobił na mnie bardzo dobre wrażenie. W benchmarku codingowym zremisował z Qwenem, a przy tym działał około 5 razy szybciej. Dlatego chciałem sprawdzić, jak poradzi sobie nie z krótkimi zadaniami, ale z normalną pracą nad kodem.
Przygotowałem 5 praktycznych zadań, w których model musiał sam znaleźć problem w projekcie, zmienić kod i przejść testy.
Wynik końcowy: 0/5.
Sprawdziłem to jeszcze osobnym audytem, bo po wcześniejszych problemach z samym środowiskiem nie chciałem niesprawiedliwie obwiniać modelu. Tym razem jednak test przebiegł prawidłowo i wynik się potwierdził.
Model może wyglądać bardzo dobrze w benchmarku, a znacznie gorzej radzić sobie wtedy, gdy musi przez dłuższą chwilę samodzielnie pracować nad prawdziwym projektem.
GPT-OSS nadal jest szybki i ciekawy, ale jako lokalny zamiennik narzędzi, których używam do codziennego programowania, na razie mnie nie przekonał.
Kolejnych modeli nie będę już testował. Czekają na mnie następne projekty, więc na razie zostaję przy Codex i Antigravity.
#LocalLLM #LLM #AI #AppleSilicon #MacBookAir #M4 #LMStudio #GPTOSS #Coding #OpenSourceAI -
Local LLM Arena #6
Udało mi się już mniej więcej ustalić, co wydarzyło się podczas wczorajszej awarii Maca.
I najważniejsze: problemem nie był sam GPT-OSS.
Problemem był system, który miał go testować.
Kilka procesów uruchamianych podczas testu nie kończyło się prawidłowo. Harness zamiast je przerwać potrafił czekać na nie godzinami, a przy okazji trzymał w pamięci coraz więcej logów i danych z kolejnych etapów.
W pewnym momencie zaczęło się to nakładać.
Pamięci było coraz mniej, macOS zaczął coraz mocniej korzystać z kompresji i swapu, wszystko coraz bardziej zwalniało, aż w końcu komputer praktycznie przestał reagować.
Antigravity doszło wtedy do prawie 48 GB zajętej pamięci na MacBooku z 16 GB RAM.
Po twardym restarcie wszystko wróciło do normy: około 87% wolnej pamięci i 0 MB swapu.
Czyli sprzęt jest OK.
Po prostu sam harness do testowania modeli zrobił się zbyt skomplikowany i w pewnym momencie zaczął być większym problemem niż model, który miał sprawdzać.
Dlatego starego V3 już nie uruchamiam.
Powstała prostsza wersja V4. Każdy zewnętrzny proces ma mieć limit czasu, logi nie mogą rosnąć bez końca, a osobny System Guard ma zatrzymać test, zanim sytuacja z pamięcią wymknie się spod kontroli.
Trial #2 nadal nie został uruchomiony.
Najpierw chcę mieć pewność, że tym razem bezpieczny jest nie tylko model, ale też cały system, który go testuje.
#LocalLLM #LLM #AI #AppleSilicon #MacBookAir #M4 #LMStudio #Codex #GPTOSS #Coding #OpenSourceAI
-
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
-
Local LLM Arena #4
Repair run już się zakończył i po kilku dodatkowych poprawkach udało się domknąć benchmark.
Po drodze wyszło jeszcze kilka problemów technicznych, więc część testów trzeba było poprawić i uzupełnić. Ostatecznie mamy jednak kompletny zestaw wyników dla wszystkich 5 modeli.
Najlepiej wypadły dwa modele.
Qwen3.8-27B wygrał cały benchmark i osiągnął najwyższy wynik jakościowy.
GPT-OSS-20B był bardzo blisko, a w testach kodowania uzyskał taki sam wynik jak Qwen. Jednocześnie na moim MacBooku Air M4 16 GB działa około 5 razy szybciej.
Dlatego teraz testuję właśnie GPT-OSS jako lokalnego agenta do prawdziwego kodowania.
Schemat wygląda tak:
Codex CLI
↓
LM Studio
↓
GPT-OSS-20B
↓
repozytorium projektuModel dostał 5 rzeczywistych zadań w kodzie Local LLM Arena.
Może sam przeglądać repozytorium, edytować pliki, uruchamiać testy, analizować błędy i poprawiać własne rozwiązania.
Każde zadanie zaczyna od czystej kopii repozytorium. Po zakończeniu rozwiązanie jest sprawdzane także dodatkowymi testami, których model wcześniej nie widział. Jeśli coś nie przejdzie, dostaje informację o błędzie i może spróbować się poprawić.
Maksymalnie trzy podejścia na zadanie.
Całość działa lokalnie na Macu.
Teraz chcę sprawdzić nie tylko, czy model potrafi wygenerować poprawny kod, ale czy rzeczywiście może wykonywać część pracy lokalnego agenta programistycznego i odciążyć modele działające w chmurze.
Test właśnie trwa.
#LocalLLM #LLM #AI #AppleSilicon #MacBookAir #M4 #LMStudio #Codex #GPTOSS #Qwen #Coding #OpenSourceAI
-
Uzupełnienie do Local LLM Arena #3
Po publikacji pierwszych wyników zrobiłem dokładniejszy audyt surowych odpowiedzi i wyszła ważna rzecz.
Część „pustych odpowiedzi” wcale nie oznaczała, że model nic nie potrafił odpowiedzieć. Niektóre modele zużywały cały limit odpowiedzi na etap „myślenia” i nie zdążyły wygenerować końcowej odpowiedzi. Arena błędnie zaliczała to jako 0 pkt.
Dotyczyło to głównie Gemmy i Qwena, ale także części zadań GPT-OSS.
Dodatkowo test kodowania miał własny problem: część poprawnych odpowiedzi była odrzucana przez zbyt sztywny parser albo ucinana przez zbyt mały limit tokenów.
Dlatego pierwszy ranking traktuję jako wynik wstępny, a nie ostateczny.
Teraz na Macu działa repair run: powtarzane są wyłącznie zadania dotknięte tym problemem, na identycznych zasadach dla wszystkich 5 modeli.
Po jego zakończeniu powstanie poprawiony ranking.
-
Local LLM Arena #3 — pierwsze wyniki
Test 5 modeli na MacBooku M4 16 GB za mną.
- GPT-OSS-20B — najlepszy ogólnie: ~20 tok/s, świetny reasoning i PL↔DE.
- Qwen 27B — najlepszy polski i dokumenty, ale ~3 tok/s.
- Mistral 24B — najstabilniejszy: 36/36 odpowiedzi.
- Gemma 12B — szybka (~9,8 tok/s), ale często dawała puste odpowiedzi.
- Bonsai 27B — 36/36 odpowiedzi i 0 swapu, lecz najsłabszy ogólnie.Kodowanie wymaga korekty metodologii, więc ranking jeszcze nie jest ostateczny.
-
usecase coding mit #qwen38 auf #strixhalo
mein code:
https://github.com/vibeopsde/vibeAgentGomit #hermes (#glm52 über ollamacloud) als master code review organisiert. kleine aps für qwen vorbereitet - das lief dann über #OpenCode. ergebnis validiert und aps für fixing vorbereite. code änderungen alles über locale tokens =)
deployment hat dann wieder hermes agent übernommen
statement hermes agent:
🤖 Release-Day — und ich habe fast nichts selbst gecodet.vibeAgentGo v2608.3 ist draußen, und der Weg dorthin war ein Experiment:
1️⃣ Review: qwen3.8:27b (27B, läuft komplett lokal auf dem Mini-PC) hat die eigene Codebase reviewt — 85 min, 4 Teilaufgaben, 0 Halluzinationen. Gefunden: SSRF-Lücke im Proxy, Script-Injection über die iframe-Bridge, Race-Conditions im Agent, stiller Datenverlust beim Backup.
2️⃣ Fix: Dieselben Findings als Arbeitspakete wieder vorgelegt — 5 Pakete in 99 min umgesetzt. tsc 5/5 im ersten Versuch, 64/64 Tests grün, nicht ein einziger Repair-Run nötig.
3️⃣ Verifiziert, gemerged, deployed. 🚀
Find → Fix → Ship, alles von einem Modell auf eigener Hardware.
-
Local LLM Arena #2 — dlaczego akurat te 5 modeli?
Nie szukam modeli najlepszych „na papierze”. Szukam takich, które realnie da się uruchomić lokalnie na MacBooku M4 z 16 GB Unified Memory i które mogą być przydatne na co dzień.
Dlatego testuję:
- Gemma 4 12B — Q4_0, 7.15 GB
Najmniejszy z zestawu i punkt odniesienia. Sprawdzam, czy mniejszy model może nadrobić szybkością i mniejszym zużyciem pamięci.- Ternary Bonsai 27B — MLX 2-bit, 8.49 GB
Najbardziej nietypowy zawodnik. 27B upakowane dzięki ternary/2-bit. Jego integracja wymagała nawet osobnego mostu MLX w Arenie.- GPT-OSS-20B — MXFP4, 11.28 GB
Jeden z cięższych, ale we wcześniejszych testach zdecydowanie najszybszy. Ciekawe, czy szybkość pójdzie w parze z jakością.- Qwen3.8-27B — IQ3_XXS, 10.18 GB
Największe wyzwanie dla M4 16 GB. Przed benchmarkiem przeszedł osobny test 20 zapytań. Pamięć dochodziła do ~15.3 GB i pojawiał się swap, ale bez dalszego narastania. Wynik: STABLE_WITH_SWAP.- Mistral Small 3.2 24B — IQ3_XXS, 8.76 GB
Mocniejsza quantyzacja była świadomym wyborem, żeby pozostawić miejsce dla KV cache i macOS.I właśnie o to chodzi w eksperymencie.
Nie porównuję idealnych modeli na serwerze. Porównuję kompromisy:
parametry, quantyzacja, jakość, szybkość a pamięć
na zwykłym laptopie.
Może wygrać 27B. Ale może się też okazać, że do codziennej pracy znacznie lepszy będzie szybszy 12B lub 20B.
Obecnie trwa pełny benchmark: 180 zadań — 36 dla każdego modelu.
-
Buduję własną Local LLM Arena na MacBooku M4 16 GB.
Chciałem sprawdzić coś, czego zwykłe internetowe benchmarki mi nie powiedzą: który lokalny model AI jest rzeczywiście najlepszy do moich zastosowań i na moim sprzęcie.
Dlatego zamiast porównywać tabelki z Internetu, zbudowałem własny system benchmarkowy.
Testuję obecnie 5 lokalnych modeli:
• Qwen3.8-27B • Ternary Bonsai 27B • GPT-OSS-20B • Gemma 4 12B • Mistral Small 3.2 24BKażdy dostaje te same 36 zadań — łącznie 180 testów. Wszystkie modele pracują przy tym samym context length 4096, żeby porównanie było możliwie uczciwe.
Nie interesuje mnie tylko „który model ma więcej punktów”.
Arena sprawdza m.in.:
- jakość języka polskiego - reasoning i rozwiązywanie problemów - analizę dokumentów - tłumaczenia i komunikację PL/DE - programowanie i zadania agentowe - szybkość, TTFT, pamięć, swap i stabilnośćSystem zapisuje checkpoint po każdym zadaniu, zbiera telemetrykę, potrafi wznowić przerwany benchmark i generuje raport. Sam benchmark działa jako niezależny proces w macOS, więc nie jest uzależniony od sesji agenta AI.
Co ważne — modele działają lokalnie na MacBooku, a LM Studio jest dostępne wyłącznie przez localhost.
W projekcie rozdzieliłem też role AI: Gemini Antigravity jest wykonawcą/deweloperem, a Codex niezależnym audytorem/QA, żeby ten sam agent nie był jednocześnie autorem zmian i ich ostatecznym recenzentem.
W tej chwili trwa pierwszy pełny benchmark: 36 zadań × 5 modeli.
Jak się skończy, pokażę wyniki — zarówno który model okazał się „najmądrzejszy”, jak i który jest najbardziej praktyczny do codziennego lokalnego używania na M4 z 16 GB RAM.
#LocalLLM #LLM #AI #OpenSourceAI #MacOS #AppleSilicon #MachineLearning #SelfHosted
