DTGaraGe | Автомобили, Офроуд, Заваряване, Linux, AI

Регистрирайте безплатен акаунт днес, за да станете член! След като влезете, ще можете да участвате в този сайт, като добавяте свои собствени теми и публикации, както и да се свързвате с други членове чрез вашата лична пощенска кутия!

AI Локален AI у дома: Практическо ръководство за лична AI инфраструктура с Ollama, RAG и Home Assistant

Локален AI у дома: Практическо ръководство за лична AI инфраструктура с Ollama, RAG и Home Assistant


Локален AI у дома- лична инфраструктура.png

Ако моделът работи на твоя хардуер, разговорът може да остане в твоята стая.


Всеки облачен AI асистент работи по сходна схема. Ти изпращаш въпрос, чужд сървър го обработва, а чужда организация определя как се управляват заявките, логовете и свързаните с тях данни. За огромна част от ежедневните задачи това е приемлив и разумен компромис.

Но има и друга категория информация - лични документи, медицински данни, договори, вътрешна кореспонденция, технически архиви, фирмени файлове и гласови команди в собствения дом. Точно тук локалният AI започва да има истински смисъл. Не защото облакът е зло, а защото някои данни просто нямат работа извън твоята мрежа.

Личната AI инфраструктура не е опит да построиш конкурент на най-големите облачни лаборатории в мазето. Тя е начин да избереш кои задачи да останат локални, кои да използват външни модели и къде удобството не трябва да печели за сметка на контрола.


Локалният AI не е задължително по-умен. Той е твой.



Какво всъщност означава „локален AI“


Локален AI означава, че моделът се изпълнява върху хардуер, който контролираш - настолен компютър, mini PC, Mac с Apple Silicon, работна станция или отделен домашен AI сървър. Заявката не е задължително да напуска машината или локалната мрежа, а файловете могат да бъдат обработвани без качване към външен доставчик.

Това обаче не означава автоматично, че цялата система е офлайн. Локалният интерфейс може да използва облачен модел, външна услуга за embeddings, интернет търсачка, дистанционен инструмент или автоматизация, която изпраща данни към чужд API. Поверителността не се определя от това къде е инсталиран чатът, а от пълния маршрут на информацията.


Локално инсталиран не означава автоматично локално обработван.



Локално, облачно или хибридно


Изцяло локална система


Моделът, embeddings, документите, гласовото разпознаване и автоматизациите работят в домашната мрежа. След първоначалното изтегляне на необходимите модели системата може да функционира и без интернет. Това е най-силният вариант за поверителност, но изисква собствен хардуер, поддръжка и приемане на ограниченията на локалните модели.

Облачна система


Получаваш достъп до мощни модели, голям контекст, по-добро сложно разсъждение и инфраструктура, която не поддържаш сам. Плащаш с абонамент, API употреба или зависимост от чужда услуга. За общи въпроси, проучване, сложен код и задачи без чувствителни данни това често е най-практичният избор.

Хибридна система


Това е най-разумният модел за повечето хора. Личните документи, транскрипциите, домашният контрол и рутинните задачи остават локални, а най-трудните заявки се изпращат към по-силен облачен модел след премахване на чувствителната информация. Не избираш лагер - избираш правилния инструмент за всяка задача.



Преди хардуера: четири понятия, които трябва да разбираш


Параметри


Обозначения като 7B, 14B и 32B показват приблизителния брой параметри на модела. По-големият модел обикновено има повече капацитет, но не е автоматично по-подходящ за всяка задача. Архитектурата, обучението, езиковата поддръжка и качеството на конкретния модел могат да бъдат по-важни от числото върху етикета.

Квантизация


Квантизацията намалява точността, с която се съхраняват теглата на модела, за да използва по-малко памет и да работи по-бързо. Обозначения като Q4, Q5 и Q8 показват различни компромиси между размер, скорост и качество. За домашна употреба добрата 4-битова или 5-битова квантизация често предлага най-разумния баланс.

Контекст


