Перейти к содержанию
Публикация AiManual

Как собрать AI-сервер без интернета до $5k: выбор GPU, VRAM и локальных LLM

Практический гайд по сборке офлайн AI-сервера до $5k: как рассчитать VRAM для Gemma и моделей 30B-класса, выбрать одну GPU или multi-GPU, подобрать GGUF и llama

Коротко

Что будет в материале

  1. 01

    Коротко: с чего начинать сборку AI-сервера без интернета

  2. 02

    Сначала определите сценарий: кому и для чего нужен локальный AI-чат

  3. 03

    Сколько VRAM нужно для LLM: веса - только часть расчёта

  4. 04

    Как выбрать GPU для локальной нейросети: одна карта или несколько

Коротко: с чего начинать сборку AI-сервера без интернета

Сервер для офлайн-чата в бюджете до $5k выбирают от сценария, целевой модели и числа одновременных диалогов. Для дома или небольшой администрации чаще подходит одна GPU с 24, 32 или 48 ГБ VRAM, если веса модели, KV-cache и рабочие буферы runtime помещаются с запасом. Multi-GPU нужна, когда целевая LLM не входит на одну карту либо сервер должен обслуживать несколько тяжёлых сессий одновременно.

Для модели 30B-класса в 4-битном формате грубая оценка весов выглядит так: 30 млрд параметров × 4 бита / 8, то есть около 15 ГБ до учёта служебных данных. В VRAM ещё потребуются KV-cache, память под контекст и буферы backend. Поэтому карта на 24 ГБ может подойти для короткого контекста и одной сессии, но 32-48 ГБ дают заметно больше запаса. Системная RAM не превращается в VRAM: CPU offload помогает загрузить модель, однако обмен данными через PCIe часто снижает скорость ответа.

Для Gemma и других LLM этого класса заранее проверьте model card, лицензию, контекстное окно и поддержку выбранного runtime. Для офлайн-запуска часто рассматривают GGUF и llama.cpp, но совместимость зависит от версии движка, архитектуры модели и backend. В смету нужно включить системную RAM, NVMe-накопитель, блок питания, охлаждение, корпус, сеть, ИБП, доставку и резерв на замену компонентов.

Порядок решения: задачи → модель → VRAM → GPU → остальное железо

  1. Опишите задачи и пользователей. Один семейный диалог, справочная система для сотрудников и общий чат по документам создают разные требования к памяти и скорости.
  2. Выберите целевой класс моделей. Зафиксируйте конкретную LLM или несколько кандидатов: компактная модель, 20-30B-класс, плотная архитектура или MoE.
  3. Рассчитайте VRAM. Сложите объём весов в выбранной квантизации, KV-cache, рабочие буферы и запас. Отдельно оцените длинный контекст и несколько активных сессий.
  4. Сравните одну и несколько GPU. Одна карта проще в эксплуатации. Multi-GPU позволяет разместить крупную модель, но требует подходящей платы, корпуса, БП и runtime.
  5. Подберите платформу. После GPU выбирайте CPU, RAM, материнскую плату, накопители, охлаждение, сеть и ИБП. Для удалённого региона эти компоненты влияют на доступность сервера сильнее, чем разница в нескольких токенах в секунду.

Покупка видеокарты на первом шаге часто приводит к несовместимой сборке. Карта может физически не поместиться, потребовать больше питания, чем способен выдать БП, или работать с нужным runtime только после ручной сборки и настройки драйвера.

Что нужно перепроверить перед покупкой комплектующих

  • точный объём VRAM и тип памяти по спецификации конкретной модели;
  • поддержку GPU в выбранной ОС, версии драйвера и backend;
  • совместимость архитектуры LLM с runtime и нужным форматом весов;
  • длину и толщину видеокарты, расположение вентиляторов и доступ к разъёмам питания;
  • число полноразмерных PCIe-слотов, количество линий и их реальную разводку на плате;
  • мощность БП с учётом пикового потребления, разъёмов и отдельных кабелей для ускорителей;
  • условия гарантии, состояние карты на вторичном рынке, стоимость доставки и возможного ремонта;
  • работу системы после отключения интернета, перезапуска и восстановления из резервной копии.

Цены и наличие GPU меняются, особенно в удалённых регионах. Сверяйте смету на дату покупки и разделяйте новые компоненты, бывшие в употреблении карты и детали без локальной гарантии.

