SeeM

Poborem prądu nie musisz się aż tak sugerować. Bywały krótkie serie powiedzmy specjalistycznych GPU dla stacji roboczych z AutoCAD i innych w rodzaju - to się może renderować całą noc, poza tym tego komputera i tak nigdy nie wyłączam. Na przykład nvidia A1000, czyli laptopowa grafika upchana na kartę pci. Nie bardzo się to przyjęło ze względu na wysoką cenę, ale pobór mocy ma max 50 watów na obciążeniu. A kiedy nic nie robi, to kilka watów idzie pewnie glównie na wentylator. Jeżeli host nie ma zainstalowanego pulpitu, tylko Ollamę, to stosownie odchudzona i przedestylowana Gemma4 chodzi szybko. Nie polecam kupowania używanych GPU. To bywają bardzo przepracowane egzemplarze z koparek, johntheripper-a, czy ostatnio komputerów z LLM w kącie biura. Wiele życia przed nimi już nie ma. Te wszystkie filmiki, jak to starsze nvidia 3060 są świetne jako tani wstęp do SI traktuj z ostrożnością. Zwłaszcza, jeżeli pod filmem są linki afiliacyjne.

Sztuczna inteligencja to na dzisiaj Nvidia, Nvidia, Nvidia, jakieś mocne minikomputery Apple, potem Radeon. Intel ma bardzo pog górkę, bo niektóre aplikacje musieli forkować, żeby w ogóle zadziałały. Spróbuj, nic nie zaszkodzi. https://docs.ollama.com/linux Link "manual install" prowadzi do instrukcji zawierającej dodatkowe informacje o Radeonach. Kiedy archiwa z Ollamą będą rozpakowane i ollama serve zadziała, pobierz chyba najmniejszy sensowny model językowy https://ollama.com/library/gemma3 . To trochę starsza technologia i trzeba mu promptować po angielsku, ale to i tak tylko do testów. Jeżeli będzie działać szybko, to będzie jak na jutubowych filmach o sztucznej. Jeżeli będzie działać wolno... to będziesz wiedział, bo zobaczysz jakieś 2-4 tokeny na sekundę.

Pytanie jest jak najbardziej na miejscu. Stos technologiczny do obsługi SI puchnie w zastraszającym tempie. Instaluje się to łatwo, bo są obrazy kontenerowe, ale one pięknie ukrywają, jak niektóre rzeczy są drutowane. Utrzymanie i aktualizowanie tego, to już zupełnie inny temat. LiteLLM Proxy to zwykła aplikacja w Pythonie i będzie działać na byle drewniaku. Nie będą za to działać modele SI. Nawet tycie Gemma, Granit, Qwen, czy Bielik właśnie, bez vram-u są tragicznie wolne. Model z rozumowaniem (to znaczy pisaniem promptów i liczeniem na nie odpowiedzi kilkanaście razy przed odowiedzią na prompt użytkownika) na samym CPU potrzebuje jakiś 20 minut na przepis do naleśników. To jak granie w Cyberpunka na Playstation 4, co może udawać jakiś rodzaj zabawy. Nawet GPU z 8 gigabajtami pamięci - tylko takie z 2023 roku najdalej, bo architektura scalaków też ma znaczenie - robi niesamowitą rożnicę. Wspomniane malutkie modele prototypowanie html, Pythona, Javy, czy redagowanie CV (w przypadku Bielika nawet po polsku) to ogarniają. To oczywiście zabawka w porównaniu z chmurowymi potworami, ale mi właśnie idzie o zabawę. Zapłacić zawsze zdążę.