Контекстът е количеството текст, което моделът може да държи активно при обработката на една заявка. Голям контекст позволява по-дълги разговори, документи и кодови бази, но използва допълнителна RAM или VRAM чрез така наречения KV cache. Модел, който се побира удобно при 4096 токена, може да остане без памет при 32 000 или 64 000 токена.

Токени в секунда


Токените в секунда измерват скоростта на генериране, но не разказват цялата история. За усещането при работа са важни и времето до първия токен, скоростта на обработване на входния текст и поведението при голям контекст. Машина с прилично генериране може пак да изглежда бавна, ако чака дълго преди началото на отговора.

Не купувай модел по броя параметри. Купувай решение за конкретна задача.



RAM, VRAM и защо видеопаметта има значение


При GPU inference видеопаметта определя колко голям модел, контекст и натоварване можеш да държиш удобно върху видеокартата. Това не означава, че VRAM определя всичко - значение имат още архитектурата на модела, квантизацията, KV cache, броят едновременни заявки и поддръжката на конкретния хардуер от избрания софтуер.

Като груб ориентир, 7-8B модел с 4-битова квантизация често заема приблизително 4-6 GB само за основните тегла. Модел около 14B обикновено изисква приблизително 8-10 GB, а 30-32B модел може да заеме около 18-22 GB. Към това трябва да добавиш контекста, служебната памет на приложението, графичната среда и останалите процеси.

Затова 12 GB VRAM са добра отправна точка за 7-8B модели и някои квантизирани 14B модели с внимателно избран контекст. При 16 GB имаш повече свобода, а 24 GB отварят вратата към част от 30-32B класа, по-голям контекст и по-високи квантизации. Това са ориентири, не гарантирани граници - два модела с еднакъв брой параметри могат да имат различни изисквания.

Когато моделът не се побира изцяло във VRAM, инструменти като llama.cpp могат да разпределят част от работата между видеокартата и системната RAM. Така стартираш по-голям модел, но скоростта обикновено пада, защото данните трябва да преминават между различни нива на паметта.




Хардуерът: четири реалистични нива


Ниво 1 - използваш това, което вече имаш


Стар лаптоп, mini PC или настолен компютър с 16 GB RAM може да стартира квантизиран модел от 7-8B клас през CPU. Скоростта ще зависи от процесора, паметта, охлаждането и квантизацията, затова не очаквай усещане като при голям облачен асистент. За класификация, извличане на информация, обобщаване на кратки текстове и пакетна обработка обаче такава машина може да бъде напълно полезна.

Стар сървър с много ядра и голямо количество RAM не е автоматично бърза AI машина. При inference често решаваща е пропускателната способност на паметта, а не само броят процесорни ядра. Можеш да заредиш голям модел, но да чакаш толкова дълго, че разговорът да започне да прилича на кореспонденция по пощата.


Ниво 2 - балансирана машина с 12-16 GB VRAM


Тук започва комфортната ежедневна употреба. Качествена видеокарта с 12-16 GB VRAM позволява бърза работа с 7-8B модели и разумна употреба на част от 14B класа. Това е подходящо ниво за чат, локално програмиране, RAG над собствени документи, транскрипция и автоматизации за един или няколко леки потребители.

При избор на употребявана карта не гледай само поколението. За локални езикови модели повече VRAM понякога е по-полезна от по-нова архитектура с малко памет, но трябва да провериш реалната поддръжка, консумацията, охлаждането и производителността на конкретния backend.

Внимание при AMD и Intel карти. NVIDIA има най-гладкия път през CUDA и почти всичко работи от кутията. При AMD трябва да провериш дали конкретният модел карта е в поддържаните от ROCm, защото списъкът е доста по-къс от продуктовия каталог. Вариантът с Vulkan backend в llama.cpp работи по-широко, но обикновено с по-ниска производителност. Същото важи и за Intel Arc. Евтина карта, която не работи добре с избрания стек, е просто скъпа печка с вентилатори.


Ниво 3 - 24 GB VRAM и сериозна локална работа