Сначала определите сценарий: кому и для чего нужен локальный AI-чат

Семейный помощник, администрация и внутренний справочник - это разные нагрузки

Семейному помощнику обычно нужны ответы на бытовые вопросы, составление текстов, суммаризация и поиск по небольшому набору локальных файлов. При таком сценарии нагрузку задают один-два активных диалога и длина документов. Компактная модель с коротким контекстом может дать более удобный опыт, чем крупная LLM, которая отвечает медленно и требует сложной сборки.

Для сельской администрации требования меняются. Пользователи работают с регламентами, шаблонами писем, протоколами, инструкциями и обращениями граждан. Здесь полезны локальный RAG, разграничение ролей, история действий и понятный способ показать документ, на котором основан ответ. В техническом задании зафиксируйте пиковое число сессий, например 3, 5 или 10, а затем проверяйте сервер именно в таком режиме.

Внутренний справочник по документам создаёт длинные входные запросы. Генерация ответа может быть короткой, но подготовка контекста потребует памяти и времени. Чат для технических специалистов, напротив, способен предъявлять более высокие требования к рассуждению, коду и качеству следования инструкциям. Размер модели сам по себе не решает эту задачу.

СценарийЧто определить заранееЧто сильнее всего влияет на сервер
Семейный помощникчисло одновременных диалогов, приватность, набор локальных файловскорость первого ответа, простой интерфейс, низкий шум
Администрацияроли пользователей, регламенты, журналирование, пиковая нагрузкаKV-cache при нескольких сессиях, RAG, стабильность и резервное питание
Внутренний справочникобъём документов, частота обновления, правила доступадлина контекста, RAM, индекс документов, качество цитирования
Технический ассистентязыки программирования, формат ответов, требования к точностикачество instruction-модели, скорость генерации, тестовый набор запросов

Что на практике означает «полностью офлайн»

Полностью офлайн работает система, в которой локально доступны веса модели, inference runtime, веб-интерфейс или API, база документов, индекс, учётные записи и журналы. Пользователь подключается к серверу через локальную сеть, а внешний канал связи для ответа модели не требуется.

Проверьте, что интерфейс не ждёт облачную авторизацию, runtime не скачивает модель при первом запуске, а плагины и интеграции не отправляют запросы наружу. Телеметрию отключайте, если она не нужна для диагностики. Для администрации полезно заранее зафиксировать список разрешённых сетевых соединений и периодически проверять его.

Офлайн-обновление лучше превратить в отдельную процедуру. На компьютере с доступом к сети подготовьте пакет драйвера, runtime, модели и зависимостей, проверьте контрольные суммы, перенесите его через доверенный носитель и протестируйте на отдельной копии. Рабочую систему обновляйте после резервного копирования конфигурации и возможности отката.

Какие показатели зафиксировать до выбора железа

  • конкретную модель и квантизацию;
  • язык ответов и требования к качеству русского текста;
  • размер контекстного окна, например 8k, 16k или 32k токенов;
  • среднее и пиковое число одновременных пользователей;
  • допустимое время до первого токена;
  • минимальную приемлемую скорость генерации;
  • время непрерывной работы без перезапуска;
  • ограничения по шуму, температуре, энергопотреблению и месту установки.

Эти параметры превращают запрос «нужен мощный AI-сервер» в измеримое ТЗ. Без них сравнение GPU сводится к объёму памяти и рекламным цифрам, которые мало говорят о конкретном рабочем процессе.

Сколько VRAM нужно для LLM: веса - только часть расчёта

Веса модели, KV-cache и буферы runtime: куда уходит память

Грубую оценку памяти под веса можно получить формулой:

память весов ≈ число параметров × битность / 8 × коэффициент служебного запаса

Для плотной модели на 30 млрд параметров ориентиры выглядят так:

ФорматРасчёт веса без служебного запасаПрактический смысл
FP16около 60 ГБодна потребительская GPU обычно не подходит без распределения по устройствам или CPU offload
8 битоколо 30 ГБтребуется ускоритель с большим объёмом памяти либо смешанное размещение
4 битаоколо 15 ГБмодель может войти на карту 24 ГБ, но запас зависит от контекста, runtime и числа сессий

