Практическая инфраструктура учебного CAD-agent стенда ТГУ

Дата среза и проверки URL: 30.10.2026 (UTC). Статус: проект архитектуры и sizing assumptions, не спецификация закупки, не испытанный стенд. Цены, наличие оборудования, лицензий ТГУ и договорная доступность API не установлены. Числа проектного sizing ниже не являются vendor minimum, результатами benchmark или обещанием производительности.

Основания: рамка и РПД, CAD-подходы, валидация и безопасность, учебный CAD-only пилот. Изучение контекста и официальных страниц выполнено кабинетно; установка CAD, запуск макросов и нагрузочные испытания не проводились.

1. Решение в одном абзаце

Основной контур — КОМПАС-3D на выделенных Windows workers с узким API-адаптером; T-FLEX CAD — отдельный Windows/.NET adapter, а не режим того же COM-адаптера. Общие Linux-сервисы обеспечивают оркестрацию, модельный шлюз, очередь, хранение и независимые проверки. CadQuery/FreeCAD на Linux полезны для открытых воспроизводимых упражнений и проверки нейтральной геометрии, но не заменяют требуемую РПД нативную историю КОМПАС/T-FLEX и оформление ЕСКД. Старт — один исполнитель, одна безопасная учебная деталь, один записывающий процесс на документ; масштабировать после измерения очереди, CAD rebuild и inference, а не сразу покупать «GPU на 24 студента».

2. Архитектура и границы доверия

2.1. Общий control plane, два разных execution plane

Учебная сеть: браузер студента / преподавателя
       │ HTTPS + SSO, course_id / student_id / task_id
       ▼
Orchestrator: state machine, требования, human gates, бюджеты
       ├── Model gateway ──┬── разрешённый договором API (egress proxy)
       │                  └── local inference в отдельной GPU-сети
       │                      (без прямого доступа к CAD/файлам студентов)
       ├── DB: состояние заданий / очередь / leases / лимиты
       ▼
Typed tool gateway: JSON Schema + RBAC + revision + units + operation_id
       │  аутентифицированные ограниченные задания, не shell-команды
       ├──────── Windows execution VLAN ──────────────────────────┐
       │    W1: isolated Windows user/session/VM                  │
       │        signed Python adapter → КОМПАС API5/API7 → CAD    │
       │    W2: isolated Windows user/session/VM                  │
       │        C# bridge → approved .NET plugin → T-FLEX Open API│
       │    watchdog/heartbeat вне CAD; по одному writer на lease │
       └──────── Linux execution VLAN ────────────────────────────┤
            одноразовая VM / hardened sandbox                    │
            Python → CadQuery/OCP или FreeCAD worker              │
            read-only inputs; private scratch; ограниченный output│
                                                                ▼
                 Artifact ingest → native + STEP + manifest/hash
                                      │
                                      ▼
              Validator (другой процесс, read-only исходник)
              native rebuild/constraints + B-rep/dimensions + change tests
                                      │
                                      ▼
              неизменяемый отчёт → human approval → accepted revision

Это предлагаемая схема, а не утверждение о готовом интегрированном продукте. Windows и Linux workers не получают ключ внешней LLM. CAD-workers не имеют общего доступа к интернету, производственному PLM, CAM, станкам, USB или реальному БАС. Лицензионному серверу, если он требуется, разрешают только документированный трафик; его отказ не должен разрешать обход проверки лицензии.

2.2. Основной Windows worker: КОМПАС

• Подготовленный образ Windows с конкретным CAD build, SDK/type libraries, Python и совместимыми модулями. Официальный курс АСКОН подтверждает Python, API5/API7 и установку модулей через КОМПАС-Макро [S4]. Применимость к версии и редакции ТГУ проверяется smoke test, а не предполагается.
• На пилоте выделенный физический ПК — часто проще VM: исключает ранний риск виртуального OpenGL/USB-ключа/удалённого desktop. VM допустима после проверки лицензирования, GPU/драйвера, удалённой сессии и API. Windows-контейнер не считать автоматической заменой desktop CAD.
• Служба broker получает задания; adapter работает от непривилегированной выделенной учётной записи в её CAD-сеансе. Не предполагать, что desktop COM корректно работает из Windows Service Session 0. Порядок запуска COM, потоковая модель, видимость CAD, разрядность, локаль и reconnect проверяются на установленном build.
• Worker не подключается к случайно открытому документу преподавателя. Перед каждой задачей проверяет owner/session/PID и пустое ожидаемое состояние; создаёт копию шаблона. В штатном варианте один CAD process обслуживает один lease последовательно. При ручном редактировании студентом agent lease снимается; после правки заново читается revision.
• CAD может показывать модальные окна: broker распознаёт зависание по heartbeat, сохраняет диагностику, прекращает задание и восстанавливает чистую сессию. GUI automation — только контролируемая диагностика/резерв, не основной контракт.