При 24 GB VRAM вече можеш да експериментираш с квантизирани модели около 30-32B, по-големи контексти и по-тежки задачи. Това не превръща домашната машина в облачен център за данни, но разликата спрямо 7-8B класа може да бъде сериозна при писане, анализ, код и работа със сложни инструкции.

Тук 64 GB системна RAM са разумна основа, особено ако планираш CPU/GPU offload, големи embeddings индекси, транскрипция и няколко контейнера едновременно. Дисковото пространство също започва да има значение - един модел е лесен, но библиотека от модели, квантизации и индекси бързо изяжда стотици гигабайти.


Ниво 4 - отделен домашен AI сървър


Това е машина, която обслужва няколко устройства, потребители или автоматизации. Тя може да работи постоянно, по график или да се стартира при нужда чрез Wake-on-LAN. Тук вече трябва да мислиш за мрежова сигурност, охлаждане, наблюдение, резервни копия, електрическа консумация и поведение при повреда.

Не е задължително AI сървърът да бъде шумна rack машина. Добре подбрана работна станция често предлага по-добър баланс между производителност, шум и консумация. Сървърният корпус изглежда сериозно, но семейството рядко оценява философската му стойност в три през нощта, когато вентилаторите решат да излитат.




Apple Silicon като отделен път


Mac с Apple Silicon използва unified memory, споделена между процесора и графичните ядра. Това позволява модели, които трудно биха се побрали в обикновена видеокарта с малко VRAM, но операционната система и всички приложения използват същия общ ресурс. Машина с 32 или 64 GB unified memory може да бъде много приятна локална AI платформа, особено когато тишината и ниската idle консумация са важни.

Има един детайл, който изненадва мнозина. macOS не позволява на графичните ядра да заемат цялата unified memory - по подразбиране лимитът е около 70-75% от общата памет при по-малките конфигурации. Тоест на машина с 32 GB реално разполагаш с около 21-24 GB за модела, а не с 32. Лимитът може да бъде вдигнат чрез iogpu.wired_limit_mb, но това се прави внимателно - ако оставиш твърде малко памет на самата система, машината започва да суапва и печалбата изчезва.

Не сравнявай директно 32 GB unified memory с 32 GB отделна VRAM. Архитектурата, пропускателната способност и начинът на споделяне са различни. Голямото предимство е, че инструменти като Ollama, llama.cpp и whisper.cpp използват Metal и са добре приспособени към Apple Silicon.




Български език: проверката, която никой бенчмарк няма да направи вместо теб


Тази част липсва в почти всяко англоезично ръководство, а за нас е решаваща. Малките модели са обучени предимно върху английски текст и качеството им пада забележимо при по-редки езици. Модел, който изглежда отлично в английските класации, може да пише на български граматически счупено, да бърка членуването или да превключва към английски по средата на отговора.

Разликата между английски и български е най-голяма точно при малките модели и намалява при по-големите. Затова понякога 14B модел с добра многоезична подготовка върши по-полезна работа на български от 8B модел, който е по-силен в английските тестове.

Има и техническа страна. Кирилицата обикновено се разбива на повече токени от латиницата, тоест същият текст на български изяжда осезаемо повече контекст и се генерира по-бавно. При RAG над български документи това означава, че се побират по-малко откъси при равен контекст.


  • Тествай всеки кандидат-модел с реални твои текстове на български, не с преводни примери.
  • Провери дали моделът остава на български при дълъг разговор.
  • При RAG задавай въпроси на български върху български документи - там се къса най-често.
  • Провери и embedding модела отделно. Ако той не е многоезичен, търсенето ще намира грешните откъси, колкото и добър да е чат моделът.
  • За транскрипция избирай по-голям Whisper модел, отколкото би избрал за английски. Разликата в точността при български е чувствителна.

Класацията е на английски. Твоите документи не са.



Три практически конфигурации


Конфигурация A - старт без нов хардуер

  • 16-32 GB системна RAM.
  • Съвременен CPU или Apple Silicon.
  • Квантизиран модел от 7-8B клас.
  • Ollama или llama.cpp.
  • Open WebUI за удобен достъп.
  • Подходяща за обобщаване, класификация, леки документи и експерименти.