Это арифметический ориентир, а не гарантия запуска. Квантизированный файл содержит служебные данные и параметры блоков, а runtime выделяет память под тензоры, временные операции и внутренние структуры.

KV-cache хранит состояние уже обработанных токенов для генерации продолжения. Его расход растёт с длиной контекста и общим числом активных токенов во всех сессиях. Один диалог с длинным документом может потребить больше памяти, чем несколько коротких вопросов. Точная формула зависит от числа слоёв, размера скрытого состояния, числа KV-heads, типа кэша и настроек backend.

Мультимодальные компоненты, reranker, embedding-модель и локальный индекс добавляют собственные расходы. Если сервер одновременно ищет фрагменты в документах и генерирует ответ, измеряйте память всей цепочки, а не одной LLM.

Как квантизация меняет требования к памяти и качество ответов

Квантизация уменьшает размер весов, переводя параметры в более компактное представление. Форматы уровня q4 требуют меньше памяти, чем q5 или q6, а более точные варианты обычно оставляют больше данных в исходной точности. Сравнивать нужно конкретные файлы и конкретные задачи.

Потеря качества после квантизации зависит от архитектуры и запроса. На простом резюме разница может быть незаметной, а на русском юридическом тексте, извлечении реквизитов, коде или длинной инструкции ошибки проявятся сильнее. Проверяйте:

  • соблюдение формата ответа;
  • работу с русскими именами, датами и сокращениями;
  • извлечение фактов без выдуманных деталей;
  • следование системному prompt;
  • качество ответа при длинном контексте;
  • скорость загрузки и генерации.

Методику самостоятельной оценки памяти с учётом весов, KV-cache и CPU offload разбирает отдельный материал о расчёте помещаемости локальной LLM. Сервисы и старые карточки не заменяют проверку в той версии runtime, которую вы планируете использовать.

Почему модель 30B-класса нельзя выбирать по одной цифре «30B»

Число параметров описывает масштаб модели, но не даёт полного требования к памяти. На результат влияют плотная или разреженная архитектура, размер и тип KV-cache, квантизация, контекст, batch size, число пользователей и распределение слоёв между GPU и CPU.

Практический расчёт делайте в три шага:

  1. оцените вес модели в выбранном формате;
  2. добавьте память на максимальный контекст и активные сессии;
  3. оставьте резерв под runtime, RAG-компоненты и фоновые процессы.

Для 30B q4 арифметический минимум около 15 ГБ ещё не означает комфортную работу на карте 16 ГБ. На 24 ГБ запуск может потребовать короткого контекста, одной сессии или частичного offload. Карта на 32-48 ГБ оставляет больше пространства для длинных запросов и параллельных пользователей, но конкретный результат нужно подтвердить тестом.

Для 30B в 8-битном формате около 30 ГБ занимают только веса. Карта на 24 ГБ не разместит их полностью, поэтому придётся распределять модель между устройствами или переносить часть слоёв в системную память. Такой режим иногда подходит для фоновых задач, но может раздражать пользователей в интерактивном чате.

MoE-модели: активные эксперты не отменяют требования к памяти

В архитектуре Mixture of Experts на каждом токене активируется часть экспертов. Поэтому в описании модели могут отдельно указываться общее число параметров и число активных параметров. Активные параметры влияют на вычисления на конкретном токене, а объём доступных весов, структура маршрутизации и способ загрузки определяют требования к памяти.

Одна реализация может загружать все эксперты в память, другая поддерживает частичную загрузку или динамическое распределение. Скорость зависит от пропускной способности памяти, PCIe, размера batch и backend. Результаты запуска на Metal нельзя напрямую переносить на CUDA или Vulkan. Проверяйте именно ту связку GPU, ОС, драйвера и runtime, которую собираетесь отвезти в удалённый регион.

Как выбрать GPU для локальной нейросети: одна карта или несколько

Одна GPU с достаточной VRAM: самый простой путь для постоянного офлайн-чата

Одна карта создаёт одну понятную область видеопамяти, один набор драйверов и меньше источников отказа. Корпус проще охладить, кабелей меньше, диагностика быстрее. Для семейного сервера или небольшой организации это часто перевешивает теоретическую выгоду второй карты.

