together-dedicated-model-inference

Этот навык предназначен для развёртывания и эксплуатации моделей на выделенных GPU через Together AI Dedicated Model Inference v2. Он относится к сценариям, где модель должна обслуживаться на зарезервированном однопользовательском оборудовании, а не вызываться как обычная serverless-модель. В описанной схеме стоимость связана с работающими репликами, минутами и выбранным оборудованием, поэтому перед началом работы важно учитывать длительность работы deployment и явно останавливать ресурсы, когда они больше не нужны. Навык охватывает beta endpoints, deployments, deployment profiles, hardware configurations, autoscaling, распределение трафика, A/B-тесты, shadow-эксперименты, Prometheus-метрики, загрузку собственных моделей и LoRA-адаптеров. Он также описывает переход с устаревшего v1 dedicated endpoints API на v2: новые операции старого API могут возвращать HTTP 403, а новые развёртывания и повторное развёртывание остановленного старого endpoint следует выполнять через v2-поток. Центральная модель ресурсов состоит из Project, Model, Config, Endpoint, Deployment и Replica. Endpoint даёт стабильное имя для inference и направляет запросы между deployment по весам; Deployment связывает модель и config с политикой autoscaling; Config фиксирует опубликованную ревизию запуска, движок, тип и число GPU и профиль оптимизации; Replica является экземпляром модели на выделенном оборудовании. Для управления используются Together CLI с командами tg beta, beta-пространства SDK client.beta.* или REST API v2. Запрос inference идёт на API inference Together, а в параметре model передаётся строка endpoint вида project_slug/endpoint_name. Управляющие идентификаторы и строка inference не взаимозаменяемы: ep_, dep_, cr_, ml_, abx_ и exp_ применяются к management-вызовам, тогда как inference использует endpoint string. Практический маршрут начинается с выбора модели и доступного deployment profile. Профиль может задавать quantization BF16 или FP8, число GPU и точные имена model/config; автоматический выбор допустим, когда у модели один профиль, а при нескольких профилях нужно явно выбрать профиль и передать config. После deploy следует опрашивать состояние до DEPLOYMENT_STATE_READY. Готовое deployment при этом не обслуживает запросы, если не включено в traffic split: отсутствие или нулевой traffic weight может проявляться как routing error или 503. Навык объясняет autoscaling, scale-to-zero, изменение min/max replicas, метрики масштабирования и относительную природу traffic weights. Вес — это не процент, а относительная ёмкость с учётом готовых реплик. Для замены deployment на живом трафике сначала создаётся новый ресурс на том же endpoint, затем он дожидается READY, после чего трафик переносится постепенно, старый deployment выводится из split, масштабируется вниз и удаляется. Для остановки затрат рекомендуется выставлять min_replicas и max_replicas в ноль либо удалять ресурс; автоматического idle shutdown по старому inactive_timeout больше нет. Для диагностики маршрутизации ответ следует проверять по заголовкам: поле model в теле лишь повторяет endpoint string, тогда как x-cluster и событие x-i-router-log-event помогают увидеть конкретный deployment и replica. Навык направляет к официальным справочным разделам Together для lifecycle API, CLI, traffic routing, моделей и конфигураций, а также к скриптам deploy_model.py и upload_custom_model.py. Он не заменяет навыки для serverless inference, fine-tuning, контейнеров или raw GPU-кластеров: эти задачи вынесены в отдельные маршруты. Управляющая поверхность beta может меняться, поэтому версия Together SDK должна быть актуальной и закреплённой в окружении. В результате карточка полезна для инженерного процесса от выбора модели и профиля до безопасного включения трафика, наблюдения, масштабирования и остановки биллинга, с явными границами между API управления, endpoint-маршрутизацией и фактическим inference.