Идея локального ИИ для бизнеса выглядит очень привлекательно.
Модель работает на собственном сервере. Данные не нужно отправлять во внешний сервис. Нет платы за каждый запрос. Можно подключить внутренние документы, базу знаний, код, отчёты и рабочие системы компании.
Особенно хорошо всё выглядит в демонстрациях.
Модель запускают на мощной видеокарте, задают ей вопрос и получают, например, 50, 100 или даже больше токенов в секунду.
Кажется, что вопрос закрыт: если ответ генерируется быстро, значит локальный ИИ готов к работе.
Но для компании этот показатель почти ничего не гарантирует.
Потому что один пользователь с коротким запросом и корпоративный сервис для десяти сотрудников — это две совершенно разные нагрузки.
Один быстрый ответ — ещё не производительность системы
Самый распространённый тест локальной модели выглядит примерно так.
Модель загружается на сервер.
Ей дают запрос.
Замеряют скорость генерации.
Получают 60 токенов в секунду.
Отлично.
Но представим, что эту систему подключили к работе пяти сотрудников.
Первый отправил большой договор.
Второй загрузил техническую документацию проекта.
Третий попросил проанализировать несколько десятков файлов с исходным кодом.
Четвёртый продолжает длинный диалог.
Пятый запускает агента, который делает несколько последовательных обращений к модели.
Теперь нас интересует уже не максимальная скорость одного ответа.
Нас интересует, сколько таких задач сервер способен выполнять одновременно и сколько времени каждый пользователь будет ждать результата.
И вот здесь цифры начинают сильно меняться.
Хороший пример: шесть RTX 3090 и семь одновременных пользователей
В одном из свежих экспериментов разработчик запускал Qwen3.8-Flash-Next на обычном, пусть и очень необычном, настольном компьютере.
В машине стояли шесть RTX 3090, Ryzen 7950X и 187 ГБ оперативной памяти. Причём четыре видеокарты были подключены через Thunderbolt, без классической серверной PCIe-топологии и без NVLink.
Автор доработал vLLM под эту конфигурацию и тестировал не только один запрос, но и несколько параллельных сессий.
В одиночном режиме генерация достигала примерно 58 токенов в секунду.
При семи одновременно генерирующих сессиях суммарная производительность доходила примерно до 206 токенов в секунду. Автор также тестировал контекст около 262 тысяч токенов.
Это интересный эксперимент не потому, что шесть RTX 3090 — разумная конфигурация для офиса.
А потому, что он хорошо показывает разницу между двумя вопросами:
- «Насколько быстро отвечает модель?»
- «Сколько работы вся система может выполнить одновременно?»
Для бизнеса второй вопрос обычно важнее.
У локальной модели есть две разные скорости
Когда говорят о токенах в секунду, часто смешивают два процесса.
Первый — обработка уже переданного контекста.
Например, вы загрузили договор на сто страниц или большую кодовую базу.
Модель должна сначала прочитать весь этот объём.
Эта стадия обычно называется prefill.
Второй процесс — непосредственно генерация ответа.
Это decode.
Для короткого чата можно смотреть почти только на скорость генерации.
Но для корпоративной работы скорость чтения контекста иногда важнее.
Представим, что модель умеет писать ответ со скоростью 80 токенов в секунду.
Очень быстро.
Но перед этим она минуту анализирует большой пакет документов.
С точки зрения сотрудника система всё равно отвечает долго.
Поэтому хороший тест корпоративного ИИ должен отдельно измерять:
- время обработки входных данных;
- время до появления первого ответа;
- скорость дальнейшей генерации;
- поведение этих показателей при нескольких одновременных пользователях.
Одного числа «100 токенов в секунду» недостаточно.
Длинный контекст стоит памяти
Есть ещё одна особенность локальных моделей.
Чем больше информации модель должна одновременно держать в контексте, тем больше памяти требуется системе.
И здесь легко ошибиться.
Допустим, модель сама помещается в видеопамять.
Из этого ещё не следует, что в оставшуюся память поместится большой контекст для нескольких пользователей.
Каждая активная сессия требует дополнительного места.
Если один сотрудник работает с большим документом, всё может быть нормально.
Если таких сотрудников одновременно пять, сервер уже может упереться в память или начать заметно терять скорость.
Это особенно важно для сценариев, где ИИ работает не как обычный чат, а с длинными материалами:
- юридическими документами;
- проектной документацией;
- большими отчётами;
- репозиториями программного кода;
- длинной историей общения с клиентом;
- несколькими найденными документами из корпоративной базы знаний.
В свежих экспериментах с Qwen3.8-Flash-Next разработчики как раз активно исследуют этот компромисс: максимальный контекст, мультимодальность, несколько сессий и скорость часто приходится балансировать между собой. На четырёх RTX 3090, например, опубликованы конфигурации от примерно 48 тысяч токенов с более высокой скоростью до 262 тысяч токенов в текстовом режиме с одним активным слотом.
То есть вопрос «поддерживает ли модель 262 тысячи токенов?» для бизнеса сформулирован неправильно.
Правильнее спрашивать:
сколько пользователей одновременно смогут работать с таким контекстом на нашем оборудовании?
Максимальный контекст почти никогда не нужен всем
Есть соблазн сразу выделить каждому пользователю максимальный размер контекста.
Если модель поддерживает 200 или 250 тысяч токенов, почему бы не использовать всё?
Потому что это ресурс.
Большинство рабочих запросов гораздо короче.
Сотрудник может задать вопрос по одной инструкции.
Разработчик — попросить изменить конкретный модуль.
Менеджер — получить краткую сводку по клиенту.
Если под каждый такой запрос заранее резервировать гигантское окно контекста, оборудование используется неэффективно.
Поэтому в корпоративной системе имеет смысл разделять разные классы задач.
Обычный чат — небольшой контекст.
Работа с документами — больше.
Анализ крупного проекта — отдельный профиль.
Редкие особо тяжёлые запросы — очередь или выделенный режим.
То же самое давно происходит с обычной инфраструктурой. Мы не выделяем максимальное количество ресурсов каждому процессу только потому, что когда-нибудь они могут ему понадобиться.
Шесть видеокарт не обязательно быстрее одной в шесть раз
Ещё одна распространённая ошибка — считать видеокарты почти линейно.
Одна карта даёт 50 токенов в секунду.
Значит, две дадут 100.
Шесть — 300.
На практике так работает далеко не всегда.
Части модели приходится обмениваться данными между устройствами.
На скорость влияет топология PCIe.
Ширина линий.
Поддержка прямого обмена памятью.
Движок выполнения.
Способ разделения модели.
Квантование.
Размер контекста.
Количество одновременных запросов.
Даже одна и та же модель на одном и том же оборудовании может показывать сильно разные результаты в разных движках.
Это хорошо видно по свежим экспериментам сообщества.
На двух RTX 3090 для одной и той же Qwen3.8-Flash-Next публикуются результаты примерно от нескольких десятков до более ста токенов в секунду в зависимости от движка, квантования и конфигурации.
Поэтому спецификация оборудования сама по себе практически ничего не говорит о конечной производительности.
Нужен тест конкретного программного стека.
Квантование тоже меняет не только потребление памяти
Большую модель часто невозможно или невыгодно хранить в исходной точности.
Поэтому используются квантованные версии.
Условно говоря, вес модели хранится менее точно, благодаря чему требуется меньше памяти.
Это позволяет запускать большую модель на более доступном оборудовании.
Но появляется компромисс.
Меняется потребление памяти.
Меняется скорость.
Иногда немного меняется качество.
Разные движки лучше или хуже работают с конкретными форматами.
Поэтому вопрос «эта модель помещается в 24 ГБ» тоже не очень полезен без уточнения.
Какая именно версия?
Какое квантование?
Какой размер контекста?
Есть ли зрение?
Сколько одновременных запросов?
Какая фактическая точность на ваших задачах?
Например, в одном из свежих экспериментов Qwen3.8-Flash-Next запускается на одной 24-гигабайтной RTX 3090 с 32 ГБ оперативной памяти при полном контексте около 262 тысяч токенов. Автор сообщает скорость генерации примерно 59–62 токена в секунду на длинном контексте. Но используется сильно квантованная конфигурация и специализированный движок Strata.
Это отличный инженерный результат.
Но из него нельзя сделать вывод, что одной RTX 3090 достаточно для корпоративного сервиса на десятки сотрудников.
Локальный ИИ — это не обязательно одна огромная модель
В бизнесе часто вообще нет необходимости обслуживать все запросы одной моделью.
Можно использовать несколько уровней.
Небольшая модель классифицирует запрос.
Более крупная отвечает на сложные вопросы.
OCR занимается изображениями.
Отдельная модель строит эмбеддинги для поиска.
Детерминированный код проверяет числа и бизнес-правила.
Редкие сложные запросы отправляются в более мощную модель.
Это может оказаться намного эффективнее, чем держать огромную модель для каждой простой операции.
Особенно если большая часть запросов выглядит так:
- определи тип документа;
- выдели тему письма;
- найди нужный регламент;
- сформируй краткое содержание;
- извлеки несколько полей.
Для таких задач использование самого большого локального ИИ может быть просто расточительством.
Локальный сервер тоже стоит денег после покупки
При сравнении локального ИИ с облачным API часто считают очень просто.
Сервер стоит, например, несколько сотен тысяч рублей.
API стоит определённую сумму за миллион токенов.
Делим одно на другое и получаем срок окупаемости.
Такой расчёт слишком оптимистичен.
У локальной инфраструктуры есть стоимость электричества.
Резервирование.
Хранение данных.
Диски.
Сеть.
Обновления.
Мониторинг.
Ремонт.
Время администратора.
Иногда отдельное помещение и охлаждение.
Периодическая замена оборудования.
Если сервер нужен только для ИИ, все эти расходы относятся к стоимости модели.
Если инфраструктура уже существует и используется для других задач, экономика меняется.
Поэтому корректнее считать полную стоимость владения хотя бы на два-три года.
Но у локальной модели есть ценность, которую сложно перевести в токены
При этом сравнивать локальный ИИ и облако только по стоимости тоже неправильно.
Локальное выполнение может давать преимущества, которые сложно выразить ценой одного запроса.
Например, данные вообще не покидают инфраструктуру компании.
Это может быть важно для внутренних документов, исходного кода, клиентской информации или коммерческой тайны.
Можно работать даже при недоступности внешнего поставщика.
Нет зависимости от внезапного изменения тарифов API.
Можно глубже интегрировать модель с внутренними системами.
Можно хранить большой постоянный контекст рядом с вычислениями.
Можно самостоятельно выбирать момент обновления модели.
Иногда именно эти требования являются основной причиной локального развёртывания, а стоимость оказывается вторичной.
«Данные остаются внутри» тоже не происходит автоматически
Важно, однако, не идеализировать локальную установку.
Если модель стоит в офисе, это ещё не означает, что данные защищены.
Нужно контролировать доступ пользователей.
Журналы запросов.
Резервные копии.
Веб-интерфейс.
Удалённый доступ.
Интеграции.
Обновления.
Секреты.
Кто имеет административные права.
Если локальный сервер опубликован наружу через плохо настроенный интерфейс, преимущество «данные не уходят в облако» быстро теряет смысл.
Локальный ИИ снижает зависимость от внешнего поставщика модели, но ответственность за информационную безопасность при этом переходит к самой компании.
Скорость нужно тестировать на собственных задачах
Публичные тесты полезны для понимания возможностей оборудования.
Но я бы не принимал решение о покупке сервера по результату из Reddit или таблицы производительности.
Потому что рабочая нагрузка компании почти наверняка будет другой.
Если нужен помощник для разработчиков, стоит взять реальный репозиторий.
Если система должна анализировать документы — реальные документы.
Если строится внутренняя база знаний — реальные запросы сотрудников.
Если модель будет использовать пять человек одновременно — тестировать пять параллельных сессий.
Если планируется двадцать пользователей — моделировать соответствующую нагрузку.
И только после этого смотреть на железо.
Не наоборот.
Какие показатели я бы замерял на пилоте
Для локального корпоративного ИИ я бы вообще не ставил скорость генерации на первое место.
Намного полезнее собрать небольшой набор показателей.
- Время до первого ответа. Сотрудник воспринимает именно его как задержку системы.
- Полное время выполнения типовой задачи. Не генерация отдельно, а от отправки запроса до готового результата.
- Количество одновременных пользователей. Когда начинается заметная деградация?
- Скорость обработки длинных документов. Особенно если это основной сценарий.
- Потребление видеопамяти и оперативной памяти. Есть ли запас для роста нагрузки?
- Качество результата. Самый быстрый ответ бесполезен, если приходится перепроверять его вручную.
- Доля запросов, которые действительно требуют большой модели. Возможно, значительную часть можно обслуживать дешевле.
- Стоимость одного полезного результата. С учётом электричества, оборудования и сопровождения.
Только после этого можно сравнивать локальный вариант с внешним API.
Необязательно сразу покупать сервер
Это, пожалуй, самый практичный совет.
Если компания думает о локальном ИИ, не нужно начинать с закупки оборудования.
Арендовать похожую конфигурацию на несколько дней обычно намного дешевле ошибки при выборе сервера.
Развернуть модель.
Загрузить настоящую рабочую выборку.
Подключить несколько пользователей.
Провести нагрузочные тесты.
Посмотреть качество.
Оценить реальные требования к контексту.
После этого станет понятно, нужны ли четыре видеокарты, две, одна или локальная инфраструктура вообще не имеет экономического смысла.
Сервер стоит покупать под подтверждённую нагрузку.
Не нагрузку придумывать под уже купленный сервер.
Когда локальная модель имеет смысл
Я бы рассматривал локальное развёртывание в первую очередь в нескольких случаях.
- Когда данные действительно нежелательно отправлять внешним поставщикам.
- Когда объём использования большой и постоянный.
- Когда нужен предсказуемый доступ без внешних ограничений.
- Когда компания готова самостоятельно обслуживать инфраструктуру.
- Когда есть достаточно типовая рабочая нагрузка, чтобы подобрать оборудование под неё.
- Когда преимущества контроля над системой важнее простоты облачного API.
Во всех остальных случаях облачная модель может оказаться намного проще.
Особенно для пилота.
Когда облако может быть лучше
Если ИИ используют несколько сотрудников время от времени, покупать сервер часто бессмысленно.
То же самое касается ситуации, когда требования постоянно меняются.
Сегодня нужна одна модель.
Через три месяца — другая.
Через полгода появилась новая архитектура, которая радикально лучше старой.
В облаке обновление инфраструктуры — проблема поставщика.
В локальном варианте купленные видеокарты остаются вашими.
Поэтому чем меньше и непредсказуемее нагрузка, тем привлекательнее аренда вычислений или API.
Локальная модель становится интереснее при стабильной загрузке и понятной задаче.
Самая дорогая ошибка — оптимизировать не тот показатель
Можно потратить недели на увеличение скорости с 60 до 80 токенов в секунду.
А потом выяснить, что сотрудники ждут не генерацию.
Они ждут минуту, пока система найдёт документы.
Или пока обработается огромный контекст.
Или пока освободится очередь.
Или пока агент выполнит пять последовательных шагов.
В таком случае ускорение генерации почти не изменит пользовательский опыт.
Поэтому оптимизацию нужно начинать с замера полного процесса.
Где действительно проходит время?
На поиске?
На чтении документов?
На модели?
На внешней системе?
На ожидании свободной видеопамяти?
Ответ может оказаться совсем не тем, который предполагался при покупке оборудования.
Что я бы делал перед внедрением
Сначала определил бы рабочие сценарии.
Не «нам нужен локальный ИИ», а конкретно:
- помощник разработчикам;
- поиск по документации;
- анализ договоров;
- работа с обращениями;
- внутренний агент;
- обработка изображений.
После этого собрал бы реальные примеры нагрузки.
Определил требования к конфиденциальности.
Посчитал одновременно работающих пользователей.
Проверил, какой контекст действительно нужен.
Протестировал несколько моделей и способов их запуска на арендованном оборудовании.
И только после этого выбирал бы сервер.
Потому что вопрос «какую видеокарту купить для ИИ» появляется довольно поздно.
Сначала нужно понять, какую работу этот ИИ должен выполнять для компании.
Локальный ИИ — это инфраструктура, а не модель
Наверное, это главный вывод.
Когда компания запускает модель на собственном сервере, она получает не «бесплатный ChatGPT».
Она получает новый инфраструктурный сервис.
У него есть производительность.
Очереди.
Пользователи.
Ограничения памяти.
Обновления.
Мониторинг.
Резервирование.
Информационная безопасность.
Стоимость эксплуатации.
И только одним из компонентов этого сервиса является сама языковая модель.
Поэтому выбирать локальный ИИ по размеру модели и максимальному числу токенов в секунду примерно так же странно, как выбирать сервер базы данных только по частоте процессора.
Это важный параметр.
Но далеко не главный.
Для бизнеса имеет значение не то, как быстро модель пишет ответ одному пользователю.
Имеет значение, сколько реальной работы вся система способна стабильно выполнять для компании.