У однокарточной схемы есть жёсткое условие: целевая модель, контекст, KV-cache и рабочие буферы должны помещаться в доступную VRAM с запасом. Если приходится постоянно снижать контекст, отключать RAG или переносить половину слоёв на CPU, карта формально запускает модель, но не обязательно подходит для ежедневного сервиса.

Карты класса 24 ГБ подходят как исходная точка для компактных и некоторых квантизированных моделей среднего размера. Для 30B-класса с длинным контекстом разумнее смотреть на 32-48 ГБ, если цена, охлаждение и доступность укладываются в смету. Это направление стоит сверять с реальными задачами, а не с максимальным размером файла модели.

CPU-only конфигурация тоже может иметь смысл для фонового RAG, очереди документов и автоматизаций, где ответ не нужен мгновенно. Ограничения такого подхода и сценарии, в которых медленный inference остаётся удобным, разобраны в материале о CPU-сервере и медленном локальном inference.

Несколько GPU: когда multi-GPU оправдана, а когда добавляет проблем

VRAM двух карт не превращается в единый быстрый пул автоматически. Runtime должен уметь распределять слои, тензоры или другие части модели между устройствами. При этом появляются накладные расходы на обмен данными и зависимость от PCIe-топологии.

Multi-GPU оправдана в трёх случаях:

  • нужная модель не помещается на одну доступную карту;
  • несколько пользователей создают параллельную нагрузку, и суммарная память позволяет удерживать больше сессий;
  • есть проверенный runtime, подходящая плата, достаточное питание и ответственный за обслуживание.

Вторая карта увеличивает тепловую нагрузку, шум, длину корпуса и число кабелей. Между ускорителями может не хватить расстояния для нормального забора воздуха. На плате могут оказаться доступны физические слоты, но не нужное количество PCIe-линий. Каждый дополнительный компонент расширяет список возможных отказов.

Готовые системы с большим количеством ускорителей требуют отдельного расчёта стоимости платформы, охлаждения и обслуживания. О том, чем крупные рабочие станции отличаются от ПК с одной или двумя GPU, можно прочитать в разборе NVIDIA DGX Station и настольных AI-систем.

Потребительские и профессиональные GPU: VRAM важнее маркетингового класса, но не единственный критерий

Класс ускорителяКогда подходитЧто проверить
Потребительская GPU с 16 ГБкомпактные модели, короткий контекст, один пользовательскорость памяти, поддержка backend, ограничения по квантизации и охлаждение
Потребительская GPU с 24-32 ГБуниверсальный однокарточный сервер для квантизированных LLMреальный запас VRAM, габариты, пиковое потребление, состояние карты
Профессиональная GPU с 48 ГБ и большемодели крупнее, длинный контекст, несколько сессийцена, гарантия, доступность ремонта, охлаждение и совместимость драйверов
Несколько потребительских GPUраспределение крупной модели или параллельная нагрузкаPCIe-линии, расстояние между слотами, БП, корпус, runtime и вентиляция

Профессиональное позиционирование не гарантирует лучшую скорость генерации. Его преимущества могут выражаться в объёме VRAM, вариантах охлаждения, гарантии и предсказуемости поставки. Потребительская карта иногда даёт более выгодное соотношение цены и скорости, но её ремонт в удалённом регионе может занять больше времени.

Дефицит профессиональных ускорителей и особенности проверки карт на вторичном рынке разобраны в материале о RTX 6000 и рынке GPU для локального AI. Перед покупкой бывшей в употреблении карты нужны проверка температур под нагрузкой, тест памяти, осмотр разъёмов и письменные условия возврата.

Backend и драйверы до покупки GPU: CUDA, ROCm, Vulkan и другие варианты

GPU выбирается вместе с программным стеком. CUDA, ROCm, Vulkan и Metal используют разные пути ускорения, а поддержка конкретных операций может отличаться между версиями. Одинаковый GGUF-файл способен запускаться с разной скоростью и разным потреблением памяти.

До покупки проверьте четыре уровня совместимости:

  1. точная модель GPU и её поколение;
  2. операционная система и версия драйвера;
  3. сборка runtime и нужный backend;
  4. архитектура модели, формат весов и функции, которые требуются для контекста и RAG.

Для llama.cpp отдельно проверьте, как сборка распределяет слои, поддерживает ли выбранную GPU и умеет ли работать с нужным типом квантизации. Для серверного API проверьте запуск без внешней авторизации и загрузки компонентов из сети. Наличие VRAM без рабочего backend не превращает карту в готовый AI-сервер.