Тази конфигурация е идеална, за да разбереш дали локалният AI действително решава твой проблем. Първо натовари стария хардуер, после портфейла. Много хора купуват видеокарта за идея, която спират да използват след третия ден.

Конфигурация B - балансирана домашна AI станция

  • 32-64 GB системна RAM.
  • GPU с 12-16 GB VRAM или Mac с достатъчно unified memory.
  • Бърз NVMe диск с поне няколкостотин свободни гигабайта.
  • 7-14B модели с разумна квантизация и контекст.
  • Open WebUI, RAG, whisper.cpp, Piper и леки n8n сценарии.
  • Подходяща за ежедневен чат, документи, транскрипция, програмиране и домашна автоматизация.

Конфигурация C - личен AI сървър

  • 64-128 GB системна RAM.
  • 24 GB или повече използваема GPU памет според избрания backend.
  • Отделен NVMe диск за модели и отделно защитено хранилище за документи и бекъпи.
  • По-големи квантизирани модели, дълъг контекст или няколко потребители.
  • WireGuard, firewall, централизирани логове и мониторинг.
  • Подходяща за постоянни услуги, голям личен архив и автоматизирани фонови задачи.

Тези конфигурации са отправни точки, не рецепти, издялани в гранит. Реалният избор трябва да започне от задачите, след това от моделите и едва накрая от хардуера. Обратният ред създава впечатляващи машини и доста скучаещи видеокарти.



Софтуерният стек за локален AI

Лична AI инфраструктура- локална неонова архитектура.png

Ollama - най-бързият старт


Ollama улеснява изтеглянето, стартирането и обслужването на локални модели през команден ред и API. Това е добър избор, когато искаш бързо да получиш работеща система, без да настройваш всеки параметър на inference двигателя. След инсталацията можеш да сменяш модели, да следиш дали работят върху CPU или GPU и да управляваш размера на контекста.

llama.cpp - когато искаш пълен контрол


llama.cpp е подходящ, когато искаш прецизен контрол върху GGUF моделите, квантизацията, GPU offload, контекста и параметрите на изпълнение. Той работи върху широк набор от процесори и графични backend-и и може да използва хибридно CPU/GPU изпълнение. Това е инструментът за хората, които не искат само бутон „Run“, а искат да знаят какво точно се случва под него.

Open WebUI - интерфейсът


Open WebUI предоставя удобен чат интерфейс, история, потребители, връзка с множество локални и външни модели, работа с документи и инструменти. Той превръща inference сървъра в услуга, която можеш да използваш от различни устройства в мрежата. Точно защото има толкова възможности, трябва внимателно да следиш кои връзки са локални и кои изпращат информация навън.

whisper.cpp и Piper - локален глас


whisper.cpp позволява локално преобразуване на реч в текст върху CPU, GPU и Apple Silicon. Piper изпълнява обратната задача - превръща текста в локално генерирана реч. Комбинацията позволява транскрипция, диктовка и гласов асистент, без аудиото задължително да напуска домашната мрежа.

n8n и Home Assistant - автоматизация


n8n свързва модела с файлове, бази данни, съобщения, API услуги и работни процеси. Home Assistant прави същото за устройствата и събитията в дома. Когато ги комбинираш, локалният AI може да обобщава известия, да разпознава гласови команди, да класифицира документи или да управлява сценарии според предварително зададени правила.

Но AI агентът не трябва да получава неограничени права. Моделът може да греши, да разбере инструкцията погрешно или да бъде манипулиран от съдържание, което обработва. Давай му минималния достъп, необходим за задачата, и изисквай потвърждение при изтриване, плащане, отключване, изпращане или промяна на критична система.


AI агентът няма нужда от root. Нуждае се от ясна задача и минимални права.



RAG над собствени документи: мястото, където локалният AI става личен


