Готового и проверенного рецепта, как открыть локальный инференс целой команде, в исходном обсуждении нет. Есть рабочая схема одного инженера и явно названная проблема, которую он пока не решил: как заставить harness работать на всех сотрудников без мучительной выдачи API-токенов сервисов вроде Google.
Схема выглядит так: локальный инференс-сервер Radiance, доступ к нему только через Tailscale по HTTPS, Hermes в роли harness на Framework Desktop с отдельным контейнером на каждого пользователя, общий центральный репозиторий навыков и Radiance на отдельной машине, доступной только через Framework. Это план, а не отчёт о внедрении. Автор вопроса на r/LocalLLaMA прямо спрашивает сообщество, как такую задачу решали другие, и содержательных ответов в треде нет.
Дальше разбор по слоям: сеть, изоляция пользователей, общие ресурсы и управление секретами. Для каждого слоя показано, что он закрывает, где заканчивается и какие вопросы остаются открытыми.
В чём задача: локальный инференс есть, а команде его не отдать
Radiance развёрнут для компании, и следующий шаг - открыть к нему доступ остальным сотрудникам. Пока конфигурация однопользовательская: один сервер, один harness, один набор навыков. Как только пользователей становится больше, появляются четыре независимых вопроса: как они подключаются, что каждому разрешено, чем они делятся и какие секреты им нужно выдать.
Что уже работает в схеме автора
- Radiance - локальный инференс-сервер компании. Одна точка входа к моделям, один набор весов, одна версия для всех.
- Tailscale - заявлен как единственный способ доступа к серверу по HTTPS. Публичного адреса у сервиса нет.
- Hermes - harness, то есть обвязка вокруг модели: инструменты, контекст, права, навыки. Именно он определяет, что пользователь может делать внутри рабочего окружения.
- Framework Desktop - хост Hermes и точка входа к Radiance. Другого маршрута к инференсу не настроено.
- Центральный репозиторий навыков - общий ресурс, открытый для всех пользовательских контейнеров.
Разделение хостов важнее, чем кажется на первый взгляд. Инференс и harness живут на разных машинах, поэтому генерация не отбирает память у контейнеров, а контейнеры не мешают загрузке модели. Плата за это - дополнительное звено в маршруте: Framework Desktop обязателен для любого запроса.
Hermes в этой роли типичный представитель своего класса: вся логика вокруг модели собрана в одном приложении (что входит в harness и когда оправдан свой код, разбираем отдельно). От того, как устроен этот слой, зависит и разграничение прав, и работа с секретами.
Что в схеме остаётся нерешённым
- Командная работа harness: как несколько человек одновременно пользуются Hermes, не мешая друг другу.
- Управление API-токенами сторонних сервисов: главная боль, названная автором.
- Права и масштаб: в источнике нет ни размера команды, ни требований к разграничению доступа.
- Версии и конфигурация: не указано, какие версии компонентов используются и как они настроены.
Отсутствие этих данных принципиально. Любая конкретная рекомендация по настройке здесь была бы догадкой, а не выводом из источника. Обсуждение фиксирует точку отсчёта: работающая схема для одного человека и открытый вопрос про команду.
Сетевой доступ: почему Tailscale, а не открытый порт
Публичный порт на домашнем или офисном сервере сканеры находят в первые часы. Схема автора обходит это: Radiance ничего не публикует в интернет, а подключение идёт по адресу внутри приватной сети Tailscale поверх HTTPS. Для команды это выглядит как обычный URL, для внешнего мира сервера не существует.
Tailscale строит оверлейную сеть на протоколе WireGuard: каждое устройство получает адрес в общем диапазоне, соединения устанавливаются напрямую между узлами, а при симметричном NAT трафик идёт через релей. Практическая выгода для инференса: не нужны проброс портов, динамический DNS и отдельный сертификат на публичный домен, а машина коллеги попадает в сеть только после авторизации в тенанте.
HTTPS внутри приватной сети: что это закрывает
Связка даёт три вещи. Шифрование канала между клиентом и сервером, причём сертификат выпускается штатными средствами, и браузер не показывает предупреждений. Отсутствие публичной экспозиции: сервис не виден из интернета, атаковать его снаружи нечем. Привязку доступа к устройствам: ноутбук сотрудника, выведенный из тенанта, теряет маршрут до Radiance.
Чего эта связка не даёт, так это ответа на вопрос «кто именно отправил запрос». Внутри меша устройства равноправны, пока не настроены ACL. Tailscale умеет ограничивать доступ по тегам и группам, но это грубая политика уровня сети: разрешить или запретить порт, а не «Аня пользуется моделью A и не может менять навыки». Аудит запросов, квоты на токены и разделение пользователей внутри приложения остаются задачей harness.
Где заканчивается сеть и начинается авторизация
Полезно разложить систему на четыре уровня и для каждого ответить, кто за что отвечает.
- Транспорт: Tailscale. Решает, доходит ли пакет и кто вообще может его отправить.
- Хост: Framework Desktop. Решает, какие процессы запущены и сколько памяти с CPU они получают.
- Harness: Hermes. Решает, что разрешено пользователю внутри рабочего окружения.
- Модель: Radiance. Решает, какой контекст и какие параметры применяются к запросу.
Если перепутать уровни, появляются классические дыры: «доступ только по VPN» превращается в «полный доступ для всех, кто в VPN». В схеме автора разграничение заявлено на уровне контейнеров Hermes, а Tailscale отвечает только за транспорт.
Альтернативы для сравнения. Публичный reverse-proxy с аутентификацией, например OAuth-прокси поверх nginx, даёт нормальный логин и аудит, зато открывает сервис в интернет и требует защиты от перебора и уязвимостей. SSH-туннели просты, но плохо масштабируются на десяток человек и неудобны для веб-доступа. Корпоративный VPN решает транспорт централизованно, однако зависит от ИТ-отдела и часто хуже работает с мобильными клиентами, чем меш.
Изолированные контейнеры на пользователя: что реально изолируется
План автора: каждому сотруднику отдельный контейнер Hermes с ограничениями доступа, при этом все контейнеры видят центральный репозиторий навыков. Замысел разумный: у каждого своя файловая система, свой набор инструментов и свои права, а общий ресурс один.
Контейнер даёт отдельный rootfs, лимиты CPU и памяти, собственный набор переменных окружения, то есть разные секреты для разных людей, возможность снести и пересоздать окружение после эксперимента и отсутствие случайных правок в чужом рабочем каталоге. Ограничения задаются на уровне оркестратора: cgroups, квоты диска, политики сети.
Контейнер не даёт изоляции от хоста при неверной конфигурации, защиты от общей сети между контейнерами и разделения нагрузки, если все они конкурируют за одни и те же ядра. И главное, он не защищает общий ресурс, к которому у всех есть доступ на запись.
Изоляция пользователей и общий репозиторий навыков
Здесь в схеме есть внутреннее противоречие, и его стоит назвать вслух. Репозиторий навыков - общий код, который исполняется в контексте каждого пользователя. Если писать в него может любой, один сотрудник способен изменить поведение harness у всей команды: подменить инструкцию, добавить шаг, уводящий данные наружу. Контейнеры остаются изолированными формально, а общая точка отказа переезжает на уровень навыков.
Мягкие варианты снизить риск: монтировать репозиторий в пользовательские контейнеры только для чтения и принимать изменения через pull request; держать стабильную и экспериментальную ветки; выдать право записи одному ответственному. Ещё один слой - версионирование навыков с фиксацией коммита, который использовал конкретный запуск, чтобы по логам было видно, что именно исполнялось. Ограничение этих мер в дисциплине: запрет на запись работает технически, а «не добавляй странный навык» контролируется только ревью.
Риск исполнения чужого кода внутри общего harness хорошо виден на свежем примере: в изолированной песочнице Qwen3.8-Flash-Next собрала данные о машине и пыталась отправить файл наружу, попытку заблокировали. Песочница помогает, но мониторинг сетевых попыток нужен отдельно.
Ресурсы хоста: Framework Desktop как узкое место
Radiance живёт на отдельном сервере, Hermes на Framework Desktop. Это лучше, чем один общий узел: инференс не конкурирует с harness за память. Но все контейнеры Hermes делят один хост, и при десятке одновременных пользователей лимиты придётся задавать явно: память на контейнер, число процессов, количество параллельных сессий.
Наблюдать стоит три метрики: загрузку памяти хоста, число контейнеров рядом с лимитом и время ответа Radiance. Без этого первый же пользователь с тяжёлым инструментом уронит harness остальным. Конкретные значения зависят от того, что делают навыки, поэтому универсальных цифр нет, а в источнике их тем более не приводится.
Общий доступ к моделям и навыкам без хаоса
В схеме два разных общих ресурса, и управляются они по-разному. Модели - состояние, которое нельзя размножать. Навыки - код, который размножать полезно, но с контролем версий.
Модели: единая точка входа вместо копий
Логика автора: Radiance остаётся единственным инференс-сервером, доступ идёт только через Framework Desktop, клиенты не тянут веса к себе. Плюсы конкретны: один набор весов вместо десяти копий, единая версия модели у всех, загрузка в память один раз, предсказуемая нагрузка на железо.
Минусы не менее конкретны. Framework Desktop становится обязательным звеном: упал он, и команда теряет не только harness, но и доступ к модели, хотя Radiance продолжает работать. Второй риск - очередь: одновременные запросы делят пропускную способность одного сервера, и отдать приоритет получится только если harness это умеет. Третий - обновления: смена модели затрагивает всех сразу, поэтому нужен либо период параллельной работы двух версий, либо окно обслуживания.
Практика локальных запусков это подтверждает: в агентских конвейерах LLM-сервер часто держат неприкосновенным и не перезапускают ради экспериментов, иначе страдают все запущенные задачи (правила такого марафона разобраны отдельно). Для команды это означает правило: обновление Radiance плановая операция, а не побочный эффект отладки.
Навыки: кто владеет общим репозиторием
Общий репозиторий без владельца деградирует за пару недель: появляются дубли, конфликтующие инструкции, навыки под личные привычки, которые ломают чужие сценарии. Минимальный набор правил: один ответственный за приём изменений, отдельная ветка для экспериментов, ревью перед попаданием в основную ветку, семантические версии и changelog.
Второе разделение - на общие и личные навыки. Общие лежат в центральном репозитории и подключаются только для чтения. Личные живут в домашнем каталоге контейнера и не влияют на других. Тогда эксперимент не требует согласования, а в общий набор попадает только то, что проверено хотя бы на двух людях.
В исходном материале механизм управления репозиторием не описан, есть только заявка на общий доступ. Всё перечисленное - организационные меры, которые стоит ввести до подключения третьих пользователей.
Главная боль: API-токены сторонних сервисов без раздачи каждому
Формулировка автора: получить harness, работающий на всю команду, без большой головной боли с API-токенами от сервисов вроде Google. Сложность в том, что у каждого сотрудника свой аккаунт, свои квоты и свои правила доступа, а harness должен вызывать внешние API от имени кого-то одного. Раздать личные токены всем - потерять контроль: их не отозвать по одному, не видно, кто что вызвал, а уволившийся сотрудник уходит с ключом.
Подходов немного, и у каждого есть цена.
Секрет-брокер и egress-прокси: суть и ограничения
Идея общая: секреты хранятся в одном месте, контейнеры пользователей их не видят. Вариантов исполнения два.
- Секрет-брокер. Harness аутентифицируется перед брокером своим сервисным токеном, брокер проверяет права и отдаёт короткоживущий токен нужного сервиса. Плюс: ключи не лежат в контейнерах, все выдачи логируются. Минус: брокер нужно развернуть и сопровождать, у него своя база секретов, и он становится критичной точкой.
- Egress-прокси с подстановкой. Контейнер ходит наружу только через прокси, прокси добавляет заголовок авторизации к запросам к разрешённым доменам. Плюс: код harness не меняется, он думает, что говорит с обычным API. Минус: прокси видит весь трафик, его компрометация равна утечке всех ключей, а часть сценариев с интерактивным OAuth и редиректом в браузере так не провести.
Оба варианта требуют того, чего в схеме пока нет: аудита вызовов, ротации токенов, ограничения по доменам и по объёму запросов на пользователя. Слой учётных данных стоит проектировать отдельно от harness, как это делают в инструментах с явным хранилищем Credentials (пример такой архитектуры разобран в материале про Later Bender).
OAuth-делегирование и сервисные аккаунты
Штатный путь провайдера выглядит так: приложение получает согласие пользователя и работает от его имени, либо организация заводит сервисный аккаунт и выдаёт ему доступ к нужным ресурсам.
OAuth-делегирование даёт нормальный отзыв: сотрудник уходит, его refresh-токен отзывается, остальные не страдают. Настройка заметно сложнее: консент-экран, скоупы, ограничения на типы аккаунтов, требования верификации у части провайдеров. Сервисные аккаунты проще в эксплуатации, зато в логах провайдера все действия выглядят как один субъект, и разобраться, кто именно дернул API, нельзя.
Честная оговорка: в исходном обсуждении нет подтверждения, что конкретный провайдер, например Google, даст нужную схему для harness без интерактивного входа у каждого пользователя. Это проверяется по политике провайдера и по типам аккаунтов, а не предполагается.
Есть и четвёртый путь: убрать сторонние сервисы из критичного контура. Локальные модели, локальный поиск, локальные инструменты. Он сужает возможности и подходит не всегда, зато почти полностью снимает вопрос управления внешними токенами.
Сравнение подходов к командному доступу
Ниже карта решений, а не рейтинг. Ни один вариант не подтверждён в источнике как рабочий: там есть план и открытая проблема. Схема автора занимает третью строку таблицы.
| Вариант | Сеть | Изоляция пользователей | Общие ресурсы | Секреты | Сложность | Главный риск |
|---|---|---|---|---|---|---|
| Tailscale без изоляции harness | Приватный меш, HTTPS | Нет, все в одном окружении | Один общий каталог | Личные токены у всех | Низкая | Один пользователь ломает окружение остальным |
| Один общий harness | Приватный меш | Фактически нет | Репозиторий без версий | Общий набор ключей в окружении | Низкая | Не видно, кто что сделал |
| Контейнер на пользователя (схема автора) | Приватный меш, вход через Framework | Есть: отдельные ФС и лимиты | Модель одна, навыки общие | Разные наборы в контейнерах | Средняя | Общий репозиторий навыков как точка отказа |
| Плюс секрет-брокер или egress-прокси | То же | Есть | То же | Ключи у брокера, не в контейнерах | Высокая | Брокер и прокси становятся критичной точкой |
| Плюс OAuth-делегирование | То же | Есть | То же | Доступ от имени пользователя, отзыв штатный | Высокая | Зависимость от политик провайдера |
| Централизованный шлюз к облачным API | Обычный интернет | На стороне шлюза | Модели у провайдера | Ключи в шлюзе | Средняя | Данные уходят наружу, расход зависит от тарифа |
Критерии выбора под свою команду
- Масштаб: три человека и тридцать требуют разной строгости. В источнике масштаб не назван.
- Требования к аудиту: нужно ли доказывать, кто и когда обращался к модели и к внешним API.
- Список сторонних сервисов: два сервиса закрываются сервисным аккаунтом, десять уже требуют брокера.
- Готовность поддерживать инфраструктуру: прокси и брокер требуют обновлений, мониторинга и ротации секретов.
- Допустимость единой точки отказа: Framework Desktop в роли единственного шлюза к Radiance падает целиком.
- Бюджет времени: полный вариант со всеми слоями собирается неделями, а не за вечер.
Что проверить перед раскаткой на команду
Список проверок, по которым в исходной схеме нет готовых ответов.
- Кто и как попадает в тенант Tailscale, что происходит при уходе сотрудника и отзывается ли его устройство автоматически.
- Какие ACL заданы между устройствами и контейнерами: может ли контейнер одного пользователя обратиться к сервису другого.
- Как выдаются учётные данные внутри Hermes: один общий набор на всех или отдельные наборы в переменных окружения каждого контейнера.
- Где хранятся логи harness и что в них попадает, включая промпты и ответы, если те содержат чувствительные данные.
- Что происходит при падении Framework Desktop: есть ли резервный маршрут к Radiance или простоя не избежать.
- Как обновляются модель и навыки: кто принимает решение и существует ли откат на предыдущую версию.
- Как ротируются токены и сколько времени занимает отзыв доступа у одного пользователя.
Ограничения схемы и когда она не подходит
Схема плохо подходит, когда команда большая и текучка заметная: ручное управление контейнерами и доступом съест больше времени, чем экономит локальный инференс. Она неудобна при жёстких требованиях к аудиту, если harness не пишет внятных логов. Она проигрывает, когда внешних интеграций много: секрет-брокер превращается в отдельный продукт со своим владельцем.
В этих случаях разумнее централизованный шлюз к облачным API: меньше контроля над данными, зато предсказуемая авторизация, квоты и аудит из коробки. Локальный инференс выигрывает в другом: данные не уходят наружу, стоимость запроса не зависит от тарифа, а модель меняется без переговоров с вендором.
Вывод: что можно взять из схемы, а что предстоит решить самому
Из схемы автора стоит забрать три вещи. Приватный транспорт вместо публичного порта: Tailscale по HTTPS убирает экспозицию сервиса в интернет и снимает возню с сертификатами. Контейнер на пользователя как базу изоляции: разные файловые системы, лимиты и наборы прав. Разделение хостов: harness и инференс на разных машинах не конкурируют за память.
Что требует собственных решений: правила общего репозитория навыков (read-only, ревью, версии), лимиты на хосте Hermes, резервный маршрут на случай падения Framework Desktop и, главное, механизм выдачи токенов сторонних сервисов. Последний пункт в источнике только обозначен. Выбор между секрет-брокером, egress-прокси и OAuth-делегированием зависит от числа интеграций, требований к аудиту и готовности поддерживать дополнительный сервис.
Следующий шаг практический: выписать, сколько человек будет пользоваться системой и к каким внешним сервисам harness обращается сегодня. Если сервисов один или два, хватит сервисного аккаунта и читаемых логов. Если больше пяти, управление ключами без брокера или прокси быстро станет рутиной на полдня в неделю. Исходное обсуждение стоит перечитать перед стартом: там зафиксирована точка отсчёта, но не готовый ответ.