2.3. Отдельный Windows worker: T-FLEX .NET

Официальный пример версии 17 — C# StarsPlugin, Open API, сборка DLL через Visual Studio с workload «Разработка классических приложений .NET», подключение приложения к CAD [S6]. Это не доказательство поддержки произвольного современного .NET runtime, headless server или совместимости с API другой версии.

Предлагаемый путь: typed JSON request → C# broker → локальный IPC с ACL → заранее собранный/утверждённый plugin → CAD API. Точную версию .NET, target framework, thread affinity, способ подключения и допустимую подпись плагина определить по SDK установленного CAD. LLM не перекомпилирует и не подменяет DLL в Program во время занятия; административная установка — операция администратора образа. Отдельная очередь tflex-version-X, отдельный golden corpus и native validator.

На текущей общей странице требований T-FLEX упомянут Astra Linux/Wine [S5]. Это существенно, но не подтверждает паритет .NET/Open API, лицензирования и поведения worker под Wine. Такой контур — отдельный compatibility spike, не основной Windows backend и не открытая Linux-альтернатива.

2.4. Open Linux: CadQuery / FreeCAD

Task/spec + pinned script/template
      ↓
одноразовая Linux VM (либо проверенный hardened container для trusted templates)
      ├─ CadQuery + OCP/OCCT: headless script → STEP + исходник/параметры
      └─ FreeCAD: native document tree → FCStd + STEP + macro/параметры
      ↓
fresh-process recompute → geometry checks → perturbation → report

CadQuery официально отделяет библиотеку от GUI; поддерживает Linux и параметрический Python [S7–S8]. Для MVP предпочтительны фиксированные функции-шаблоны с параметрами; произвольный сгенерированный Python требует более сильной изоляции, чем обычный virtualenv. FreeCAD подтверждает Python, native history и OCCT [S9]; headless-поддержка каждого используемого workbench/exporter должна пройти собственный тест. Функцию, зависящую от GUI/драйвера, не выдавать за гарантированно headless; рендер вынести в отдельный процесс.

CadQuery и FreeCAD оба используют Open CASCADE [S7, S9]: это две оболочки, не два независимых ядра. Проверка STEP открытым backend дополняет исходный CAD rebuild, но не доказывает сохранение нативного дерева или абсолютную независимость проверки.

3. Минимальные сервисы и tool contract

Предлагаемый контракт (не существующий CAD-стандарт):

{
  "schema_version": "1",
  "task_id": "course-example-001",
  "document_id": "doc-001",
  "expected_revision": "sha256:...",
  "operation_id": "unique-op-0007",
  "backend": "kompas-approved-build",
  "tool": "set_parameter",
  "arguments": {"name": "wall_thickness", "value": 2.0, "unit": "mm"}
}

Gateway проверяет, что параметр разрешён ТЗ, размерность/диапазон допустимы, документ принадлежит задаче, revision актуален. Ответ содержит status, новый revision, фактические измерения, CAD error code, diagnostics и artifact IDs, а не произвольные локальные пути. operation_id и ledger устраняют повторную мутацию при повторной доставке; один ID с другим payload — конфликт. Сетевой timeout не означает, что операция не состоялась: сначала запросить статус, затем решать о повторе. Нет обещания «exactly once» через сеть: нужны reconciliation и checkpoint.

Allowlist MVP: inspect_document, create_from_template, set_parameter, узкий набор sketch/features, recompute, measure, save_checkpoint, export_allowed_format. Запрещены general shell/exec, произвольные COM ProgID, загрузка plugin, сетевой URL и путь за пределами task root. При необходимости расширения операций меняют подписанную конфигурацию, тесты и версию gateway, не prompt.

