Příspěvky

1

Vývoj / Re:Nový systém pro vývoj softwaru

« kdy: 18. 05. 2026, 16:00:56 »

Jestli se to přiblíží, tak pro inspiraci:
Používám stávající řešení. Jedná se především o interní aplikace, nic není vystaveno do internetu.

Vývojové nástroje:
   - OS: Debian
   - CLI: Opencode s lokálním modelem Qwen 3.6
   - Editor: Nano
   - Git: Forgejo

Mám Core napsané v Pythonu používající upravený fork frameworku web.py (FastAPI jsem nepoužil web.py stačí pro lokální aplikace), který poskytuje služby (routing, šablony, DB, session, CSRF). Každý modul je 100% izolovaný a nekomunikuje přímo s jiným modulem a má vlastní SQLite DB (web.py je single-threaded) – Core funguje jako službami zásobovaný registr, nikoliv jako komunikátor mezi moduly. Každý modul má vlastní Git repozitář (Git submodule) s větvemi main a test. Protože používám web.py, který má v sobě i webserver, je pro mě nasazení jednoduché pomocí git clone. Na serveru mi pak pomocí systemd běží dvě instance stejné aplikace, jedna pro větev main a druhá pro test. Před nimi je Caddy se dvěma doménami produkce.home.arpa a test.home.arpa.

Framework web.py je tak přímočarý, že moduly dokáže vyvíjet i lokální agent, po kterém je to snadné zkontrolovat.

Vývoj nového modulu zabere jen pár hodin i s testováním a manuální kontrolou.

Jelikož je to webová aplikace a používá Python, tak to běží všude a dokáže to obsloužit cokoliv.

Je to prostě podvozek postavený na už vymyšlených kolech. A pro mé potřeby to stačí.

2

Hardware / Re:Hardware pro provoz lokálního LLM

« kdy: 08. 12. 2025, 18:40:17 »

K jakým účelům používáte lokální LLM? Pokud jde jen o to ušetřit 20 nebo 30$, tak to odpovídat nemusíte. Díky

Podle mě lokálním LLM, pokud nemáte z nějakého důvodu nevyužitý nadupaný HW jehož cenu nepočítáte, nejde ušetřit ani těch $20. Tyhle malé modely typicky stojí tak $0.5 za milion výstupních tokenů. I kdyby vám to generovalo 50 tokenů za sekundu (diskutující výše má 7 tokenů za sekundu na slabším HW), tak pro těch $20 měsíčně by to muselo běžet 8 hodin v kuse každý den.

Podle mě jediným reálným důvodem může být paranoia / obecně zdráhavost posílat data někam do cloudu.

Jen si dovolím upřesnit můj případ a použití.

Jak jsem již psal, generování mám 7T/s čtení 160T/s (to jsem zapomněl uvést).

Programuji převážně v jazyce Python a rozděluji moduly cca po 200 řádcích PEP8 na soubor.

Když mám hotovo, nechám lokální LLM zkontrolovat celý projekt na několik kol, takže vstupní tokeny jsou enormní. Výstupních moc není. Mám to cca 90/10 .

Jelikož API je bezstavové, tak odesíláním kontextu není problém spotřebovat předplacené tokeny, to se mi u lokálního LLM nestane.

Malé modely sice nejsou tak chytré, ale na můj konkrétní způsob použití se hodí.

Používám aider.chat převážně v módu /ask pro konzultace a /code pro generování testů a komentářů. (Dokumentace mě nikdy moc nebavila i když tou by se vlastně mělo začínat)

Souhlasím s tvrzením, že pro všeobecné použití a chat se lokální LLM nehodí.

3

Hardware / Re:Hardware pro provoz lokálního LLM

« kdy: 06. 12. 2025, 08:37:35 »

@ladislav.danis , odpusťte lamí dotaz: jestli správně chápu, Qwen3-coder publikovaný v rámci frameworku/projektu Unsloth.ai je hotový naučený model na bázi llama.cpp, který stáhnete z internetu a lokálně spustíte v režimu "inference", je to tak?

Ano, chápete to správně. LLama.cpp si ho umí i v rámci příkazu stáhnout sama, ale z důvodu používání příkazu jako službu systemd mám zadán model cestou k souboru.

4

Hardware / Re:Hardware pro provoz lokálního LLM

« kdy: 06. 12. 2025, 07:47:32 »

Dnes při správném modelu i konfiguraci lze použít i zdánlivý šrot.

Na mém starém Dell OptiPlex Sff 3050
Intel(R) Core(TM) i5-7500 CPU @ 3,40 GHz
64 GB RAM DDR4
Tesla P4 8 GB VRAM

s příkazem:
llama-server \
--model /home/testbox/.cache/llama.cpp/unsloth_Qwen3-Coder-30B-A3B-Instruct-GGUF_Qwen3-Coder-30B-A3B-Instruct-UD-Q8_K_XL.gguf \
--threads 3 \
--batch-size 384 \
--ctx-size 40960 \
--cache-type-k q8_0 \
--cache-type-v q8_0 \
--jinja \
--temp 0.7 --min-p 0.01 --top-p 0.80 --top-k 20 --repeat-penalty 1.05 \
--flash-attn on \
-a qwen3-coder-30-a3b-p4 \
--n-gpu-layers 48 \
--override-tensor ".blk.([1-9]|[1-3][0-9]|4[0-6]).ffn_._exps.*=CPU" \
--host 0.0.0.0 \
--port 4000

konzistentně dosahuje krásných přibližně 7 t/s

Kdybych neměl kvůli velikosti RAM snížený duální kanál (můj DELL oficiálně podporuje 32 GB RAM), věřím, že výsledek by byl ještě lepší.

Používám to jako konzultanta při programování pro opravu chyb z nepozornosti.

Záleží na tom, co od toho člověk očekává. Na speciální účely se lokální LLM hodí, ale pro takové to ChatGPT tlachání je to marná investice.