Как KTMS подключает свои GPU и переживает сбои
Open-source LLM-шлюз KTMS научился работать не только с облаком, но и с локальными видеокартами: Mac Studio и Linux-машины можно добавить как отдельный источник ответов. В новой статье авторы показали, как это устроено в продакшене — от установки ноды и балансировки до поведения при отказах и обновлений без простоя.
Локальные видеокарты как ещё один источник ответов
Идея KTMS проста и практична: если у команды уже есть Mac Studio или Linux-сервер с хорошей видеокартой, его можно использовать как «локального вендора». Тогда шлюз сначала отправляет запросы туда, а облако подключает только если свои ноды заняты или не успевают ответить.
Чтобы добавить такую ноду, администратор выпускает для неё отдельный ключ, привязанный к конкретному идентификатору машины, а затем регистрирует модель с пометкой vendor: local. После этого ставится агент, Ollama, сама модель и сервисы запускаются в фоне, а машина не уходит в сон. Для macOS это можно сделать без прав администратора, а повторный запуск скрипта обновляет только то, что изменилось.
Как шлюз решает, куда отправить запрос
KTMS смотрит на несколько вещей сразу: есть ли нужная модель, свободен ли слот, хватает ли контекста для входного текста и будущего ответа. Сначала в приоритете здоровые ноды, а сомнительные используются только если подходящих вариантов больше нет. Если модель уже загружена в память, шлюз старается выбирать «тёплые» ноды, чтобы не тратить время на лишний прогрев.
Балансировка учитывает не только занятость, но и скорость работы каждой ноды. Шлюз сравнивает скорость генерации и время до первого токена между машинами, а затем распределяет запросы по схеме smooth weighted round-robin — так же, как это делает nginx. Если локальная нода слишком долго стоит в очереди, запрос не зависает зря: шлюз оценивает ожидание и переключает его на следующую модель, обычно облачную.
Что будет при сбоях и как пережить обновления
В статье отдельно разобрали поведение при отказе зависимостей. У KTMS есть Postgres, Redis и сервис учёта, и для каждого заранее описано, что делать при проблемах: где-то трафик продолжат пропускать без учёта, где-то будут использовать последний удачный снимок, а где-то запросы уйдут в облако, если состояние ноды уже не видно. После нескольких сетевых ошибок Redis шлюз ещё и «остывает» на пару секунд, чтобы не добивать зависший сервис постоянными попытками.
Есть и вопросы безопасности: ключи вендоров хранятся в Postgres в зашифрованном виде с AES-256-GCM, а ключ шифрования можно менять отдельно. Авторы также описали, как проверять подлинность релиза и обновляться без простоя. Для команд, которые держат ИИ-инфраструктуру у себя и не хотят терять доступ к модели даже во время поломок, это очень прикладная схема.
Если говорить по-деловому, KTMS пытается убрать самый дорогой сценарий — когда локальная инфраструктура простаивает, а облачные запросы продолжают капать в счёт. Для разработчиков и DevOps это способ использовать свои GPU эффективнее и не терять сервис при очередном сбое одной из зависимостей.