Validator: измеряет реальную геометрию, не только входные переменные; проверяет rebuild, число solids, отверстия/габариты/стенки по ТЗ, единицы, constraints, экспорт и perturbation. ЕСКД/чертёж/спецификация — отдельная ручная/автоматизированная рубрика. Агент не может менять acceptance suite или снять fail. Human approval привязывается к hash; после правки аннулируется. Подробная методика — отчёт о валидации.

4. Официальные system requirements — отдельно от sizing стенда

Ниже только содержание официальных страниц, открытых web_fetch 30.10.2026. Copyright не трактуется как дата публикации; общая страница без номера версии не доказывает требования конкретного установленного продукта.

5. Проектные sizing assumptions: 1 / 12 / 24 студента

5.1. Допущения и единицы ёмкости

Все конфигурации в этом разделе — проектные sizing assumptions для учебной детали и сборки 2–3 деталей, не vendor minimum. Нет FEA/CFD, фотореалистичного рендеринга или сборки на тысячи компонентов. Один активный student session имеет свою рабочую копию и историю. Один worker slot — один исполняющийся CAD-сеанс, не один студент в списке группы. Chat concurrency, CAD concurrency и GPU batch concurrency — разные величины.

Рекомендуемый экономный учебный старт: 12–24 студента объединяются в 3–8 команд (конкретный размер команды задаёт преподаватель); начать с 2 физических workers и очереди, предварительно измерив профили 1/2/4 одновременно исполняемых задач. Это не 12/24 индивидуальных одновременных CAD-сеанса: один team lease, видимая очередь и отдельная индивидуальная защита. Таблица ниже показывает следующий capacity-planning шаг для индивидуальных student sessions; её 4/8 queue slots не обязательная стартовая закупка. Для рабочего ПК профиль 6–8 современных физических ядер / 32 ГБ RAM / NVMe 1 ТБ — проектная гипотеза, уточняемая тестом; 8 ядер ниже — один вариант этого диапазона.

Первичный профиль слота: Windows desktop CAD — 4 vCPU/16 ГБ RAM, 80 ГБ системного тома + 20 ГБ scratch, tested discrete/vGPU OpenGL profile с 4 ГБ VRAM на слот как стартовая гипотеза; Linux CadQuery/FreeCAD headless — 2 vCPU/8 ГБ, 20 ГБ scratch, без GPU для geometry-only. CPU преимущественно высокой однопоточной производительности; деление на vCPU — бюджет, а не гарантия параллелизма геометрического ядра. Для физического Windows pilot разумный проверяемый профиль: 8 современных физических ядер, 32 ГБ RAM, discrete GPU 4–8 ГБ, NVMe 1 ТБ. Для сложных учебных моделей поднять лимит и повторить тест.

Это альтернативы, не требование одновременно купить classroom ПК и VDI-серверы. Windows/T-FLEX/КОМПАС pools можно разделять; число слотов каждого зависит от расписания, не складывается автоматически по числу всех продуктов. Если учебный сценарий использует открытый backend вместо Windows исполнения, 12/24 одновременно работающих headless slots дают соответственно 24/48 vCPU и 96/192 ГБ guest RAM, плюс запас хоста/контрольные сервисы. Это не native КОМПАС capacity.

Для VM-хостов резервировать первоначально 20–25% RAM/CPU сверх guest allocation и не обещать p95 при произвольном CPU overcommit. Гипотеза хоста на 12 Windows slots: 32–48 физических ядер, 256–384 ГБ RAM, NVMe 2×2 ТБ mirror для системы/VM; для 24 — два таких хоста с распределением 12+12. Mirror — отказоустойчивость диска, не backup и не HA хоста. Для переживания потери одного хоста без очереди оставшиеся хосты, GPU и лицензии должны вмещать весь admitted load: обычная схема 12+12 этого не гарантирует. vGPU/passthrough и VRAM нельзя валидно «разделить на число студентов» без проверки профилей/драйверов/лицензий; при сомнении выбрать физические workers.

5.2. Очередь, сеть и хранение считаются по измерениям

