Да, именно так — но это один из сценариев: — 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-оркестрации — лучший выбор.
Не пишут с нуля — интегрируют. llama.cpp/ollama — готовый инференс. Go: библиотек мало, но ollama — весь стек на Go. Java: Spring Boot, DJL, ONNX Runtime — готовый фреймворк. gin — 200 строк API. Opensearch — векторный и классический поиск за день. OpenTelemetry, Kubernetes/Helm — всё быстро и надёжно. 2–4 недели — сборка из готовых кирпичей. Go/Java — не для обучения, а для надёжного инференса.
Вы правы — стек сложнее, чем RTX 5090. Но инференс на GPU — это не только карта за 300–800 тыс. ₽: это электричество, охлаждение, сопровождение, и — если вы работаете с конфиденциальными данными — ещё и привязка к поставщику внутри ЦОДа, где GPU не всегда доступен. CPU-сервер с GGUF-моделью — прост, универсален и его может обслужить любой, кто работает с локальной инфраструктурой. Поддержка — не «зоопарк», а изолированные сервисы: инференс через llama.cpp или Ollama, оркестрация — на Java/Go. Не все могут. Но тем, у кого данные важны — это осознанный выбор.
Тогда все, кто соблюдают code style и использует форматирование — тоже GPT
Есть в психологии приём:
когда научился распознавать отклонения —
перестань искать их в каждом.
Спасибо за комментарий.
Буду рад писать дальше!
Да, именно так — но это один из сценариев:
— 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 — инфраструктура.
Не пишут с нуля — интегрируют.
llama.cpp/ollama — готовый инференс.
Go: библиотек мало, но ollama — весь стек на Go.
Java: Spring Boot, DJL, ONNX Runtime — готовый фреймворк.
gin — 200 строк API.
Opensearch — векторный и классический поиск за день.
OpenTelemetry, Kubernetes/Helm — всё быстро и надёжно.
2–4 недели — сборка из готовых кирпичей.
Go/Java — не для обучения, а для надёжного инференса.
Вы правы — стек сложнее, чем RTX 5090.
Но инференс на GPU — это не только карта за 300–800 тыс. ₽: это электричество, охлаждение, сопровождение, и — если вы работаете с конфиденциальными данными — ещё и привязка к поставщику внутри ЦОДа, где GPU не всегда доступен.
CPU-сервер с GGUF-моделью — прост, универсален и его может обслужить любой, кто работает с локальной инфраструктурой.
Поддержка — не «зоопарк», а изолированные сервисы: инференс через llama.cpp или Ollama, оркестрация — на Java/Go.
Не все могут.
Но тем, у кого данные важны — это осознанный выбор.