Часть 5. Ollama: локальный AI, который не звонит в облако по ночам

В Части 4 мы оставили банковского ассистента на LangChain4j в момент, когда он уже умеет проверять баланс и инициировать платёж — но всё ещё зависит от внешнего API. А это вопрос комплаенса: банк не может просто так отправить транзакцию клиента в чужое облако. Регулятор захочет знать, где данные и что будет при отключении. Здесь на сцену выходит инструмент, за два года прошедший путь от игрушки до инфраструктурного компонента Fortune 500.

9 июля 2026 года Ollama объявила о привлечении $65 млн в раунде Series B во главе с Theory Ventures, доведя общий объём финансирования до $88 млн. Число активных разработчиков выросло до 8,9 млн в месяц. По данным компании, Ollama используется в 85% организаций из списка Fortune 500. Команда — 14 человек, ~1 млн установок в неделю.

За 2026 год Ollama добавила поддержку Apple Silicon через MLX (декодирование быстрее почти вдвое) и multi-token prediction для Gemma 4 — по заявлениям разработчиков, до 90% ускорения в кодинг-агентах.

Для Java это убирает последнюю преграду между стеком и локальным AI. Тем, где, по данным Azul, уже работают 62% компаний. Модель внутри периметра попадает в ту же систему логирования, мониторинга и доступа, что и остальные сервисы: не нужно строить отдельный контур безопасности для «AI-части». Одна платформа, одни правила, один аудит — принцип, по которому корпоративные Java-приложения жили десятилетиями. И, что удивительно, дожили.

Интеграция уже готова: Spring AI 2.0 включает стартер для Ollama, автоматически настраивающий OllamaChatModel. Приложение общается с локальным сервером через HTTP/REST, так что та же логика работает и с локальной, и с облачной моделью — меняется адрес. Для команд на Spring Boot порог входа — «добавить зависимость и запустить ollama pull». Никаких новых языков, никаких отдельных пайплайнов для данных, никакой второй инфраструктуры.

LangChain4j поддерживает Ollama как провайдер: несколько моделей для RAG-пайплайнов и агентов без Python. Есть и прямые Java-клиенты. Например, Ollama4j — библиотека с поддержкой чата, изображений и стриминга, доступная через Maven Central.

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

Эта логика роднит Ollama с агентами из Части 2: там LLM отвечала за решения через GOAP и логи, здесь мы убираем ещё один источник непредсказуемости — чужое облако. Агент на Embabel может работать и на локальной модели.

Экономика здесь та же, что и в Части 3, но с другого конца. JVM экономит вычислительные ресурсы, Ollama убирает счёт за токены: остаётся стоимость железа и электричества. Для предприятий с сотнями агентов это не мелочь. Когда Java-приложение и модель на одном сервере, исчезают вопросы о том, куда уходят данные. Ollama не заменяет облачные модели — она даёт выбор: запустить модель у себя, не отдавая данные наружу.

Что дальше? Java не догоняет Python в экспериментах. Она делает AI-инфраструктуру надёжной и встроенной в корпоративные процессы. Project Panama улучшает интероп с нативными AI-библиотеками, Project Loom обрабатывает тысячи запросов к LLM без блокировки потоков, Project Babylon делает GPU доступнее.

AI становится функцией платформы — как транзакции или очереди. А платформы пишут на Java. Не потому, что модно, а потому что работает десятилетиями. Если следующая волна AI-продуктов будет строиться там, где нужна надёжность, Java окажется не догоняющим, а тем, кого догоняют.

А понедельники? Они будут всегда. Но с логами, локальной моделью и работающим деплоем понедельник перестаёт быть днём ужаса. Он становится просто днём, когда вы выходите на работу. Лучший аргумент в пользу локального AI на Java — не громкий, зато честный.