Пусть N студентов, средний цикл запросов одного студента Tcycle минут, занятость CAD на задание S минут. Предварительно λ = N / Tcycle, ρ = λ × S / c, где c — workers одного backend. Стартовая цель ρ ≤ 0,7 — проектный запас, не доказанная гарантия latency. Пример: если измерятся Tcycle=10, S=2, то 12 студентов/4 слота дают ρ=0,6, 24/8 также 0,6. Но синхронный старт 24 задач по 2 минуты на 8 слотах — три волны, последний старт примерно через 4 минуты. Значит экономный профиль не обеспечивает мгновенный старт всему классу; нужно разнести действия по методике либо увеличить слоты.

Сеть — проектная гипотеза: проводной 1 Гбит/с к workers/местам; 10 Гбит/с uplink хранилища/VM-хостов для класса 12/24. Не потому, что текстовые prompts требуют 10 Гбит/с, а из-за одновременной загрузки образов/STEP/checkpoints. Если 24 студента передают по 100 МБ за 30 секунд, payload ≈640 Мбит/с без overhead: на общем 1 Гбит/с uplink мало запаса. Для VDI отдельно измерять bandwidth/p95 RTT/packet loss при вращении модели; гипотеза целевого campus RTT <20 мс, не vendor limit. Для внешнего API нужны устойчивый TLS/DNS, допустимый endpoint, договорные TPM/RPM; требуемую интернет-полосу считать из bytes per request, а не числа GPU. В restricted/local режиме интернет во время занятия не нужен, но это проверяется отключением uplink.

Хранилище: Vprimary = N × jobs_per_student × retained_revisions × mean_artifact_size + traces + reference_corpus + images/weights, затем запас свободного места. Например, не измерено: 24×10 задач×20 ревизий×50 МБ ≈240 ГБ на одну учебную кампанию до журналов/копий; несколько групп быстро превышают это. Usable 2/4 ТБ выше — начальный бюджет, не расчёт по реальным данным ТГУ. Полные VM images, backups и реплики считаются отдельно. Алерт свободного пространства 20%; quota на студента/задачу; скриншоты и mesh previews имеют отдельную политику retention.

6. Выбор модели: API против local inference

6.1. Не выбирать модель только по общему coding benchmark

Проверять на собственном закрытом наборе CAD-задач: русскоязычные ТЗ, mm/inch, неоднозначности, нужный SDK, корректность tool JSON, отказ от выдуманных размеров, исправления по solver errors, работа с ограниченным контекстом. Сравнить approved API и local model при одинаковом suite/лимитах; измерять accepted-native-result rate и полную цену принятой задачи. VLM для скриншотов — необязательный дополнительный режим; размеры брать из CAD API.

Проверенный конкретный географический риск: в официальном списке стран OpenAI API, прочитанном 30.10.2026, РФ отсутствует; страница предупреждает о возможной блокировке/приостановке при доступе вне списка [S13]. Поэтому этот сервис не гарантированный baseline для ТГУ. Прокси/посредник не отменяет условий и риска передачи КД; обход не предлагается. Доступность иных API здесь не доказана и не отрицается без проверки.

«Не обучаем на API-данных» ≠ «не храним данные». Например, OpenAI отдельно описывает default abuse monitoring до 30 дней, состояние некоторых endpoints и одобряемые режимы ZDR [S14]. Это иллюстрация необходимости endpoint-specific проверки, не рекомендация сервиса для РФ. Эти условия нельзя переносить на другого провайдера или consumer-подписку.

6.2. Локальный inference: размер памяти — не throughput

Следующие параметры — проектные sizing assumptions для pre-pilot, не vendor minimum и не доказательство вместимости конкретных weights:

• Эксперимент 1 пользователя: отдельный Linux узел 16 физических CPU cores, RAM 64–128 ГБ, GPU 16–24 ГБ VRAM (24 ГБ — более свободный стартовый бюджет), NVMe 1–2 ТБ; начать с модели класса 7–14B в допустимой квантовке и ограниченного контекста. Этот узел не совмещать с CAD GPU.
• Класс 12/24: сначала один узел GPU 48 ГБ либо 2×24 ГБ, CPU 24–32 cores, RAM 128 ГБ, NVMe 2 ТБ для capacity experiment, а не обещание 24 одновременно быстрых ответов. Модель и квантовка могут не поддерживать выбранный runtime; две GPU не образуют автоматически один 48-ГБ пул. Использовать отдельную очередь inference и проверенное batching/parallelism. Число replicas определяется токенами/сек и p95 на реальном контексте.
• Весовая оценка dense модели: Mweights ≈ parameters × bits/8. Для 14B/4-bit это ≈7 ГБ десятичных до metadata/scales/runtime/KV/активаций, для 32B — ≈16 ГБ; не основание обещать fit в 8/16 ГБ. VRAM_total ≥ weights + KV_cache(concurrency, context_length, architecture) + activations/workspace + safety_margin. Для MoE и multimodal использовать архитектуру модели, не подставлять число «активных» параметров вместо всех хранимых weights.
• Зафиксировать max context, max output, max concurrent sequences, quantization, cache dtype и runtime build. CPU offload может вместить модель, но не гарантирует учебную latency. При overflow — очередь/явный отказ, не скрытое переключение на внешний API.

Проверяемая потребность: output_tokens_per_second_needed ≈ N × requests_per_minute_per_student × mean_output_tokens / 60; отдельно считать prefill input tokens и burst. Например 24×0,5×1000/60 = 200 output tokens/s aggregate как гипотеза спроса, не скорость предложенной GPU. Длинный context и tool-call round trips увеличивают задержку; локальная система может быть экономически и педагогически хуже approved API либо template-first. GPU закупать после измерения, не по этой формуле одной.

7. Лицензии, РФ, КД/IP и права доступа

7.1. Procurement checklist до масштабирования

1. Инвентаризация: редакция/build КОМПАС/T-FLEX, serial/entitlements, доступ к SDK, импорт/экспорт и библиотеки, сроки поддержки, точный тип Windows/VDI.
2. Письменная проверка у лицензиара: академическое использование, автоматизация API/unattended jobs, число одновременно используемых CAD-инстансов, shared server/VM/remote desktop, физические ключи/vGPU, преподавательские/резервные места. 24 студента ≠ автоматически 24 разрешённых daemon workers, а пустой запущенный сеанс может удерживать seat.
3. Если validator повторно открывает native CAD, учесть дополнительный seat/таймслот; не брать CAD seat на весь LLM think time без необходимости, но освобождение лицензии делать только штатным подтверждённым способом.
4. Официальная T-FLEX академическая страница говорит об образовательных организациях, бессрочной лицензии, прямой поставке и запросе предложения; возможность специальной цены/бесплатной поставки не доказывает конкретное предложение ТГУ [S12]. Бесплатную учебную/домашнюю версию не считать эквивалентом вузовской сетевой лицензии или разрешения серверной автоматизации.
5. CadQuery: Apache-2.0 [S11]; FreeCAD core: LGPL2+ по официальной wiki, модули/зависимости проверяются отдельно [S15]. Лицензия CAD не даёт автоматически прав на импортированные модели/шрифты/каталоги/учебные материалы. Open source не означает нулевых расходов поддержки или гарантии загрузки из РФ.
6. Для локальной LLM проверить license конкретных weights и ограничения использования/redistribution, не только лицензию inference server. Архивировать разрешённые installers/packages/weights и hashes в вузовском mirror; не полагаться на живой GitHub/pip во время урока. Покупка GPU/поддержки/облачного API — только после актуальных предложений, без предположения о цене, наличии или санкционной допустимости.

7.2. Передача конструкторской документации и студенческих данных

Классы данных — предлагаемая политика, согласуемая с ТГУ:

• Public/synthetic: учебная синтетическая геометрия без персональных данных и стороннего IP — кандидат для approved API.
• Internal teaching: ФИО, оценки, индивидуальные следы работы, непубличные задания — хранить в утверждённом вузовском контуре, наружу только после согласованной минимизации/правового основания.
• Restricted IP/KD: партнёрская/договорная КД, непубличные сборки, sensitive metadata — local-only до письменного решения владельца данных и ИБ/юриста; некоторые данные могут быть вообще исключены из стенда.

