Коротко
Автор поставил self-hosted прокси-фильтр, который маскирует персональные данные и секреты в запросах к облачным моделям и обрабатывает ответы. После сбоя он добавил проверки режима, мониторинг пропусков и контролируемый fail-open, чтобы сочетать приватность с доступностью.
Контекст
Автор самостоятельно подбирал оборудование для локального запуска моделей и искал практичную защиту от передачи чувствительных данных облачным LLM. Вместо полного self-hosting он выбрал open-source guardrails-llm-filter от Cloud.ru (Apache-2.0), работающий как прокси; локальные Gemma4 и Qwen3.8 оставил в резерве.
Главное
- Автор тестировал RTX PRO 6000 96GB, RTX 4090 48GB и H200; затем приобрёл RTX 5070 Ti и V100 32GB, но в итоге не стал переносить всю работу на локальные модели.
- Выбран guardrails-llm-filter от Cloud.ru с лицензией Apache-2.0; он действует как прокси для запросов и ответов.
- Режим enforce подменяет персональные данные и секреты плейсхолдерами, а detect записывает обнаружения без замены.
- Первоначальная версия упала 22 сентября: у системного пользователя не было доступного для записи кэша Go, бинарник исчез, а Ansible не пересобирал его при отсутствии файла.
- После сбоя systemd пытался запустить отсутствующий бинарник более 2 600 раз примерно за четыре часа; обе облачные конфигурации автора зависели от прокси.
- Исправления: перенести HOME и кэши в доступный каталог и запускать пересборку, если бинарного файла нет. Режим enforce теперь задан и при старте, и в применённых настройках; Ansible проверяет его после сбоя.
- Автор подчёркивает, что PUT заменяет объект настроек целиком, поэтому теперь перечитывает и проверяет статус, режим и набор типов данных.
- LiteLLM с Presidio автор отверг после тестов: по его оценке, пересборка запросов портила общий префикс и могла сократить экономию кэша провайдера примерно на 90%.
- В OneUptime настроены два контроля: heartbeat раз в пять минут и счётчики fail-open за пятиминутные интервалы. Метрики не содержат текста запросов.
- Если фильтр не может разобрать отдельный запрос, он пропускает его без маскирования и увеличивает счётчик; монитор превращает такие случаи в инцидент. Если сам процесс остановлен, вызов к модели просто не проходит.
Как сделано
Фильтр стоит между клиентом и облачными моделями и обрабатывает трафик в обе стороны. В режиме enforce он подменяет персональные данные и секреты плейсхолдерами; в detect только фиксирует найденные случаи. Автор отказался от клиентского хука: за пять сессий столкнулся с проблемами ONNX, испорченными строками и конфликтом с кэшем промптов. LiteLLM тоже не выбрал: по его тестам, пересборка запросов ломала общий префикс и снижала экономию на кэше примерно на 90%.
Результаты
После исправлений фильтр пережил полную перезагрузку сервера и поднялся включённым, в режиме enforce и с шестью типами данных. В OneUptime настроены heartbeat-проверка каждые пять минут и мониторинг счётчиков fail-open за пятиминутные интервалы. Автор сообщает примерно о 1,5 млрд кэшированных токенов за три недели и считает, что сохранение кэша было важным фактором при выборе архитектуры. Измерений точности фильтра или доли обнаруженных утечек в статье нет.
Ограничения
Описан личный опыт, а не сравнительное исследование: методика и наборы тестов не приведены. Fail-open намеренно пропускает запрос без маскирования, если сервис не может разобрать его тело; это снижает риск случайных блокировок, но допускает отправку чувствительных данных. При полном падении прокси запасного маршрута нет и вызовы к моделям прекращаются. Фильтр снижает, но не устраняет риски передачи данных провайдерам; локальные модели автор считает уступающими ведущим облачным. Упомянутые показатели кэша и снижение его эффективности в LiteLLM — оценки автора.
Что взять себе
- Прокси перед LLM может централизовать маскирование и обработку ответов, но его отказ затрагивает весь маршрут к моделям.
- Проверяйте конфигурацию не только при деплое: контролируйте режим после перезапуска и корректно обрабатывайте отсутствие бинарника.
- Fail-open удобен для непрерывной работы, но безопасен лишь при явном мониторинге и понимании, что запрос может уйти без фильтрации.
- Изменение прокси-слоя способно повлиять на кэширование промптов; проверяйте стоимость на реальном трафике до перехода.
- Не храните тексты запросов в мониторинге без необходимости: автор использует счётчики, типы данных и задержки.
Читать оригинал, если…
Откройте оригинал, если нужны подробности настройки Ansible, API и OneUptime, а также личные наблюдения о кэшировании промптов и отказах фильтра.