Локальная LLM в production: как мы подключили Ollama к Laravel

Задача была сложнее обычного чата

В этом проекте AI встроен в backend-конвейер. Система собирает GitHub-проекты, читает описание, README, сайт и метаданные, а затем определяет тип продукта, целевую аудиторию, проблему, коммерческий потенциал, сложность реализации, доступность данных и конкуренцию.

Ответ нельзя заменить свободным текстом. Следующий этап ожидает структурированный объект: 21 обязательное поле, заданные типы данных и оценки в допустимых диапазонах. Ошибка модели здесь ломает не красоту ответа, а автоматическую обработку.

С чего начинали

7B против 14B и облачной модели

На одном и том же ProjectAnalysisInput сравнили DeepSeek, Qwen2.5 7B и Qwen2.5 14B. Более крупная локальная модель местами давала оценки ближе к DeepSeek, но на CPU один запуск занимал больше шести минут.

Вывод не в том, что 14B «плохая». Для интерактивного CPU-конвейера её цена по времени оказалась выше прироста качества.

Почему восемь CPU оказались практичнее двенадцати

Следующий тест — ограничение числа логических CPU для одного и того же запроса. Основной прирост произошёл между четырьмя и шестью потоками. После восьми скорость почти перестала меняться.

Если отдать модели все 12 потоков, MySQL, PHP, Redis и очереди останутся без запаса, а inference не ускорится. Поэтому верхний лимит установили на 8 CPU: это не абсолютный максимум, а баланс всего production-сервера.

Structured output дал больше, чем увеличение модели

Сначала JSON Schema находилась прямо в prompt рядом с инструкцией, README и данными проекта. Для облачного API лишние токены почти незаметны, но локальная модель обрабатывает каждый из них на CPU.

Схему передали через нативный параметр format Ollama. После сокращения инструкции и входа лабораторное время анализа снизилось примерно со 159 до 95–100 секунд — почти на 40%, при этом ответ сохранил все обязательные поля.

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

Валидный JSON ещё не означает правильный анализ

Qwen2.5 7B стабильно возвращала 21 поле без лишних ключей. Но после слишком агрессивного сокращения system prompt появилась семантическая ошибка: репозиторий книги Python Data Science Handbook модель классифицировала как ecommerce — из-за упоминания печатной версии.

Формально ответ был идеальным. Смысл — неверным. После уточнения правил классификация исправилась. Этот пример показал, что проверять замену провайдера только фразой «JSON пришёл» нельзя.

• Схема

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

• Семантика

  Контрольные проекты, пограничные случаи и сравнение с историческими результатами.

• Эксплуатация

  Timeout, повторы, очереди, логирование, нагрузка и влияние на остальные сервисы.

Laravel не пришлось привязывать к Ollama

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

AiProviderInterface
├── OpenAiProvider
├── DeepSeekProvider
└── OllamaProvider

OLLAMA_API_URL=http://…/v1
OLLAMA_MODEL=qwen2.5:7b
OLLAMA_TIMEOUT=600

Ollama предоставляет OpenAI-совместимый /v1/chat/completions, поэтому инфраструктурная разница не просачивается в бизнес-логику. DeepSeekProvider остаётся доступным: провайдера и модель можно менять независимо от конвейера.

Как закрыли сетевой доступ к модели

Laravel и Ollama находятся на разных физических серверах. Публично открывать inference API не стали. Между хостами работает зашифрованный SSH-туннель, а ключ отдельного системного пользователя ограничен единственным направлением permitopen="127.0.0.1:11434".

Контрольный production-тест

Интеграцию проверили из того же Horizon-контейнера, где работают фоновые задачи. Для реального проекта вход сформировал штатный builder, после чего был вызван именно OllamaProvider — без сохранения результата в базу.

Итоговая архитектура: Ollama и DeepSeek вместе

Эксперимент начинался с вопроса «можно ли заменить облачный API?», но более полезным оказался другой вариант — распределить работу по стоимости и сложности.

1. Обычные фильтры

   Код отбрасывает проекты, которые не проходят формальные критерии.

   metadata · heuristics · rules

2. Ollama делает первичную оценку

   Qwen2.5 7B обрабатывает массовый поток локально и распределяет проекты по базовым категориям.

   ignore · watch · interesting

3. DeepSeek получает только сильных кандидатов

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

   investigate · build

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

Когда CPU-only LLM подходит