Отправка prompt тоже может быть передачей КД: размеры, текст спецификации, скриншот, BOM и извлечённая «обезличенная» геометрия раскрывают замысел. Передача STEP — не безопасная анонимизация. Не включать секреты в CAD properties; gateway не даёт модели доступ к домашним папкам/почте. До API выяснить место обработки/хранения, subprocessors, retention/delete, использование для обучения, условия поддержки/инцидентов, применимые требования по ПДн и договорные/экспортные ограничения. Это checklist для профильного решения, не юридическое заключение о законности конкретной передачи.

SSO/RBAC: студент — только свои задачи; преподаватель — назначенный курс; validator — read-only артефакты, write-only отчёты; worker — конкретный task root; оператор — обслуживание без права менять оценку; владелец КД — разрешение передачи/публикации. Ключи API — серверные из secret store, не в браузере/логах/CAD image; scoped service credentials и ротация. Egress firewall deny-by-default, артефакты проходят ingest, а не открытый общий SMB для всех. Инъекции в PDF/STEP properties не меняют эти полномочия.

8. Versioning, журналы, backup, rollback и обновления

8.1. Что хранить

На run_id: task/spec version/hash, owner/course/data class, CAD/kernel/SDK/OS/driver builds, worker image digest, model ID/weights hash/provider snapshot и inference settings, gateway/test-suite version, inputs и параметры, tool trace и ошибки, все retries/стоимость, native и STEP, numerical report, previews, human approvals. Не нужны скрытые рассуждения модели; нужны наблюдаемые действия. Секреты редактируются; часы серверов синхронизируются, latency измеряется monotonic clock.

Текстовые спецификации/scripts/tests — versioned repository (Git возможен; в данной работе коммитов нет). Native CAD/экспорты — immutable object IDs либо versioned file store с hash manifest; большие бинарные файлы не считать удобным текстовым diff. DB хранит связи requirement → operation → revision → test → approval, но DB запись сама по себе не backup артефакта. Наблюдаемость: очередь по backend, возраст jobs, свободные seats, heartbeat/CAD modal stalls, CPU/RAM/VRAM/scratch, latency, API 429/timeouts, стоимость/курс/студент, validator failures. Содержимое КД не помещать в metric labels; detailed traces имеют более узкий доступ.

8.2. Три разных восстановления

• Rollback CAD-задачи: checkpoint перед мутацией; при fail закрыть disposable copy и восстановить последнюю валидную revision. Не доверять только GUI Undo после crash; external artifacts сохраняются атомарно через temporary → hash check → publish. Старый approved документ не перезаписывается.
• Recovery worker/service: золотой образ, watchdog, пересоздание clean session; expired lease переводится в needs_reconciliation, а не слепо исполняется повторно. Можно повторить committed input, но не автоматически выпустить результат без validator.
• Backup/DR: независимая копия DB+артефактов+конфигурации/тестов/образов, вне той же машины и прав worker. Snapshot VM/RAID/реплика в той же учётной записи не достаточная независимая копия. Шифрование at rest/in transit, отдельные backup credentials, offline/immutable копия по политике ИБ, ключи восстановления отдельно.

Проектные эксплуатационные цели, утверждаемые до пилота: принятые артефакты фиксируются до подтверждения сдачи; промежуточные сохраняются каждые ≤5 минут; backup DB/metadata каждый час, artifacts ежедневно и при завершении занятия; исходная цель DR RPO ≤24 часа для полной площадки, RTO ≤1 рабочего дня. Это не обещание RPO=0: если требуется не терять принятую сдачу при потере площадки, перед ack нужна независимая durable копия/реплика и измеренный DR-тест. Worker recovery целевой ≤5 минут, при отсутствии spare возможна очередь. Retention-гипотеза: рабочие traces 90 дней, принятые учебные артефакты один учебный год; фактические сроки определяют требования аттестации, договоры и политика ПДн, не этот документ.

Перед первой группой восстановить случайную задачу и целую связку DB+artifact store на чистом узле, открыть native CAD и проверить hashes/approval links. Повторять тест восстановления после существенного изменения и по согласованному календарю; наличие зелёного backup job без restore не доказательство.

8.3. Обновления без срыва занятия