RAG означава Retrieval-Augmented Generation - генериране, подпомогнато от извличане на информация. Моделът не се обучава наново върху документите ти и не ги запаметява магически. При всеки въпрос системата търси подходящи откъси, поставя ги в контекста и кара модела да отговори върху тяхна основа.

Една практична RAG верига изглежда така:


  1. Документът се прочита и текстът се извлича.
  2. Сканираните страници преминават през OCR.
  3. Текстът се разделя на логически фрагменти.
  4. Фрагментите се превръщат в embeddings.
  5. Embeddings се записват във векторен индекс.
  6. При въпрос системата намира най-близките фрагменти.
  7. Hybrid search и reranking могат да подобрят подбора.
  8. Моделът получава намерените откъси и съставя отговор.

Слабият OCR създава слаб RAG. Лошото разделяне на текста скъсва смисъла между два фрагмента. Неподходящият embedding модел намира близки думи вместо правилния отговор, а прекалено много подаден контекст размива важната информация.

Затова добрата RAG система трябва да показва източниците, страниците или използваните откъси. Настрой модела да признава, когато информацията липсва, вместо да запълва празнините с убедително звучащи предположения. Красивият отговор без проверим източник е литературно постижение, не информационна система.


Практически правила за качествен RAG


  • Пази оригиналните документи, а не само векторния индекс.
  • Проверявай OCR резултата при сканирани PDF файлове. При кирилица задължително провери дали OCR-ът е настроен за български, иначе получаваш убедително изглеждащ боклук.
  • Разделяй по заглавия, абзаци и логически секции, а не само през фиксиран брой символи.
  • Използвай един и същ embedding модел при индексиране и търсене.
  • Преиндексирай документите след промяна на embedding модела или chunk настройките.
  • Добавяй metadata като документ, дата, категория, версия и страница.
  • Използвай hybrid search при документи с технически номера, кодове и точни термини.
  • Тествай системата с въпроси, чиито отговори вече знаеш.
  • Разделяй достъпа между потребителите. Един общ индекс не трябва да превръща личните папки в обществена библиотека.

Документите също могат да съдържат инструкции, които се опитват да влияят върху модела. Затова извлеченият текст трябва да бъде третиран като източник на данни, а не като автоматично доверена команда. Това е особено важно, когато RAG е свързан с инструменти, файлове или автоматизации.

Моделът не знае документите ти. Системата трябва да му намери правилния откъс.



Локален глас и Home Assistant


За локален гласов асистент са нужни три основни части - разпознаване на реч, система за разбиране на командата и синтез на отговора. Whisper е подходящ за свободна реч и диктовка, но изисква повече изчислителна мощ. Speech-to-Phrase е по-ограничен, но може да бъде значително по-бърз при предварително известни домашни команди.

Piper връща отговора като локална реч, а Home Assistant свързва гласовата команда с устройствата и автоматизациите. Така можеш да управляваш осветление, отопление, сцени и сензори без аудиото задължително да се обработва от външен сървър.

Гласът обаче отваря нова повърхност за грешки. Разрушителни или чувствителни действия трябва да изискват потвърждение, а микрофонните устройства е добре да имат физически бутон за изключване. Команда като „изгаси лампата“ е едно, а „отключи вратата“ е съвсем друга категория доверие.




Автоматизация с n8n: мощност с ключовете на къщата


n8n може да получава файлове, да чете поща, да използва API ключове, да изпълнява код и да предава резултати между различни системи. Това го прави изключително полезен, но и чувствителен компонент. Той не е просто визуален редактор с красиви квадратчета, а оркестратор, който често държи достъп до най-важните ти услуги.

  • Не излагай административния интерфейс директно към интернет.
  • Използвай TLS, силна автентикация и двуфакторна защита.
  • Съхранявай encryption key сигурно и го включи в плана за възстановяване. Без него запазените credentials в бекъпа са безполезни.
  • Давай на всеки workflow само необходимите credentials.
  • Ограничавай достъпа до локални файлове и вътрешни адреси.
  • Не пази чувствителни входове и резултати в execution history по-дълго от необходимото.
  • Преглеждай изоставените workflow-и. Забравената автоматизация е забравена услуга с чужди ключове.



