Enterprise AI редко ломается на модели. Чаще проблема в том, что вокруг нее нет целой архитектуры: compute, storage, serving и integration. Эта AI архитектура определяет, станет ли модель частью production или останется пилотом.
Enterprise teams часто начинают с вопроса о выборе модели, но упираются не в shortlist, а в операционную реальность. Если нет понятной схемы, как модель хранится, где исполняется, как подается через endpoint и как связывается с существующими системами, проект остается локальной демонстрацией. В этом и состоит главный вызов enterprise AI: модель сама по себе не дает готовой capability.
По сути, речь идет не о “подключении AI”, а о сборке инфраструктурного стека. В исходной архитектуре выделены 4 слоя: compute, model storage, inference and serving, integration. Это прагматичный способ разложить ответственность по уровням. Он помогает увидеть trade-offs: managed API снимает часть операционной нагрузки, но self-hosting дает больше контроля над estate и данными.
Первый слой — compute and hardware. Для LLM и большинства generative workloads здесь почти всегда нужны GPU или сопоставимые accelerators, потому что матричные операции плохо масштабируются на CPU alone. При self-hosted inference это обычно GPU servers в датацентре или GPU-backed instances в cloud, часто через Kubernetes platform, такую как Red Hat OpenShift with GPU operators. Размер этого слоя зависит от модели и concurrency. Если capacity недостаточна, система деградирует через elevated latency, throttling или queued requests.
Второй слой — model storage. На практике это не просто “файлы модели”, а пакет artifacts: weight files, tokenizer vocabulary и configuration для архитектуры и serving settings. Чем больше parameter count и выше numeric precision, тем больше disk footprint и дольше startup. Quantized builds уменьшают оба показателя, но это уже компромисс между размером и режимом исполнения. Для self-hosted deployments веса обычно лежат в durable blob или object storage, например S3, MinIO или OCI images.
Третий слой — inference engine и model serving. Здесь легко смешать два разных механизма, но разделение важно. Engine загружает weights в accelerator memory, tokenizes input, batches requests, streams tokens и контролирует concurrency limits. Serving отвечает за routing, health checks, replicas и autoscaling, согласованные с GPU capacity. В тексте названы open engines vLLM, Text Generation Inference и Ollama, а также указано, что Red Hat AI Inference использует vLLM в своей основе.
Четвертый слой — integration. Именно здесь AI перестает быть отдельной системой и встраивается в enterprise architecture. Интеграция идет в двух направлениях. В первом ваш application вызывает served model endpoint через OpenAI-compatible HTTP API. Во втором сам model или agent framework обращается к databases, internal APIs, ticketing systems и document stores. Эти направления отличаются по риску: в первом случае модель пассивна, во втором она инициирует действия, поэтому нужны input validation, authentication, error handling и guardrails.
Для первого сценария исходник подчеркивает важность timeouts, retries, cost controls и audit logging. Когда много внутренних систем делят один endpoint, useful становится AI-aware gateway. Он может enforce authentication, quotas, token-aware rate limits и observability, настроенные под inference traffic. Red Hat Connectivity Link выступает как такой gateway для Kubernetes и Red Hat OpenShift. Это эволюционное улучшение, а не замена serving layer.
Для второго сценария ключевой проблемой становится tool exposure. Без общего протокола каждое agent-to-system connection превращается в bespoke integration. Здесь используется Model Context Protocol, или MCP. Идея проста: capabilities публикуются как MCP servers, а agents находят и вызывают их через shared protocol. На enterprise уровне все равно нужен governed front door с federated discovery, authentication, identity-based tool filtering и audit. В тексте отмечено, что Red Hat Connectivity Link добавляет MCP gateway в technology preview на Red Hat OpenShift.
Практический вывод этой архитектуры в том, что hosting choice меняет не саму структуру, а только то, кто оперирует слоями 1–3. Managed API передает vendor compute, storage и serving для модели. Self-hosting оставляет эти слои на вашей стороне. Integration остается вашей ответственностью в обоих случаях. Поэтому вопрос production AI в enterprise — это вопрос операционной модели, а не только качества модели.
Если свести разбор к одному чеклисту, он будет таким: compute исполняет модель, storage хранит и версионирует artifacts, engine и serving делают endpoint стабильным, integration связывает AI с бизнес-системами. Именно эта последовательность отличает pilot от production. И именно поэтому enterprise AI чаще требует архитектурной дисциплины, чем очередного выбора “лучшей” модели.