Образы dev → staging → canary → classroom; freeze на занятие/измерительный пилот, без pip install latest от агента и непроверенных add-ons. Патчи ОС/драйвера/CAD/API/модели — разные change requests с владельцем и smoke/regression suite: создание/открытие, rebuild, размерные и change tests, STEP round-trip, лицензия/reconnect, изоляция. Критическое обновление ИБ может требовать приостановки режима, а не бесконечного откладывания ради freeze.

Rollback обновления — предыдущий образ и совместимая схема DB/конфигурации. Перед миграцией сохранять backup, для форматов native CAD проверять обратную совместимость: файл, сохранённый новой CAD, может не открыться старой. Старый оригинал хранить, reverse migration не обещать. Изменение API model alias — изменение экспериментальной конфигурации; если snapshot недоступен, явно отмечать потерю точной воспроизводимости.

9. Измеряемый load test вместо обещания «24 места работают»

Это проект протокола, не результаты теста. До закупки/масштабирования запускать отдельно CAD replay (детерминированные операции), отдельно model serving, затем полный агентный цикл. Так CAD crash не маскируется средней token throughput.

Набор и режим

1. Заморозить версию и хэши 10 учебных заданий: параметрический корпус/кронштейн, изменение размеров, сборка 2–3 деталей, native drawing/export; включить валидные/дефектные fixtures. Указать, какие features реально поддерживает adapter. Один публичный warm-up, остальные не подгонять под единственный удачный run.
2. Проверить 1, затем 12, затем 24 раздельных student identities: (а) synchronized burst; (б) staggered think time 30–120 с как гипотеза; (в) очередь экономного числа slots; (г) full-concurrency, если заявлена. Worker count/seat count не менять скрыто между сравнениями.
3. На каждой конфигурации три прогона по 45 минут после 10-минутного warm-up; отдельно cold start и двухчасовой soak с повторными открытиями. В каждом профиле собрать минимум 100 завершённых/отказавших job attempts суммарно либо увеличить длительность; публиковать реальный n, p50/p95/max и uncertainty, не только среднее. Для teacher timetable далее согласовать академическую длительность занятия отдельно.
4. Трасса: enqueue/start/LLM prefill/output/tool/CAD rebuild/export/validate/approval; end-to-end без включения ручной защиты и отдельно полное время с человеком. Записывать число tokens и bytes, RAM peak, VRAM/KV, CPU saturation, disk latency/free space, сетевой RTT/loss, seats in use, retries и terminal errors.
5. Fault injection на тестовом corpus: остановка CAD процесса; потеря связи после мутации до ответа; повтор operation ID; worker reset; недоступный license server; API 429/timeout; заполнение scratch; отключение внешнего интернета; попытка чтения чужой задачи/egress. Не атаковать внешние системы и не использовать реальные секреты.

Предлагаемые pass/fail ворота

Semantic CAD acceptance определяется проверенными требованиями, не облегчается ради throughput. Нулевая утечка в тесте не доказывает отсутствие всех атак; 99% при малом n не доказательство будущего SLA. Если критерии не выполнены — уменьшить admitted concurrency/контекст, добавить workers/replicas/seats, изменить расписание или backend; повторить тот же suite. Не лечить дефицит лицензий дополнительной GPU.

10. TCO без выдуманных цен

Считать за единый горизонт H (семестр/год) в одной валюте и ценах одной даты, показывать actual quotes отдельно от assumptions:

TCO(H) = amortized_CAPEX(H)
       + CAD/API/OS/VDI/vGPU/support licenses(H)
       + API_tokens_and_other_metered_usage(H)
       + electricity + cooling + network + storage + backup(H)
       + setup_and_integration_hours × loaded_rate
       + operations_and_teaching_support_hours × loaded_rate
       + validation_and_rework_hours × loaded_rate
       + measured_downtime_cost(H)

APIcost = Σrequests (Tin × Pin + Tout × Pout + cache/image/other charges)
          # единицы тарифов, дата, налоги/FX из реального предложения

Energycost = measured_average_kW × operating_hours × local_tariff
Caccepted = TCO_allocated_to_pilot / number_of_independently_accepted_tasks
Cstudent_hour = TCO_allocated_to_teaching / delivered_student_hours

