Локальная LLM: гадкий утенок в мире прекрасных лебедей

Сравнительный анализ локальных и облачных LLM

Всем привет! Я — Иван, инженер по разработке AI-систем CodeInside. Мы разрабатываем и внедряем кастомные AI-решения — от интеллектуальных поисковых систем на основе RAG до специализированных AI-агентов и ассистентов для автоматизации процессов в бизнесе и промышленности.

В этой статье я расскажу о результатах тестирования локальных и облачных LLM в RAG-сценариях. Мы сравнили их точность, полноту, достоверность и скорость работы, чтобы понять, насколько локальные модели готовы к реальным задачам и в каких случаях они могут быть не хуже — а иногда и лучше — облачных аналогов.

Когда обсуждают языковые модели, чаще всего в центре внимания ^[1] оказываются облачные «коммерческие» LLM. Мир очарован GPT, deepseek, Claude Sonnet, Gemini и т.д. Они выглядят впечатляюще: быстрые ответы, естественные формулировки, высокий уровень «интеллектуальности». 

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

Заказчиками локальные модели часто воспринимаются как менее привлекательные — «гадкий утенок» на фоне облачных «лебедей». Мы решили проверить, насколько справедливо это мнение, проведя собственное тестирование.

Методика тестирования

Для эксперимента мы выбрали шесть моделей: три облачные (GPT-4.1 Mini, Google Gemini 2.5 Flash, Deepseek R1) и три развернутые локально (Llama 3.3 70B, Mistral Small 3.2-24B, Qwen3-Coder-30B-A3B в максимальной (max) и минимальной (min) конфигурациях оборудования).

Задача теста состояла в том, чтобы оценить их работу в сценарии RAG (Retrieval-Augmented Generation). Этот подход предполагает, что модель формирует ответ на основе предварительного поиска информации в заданной базе документов. Такой сценарий мы выбрали потому, что он близок к реальным прикладным задачам: поиску по внутренней базе знаний, работе с нормативными документами или технической документацией.

Для оценки использовалась система RAGAS, которая проверяет три ключевых показателя:

1. точность и полнота контекста — как хорошо модель опирается на факты из контекста и насколько полно она их отразила в своем ответе

2. достоверность — соответствует ли ответ найденной информации, без «галлюцинаций» или искажений.

3. скорость генерации ответа, измеряемая в секундах.

Все модели тестировались в одинаковых условиях: единый системный промпт, одинаковые параметры генерации, единая база документов.

Результаты

В таблице ниже приведены результаты для RAG на разных моделях.

Анализ показал, что open-source архитектуры вполне могут конкурировать с коммерческими по качеству поиска и генерации — особенно при разворачивании на хорошем железе.

Например, Qwen3-Coder-30B-A3B (max) по точности и полноте (0.98/0.97) показала результат, сопоставимый с GPT-4.1 Mini и Google Gemini 2.5 Flash. Это опровергает распространенный миф, будто высокое качество — исключительно прерогатива облачных решений.

По достоверности ответов (насколько модель опирается в ответе на предоставленный контекст) лидерами остаются Deepseek R1 (0.91) и GPT-4.1 Mini (0.82). Но Qwen3-Coder-30B-A3B (0.79) в максимальной конфигурации также демонстрирует очень достойный результат, обгоняя другие локальные и даже часть облачных моделей.

По скорости ожидаемо лидируют облачные решения: Google Gemini 2.5 Flash — 2.85 секунды. Однако 3-Coder-30B-A3B на мощной конфигурации (8.54 сек) почти сравнялась по скорости с GPT-4.1 Mini (6.19 сек), а разница между max и min конфигурациями одной и той же модели (Qwen3-Coder-30B-A3B) показала, насколько критично правильно подобрать инфраструктуру.

Локальные модели Llama 3.3 70B и Mistral Small 3.2-24B показали хорошие результаты — как по скорости (около 10 сек), так и по качеству, особенно в задачах, где важны контроль над данными и on-premise работа.

Прикладное значение результатов

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

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

Локальная модель на практике

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

В CodeInside мы уже применяем этот подход в реальных проектах.

Например, Docora AI ^[2] обеспечивает быстрый и точный поиск по корпоративной базе знаний с использованием RAG, помогая сотрудникам находить ответы без ошибок и «галлюцинаций».

В решении Tender Flow ^[3] локальная LLM выступает как AI-агент для анализа тендерной документации и подготовки предложений, экономя время отделов продаж.

В AI-Экзаменаторе ^[4] локальная модель используется для автоматизированной и объективной проверки знаний студентов.

А в AI-ассистенте для расчета строительных материалов ^[5] RAG-система помогает менеджерам и инженерам точно определять количество и стоимость материалов, учитывая специфику объекта.

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

Подведем итог

Наш эксперимент не показал явного и однозначного превосходства облачных моделей над локальными — ни по точности, ни по полноте извлеченной информации. Локальные модели вполне могут обеспечивать сравнимое качество генерации, особенно, если правильно организовать пайплайн и подобрать подходящее оборудование. На практике, такие архитектуры, как Qwen или Mistral, уже сегодня справляются с прикладными задачами на уровне GPT‑4‑класса.

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

Рынок очарован коммерческими сервисами вроде ChatGPT, Perplexity, DeepSeek и др., под капотом которых работают большие языковые модели с сотнями или даже тысячами миллиардов параметров. Для работы таких моделей требуются дорогие фермы GPU и это многим кажется непреодолимым барьером на пути к построению on-premise решений.

На фоне этого стереотипа, многие недооценивают потенциал open source моделей, у которых параметров на порядок меньше — всего лишь десятки миллиардов.

Действительно, из коробки такие модели будут давать более скромный результат по сравнению со «старшими братьями». Но наш опыт ^[6] показывает, что умелая подготовка малых языковых моделей под узкую задачу заказчика может обеспечивать результат не хуже. К тому же, малые языковые модели требуют скромных вычислительных ресурсов — для ряда задач достаточно пары GPU бытового уровня, — Максим Семёнкин, CEO CodeInside.

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