В чём суть кейса: приватные данные, которые нельзя отдать в облако
В октябре 2026 года пользователь раздела r/LocalLLaMA описал рабочий кейс: локальная модель Qwen 3.8 FN (в исходном тексте, «Qwen 3.8 flash next») в связке opencode + vllm внутри Docker-контейнера закрыла задачу, которую нельзя было отправить в облако. Речь о персональных данных студентов и руководителей. Сразу оговорка: это единичный пользовательский опыт. Замеров, бенчмарков и раскрытой конфигурации железа в отчёте нет, поэтому всё дальше - наблюдения одного человека на одной задаче, а не проверенные характеристики модели.
Суть работы: сопровождение модуля магистерской диссертации. Нужно вести студентов, руководителей, предложенные проекты, выборы проектов, экзаменаторов и в итоге оценки. Логика сопоставления двусторонняя. Студенты выбирают пять проектов из предложенного списка, руководители тоже выбирают студентов. При этом руководитель не может оценивать работу своих студентов, но может оценивать чужих. Держать все эти связи в голове и в Excel одновременно - отдельное развлечение.
Автор называет себя активным пользователем Codex, и это важная деталь. Он не искал повод уйти из облака: привычный инструмент у него был. Мешало другое: имена и email студентов и руководителей, а также детали ранних исследовательских проектов нельзя выгружать наружу. Отсюда и мотивация, которую он формулирует прямо: не думать постоянно о приватности и GDPR при работе с агентами и знать, что данные не покидают диск.
Ключевой вывод из первой части кейса простой: локальная модель здесь нужна не ради идеологии, а потому что облачный инструмент для этих данных закрыт по условиям работы. Дальше разбираем, как устроена связка, что она сделала и где у неё пределы.
Почему облачный Codex не подошёл: приватность и GDPR как техническое требование
В этом кейсе приватность перестаёт быть юридической формулировкой в шапке документа и превращается в ограничение архитектуры. На входе у агента три источника: экспорт формы ms forms, база студенческих записей и Moodle. Внутри - ФИО, адреса почты, темы ранних исследовательских проектов. Это не обезличенные логи и не открытые датасеты.
Разница между «неудобно отдавать» и «нельзя отдавать» здесь принципиальная. Первое решается привычкой. Второе означает, что любой инструмент, который отправляет данные на чужой сервер, выпадает из допустимого контура, каким бы удобным он ни был. GDPR в описании автора выступает ровно в этой роли: как причина, по которой облачный сценарий отменяется, а не как абстрактное требование к документам.
Автор не утверждает, что облачные сервисы плохи или небезопасны в целом. Он говорит о своём ограничении: конкретные данные нельзя отдавать наружу. Практический вывод для читателя: если у вас есть персональные данные, которые по внутренним правилам или регуляторике не должны покидать ваш контур, локальная модель перестаёт быть экспериментом и становится требованием к стеку. Юридических деталей кейс не раскрывает, и воспринимать его как консультацию по GDPR не стоит.
Из чего состоит локальный стек: opencode, vllm и Docker-песочница
Связка в отчёте описана коротко, но у неё четыре различимых слоя. Модель Qwen 3.8 FN отвечает за понимание запроса и планирование шагов. vllm поднимает инференс локально. opencode ведёт цикл «запрос → вызов инструмента → проверка результата». Docker-контейнер изолирует агента от остальной системы. Каждый слой решает свою задачу, и замена любого из них меняет поведение всей конструкции.
Роль vllm как локального бэкенда
В кейсе vllm - это отдельный процесс, который отдаёт модели ответы обвязке. Точка разделения удобна сама по себе: opencode не знает, откуда пришла модель, а бэкенд не знает, как агент распорядится результатом. Меняете модель или её квантование - обвязка остаётся прежней. Меняете обвязку - бэкенд продолжает работать. Именно поэтому формулировки вроде «vllm локальный запуск» и «opencode vllm» обычно ищут вместе: это две половины одной схемы, а не конкурирующие инструменты.
Каких-то настроек производительности, параметров батчинга или версий в источнике нет. Есть только факт: связка работала и обслуживала агентский цикл. Конкретные команды запуска зависят от вашего окружения, GPU и выбранного формата весов, и придумывать их за автора кейса бессмысленно.
Зачем агенту Docker-песочница
Права в контейнере описаны двумя пунктами, и оба важны. Первый: read-only доступ ко всем входным данным. Агент может читать исходные CSV и базу, но не может их испортить. Второй: право записи в рабочее пространство. Всё, что он создаёт, остаётся в workspace и не расползается по диску.
Такой набор прав решает конкретную проблему: агент с доступом к файлам и Python способен случайно перезаписать исходник или удалить каталог. Read-only входы убирают самый разрушительный класс ошибок. Это ограничение прав, а не магия безопасности: если смонтировать в контейнер домашний каталог с правами записи, изоляция превратится в декорацию. Настройка песочницы требует времени и понимания, что именно вы монтируете, и это часть работы, а не бесплатный бонус к модели.
Набор инструментов внутри тоже ограничен. По словам автора, у агента есть веб-доступ, python, pypdf, libreoffice и возможность ставить пакеты через pip в venv, и это примерно всё. Такой минимум закрывает работу с документами и таблицами, но не превращает агента в универсальную среду. Как выглядят похожие ограничения на практике, мы разбирали в материале о том, как 27B-модель сутки работала над кодом на двух GPU: файловая память агента, мелкие фазы с машинной проверкой и запрет трогать сервер, который сам же и обслуживает модель.
Как выглядела задача: грязные CSV, сопоставление и сборка данных
Данные приходили из ms forms, базы студенческих записей и Moodle. Во всех трёх случаях это CSV-экспорт, но форматы разные, порядок полей разный, написание вторых имён тоже расходится. Классическая ситуация, где ручная сборка съедает день, а то и два, и каждый следующий семестр приходится начинать заново.
По словам автора, модель справилась с неоднородными структурами из разных источников и их объединением. Именно это, а не генерация текста, было ядром задачи: свести три несовпадающих представления об одних и тех же людях в одну базу.
Ingest и повторяемая пересборка: что именно сделал агент
Работа шла в два слоя. Первый: агент написал ingest-функцию, которая читает CSV в базу. Данные складывались в SQLite, а Python служил рабочим инструментом для всей обработки. Второй слой - ручные правки, которые позволяли пересобирать базу из источников повторяемо, каждый раз исправляя опечатки и грамматику, приходившие из ms form.
Наличие ручных правок стоит читать правильно. Это не признак того, что модель не справилась, а часть решения: правила очистки зафиксированы, пересборка воспроизводима, следующий прогон не требует заново объяснять, что «Иванов А.» и «Иванов Александр» - один человек. Агент закрыл полный цикл: прочитать, привести к общей структуре, записать, собрать выходной документ.
Скорость на реальной операции
Самая конкретная цифра в кейсе относится к генерации docx-буклета проектов из базы SQLite напрямую с SSD - несколько секунд, включая время на обдумывание запроса. Это наблюдение автора, без бенчмарка и без указания железа. Экстраполировать его на другие задачи, модели и конфигурации нельзя: буклет из базы и разбор трёх грязных CSV - операции разного веса.
Почему локальный вариант оказался быстрее облачного Codex
Автор формулирует это без оговорок: локальная связка быстрее Codex, и заметно. Причины в рамках описанного сценария понятны. Данные лежат на локальном SSD, сетевых раунд-трипов между агентом и моделью нет, файлы читаются напрямую. Пока облачный сервис отправляет контекст, ждёт ответа и возвращает результат, локальный агент уже выполнил следующий шаг.
Замеров автор не приводит, сравнение не оформлено как тест, а конфигурация железа не раскрыта. Поэтому корректная формулировка звучит так: на этой задаче у этого пользователя локальный стек оказался быстрее привычного облачного инструмента. Переносить вывод на другие конфигурации рискованно: скорость зависят от модели, квантования, бэкенда и железа. Про то, во сколько обходится облачным агентам работа с кодом и как уложиться в лимиты подписки, у нас есть отдельный разбор - оркестрация моделей и оптимизация кодовой базы при лимитах Codex.
Баланс настойчивости агента: opencode против hermes agent и pi
Самое полезное наблюдение в кейсе касается не модели, а обвязки. С той же моделью и тем же бэкендом hermes agent и pi оказались слишком настойчивы: выбирали следующий шаг без проверки, уходили в сторону, и их приходилось возвращать. opencode автор считает лучше сбалансированным и более похожим на Codex, что для него, по его собственным словам, высокая похвала.
За этим стоит вполне измеримое свойство, которое можно назвать балансом настойчивости. Агент должен идти вперёд без постоянных вопросов, но проверять результат перед следующим шагом. Перекос в любую сторону ломает работу: слишком осторожная обвязка заставляет подтверждать каждую мелочь, слишком настойчивая начинает перестраивать то, о чём её не просили. На данных, где ошибка в сопоставлении студентов и оценок стоит дорого, второй перекос заметно неприятнее.
Оценка субъективная, и автор сам допускает, что замечание про hermes agent и pi может объясняться его навыками работы с этими инструментами. Это мнение одного пользователя на одной задаче, а не рейтинг обвязок. Проверять стоит на своём сценарии: один и тот же промпт, одна и та же модель, разные обвязки, и смотреть, сколько шагов агент делает без проверки.
Где ограничения: VRAM, доступность моделей и настройка песочницы
Главное ограничение автор называет прямо: нехватка VRAM. Его формулировка про будущее звучит так: если бы не дефицит видеопамяти, у всех была бы «достаточно хорошая» локальная LLM на своём железе, а 64-128 ГБ VRAM стали бы стандартом. Это оценка перспективы, а не требование конкретно к Qwen 3.8 FN: цифр потребления памяти для описанного стека в источнике нет.
Дальше идут ограничения, которые видны из описания, но не вынесены в отдельный список. Настройка Docker-песочницы и прав доступа требует времени, и делать её нужно до того, как агент получит доступ к реальным данным. Набор инструментов узкий: веб-доступ, python, pypdf, libreoffice, pip install в venv. Доступность конкретных моделей и бэкендов зависит от окружения, формата весов и поддержки со стороны вашего GPU. И есть инфраструктурный слой, который легко упустить: у агентных сценариев узким местом может стать не GPU, а CPU, что мы разбирали в кейсе про 25 агентов на RTX 5090, которые зависали на tool call.
Что делать, если VRAM не хватает
Кейс не даёт ответа, какая конфигурация минимально достаточна, поэтому вариантов несколько, и у каждого есть цена. Уменьшить масштаб задачи: работать не с полным набором данных, а с одной таблицей за раз, но тогда часть выигрыша от сквозной сборки пропадает. Взять более компактную модель или более агрессивное квантование: память освободится, качество на грязных данных может просесть, и проверять это придётся самому. Арендовать железо: память перестанет быть проблемой, а вместе с ней уйдёт и аргумент про данные, которые не покидают диск.
Общие ориентиры по памяти, KV-cache и стоимости инференса при выборе модели для локального ПК мы собирали в разборе о том, почему отставание DeepSeek от Qwen и GLM может выглядеть иначе при других условиях запуска.
Кому подходит локальная модель вместо облака
Критерии применимости прямо следуют из кейса. Первый: есть персональные данные или требования вроде GDPR, из-за которых облачный инструмент закрыт. Второй: задача связана с обработкой файлов и данных, а не с генерацией текста ради текста - сборка, сопоставление, приведение форматов, генерация документов. Третий: есть железо с достаточным объёмом VRAM, пусть даже с оговорками. Четвёртый: есть готовность настроить песочницу и ограничить права агента, а не запускать его с доступом ко всему диску.
Обратная сторона тоже понятна. Если данные нечувствительны, облачный агент проще: не нужно поднимать бэкенд, следить за памятью и собирать контейнер. Если железа нет, локальный стек превратится в борьбу с VRAM, и время, сэкономленное агентом, уйдёт на тюнинг квантования. Для команд, где такие задачи повторяются, локальные LLM для бизнеса имеют смысл именно как инфраструктура с предсказуемым контуром данных, а не как способ сэкономить на подписке.
Что этот кейс доказывает, а что нет
Доказывает он немного, но полезного. Локальная связка из модели, агентной обвязки, инференс-бэкенда и песочницы способна закрыть полный цикл обработки приватных данных: прочитать разнородные CSV, собрать базу, сгенерировать документ. Схема рабочая, права в контейнере продуманы, инструменты подобраны под задачу.
Не доказывает он гораздо больше. Замеров нет, конфигурация железа не раскрыта, сравнение с Codex по скорости остаётся наблюдением. Автор не утверждает, что Qwen 3.8 FN лучше frontier-моделей: он говорит, что на этой конкретной задаче не считает её хуже. Сравнение обвязок - субъективная оценка одного пользователя, который сам допускает влияние своих навыков. И весь сценарий собран вокруг одной задачи, одного набора данных и одного семестра.
Практическая польза кейса в другом: это готовый шаблон архитектуры и список требований. Модель в изолированном контейнере, read-only входы, запись только в workspace, минимум инструментов, повторяемая пересборка из источников. Воспроизводить стоит именно схему, а не выводы: подставьте свои данные, свои критерии качества и измерьте, сколько шагов агент делает без проверки, сколько времени экономит и что происходит, когда входные CSV снова поменяют формат.