Сигурност на домашния AI сървър


Фактът, че системата е у дома, не я прави автоматично защитена. Локалният AI сървър съдържа чатове, документи, embeddings, API ключове, автоматизации и понякога достъп до останалата инфраструктура. Един лошо изложен интерфейс може да даде на нападателя много повече от свободна видеокарта.

  • Не публикувай директно Ollama, llama.cpp, Open WebUI, n8n или Home Assistant към интернет без ясна необходимост и защита.
  • Внимавай особено с Ollama. По подразбиране той слуша само локално, но много ръководства съветват да го отвориш към мрежата чрез OLLAMA_HOST=0.0.0.0, а API-то няма никаква автентикация. Отворен към интернет, това е чужд достъп до твоя хардуер и модели.
  • Използвай WireGuard за отдалечен достъп до административните интерфейси.
  • Ограничи услугите с firewall и ги свързвай само към нужните мрежови интерфейси.
  • Използвай отделни потребители, контейнери и минимални права.
  • Не монтирай целия домашен архив в контейнер, който се нуждае само от една папка.
  • Пази API ключовете и паролите извън compose файлове и публични Git хранилища.
  • Обновявай моделния сървър, интерфейса, контейнерите и операционната система.
  • Архивирай конфигурацията, оригиналните документи, базите и encryption ключовете.
  • Следи логовете за неизвестни потребители, нови връзки и необичайна GPU активност.

Проверка за реална локалност

  • Къде работи основният езиков модел?
  • Къде се генерират embeddings на документите?
  • Използва ли системата външна уеб търсачка?
  • Свързани ли са облачни модели или API доставчици?
  • Има ли remote MCP, OpenAPI или други външни инструменти?
  • Изпраща ли n8n съдържание към външни услуги?
  • Може ли системата да работи при физически прекъснат интернет?

Последният тест е най-честният. Изключи интернет връзката и провери кое продължава да работи. Така за пет минути ще научиш повече за архитектурата си, отколкото от двадесет етикета с думата „private“.

Поверителността не е настройка. Тя е маршрутът, по който данните не минават.



Електричество, шум и реалната цена


Цената на локалния AI не свършва с видеокартата. Имаш електричество, охлаждане, дискове, резервни копия и време за поддръжка. Машина със средна постоянна консумация от 200 W използва приблизително 1752 kWh годишно.

Code:
Годишна консумация =
мощност във ватове / 1000 × 24 часа × 365 дни

Пример 1 - машина, работеща денонощно:
200 W / 1000 × 24 × 365 = 1752 kWh годишно
1752 kWh × 0,13 EUR = около 228 EUR годишно

Пример 2 - същата машина, но 2 часа дневно:
300 W / 1000 × 2 × 365 = 219 kWh годишно
219 kWh × 0,13 EUR = около 28 EUR годишно

Цената от 0,13 EUR за kWh е само ориентир - смени я с твоята реална тарифа заедно с всички добавки по сметката. Разликата в примерите обаче остава показателна: осем пъти по-висока сметка за машина, която повечето време просто чака.

Важно е да измериш средната консумация, а не да умножаваш максималната мощност от етикета на захранването. Провери idle режима, зареждането на модела и реалното inference натоварване. Най-евтиният начин да разбереш е ватметър за контакт - струва малко и приключва всички спорове по темата.


  • Използвай автоматично разтоварване на неизползваните модели.
  • Спирай ненужните контейнери и услуги.
  • Пускай тежките пакетни задачи по график.
  • Използвай Wake-on-LAN, когато сървърът не е необходим постоянно.
  • Настрой разумни power limits, когато малка загуба на скорост носи голямо намаление на консумацията и шума.
  • Измервай температурата на помещението, не само тази на видеокартата.

Най-скъпият AI сървър е този, който работи денонощно, за да отговори на три въпроса седмично.