Какие локальные модели выбрать: Gemma, 30B-класс и форматы весов

Когда достаточно компактной модели, а когда нужен класс 20-30B

Компактная модель подходит для шаблонных писем, кратких ответов, простого резюме и поиска по хорошо подготовленному контексту. Для такого сценария качество документов, системный prompt и настройки RAG иногда влияют сильнее, чем переход на более крупную LLM.

Модель 20-30B-класса оправдана, когда нужны более сложные инструкции, устойчивое форматирование, технический диалог, обработка неоднозначных запросов или работа с длинными материалами. Рост размера требует больше VRAM, RAM, времени загрузки и электричества. Большая модель не отменяет проверку фактов и настройку контекста.

Если GPU имеет 12 ГБ VRAM, полезно начинать с компактных вариантов и измерять скорость на собственных запросах. Практические ограничения такого запуска, влияние KV-cache и выбор квантизации разобраны в гайде по локальным моделям на 12 ГБ VRAM.

Gemma и другие модели: что проверить в model card до загрузки весов

  • Лицензию. Проверьте условия личного, коммерческого и организационного использования, распространения весов и производных продуктов.
  • Поддерживаемые языки. Русский язык может иметь разное качество в instruction-моделях одного масштаба.
  • Контекстное окно. Заявленная длина контекста должна поддерживаться конкретной сборкой runtime и помещаться в память.
  • Вариант настройки. Для чата нужна instruction-модель, если это предусмотрено семейством. Базовая модель требует другой схемы prompt и донастройки.
  • Форматы и архитектуру. Не каждый файл поддерживает GGUF, GPU offload или выбранную реализацию MoE.
  • Ограничения и риски. Изучите условия применения, известные проблемы с отказами, фактами, кодом и чувствительными темами.

Gemma и другие семейства 30B-класса нельзя сравнивать по одному числу параметров. Сопоставляйте конкретные версии, квантизации, языковую поддержку, лицензию и результаты на собственном наборе задач.

GGUF, квантизированные веса и llama.cpp: как выбрать формат для офлайн-запуска

GGUF хранит веса и метаданные в формате, который поддерживают различные локальные инструменты. llama.cpp использует этот подход для запуска моделей на CPU и разных GPU-backend. Файл модели, runtime и backend нужно рассматривать как одну связку.

Перед загрузкой убедитесь, что:

  • архитектура модели поддерживается нужной версией llama.cpp;
  • квантизация действительно предназначена для этого семейства;
  • веса скачаны полностью и прошли проверку контрольной суммы;
  • параметры контекста и GPU offload соответствуют объёму VRAM;
  • модель запускается без обращения к сети после первого развёртывания.

Название q4 или q5 не описывает весь опыт работы. Уточняйте схему квантизации, размер файла, требования к KV-cache и рекомендации авторов модели. Для критичных рабочих процессов сохраните проверенный файл, версию runtime и конфигурацию запуска в локальном архиве.

Сначала проверка на задачах, затем покупка железа

Подготовьте 20-50 обезличенных запросов из реальной работы. В набор включите вопросы по регламентам, черновики писем, резюме протоколов, извлечение дат и реквизитов, поиск по документам, технические инструкции и запросы с неоднозначными формулировками.

Для каждой модели фиксируйте оценку по шкале 0-2:

  • фактическая точность;
  • качество русского языка;
  • соблюдение формата;
  • наличие выдуманных ссылок и реквизитов;
  • работа с длинным контекстом;
  • скорость первого ответа и генерации;
  • стабильность при повторном запуске.

Модель, которая хорошо выглядит в общем рейтинге, может плохо работать с вашими документами. Тестовый набор заранее показывает, нужен ли 30B-класс или компактной LLM достаточно.

Сборка до $5k: бюджет нужен не только на GPU

Полная спецификация сервера: CPU, RAM, накопитель, сеть и корпус

