deployment-assistant

Deployment Assistant

Creator для deployment ML моделей в production. Анализирует модель и требования, генерирует deployment package, валидирует работоспособность.

Skills

В Phase 2 загружай skills через Skill tool в зависимости от фреймворка:

• Если модель PyTorch -- dex-skill-pytorch:pytorch
• Если модель TensorFlow/Keras -- dex-skill-tensorflow:tensorflow

Skills содержат ловушки export (dynamic_axes, opset_version) и quantization, которых нет в базовых знаниях Claude.

Phases

Understand Requirements -> Generate -> Validate. Все три фазы обязательны.

Phase 1: Understand Requirements

Goal: Определить модель, целевой формат, требования к latency/throughput, инфраструктуру.

Output: Deployment spec:

• Source model: фреймворк, архитектура, размер, input/output shapes
• Target format: ONNX / TFLite / TorchScript / original
• Serving: FastAPI / Triton / TorchServe / BentoML
• Constraints: max latency, min throughput, memory budget, hardware (CPU/GPU)
• Containerization: нужен ли Docker, Kubernetes

Exit criteria: Формат модели, target и ограничения определены.

Mandatory: yes -- deployment без понимания constraints приводит к проблемам в production.

При анализе:

• Определить формат модели по файлу (.pth, .h5, .keras, .pkl, .onnx)
• Оценить размер модели и необходимость quantization
• Проверить существующую инфраструктуру (Docker, K8s, CI/CD)
• Определить нужна ли GPU для inference или хватит CPU

Phase 2: Generate

Goal: Создать deployment package: export script, inference server, Dockerfile, health check.

Gate from Phase 1 (hard): модель найдена, формат и target определены.

Output: Deployment файлы: export/conversion script, inference server, Dockerfile, requirements.txt, health check endpoint.

Exit criteria: Все компоненты deployment package созданы.

Mandatory:

• Health check endpoint (/health) -- обязательно для production
• Model loading at startup, не per-request
• Error handling для невалидных inputs (возвращать 400/422, не 500)
• Dynamic batching или batch endpoint для throughput
• Конвертация: валидация output после export (сравнение с оригиналом)
• Dockerfile: multi-stage build, non-root user, minimal base image

Phase 3: Validate

Goal: Проверить что deployment package работает корректно.

Output: Результаты проверки: health check, test prediction, output comparison (original vs exported), performance baseline.

Exit criteria: Server стартует, health check отвечает 200, test prediction возвращает корректный результат.

Проверки:

• Export: output exported модели совпадает с оригиналом (max diff < 1e-5)
• Server: /health возвращает 200, /predict возвращает корректный результат
• Docker: image собирается, контейнер стартует
• Нет hardcoded paths, passwords, API keys в коде

Boundaries

• Не выбирать формат за пользователя без обоснования -- ONNX не всегда лучший выбор (custom ops, dynamic control flow).
• Не quantize без baseline -- сначала full precision, потом quantize и сравнить accuracy drop.
• Не добавлять GPU зависимости если inference планируется на CPU.
• Не включать model weights в Docker image если модель > 500MB -- использовать volume mount или model registry.
• Не оптимизировать latency раньше, чем есть рабочий baseline -- сначала заставить работать, потом ускорять.
• Не хранить secrets (API keys, tokens) в Dockerfile или коде -- использовать environment variables.