LiteLLM to jest takie jakby HAProxy dla klientów modeli językowych. Żeby nie łączyły się od razu do API Ollamy, ani do chmury, ale żeby było coś po drodze. Pełni rolę ogranicznika oraz wystawia swoje własne klucze, dzięki czemu ryzyko wklejenia wrażliwego klucza API przez użytkownika maleje do zera. Potrzebuje to bazy na Postgresie. Trzeba utworzyć bazę, rolę i nadać poniższe uprawnienia. # \c litellm You are now connected to database "litellm" as user "postgres". # grant all ON database litellm to litellm; # grant CONNECT on database litellm to litellm; # GRANT ALL PRIVILEGES ON SCHEMA public TO litellm; # ALTER ROLE "litellm" WITH LOGIN; Na razie testuję to sobie na venv w Pythonie 3.12 i takich oto zależnościach: aiohappyeyeballs==2.7.1 aiohttp==3.14.3 aiosignal==1.4.0 annotated-doc==0.0.5 annotated-types==0.8.0 anyio==4.15.1 APScheduler==3.11.3 attrs==26.1.0 azure-core==1.41.0 azure-identity==1.25.3 azure-storage-blob==12.30.1 backoff==2.2.1 boto3==1.43.89 botocore==1.43.89 certifi==2026.7.22 cffi==2.1.1 charset-normalizer==3.5.1 click==8.5.0 croniter==6.2.4 cryptography==50.0.1 distro==1.9.0 dnspython==2.8.0 email-validator==2.3.0 Expression==5.7.0 fastapi==0.141.1 fastapi-sso==0.22.0 fastuuid==0.14.0 filelock==3.32.5 frozenlist==1.8.0 fsspec==2026.7.0 granian==2.8.2 gunicorn==23.0.0 h11==0.16.0 hf-xet==1.6.0 hiredis==3.4.1 httpcore==1.0.9 httpx==0.28.1 httpx-sse==0.4.3 huggingface_hub==1.30.0 idna==3.19 importlib_metadata==8.9.0 inquirerpy==0.3.4 isodate==0.7.2 Jinja2==3.1.6 jiter==0.16.0 jmespath==1.1.0 jsonschema==4.26.0 jsonschema-specifications==2025.9.1 litellm==1.99.0 litellm-enterprise==0.1.59 litellm-proxy-extras==0.4.89 markdown-it-py==4.2.0 MarkupSafe==3.0.3 mcp==1.29.1 mdurl==0.1.2 msal==1.38.0 msal-extensions==1.3.1 multidict==6.7.1 nodeenv==1.10.0 numpy==2.5.2 oauthlib==3.3.1 openai==2.54.0 orjson==3.12.0 packaging==26.3 pfzy==0.3.4 polars==1.44.1 polars-runtime-32==1.44.1 prisma==0.13.0 prompt_toolkit==3.0.53 propcache==0.5.2 pycparser==3.0 pydantic==2.13.5 pydantic-settings==2.15.0 pydantic_core==2.46.5 Pygments==2.21.0 PyJWT==2.13.0 PyNaCl==1.6.2 pyroscope-io==0.8.16 python-dateutil==2.9.0.post0 python-dotenv==1.2.3 python-multipart==0.0.32 PyYAML==6.0.3 redis==8.1.0 referencing==0.37.0 regex==2026.9.3 requests==2.34.2 RestrictedPython==8.5 rich==13.9.4 rpds-py==2026.6.3 rq==2.12.0 s3transfer==0.19.2 six==1.17.0 sniffio==1.3.1 soundfile==0.14.0 sse-starlette==3.4.11 starlette==1.6.0 tiktoken==0.14.0 tokenizers==0.23.2 tomlkit==0.15.1 tqdm==4.70.0 typing-inspection==0.4.4 typing_extensions==4.16.0 tzlocal==5.4.4 urllib3==2.7.0 uvicorn==0.52.4 uvloop==0.22.1 wcwidth==0.8.3 websockets==15.0.1 yarl==1.24.5 zipp==4.1.0 Co potem? Konfiguracja jest trochę zakręcona. Trzeba sobie najpierw zorganizować Ollamę z jakimiś modelami. Potem trzeba napisać plik konfiguracyjny litellm_config.yaml dla LiteLLM: model_list: - model_name: granite litellm_params: model: ollama/granite4.2:8b api_base: http://host.local:11434 - model_name: gemma litellm_params: model: ollama/gemma4:12b api_base: http://host.local:11434 - model_name: qwen litellm_params: model: ollama/qwen3.5:9b api_base: http://host.local:11434 - model_name: bielik litellm_params: model: ollama/bielik-11b:Q5_K_M api_base: http://host.local:11434 router_settings: routing_strategy: latency-based-routing num_retries: 2 timeout: 601 fallbacks: - granite: ["qwen"] - bielik: ["gemma"] general_settings: master_key: admin store_prompts_in_spend_logs: true ###disable_env_credential_login: true database_url: "postgresql://litellm:[haslo_uzytkownika]@[host.bazodanowy.local]:5432/litellm" Teraz trzeba - ręcznie, bo LiteLLM sam tego nie robi - utworzyć tabele w bazie danych: prisma generate --schema lib/python3.12/site-packages/litellm/proxy/schema.prisma Zajmuje to zadziwiająco dużo czasu. Wygląda, jakby coś się zawiesiło, ale w końcu przejdzie. Uruchomienie LiteLLM: litellm --config litellm_config.yaml --port 4040 To również zajmuje bardzo dużo czasu. W końcu przejdzie. W przeglądarce trzeba wejść na stronę http://127.0.0.1:4040/ui/login/ i zalogować się: użytkownik: admin hasło: admin Hasło wynika z ustawienia general_settings.master_key z pliku litellm_config.yaml . Najważniejsze ustawienia są na stronie http://127.0.0.1:4040/ui/api-keys/ , gdzie można dodać nowy klucz, przypisać go do użytkowników, modeli i ustawić różne ograniczenia. Potem ten właśnie klucz podaje się na kliencie. Poniżej przykład uruchomienia aider: AIDER_ANALYTICS_DISABLE=true AIDER_CHECK_UPDATE=false AIDER_YES_ALWAYS=true AIDER_DARK_MODE=true LITELLM_PROXY_API_BASE=http://127.0.0.1:4040 LITELLM_PROXY_API_KEY=sk-[token_w_litellm] aider --model=litellm_proxy/granite Najlepiej byłoby uruchomić LiterLLM na zdalnym hoście, którym nie jest host z Ollamą. Wówczas można ładnie odseparować sieciowo klientów od Ollamy i zwyczajnie zmusić użytkowników do przechodzenia przez proxy. Pracuję jeszcze nad ukonteneryzowaniem tego LiteLLM na bazie CentOS, czy innym RHEL. Z jednej strony wydaje się to żadnym problemem, ale procedura przechodzenia przez migrację bazy danych oraz ustawienie master_key, a później jego odwołanie za pomocą ustawienia disable_env_credential_login: true i późniejsza konieczność zrestartowania aplikacji nie pomagają. Dodatkowo wszystkie ustawienia z pliku konfiguracyjnego są jakby "zamrożone" i nie można ich zmienić, klikając po panelu administracyjnym. Z jednej strony fajne, bo nikt niechcący nie zepsuje. Gorzej, kiedy na hoście z Ollamą aktualizuje się modele i wówczas trzeba poprawić plik konfiguracyjny LiteLLM i oczywiście restartować aplikację. --------------------------------------------------------------------------------------- Podsumowując. Bardzo mi się to podoba, ale widać, że projekt nie wyszedł z bety. Wersja z powyższego requirements.txt mi działa, ale na poprzedniej nie mogłem zrobić migracji bazy, z powodu jakiegoś błędu nawet nie w LiteLLM, tylko w prisma. Czuć trochę, że autorzy LiteLLM do Postgresa wolą się nie dotykać. Nawet u siebie w mieszkaniu ustawię to sobie na domowym serwerku chociażby po to, żeby mieć w logach aplikacji wszystkie prompty. Powodzenia!

