Локальная LLM: гадкий утенок в мире прекрасных лебедей
Разработчик CodeInside провел сравнительный анализ локальных и облачных LLM и рассказал о результатах тестирования в RAG-сценариях.
Разработчик CodeInside провел сравнительный анализ локальных и облачных LLM и рассказал о результатах тестирования в RAG-сценариях.
Всем привет! Я — Иван, инженер по разработке AI-систем CodeInside. Мы разрабатываем и внедряем кастомные AI-решения — от интеллектуальных поисковых систем на основе RAG до специализированных AI-агентов и ассистентов для автоматизации процессов в бизнесе и промышленности.
В этой статье я расскажу о результатах тестирования локальных и облачных LLM в RAG-сценариях. Мы сравнили их достоверность и скорость работы, чтобы понять, насколько локальные модели готовы к реальным задачам и в каких случаях они могут быть не хуже — а иногда и лучше — облачных аналогов.
Когда обсуждают языковые модели, чаще всего в центре внимания оказываются облачные «коммерческие» LLM. Мир очарован GPT, deepseek, Claude Sonnet, Gemini и т.д. Они выглядят впечатляюще: быстрые ответы, естественные формулировки, высокий уровень «интеллектуальности».
В реальных проектах мы сталкиваемся с ограничениями, которые накладывают требования безопасности, регламенты работы с данными и особенности инфраструктуры. Во многих случаях это исключает использование облачных моделей и ставит вопрос о необходимости локального развертывания.
Заказчиками локальные модели часто воспринимаются как менее привлекательные — «гадкий утенок» на фоне облачных «лебедей». Мы решили проверить, насколько справедливо это мнение, проведя собственное тестирование.
Для эксперимента мы выбрали восемь моделей.
Облачные коммерческие модели:
Open-Source модели (локальное развертывание):
При запуске LLM ключевым узким местом является видеокарта. Объем и скорость системной памяти и модель процессора оказывают куда меньшее влияние, чем GPU. В обеих конфигурациях использовались видеокарты с 48 ГБ памяти, что позволяет запускать 30B-модель в полном (full precision или bfloat16) режиме.
Основное различие между A5000 и RTX 6000 Ada заключается в архитектуре и энергоэффективности:
Задача теста состояла в том, чтобы оценить их работу в сценарии RAG (Retrieval-Augmented Generation). Этот подход предполагает, что модель формирует ответ на основе предварительного поиска информации в заданной базе документов. Такой сценарий мы выбрали потому, что он близок к реальным прикладным задачам: поиску по внутренней базе знаний, работе с нормативными документами или технической документацией.
Для оценки использовалась система RAGAS, которая проверяет два ключевых показателя:
Все модели тестировались в одинаковых условиях: единый системный промпт, одинаковые параметры генерации, единая база документов.
В таблице ниже приведены результаты для RAG на разных моделях:
Анализ показал, что open-source архитектуры вполне могут конкурировать с коммерческими по качеству поиска и генерации — особенно при разворачивании на хорошем железе.
Например, по достоверности ответов (насколько модель опирается в ответе на предоставленный контекст) лидерами стали Gemini 2.5 Pro (0,92), Deepseek R1 (0,91) и GPT-4.1 Mini (0,82). Но Qwen3-30B-A3B (0,79) в максимальной (max) конфигурации также демонстрирует достойный результат, обгоняя другие локальные и даже часть облачных моделей.
По скорости ожидаемо лидируют облачные решения: Google Gemini 2.5 Flash — 2,85 секунды и GPT-4.1 Mini — 6,19 секунд. Однако Qwen3-30B-A3B в максимальной (max) конфигурации (8,54 сек) обогнала Gemini 2.5 Pro (8,7 сек) и почти сравнялась по скорости с GPT-4.1 Mini (6,19 сек), а разница между max- и min-конфигурациями одной и той же модели (Qwen3-30B-A3B) показала, насколько критично правильно подобрать инфраструктуру.
Локальные модели Llama 3.3 70B и Mistral Small 3.2-24B показали хорошие результаты — как по скорости (около 10 сек), так и по достоверности, особенно в задачах, где важны контроль над данными и on-premise работа.
Практическая ценность этих данных в том, что при правильной настройке и достаточных вычислительных ресурсах локальные модели могут решать широкий круг задач без ощутимой потери качества. В сценариях, где критически важно сохранять контроль над данными — например, в проектах для госсектора, критической информационной инфраструктуры или финансовой отрасли — локальные решения позволяют исключить риски, связанные с передачей информации во внешние сервисы.
Кроме того, локальные модели проще интегрировать в существующую инфраструктуру, так как они не требуют постоянного подключения к интернету и могут быть адаптированы под специфику конкретной предметной области.
На практике локальные LLM особенно эффективны в задачах, где ключевыми являются предсказуемость и безопасность. Это может быть интеллектуальный поиск по базе знаний компании, автоматизация обработки запросов в техподдержке, помощь сотрудникам в навигации по нормативной документации или в подготовке тендерных заявок. В таких сценариях ценится не эффектность генерации, а стабильная работа и возможность объяснить, откуда взялся тот или иной ответ.
В CodeInside мы уже применяем этот подход в реальных проектах.
Например, Docora AI обеспечивает быстрый и точный поиск по корпоративной базе знаний с использованием RAG, помогая сотрудникам находить ответы без ошибок и «галлюцинаций».
В решении Tender Flow локальная LLM выступает как AI-агент для анализа тендерной документации и подготовки предложений, экономя время отделов продаж.
В AI-Экзаменаторе локальная модель используется для автоматизированной и объективной проверки знаний студентов.
А в AI-ассистенте для расчета строительных материалов RAG-система помогает менеджерам и инженерам точно определять количество и стоимость материалов, учитывая специфику объекта.
Эти решения демонстрируют, что локальные LLM уже сегодня могут быть полноценными рабочими инструментами, если их интеграция выстроена грамотно.
Наш эксперимент не показал явного и однозначного превосходства облачных моделей над локальными — ни по скорости, ни по достоверности ответа. Локальные модели вполне могут обеспечивать сравнимое качество генерации, особенно, если правильно организовать пайплайн и подобрать подходящее оборудование. На практике, такие модели, как Qwen или Mistral, уже сегодня справляются с прикладными задачами на уровне GPT‑5‑класса.
Но не смотря на то, что облачные модели лидируют по заданным метрикам, разрыв постепенно сокращается, и локальные LLM, особенно при хорошей настройке, уже демонстрируют конкурентоспособные результаты.
Рынок очарован коммерческими сервисами вроде ChatGPT, Perplexity, DeepSeek и др., под капотом которых работают большие языковые модели с сотнями или даже тысячами миллиардов параметров. Для работы таких моделей требуются дорогие фермы GPU и это многим кажется непреодолимым барьером на пути к построению on-premise решений.
На фоне этого стереотипа, многие недооценивают потенциал open-source моделей, у которых параметров на порядок меньше — всего лишь десятки миллиардов.
Действительно, из коробки такие модели будут давать более скромный результат по сравнению со «старшими братьями». Но наш опыт показывает, что умелая подготовка малых языковых моделей под узкую задачу заказчика может обеспечивать результат не хуже. К тому же, малые языковые модели требуют скромных вычислительных ресурсов — для ряда задач достаточно пары GPU бытового уровня, — Максим Семёнкин, CEO CodeInside.
Ключевым преимуществом локальных решений остается не только автономность, но и полный контроль над данными, возможность гибкой интеграции в существующую ИТ-инфраструктуру и отсутствие зависимости от внешних сервисов. Это особенно важно для компаний, работающих в условиях повышенных требований к безопасности, импортонезависимости и соблюдению регуляторных норм.
