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

В официальной карточке AliceAI-Foundation-80B-A3B-Base указаны 80 миллиардов параметров, около 3 миллиардов активных на токен и предельный контекст 262 144 токена. Лицензия обозначена как Apache 2.0. Эти свойства относятся к конкретному опубликованному релизу. Их нельзя автоматически переносить на приложение Алиса, облачный API или другую модель с похожим названием.

Яндекс прямо описывает этот выпуск как предварительно обученную модель без дополнительного post-training и alignment. Разработчики рекомендуют собственное тестирование и подготовку перед использованием в продуктах. Поэтому первое решение заказчика — нужен ли исследовательский проект на базовой модели или готовая модель, уже подготовленная к выполнению инструкций.

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

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

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

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

В MoE-архитектуре на конкретном шаге используется часть экспертных блоков. Это влияет на вычислительную работу, но для обслуживания следующих токенов системе нужны и другие эксперты. План размещения нельзя строить так, будто в модели всего три миллиарда параметров. Конкретная схема хранения и загрузки зависит от программного движка.

Также нельзя вычесть объём весов из суммарной памяти карт и объявить остаток доступным пользователям. Часть ресурсов занимают буферы, временные данные и обмен между устройствами. При использовании CPU-памяти меняются задержка и пропускная способность. Номинально вместившаяся модель может оказаться неудобной при одновременной работе отдела.

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

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

Этот слой позволяет обновлять документы независимо от весов. Если меняется инструкция или прайс, обычно требуется обновить источник и индекс, а не заново обучать языковую модель. Различия подходов разобраны в сравнении RAG и дообучения. Возможность найти актуальный материал и способность корректно оформить ответ проверяют отдельно.

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

1. Качество по примерам. Сравните ответы на обычных, неполных и противоречивых материалах. Для каждой ситуации заранее определите допустимый результат.
2. Нагрузка отдела. Измерьте задержку и очередь при ожидаемом числе одновременных пользователей. Отдельно проверьте длинный документ и длинный ответ.
3. Права на источники. Используйте тестовые роли и закрытые документы. Проверяйте текст ответа, историю диалога и доступ к оригиналу.
4. Маршрут данных. Учтите генерацию, поиск, распознавание, телеметрию и обслуживание. В строго локальной схеме внешний модельный резерв отключён.
5. Обновление и откат. Зафиксируйте версию модели, настройки запуска и проверочный набор. Проверьте возврат к принятой конфигурации после изменения.
6. Эксплуатация. Назначьте ответственного за источники, мониторинг, копии и восстановление. Успешный первый запуск не заменяет рабочую процедуру обслуживания.

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

В официальном репозитории приведён пример LoRA на четырёх GPU с 80 ГБ памяти. Это конфигурация определённого примера, а не универсальная рекомендация для любого обучения. Другие длины последовательности, данные и настройки требуют собственной оценки. Покупку оборудования под обучение нельзя обосновать лишь тем, что квантизованные веса помещаются на одной карте.

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

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

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

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

• Яндекс: официальная карточка AliceAI-Foundation-80B-A3B-Base
• Команда Яндекса: описание архитектуры и подготовки AliceAI
• Николай Хлебинский: обсуждение открытой модели Яндекса, источник темы