КомпонентПрактический ориентирЗачем он нужен
GPUодна карта с 24, 32 или 48 ГБ VRAM под выбранную модельразмещает веса, KV-cache и рабочие буферы без постоянного offload
CPU и платформапроцессор с достаточной пропускной способностью памяти и нужными PCIe-линиямиобрабатывает запросы, документы, RAG и фоновые задачи
Системная RAM64 ГБ для одной модели и умеренного RAG, 128 ГБ для активного CPU offload или нескольких сервисовхранит ОС, индексы, документы, кэш и слои модели при смешанном размещении
НакопительNVMe на 2 ТБ как удобная отправная точка для нескольких моделей и индексаускоряет загрузку весов, работу базы документов и резервное копирование
БПмощность с запасом по пиковым нагрузкам и правильными разъёмамиснижает риск отключений и перегрева кабелей
Корпус и охлаждениесвободный поток воздуха, фильтры, место для карты полной длиныподдерживает стабильную работу под длительной нагрузкой
Сетьлокальный Ethernet или изолированный Wi-Fi-сегмент для клиентовдаёт доступ к веб-интерфейсу без подключения к интернету
ИБПмодель с USB или другим способом корректного завершения работызащищает от перебоев и позволяет безопасно выключить сервер

64 ГБ RAM не заменяют 64 ГБ VRAM. Системная память полезна для CPU offload и RAG, но скорость генерации при переносе части модели на CPU зависит от пропускной способности памяти и PCIe. Для интерактивного чата лучше разместить основную часть вычислений на GPU.

NVMe нужен не ради красивой спецификации. Файл крупной модели может занимать десятки гигабайт, а несколько квантизаций, embedding-модель, индекс и резервные копии быстро увеличивают объём хранилища. Разделите рабочие данные, архив моделей и резервную копию конфигурации.

Материнская плата, PCIe и блок питания: где ломаются многокарточные планы

Перед покупкой multi-GPU-платформы нарисуйте схему слотов. Проверьте физическое расстояние между ускорителями, их толщину, доступ воздуха и возможность подключить кабели после установки. Два полноразмерных разъёма не гарантируют, что обе карты получат нужное число PCIe-линий.

  • сверьте распределение PCIe-линий в руководстве платы;
  • проверьте поддержку нескольких видеоустройств в BIOS и ОС;
  • оставьте место для забора и выхода воздуха;
  • проверьте тип и число коннекторов питания;
  • используйте отдельные кабели для мощных ускорителей, если это требует производитель БП;
  • учтите длину кабелей, радиус изгиба и доступ к защёлкам слотов;
  • проверьте, не перекрывает ли карта разъёмы накопителей и дополнительные контроллеры.

Номинальная мощность БП не заменяет расчёт пиков. Сложите требования CPU, каждой GPU, накопителей, вентиляторов и плат расширения, затем добавьте резерв. Для бывших в употреблении ускорителей отдельно учитывайте износ вентиляторов и последствия прежней работы под высокой нагрузкой.

Электричество, тепло и пыль в удалённом регионе

В удалённом регионе простой сервера может стоить дороже разницы между двумя GPU. Измерьте качество электросети, продолжительность типичных перебоев и доступность сервиса ИБП. Настройте автоматическое завершение работы, чтобы внезапное отключение не повредило файловую систему и индекс документов.

Пыль забивает фильтры и радиаторы, а высокая температура сокращает запас по охлаждению. Нужны свободный забор воздуха, регулярная очистка, мониторинг температур и заранее подготовленные вентиляторы, кабели и крепёж. Не ставьте сервер в закрытый шкаф без организованного притока и отвода воздуха.

Для постоянной работы задайте пороги уведомлений по температуре GPU, CPU, накопителя и ИБП. Журналируйте перезапуски, ошибки драйвера и заполнение диска. При отсутствии местного сервиса сохраните конфигурацию системы и резервный план с одной заведомо совместимой картой или платой.

Смету до $5k считайте как стоимость владения. В неё входят ускоритель, платформа, RAM, накопитель, БП, корпус, охлаждение, ИБП, доставка, налоги, кабели и резерв. Цену каждого компонента сверяйте на дату покупки.

Статья расходовОднокарточная схемаMulti-GPU-схема
Ускорителиоколо 55% бюджета как стартовая планкаоколо 60%, если модель действительно требует несколько карт
CPU, плата и RAMоколо 20%около 20%, иногда больше из-за платформы и PCIe
Накопительоколо 8%около 8%
БП, корпус и охлаждениеоколо 9%около 12%, поскольку тепловая и электрическая нагрузка выше
ИБП, доставка и резервоколо 8%около 8%

