KubeVela запропонувала OAM-шар для AI-інференсу: моделі можна міняти без переписування застосунку

Команда KubeVela опублікувала практичний експеримент із розгортання AI-інференсу через Open Application Model. Його ідея проста: продуктова команда описує, що саме потрібно застосунку, а платформа окремо вирішує, де працює модель, який runtime її обслуговує, як налаштовано масштабування і в якому середовищі відбувається запуск. У прототипі використано KubeVela 1.11, локальний кластер k3d, Ollama та сумісний з OpenAI API проміжний сервіс.

Наміри застосунку описуються в OAM, тоді як виконання моделі залишається за Ollama або спеціалізованим inference backend.
Що саме розділяє OAM
У запропонованій схемі Component відповідає за тонкий HTTP-фасад, сумісний з OpenAI. Trait додає модель, адресу backend, системний prompt, температуру або правила автоскейлінгу. Policy визначає розміщення, квоти й відмінності між середовищами, а WorkflowStep задає перевірки готовності та порядок доставки. Завдяки цьому продуктова команда застосовує один Application, не копіюючи приватний набір Deployment YAML для кожної моделі.
Тонкий проксі зберігає стабільний API-контракт і дозволяє замінювати backend інференсу.
Фасад не намагається стати планувальником токенів. Він підставляє модель за замовчуванням, за потреби додає системне повідомлення й пересилає запит на обраний backend. Спеціалізовані завдання — розділене prefill/decode, KV-cache, GPU packing та model-aware routing — залишаються llm-d, Gateway API Inference Extension і device plugins.
Що показав локальний прототип
Перший маршрут звертався до Ollama на хості, другий — до внутрішньокластерного симулятора. Обидва віддавали однаковий OpenAI-сумісний інтерфейс. Це перевіряє головну гіпотезу: Application не залежить від конкретного сервера моделей, якщо відмінності оформлено як параметри платформи.
Застосунок першого маршруту готовий до запитів через локальний Ollama.
Виклик OpenAI-сумісного endpoint на маршруті з Ollama.
Той самий контракт працює з іншим внутрішньокластерним backend.
Каталог і кілька моделей
Автор також перевірив композицію через каталог визначень. Платформна команда може один раз опублікувати Component і Traits, після чого розробники обирають їх як готові будівельні блоки. Для кількох моделей створюються окремі інстанси з власними ресурсами й backend, але схема доставки залишається однаковою.
Готові визначення компонуються без ручного дублювання Kubernetes-маніфестів.
Окремі інстанси моделей працюють під одним платформним контрактом.
Policy topology та override дають змогу просувати той самий Application між dev і prod, змінюючи namespace, ресурси та адресу backend. Для команд це важливіше за ще один шаблон Helm: намір застосунку залишається стабільним, а операційні відмінності контролює платформа.
Один Application просувається між середовищами через policy та override.
Практичний висновок і обмеження
Підхід корисний платформним командам, які вже використовують Kubernetes і хочуть дати розробникам стабільний self-service контракт. Починати варто з мінімального Component, чітких Traits для моделі та ресурсів і окремих policy для середовищ. Не слід переносити в OAM функції inference scheduler: це створить ще один складний контрольний контур.
Експеримент є proof of concept, а не результатом навантажувального тесту на GPU-кластері. Локальний k3d і симулятор не доводять ефективність KV-cache, пропускну здатність чи поведінку під великим трафіком. Перед production потрібні тести відмови backend, autoscaling за корисними метриками, обмеження доступу до моделей, керування секретами й вимірювання вартості кожного маршруту.
Автор першоджерела: Ayush Kumar.
Ліцензія: Apache License 2.0 — https://github.com/kubevela/kubevela.github.io/blob/main/LICENSE. Матеріал перекладено, переказано й адаптовано українською мовою.