Architecture

Decision

Используем архитектуру core + plugins.

Это промежуточный вариант между монолитом и микросервисами: быстро стартуем в одном репозитории, но держим границы так, чтобы любой плагин можно было вынести в отдельный сервис.

Core

core содержит общие возможности платформы:

registry: учет моделей, адаптеров, версий, лицензий и требований к ресурсам.
inference: единый слой запуска моделей и совместимый API.
training: общие пайплайны подготовки данных и дообучения.
evals: общие правила оценки качества моделей.
deploy: развертывание, включая GPU Docker host.
storage: правила локального хранения моделей и датасетов.
monitoring: метрики GPU, latency, ошибок и использования моделей.

core не должен содержать бизнес-логику конкретной задачи.

Plugins

Плагины содержат прикладные направления:

text: работа с текстом, суммаризация, анализ, генерация.
translation: перевод.
audio: speech-to-text, diarization, text-to-speech.
video: извлечение кадров, аудио, анализ сцен и суммаризация.
image: генерация изображений, inpainting и редактирование по маске.
1c: помощник по 1С, BSL, запросы, метаданные, RAG и дообучение.

Каждый плагин должен иметь собственные:

описание назначения;
список моделей;
пайплайны;
датасеты;
eval-тесты;
настройки инференса;
план будущего API.

Plugin Boundary

Плагин может использовать core, но core не должен зависеть от конкретного плагина.

Правильное направление зависимости:

plugins/* -> core/*

Неправильное направление:

core/* -> plugins/*

Growth Path

Stage 1: one repository, core + plugins
Stage 2: heavy plugins run as separate containers
Stage 3: 1c/audio/video/image become standalone services
Stage 4: full service architecture if production load requires it

2.7 KiB Raw Blame History