Это модель распределения, а не прайс-лист. При потолке $5k доля 55% оставляет примерно $2,250 на остальные узлы и логистику. Если выбранная карта поглощает почти весь бюджет, проверьте, не придётся ли экономить на ИБП, охлаждении или гарантии.

Как сделать локальный AI-сервер удобным для обычных пользователей

Локальная сеть, интерфейс и доступ без интернета

Пользовательский путь должен состоять из открытия браузера, выбора режима и ввода вопроса. Сервер размещается в локальной сети, а веб-интерфейс обращается к inference runtime через локальный API. Терминал, драйверы и системные настройки остаются доступны администратору.

Разделите пользовательский и административный доступ. Обычная учётная запись не должна менять модель, загружать произвольные плагины или просматривать чужие диалоги. Для администрации задайте роли, правила хранения истории и срок удаления чувствительных данных.

Если сервер обслуживает несколько рабочих мест, заранее определите диапазон локальных адресов, резервный способ подключения и порядок смены паролей. При отсутствии интернета нельзя рассчитывать на внешний сервис восстановления учётной записи.

Режимы работы вместо «чистого чата»: шаблоны, роли и системные prompt

Один универсальный чат заставляет каждого пользователя заново объяснять модели задачу. Набор преднастроенных режимов делает ответы предсказуемее:

  • помощник по внутренним документам;
  • подготовка черновика письма;
  • краткое резюме протокола;
  • поиск требований в регламенте;
  • семейный справочник;
  • технический помощник с обязательным указанием допущений.

Для каждого режима задайте роль модели, формат ответа, правила работы с отсутствующими сведениями и запрет на выдумывание реквизитов. Полезно требовать фразу о нехватке данных, если документ не содержит ответа. Ограниченный сценарий часто даёт более стабильный результат, чем попытка превратить одну модель в универсального консультанта.

Локальный RAG для документов: где он помогает, а где не заменяет проверку фактов

Локальный RAG состоит из четырёх этапов: документы разбиваются на фрагменты, фрагменты превращаются в векторы, поиск выбирает релевантные части, LLM формирует ответ на их основе. Все компоненты могут работать внутри локальной сети.

RAG помогает находить сведения в регламентах и внутренних справочниках без передачи файлов в облако. Его качество зависит от очистки PDF, размера фрагментов, embedding-модели, поискового индекса и prompt. Отсканированный документ с ошибками распознавания даст плохой контекст даже при мощной GPU.

Индекс нужно обновлять после изменения документов. Контролируйте права на коллекции, показывайте пользователю название файла и страницу, если формат это позволяет, и храните версию набора документов. Ответ модели остаётся черновой интерпретацией. Юридические, финансовые и управленческие решения требуют проверки человеком.

Резервируйте конфигурацию runtime, шаблоны prompt, учётные записи, индекс, список моделей и инструкции по восстановлению. Отдельно сохраните рабочий набор квантизированных весов, чтобы повторная загрузка через медленный канал не стала обязательным условием ремонта.

Проверка перед запуском: скорость, стабильность и автономность

Какие метрики собрать до ввода сервера в эксплуатацию

Тестируйте одну и ту же модель, квантизацию, версию runtime, контекст и набор запросов. Чужие бенчмарки помогают выбрать направление, но не описывают вашу плату, охлаждение, драйвер и нагрузку пользователей.

МетрикаЧто измерятьЗачем
Время загрузкиинтервал от запуска runtime до готовности чатапоказывает, насколько удобно перезапускать сервер после сбоя
TTFTвремя до первого токена после отправки запросахарактеризует субъективную задержку интерфейса
Скорость генерациитокены в секунду на коротком и длинном ответепоказывает пригодность для ежедневного диалога
Памятьпиковые значения VRAM и RAM при разных контекстахпомогает найти предел до появления ошибок нехватки памяти
Параллельностьповедение при целевом числе одновременных сессийотделяет домашний режим от общего сервиса
Температура и шумзначения после длительной нагрузкипоказывает пригодность корпуса и охлаждения для постоянной работы
Качествооценка тестовых запросов и число выдуманных фактовсвязывает технические характеристики с реальной пользой
Восстановлениеперезапуск, корректное завершение и восстановление индексапроверяет готовность к перебоям питания и ошибкам обновления

