LLM-шлюз KTMS добавил локальные ноды: свои GPU как отдельный вендор

30 октября 2026 года вышла статья про эксплуатацию Keystone. The Model Switchboard. (KTMS) — open-source LLM-шлюза (прослойка между приложением и моделями) на Go. В прошлый раз речь шла о маршрутизации и деньгах. Теперь — о том, как подключить свои видеокарты и что делать, когда что-то отваливается.

Отличие от предыдущего материала в фокусе. Раньше разбирали, куда шлюз отправляет запросы и как считает стоимость. Сейчас — эксплуатация: ноды, отказы зависимостей, смена ключей шифрования, проверка скачанного релиза и обновление без простоя. То есть статья про то, что происходит после того, как маршрут выбран.

На практике схема такая. Администратор шлюза выдаёт ключ ноды, привязанный к её идентификатору. Ключ показывается один раз. Затем регистрирует модель с vendor (вендор — источник модели) local и параметрами вроде queue_timeout_ms. На самой машине установка сводится к одной команде: скрипт ставит Ollama (локальный раннер моделей), саму модель и агента ноды, запускает их как фоновые сервисы. В примере из статьи — нода anna-mac и модель gemma4:26b-a4b-it-qat. Запросы идут на локальные машины первыми, облако подключается, когда ноды заняты. Логика простая: у многих команд есть Mac Studio или Linux-машина с картой, которая простаивает, и счёт за облачные запросы, на которые локальная модель ответила бы не хуже.

Что осталось неизвестным. Детали обработки отказов каждой зависимости, порядок смены ключей шифрования, способ проверки, что скачан именно нужный релиз, и механику обновления без простоя автор анонсировал, но в пересказе конкретики нет. Данных о том, как это устроено внутри, в заметке не приводится.