Если CAPEX уже амортизирован, не добавлять его полную сумму второй раз. Для существующего classroom оборудования показать marginal cost и full economic cost отдельно; для shared GPU распределять долю времени/резервируемой мощности, включая idle в часы доступности. В API считать все попытки, retrieval, checker calls и retries, не только принятый ответ. Для local считать weights/runtime support, драйверы, простоевшую мощность и труд администратора; open weights не означают нулевой inference cost. Caccepted при нуле принятых задач не определён.

Сравнительная таблица закупки должна иметь строки «1 / 12 / 24 students», queue/full service level, количество CAD seats/workers/model replicas, measured acceptance/latency, upfront quote и годовой OPEX. Break-even API/local решать при одинаковом качестве/latency/data policy: большой объём токенов сам по себе не оправдывает локальную модель с низким native acceptance. Чувствительность: число групп и уроков, средняя длина контекста, repair rate, teacher support time, срок службы GPU, недоступность API и CAD license bottleneck. В этом обзоре денежных оценок нет.

11. Поэтапный MVP и эксплуатационные роли

Этапы с критериями выхода

1. M0 — аудит и разрешения. Установленные versions/licenses/seat count; owner курса/КД; data classification; approved model options; CAD эталон и запрет CAM/flight. Выход: подписанный паспорт стенда и проверенный вручную native пример. Если нет разрешения API/VDI — не строить на предположении.
2. M1 — детерминированный worker на 1 место. Один Windows КОМПАС worker, одна деталь из утверждённого шаблона, typed tools, save/rebuild/measure/export; без LLM проверить idempotency, crash и rollback. Выход: replay на чистом окружении и restore тест.
3. M2 — один bounded агент. Orchestrator, approved API либо local endpoint; бюджеты/три repair attempts как начальная политика, human gates, immutable validator, аудит расходов. Выход: замороженный suite, честная доля отказов, нет нерешённого критического security fail; учебный pre-pilot.
4. M3 — 12 студентов. Scheduler fairness, 4 slots queued или 12 full согласно измеренному SLA и лицензиям; staging/monitoring/дежурный. Выход: load/fault test и первая учебная группа с индивидуальной защитой. Не утверждать pedagogical effect по инфраструктурному тесту.
5. M4 — 24 студента. 8 queued либо 24 full после теста; backup/DR exercise, обновления/rollback, подтверждённые ресурсы сопровождения. Выход: готовность конкретного расписания/числа групп, а не абстрактные «24 лицензии».
6. M5 — дополнительные backend. T-FLEX .NET adapter для соответствующего курса, open Linux для сравнительного эксперимента. Общий tool schema, но собственные capability matrix/native acceptance. Не задерживать основной КОМПАС MVP ради трёх одновременно недоведённых интеграций.

Ориентир планирования, не обещание сроков: M0 1–2 недели; M1–M2 2–4 недели при готовых лицензиях/API и эталоне; M3–M4 — отдельные окна тестирования и занятия. Закупка/юридическое согласование/SDK несовместимость могут доминировать срок. Не делать rollout в день контрольной работы.

Роли и ответственность

В малом пилоте роли можно совмещать, но автор агента не должен единолично принимать его результаты, а оператор не меняет оценки. На каждое занятие назначены дежурный и способ эскалации; операционные действия документированы. Preflight: лицензии/worker heartbeat, свободное место, модель/сеть, контрольная деталь, backup last success, manifest версий. При отказе — сохранённая ручная CAD-задача/детерминированный шаблон с явной маркировкой режима; не скрытый внешний API или демонстрация старого результата как нового.

12. Реестр первичных источников и даты

Все перечисленные содержательные опоры получены через web_fetch 30.10.2026. Дата публикации не указана там, где её не удалось установить; latest/master изменяемы и требуют закрепления версии при реализации.

Границы проверки: URL https://www.freecad.org/license.php вернул 404; лицензия проверена через официальную wiki [S15], не через недоступную страницу. Документация vLLM latest/serving/parallelism_scaling/ открылась как developer preview и длинная навигация; её конкретные performance claims не использованы. Не проверены договоры ТГУ, наличие CAD seats/VDI/API, цены оборудования, доступность оплат/поставок и надёжность конкретных local weights. Поэтому финальное решение — подготовить один измеряемый worker и load suite, а затем уточнить спецификацию по фактическим ограничениям.