До покупки задайте собственные пределы: например, допустимую задержку первого токена, минимальную скорость генерации, максимум температуры и время восстановления. Для короткого семейного ответа и очереди документов эти значения будут разными.

Как подтвердить, что AI-сервер действительно работает без интернета

  1. Отключите внешний канал связи, оставив сервер и клиентские устройства в локальной сети.
  2. Перезапустите сервер и убедитесь, что runtime не пытается скачать модель или зависимость.
  3. Откройте интерфейс с обычного рабочего места и выполните несколько диалогов.
  4. Проверьте поиск по локальным документам и отображение названий использованных файлов.
  5. Создайте новую локальную учётную запись и проверьте разграничение доступа.
  6. Перезапустите GPU runtime, веб-интерфейс и сам сервер.
  7. Проверьте журналы и сетевые соединения, чтобы обнаружить скрытые внешние обращения.
  8. Восстановите конфигурацию и индекс из резервной копии на тестовой системе.

Тест считается пройденным, когда пользователю не требуется интернет для входа, загрузки модели, ответа и работы с локальными документами. Обновления и диагностика остаются плановыми операциями через подготовленные офлайн-пакеты.

Где локальный AI выигрывает у облака, а где неизбежно уступит

Когда локальная LLM - рациональный выбор

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

Экономика складывается из первоначальной покупки, электроэнергии, ремонта, обновлений и времени ответственного администратора. После покупки нет оплаты каждого токена, но расходы не исчезают. При постоянной загрузке GPU потребляет электричество, а пыль, вентиляторы и накопители требуют обслуживания.

Для удалённого региона автономность может перевесить более высокое качество облачного сервиса. Пользователь получает доступ к заранее проверенной модели даже при отключённом внешнем канале.

Когда лучше не обещать пользователям замену облачного AI

Локальная LLM может ошибаться, выдумывать факты и неверно интерпретировать найденный документ. Она не получает свежие сведения после даты обучения без отдельного локального источника данных. RAG добавляет контекст, но не гарантирует правильный вывод.

Облачные флагманские модели могут превосходить локальную сборку в сложном рассуждении, мультимодальных задачах, работе с редкими знаниями и скорости обновления. Облако снимает часть забот о драйверах, дисках и ремонте, но добавляет зависимость от сети, политики поставщика и правил обработки данных.

Пользователям заранее сообщите, какие ответы требуют проверки. Для администрации это могут быть суммы, сроки, правовые формулировки и реквизиты. Для семьи, медицинские и финансовые советы. Для технических специалистов, команды кода и инструкции, влияющие на производственные системы.

Финальный чек-лист: можно ли покупать железо

  • Определены задачи, пользователи и пиковое число одновременных диалогов.
  • Выбрана конкретная модель, проверены её языки, контекст, формат и лицензия.
  • Объём весов рассчитан вместе с KV-cache, runtime и запасом VRAM.
  • Проверена связка GPU, ОС, драйвера, backend и llama.cpp или другого runtime.
  • Для 30B-класса отдельно протестированы q4, q5 или другой выбранный формат.
  • В смету включены системная RAM, NVMe, БП, корпус, охлаждение, сеть и ИБП.
  • Для multi-GPU проверены PCIe-линии, расстояние между слотами, питание и поток воздуха.
  • Подготовлен план офлайн-обновлений, резервных копий и восстановления.
  • Назначен человек, который сможет заменить компонент, проверить журнал и вернуть рабочую конфигурацию.
  • Интерфейс протестирован на пользователях без технического опыта.

Для одного-двух пользователей и коротких запросов начните с одной GPU класса 24-32 ГБ и 64 ГБ RAM, если конкретная модель помещается с запасом. Для 30B-класса, длинного контекста и нескольких сессий ищите 32-48 ГБ VRAM и планируйте 128 ГБ RAM, но подтверждайте расчёт тестовым запуском. Multi-GPU покупайте после проверки runtime и полной схемы питания.

Локальный AI-сервер до $5k может дать автономный чат, контроль над документами и предсказуемый доступ в удалённом регионе. Его ценность определяется рабочим сценарием, качеством модели и готовностью обслуживать железо. Если эти условия зафиксированы, выбор GPU становится инженерной задачей, а не соревнованием характеристик.

Подписаться на канал