Къде локалният AI наистина печели


  • Лични документи: търсене и обобщаване на договори, бележки, ръководства и архиви.
  • Чувствителна информация: предварителна организация и извличане на данни, без файловете да бъдат качвани към външен модел.
  • Транскрипция: локална обработка на интервюта, диктовки, срещи и лични записи.
  • Технически архиви: RAG над документация, конфигурации, сервизни ръководства и собствени записки.
  • Домашен гласов асистент: команди и отговори без постоянно изпращане на аудио към чужд сървър.
  • Повтарящи се задачи: класификация, извличане на полета, именуване, сортиране и предварително обобщаване.
  • Предвидима цена: голям брой малки операции без отделна API такса за всяка заявка.
  • Работа без интернет: достъп до базови AI функции при прекъсната връзка или изолирана мрежа.



Къде локалният AI честно губи


Няма смисъл да се лъжем. Малък модел от 7-8B клас върху домашна машина обикновено не достига най-силните облачни модели при сложно разсъждение, труден код, дълги зависимости и задачи, изискващи широки актуални знания. Разликата понякога не е нюанс, а цяла категория възможности.

  • Сложно многостъпково разсъждение.
  • Работа с огромен контекст и много файлове едновременно.
  • Актуална информация без локално изградена търсачка.
  • Мощни мултимодални задачи с изображения, видео и звук.
  • Няколко активни потребители върху ограничен хардуер.
  • Задачи, при които точността е по-ценна от поверителността или цената.

Локалният модел не трябва да побеждава облака във всичко, за да бъде полезен. Той трябва да изпълнява правилните задачи достатъчно добре, при условията, които ти контролираш. Това е инфраструктурно решение, не състезание по класации.

Изборът не е локален AI срещу облачен AI. Изборът е кои данни и задачи заслужават да останат вкъщи.



Практически план за начало

  1. Избери една конкретна задача, която искаш да решиш.
  2. Инсталирай Ollama или llama.cpp върху наличния хардуер.
  3. Започни с добър квантизиран модел от 7-8B клас.
  4. Измери скоростта, използваната памет и качеството на отговорите на български.
  5. Добави Open WebUI само ако ти е необходим удобен интерфейс или няколко потребители.
  6. Изгради малка RAG база с десет качествени документа, не с целия хаотичен архив.
  7. Тествай въпроси с предварително известни отговори и проверявай източниците.
  8. Добави WireGuard, автентикация и резервно копиране преди достъп отвън.
  9. Едва след това прецени дали нов хардуер действително ще реши измерен проблем.



Минимален checklist за лична AI инфраструктура

  • Знам точно коя задача решава локалният модел.
  • Знам къде работят моделът и embeddings.
  • Контекстът е съобразен с наличната RAM или VRAM.
  • Тествал съм качеството на български, не само на английски.
  • Не съм изложил административните услуги директно към интернет.
  • Проверил съм на кой адрес слуша inference сървърът.
  • Отдалеченият достъп минава през WireGuard или еквивалентна VPN.
  • Потребителите и автоматизациите имат минимални права.
  • RAG отговорите показват използваните източници.
  • Оригиналните документи и конфигурации се архивират.
  • Проверил съм какво спира да работи без интернет.
  • Измерил съм реалната консумация, температура и шум.
  • Имам критерий кога задачата трябва да премине към по-силен облачен модел.



Често задавани въпроси за локалния AI


Нужна ли е видеокарта за локален AI?


Не. Можеш да стартираш квантизирани модели и само върху CPU, но интерактивната скорост обикновено ще бъде по-ниска. GPU е най-полезен, когато искаш бърз разговор, по-голям модел, по-дълъг контекст или няколко едновременни задачи.

Колко VRAM е необходима?


За начало 8 GB могат да бъдат използваеми с малки модели и ограничен контекст, но 12-16 GB дават значително по-добра свобода. 24 GB са силна основа за по-големи квантизирани модели и по-сериозна локална работа. Точната нужда зависи от модела, квантизацията, контекста и броя заявки.

Може ли локалният AI да работи без интернет?


Да, след като моделите и необходимият софтуер са изтеглени. Облачни модели, външни embeddings, интернет търсене и remote инструменти естествено няма да работят. Напълно офлайн системата трябва да използва локални компоненти по цялата верига.