Kod dnf provides oraz dnf install /sciezka/do/pliku/z/jakiegos/pakietu robi coś dziwnego i dotyczy to zarówno pythonowych DNF, jak i tych nowszych. Fedora mam pakiety budowane dla 32-bitowej architektury, czasem takie właśnie DNF pobiera i nie może rozwiązać zależności. Dla Red Hata to nie problem, bo w RHEL i686 jest porzucone. A dla nas jest.

Na razie bez pozytywnego rezultatu. Wykonaj aktualizację Invision Community Krok 1 Potwierdź aktualizację Krok 2 Zaloguj się Krok 3 Dane FTP Krok 4 Pobierz i rozpakuj aktualizację Krok 5 Zakończ aktualizację Database Check There are some problems with your database which need to be fixed before you can start the upgrade. Nie mogę tego rozgryźć. Zaproponowany przez aktualizator skrypt sql jest co prawda duży i wykonuje się około minuty, ale błędów nie zwraca. Tymczasem aktualizator w kółko wymusza jego wykonanie, co uniemożliwia przejście do kroku pierwszego. Na dzisiaj koniec. Poczytam, jak można to obejść.

26.09.2026 w godzinach 07:00-08:30 forum będzie miało kilka małych przerw technicznych. Spróbuję zaktualizować silnik forum do najnowszej dostępnej nam wersji.

