Comments 15
Сладкий звон жэпэтэллера.
Много воды, почти никакой конкретики.
Очень хотелось бы посмотреть на то как приложение для прода собирается за 2-4 недели, без возможности использовать фреймворки. Под go с этим вообще весьма туго, есть всего пара фреймворков
Не пишут с нуля — интегрируют.
llama.cpp/ollama — готовый инференс.
Go: библиотек мало, но ollama — весь стек на Go.
Java: Spring Boot, DJL, ONNX Runtime — готовый фреймворк.
gin — 200 строк API.
Opensearch — векторный и классический поиск за день.
OpenTelemetry, Kubernetes/Helm — всё быстро и надёжно.
2–4 недели — сборка из готовых кирпичей.
Go/Java — не для обучения, а для надёжного инференса.
Окей, тоесть вы просто берете ollama, раните там какой то gguf. И видимо далее используете ollama api чтобы просто кидать запросики из java (или чего то еще) ?
Я почему то подумал что речь про оптимизацию и приложение целиком собрано в go монолит, вероятно с использованием langchaingo/eino и вот это все за 2-4 недели
Да, именно так — но это один из сценариев:
— ollama — CPU-инференс без Python
— Java/Go — аудит, SLA, безопасность
— Kubernetes, OpenTelemetry — стабильность, наблюдаемость
Это и есть 2–4 недели на готовый стек — когда вам не нужен GPT, а нужна надёжность, контроль и цена.
Есть попытки запускать GGUF напрямую в Java — через экспериментальные API, например, Vector API (JEP 469) или TornadoVM, но пока с ограниченной поддержкой.
Мы также тестировали Qwen3 4B в ONNX — инференс из Java дал прирост скорости по сравнению с Python-аналогом.
Вывод: Go/Java — не для всех моделей, но для production-оркестрации — лучший выбор.
Большое вам спасибо за статью. Вы единственный автор на хабре, который в этом направлении не стал писать шляпу из GPT. По поводу vLLM и ONNX. Эти движки прям вещь, но с пользовательской стороны чувствуется, что разрабы лютые нерды математики, что не скажешь про ollama, которая бодрее запускает модели, чем lms. Кубер и контейнеризация простые и удобные вещи, но KubeFlow тоже завоз не очень понятный, но конечно полезный. Все эти многослойные уровни это не очень хорошая зависимость, чем больше нового софта, тем больше шанс получить вилами в спину. По опыту скажу, моделей в формате GGUF нету лучше, чем линейка qwen3, да есть минусы с иероглифами, но в остальном это лучшая легковесная модель для любых задач. Мне нравятся такого рода статьи, поэтому жду от вас таких же полезных статей.
Даже комменты через гпт
Компании, которые не могут себе позволить нормальные GPU, в состоянии оплатить разработку и поддержку такого стэка технологий?
ИМХО тут описаны работы сильно дороже, чем стоит RTX 5090 и возможно дороже А100. А если эти разработчики ещё и сторонние(что часто дешевле), то с их пропажей поддержка такого зоопарка будет отдельным приключением. Есть сомнения, что малый бизнес такое способен поиянуть
Вы правы — стек сложнее, чем RTX 5090.
Но инференс на GPU — это не только карта за 300–800 тыс. ₽: это электричество, охлаждение, сопровождение, и — если вы работаете с конфиденциальными данными — ещё и привязка к поставщику внутри ЦОДа, где GPU не всегда доступен.
CPU-сервер с GGUF-моделью — прост, универсален и его может обслужить любой, кто работает с локальной инфраструктурой.
Поддержка — не «зоопарк», а изолированные сервисы: инференс через llama.cpp или Ollama, оркестрация — на Java/Go.
Не все могут.
Но тем, у кого данные важны — это осознанный выбор.
Питон не является узким местом. Это обман. Не знаю что вы там собрали на CPU с поддержкой тысяч запросов в секунду но это звучит сказочно. Для раста/го нет полноценных либ для ИИ и не будет тк интерпретатор удобнее чем бесконечно тыкать сохранить-скомпилить-запустить-глянуть логи
PS попробуйте ryzen ai 395: огромная расширяемая память, скорость на уровне 70т/сек на квене как у топ карт
Как мы перестали использовать Python в production LLM-системах — и почему это было необходимо