RAG обучава ли модела върху моите документи?


Не. RAG търси подходящи части от документите и ги добавя към текущата заявка. Моделът не променя основните си тегла и качеството зависи от извличането, chunking настройките, embeddings и подадения контекст.

Как се справят локалните модели с български?


Значително по-слабо, отколкото с английски, особено при малките модели. Кирилицата използва и повече токени за същия текст, което намалява реално използваемия контекст и скоростта. Тествай всеки модел с реални български текстове, преди да го приемеш за годен.

Локалният AI автоматично ли е по-сигурен?


Не. Лошо конфигуриран локален сървър, публично изложен интерфейс или автоматизация с прекомерни права могат да бъдат сериозен риск. Локалното изпълнение ти дава контрол, но не върши работата вместо теб.

Трябва ли да избирам между локални и облачни модели?


Не. Хибридната архитектура често е най-практична - чувствителните и повтарящи се задачи остават локални, а най-сложните заявки използват облачен модел при подходяща обработка на данните. Инфраструктурата трябва да обслужва теб, не идеологията.



Въпросът към вас


Кой вече изгражда или използва локален AI у дома? Интересуват ме реалните конфигурации, измерените резултати и проблемите, които не се виждат в красивите демонстрации. Точно там започва полезният разговор.

  • На какъв хардуер работите - CPU, NVIDIA, AMD или Apple Silicon?
  • Кои модели се оказаха реално използваеми и за какви задачи?
  • Каква скорост постигате, при каква квантизация и какъв контекст?
  • Кой модел се справя най-добре на български според вас?
  • Използвате ли Ollama, llama.cpp, Open WebUI или друг стек?
  • Имате ли работещ RAG над собствени документи и как решихте chunking и OCR проблемите?
  • Свързали ли сте локален модел с Home Assistant или n8n?
  • Колко ток, шум и време за поддръжка ви струва системата?
  • И скептиците са добре дошли - убедете ни защо всичко това е губене на време, ток и добри видеокарти.

Няма универсална конфигурация. Има правилно разбрана задача, измерени ограничения и система, която върши полезна работа. Всичко останало е хардуерна поезия с вентилатори.


Основни теми: локален AI у дома, личен AI сървър, Ollama, llama.cpp, Open WebUI, RAG над собствени документи, локален гласов асистент, whisper.cpp, Piper, Home Assistant, n8n, WireGuard, AI поверителност и домашна AI инфраструктура.
Полезни проекти и документация: Ollama, llama.cpp, Open WebUI, whisper.cpp, Piper, Home Assistant, n8n и WireGuard.


toni@dtgarage:~$ whoami
Тони Ангелчовски | Ексклузивно за DTGaraGe
toni@dtgarage:~$ cat LICENSE
🔒 Копирането и препубликуването без разрешение не е позволено.
toni@dtgarage:~$ ./support.sh
☕ Подкрепи DTGaraGe и независимото техническо съдържание
toni@dtgarage:~$ █
 
Локален AI – това е като да си държиш ключа за сервиза – в джоба, не на кука пред вратата.

Ollama: контейнерът за моделите – зареждаш, изолираш, командваш.
RAG: не търси в празното, а в твоите архиви – като да въртиш гайка с твоя тресчотка, не сета на съседа.
Home Assistant: мозъкът, който чете стаята, не клауд логовете.

В локалното няма магия – има яснота.
Слагаш на масата само желязото, което познаваш.
Данните не излизат навън, освен ако не решиш – ти, не алгоритъм някъде в облака.

Който си е правил сервиза сам, знае:
Локален AI е изборът между да слушаш ехото на интернет и да чуваш тишината на своята стая.
Тишината казва повече, отколкото всякакъв log файл.
 
Top Bottom
🛡️ Този сайт използва аналитични инструменти за подобряване на потребителското изживяване. Никакви лични данни не се събират. С продължаването си в Потока приемаш тази философия на прозрачност и уважение.