Bardzo miło mi powitać Was z Fedory 45. $ cat /etc/os-release NAME="Fedora Linux" VERSION="45 (Workstation Edition Prerelease)" RELEASE_TYPE=development ID=fedora VERSION_ID=45 $ lscpu [...]AMD E1-2100 APU with Radeon(TM) HD Graphics[...] Jestem bardzo pozytywnie zaskoczony. Nawet mój czajnik jest szybszy, niż ten procesor. Na Kernelu 7.2 nie dość, że jest naprawiony błąd https://bugzilla.redhat.com/show_bug.cgi?id=2502167 , to jeszcze nie ma już żadnych graficznych artefaktów przy uruchamianiu aplikacji. Myślałem, że będę musiał się z tym laptopem cofnąć do CentOS-a 10, ale najwyraźniej jeszcze trochę pociągnie.

Testowanie Fedory jest jednym z niewielu powodów, dla których trzymam jeszcze to muzeum. Jeden z laptopów będzie aktualizowany jutro.

Ja podmana bardzo doceniam, ale Toolboksa używam tylko wtedy, kiedy potrzebuję pojedynczo użyć aplikacji, której nie do końca ufam. toolbox create --container niewiadomoco toolbox enter --container niewiadomoco Instaluję co potrzebuję, włączam, wyłączam i usuwam. Szkoda czasu na pisanie dockerfile.

Hej. Są dwie przyczyny. du nie sprawdza katalogów zaczynających się kropką, parametr -h, --human-readable zaokrągla i zawyża wyniki, niewielka część systemu plików jest zajęta przez węzły / inode , które przy walce o ostatnie megabajty potrafią przeważyć.

https://vote.debian.org/~secretary/gr_llm/results.txt W skrócie: nic się nie zmienia, ale przez ostatni tydzień przeczytałem o tym sumarycznie nowelkę na ładnych 40 stron z samych tylko kanałów RSS, które mi się nawinęły. Jest to jeden z powodów, za które Debiana się uwielbia. (-: Mam nadzieję, że to już zostanie tak zawsze.

Akurat nie mam komputera pod ręką, ale clamd oraz freshclam jestem pewien.

Na oko w miarę dobrze. Jest tylko jedno ale, które wyróżnia ClamAV od antywirusów z Windowsa. Clam jest zaprojektowany, by skanować pliki pojawiające się w jakimś katalogu i coś z nimi ewentualnie robić. Dobre do udzialów smb, skrzynek pocztowych, katalogu Pobrane, aplikacji Nextcloud. Pod warunkiem, że te zasoby nie są szyfrowane, bo wówczas Clam jest bezradny. Możesz też od czasu do czasu puścić skan podejrzanych katalogów, gdzie zapisujesz załączniki i synchronizujesz chmurowe, kilkuosobowe zasoby. To nie działa tak, jak na Windows, że Clam uruchamia się w przestrzeni kernela, chodzi sobie na najwyższych uprawnieniach i przechwytuje pliki wygrane podczas partii Counter Strike, blokuje strony www, czy pobierane właśnie Torrenty. Zupełnie inna liga i inny pomysł na ochronę. Takie rzeczy na Linuksa istnieją chociażby niesławny "Crowdstrike", ale to raczej rynek korposieci i kosmiczne kwoty.

Autorzy WPS są wyjątkowo leniwi i nie tylko nie podpisują swoich pakietów, ale nie dają swoim klientom szansy weryfikacji pobranego archiwum przed instalacją. rpm --noverify -Uvh [nazwapliku.rpm] sobie z tym poradzi.