llama.cpp
Локальный и edge inference, quantized models, CPU/GPU и простой server mode.
Inference backend загружает модели, управляет GPU/CPU-ресурсами, batching, cache и streaming. Runtime скрывается за AI Gateway, чтобы приложения не зависели от конкретного движка.
OpenAI-compatible контракт упрощает замену движка, но capacity, tokenizer, context limits и feature support проверяются отдельно.
Место компонента в общей архитектуре корпоративной AI-платформы.
Внутренние компоненты, границы ответственности и основные связи.
Путь пользовательского запроса через контрольные точки компонента.
Движение данных, контекста и результатов внутри системы.
Движки показаны как реализации разных эксплуатационных профилей, а не как обязательный стек.
Локальный и edge inference, quantized models, CPU/GPU и простой server mode.
Высокопроизводительный serving, continuous batching и GPU-пулы.
Production serving для transformer-моделей с distributed inference.
Быстрый локальный запуск, управление моделями и удобный developer workflow.
Оптимизированный NVIDIA inference для максимальной производительности.
Serving сложных generation workloads, structured output и agentic patterns.
Чаще всего runtime-слой ломается не на выборе движка, а на отсутствии capacity-планирования и проверки контрактов.
Профили нагрузки разные: llama.cpp не заменяет vLLM под high-load, а vLLM избыточен для edge и локальных прототипов.
Длинный контекст, batch и KV-cache съедают VRAM быстрее ожиданий; пиковая нагрузка проверяется до production, а не на пользователях.
OpenAI-compatible ≠ идентичный: tokenizer, context limits, streaming и function calling отличаются между backends.
Приложения, минующие AI Gateway, теряют квоты, fallback, cost-учёт и audit trail — и ломаются при замене backend.
Продолжите по соседнему слою архитектуры или вернитесь к полной карте технических материалов.
Можно начать с короткой архитектурной сессии: выбрать первый сценарий, определить данные, модельный маршрут, требования к железу, риски и пилотные метрики.