05. LLM «мозг» и сайзинг GPU¶

1. Выбор модели (Qwen, актуально на 2026)¶

Один и тот же «мозг» Qwen доступен и как облачный API (старт), и как открытые веса (self-host) — поэтому переход между фазами не меняет поведение агента радикально.

Облачные API-модели (Alibaba Model Studio) — этапы 1-2 (Пилот, Рост). Базовая схема — две модели: - qwen3.6-flash («маленький» дешёвый ярус) — простые операционные задачи: роутинг, классификация, извлечение сущностей, сбор данных, типовые FAQ. Дёшев ($0,25/$1,50 за 1M). - qwen3.7-max («самый умный» ярус) — тяжёлые задачи, где нужны рассуждение и размышление: сложная квалификация, работа с возражениями, нетривиальные решения. Флагман ($1,25/$3,75 промо за 1M). - qwen3.7-plus — опциональный средний ярус ($0,40/$1,60): вводится для оптимизации стоимости, когда качества plus достаточно и не нужен дорогой max. Снижает счёт за LLM (см. 06, §4.2).

Открытые веса Qwen — этап 3 (Масштаб, self-host в РФ: 152-ФЗ / контроль / объём): - Qwen3.6-35B-A3B (MoE, ~3B активных параметров) — основной кандидат в «мозг»: качество уровня крупной модели при дешёвом инференсе по вычислениям. - Qwen3.6-27B (dense, vision-language) — альтернатива под максимальное качество/мультимодальность. - Малые Qwen3.6 (4-8B) — ярус роутинга/классификации.

2. Ярусная система моделей (model tiering)¶

flowchart TD
    msg[Входящее сообщение] --> router{Роутер: простое или требует рассуждения?}
    router -->|простое, операционное ~80%| flash[Маленький Qwen - flash: роутинг, сбор данных, типовые FAQ]
    router -->|тяжёлое, размышление ~20%| brain[Умный Qwen - max: сложная квалификация, возражения, решения]
    flash --> out[Ответ]
    brain --> out

Этапы 1-2: flash и max — это облачный Qwen API. Этап 3: те же роли, но self-host в РФ — малый Qwen 4-8B (flash-роль) + открытый Qwen 27-35B («мозг»); самый тяжёлый «max-уровень» может уходить в облачный qwen3.7-max как burst (обезличенно), т.к. max — проприетарная облачная модель.

Зачем: ~80% сообщений просты (приветствие, уточнение телефона, типовой вопрос) — их незачем гонять через дорогую «умную» модель. Это снижает стоимость и латентность, а дорогую модель включаем только там, где реально нужно рассуждение.

3. Память GPU: сколько занимает модель¶

VRAM = веса + KV-кэш + overhead. Веса (ориентировочно):

Модель	FP16	FP8/INT8	INT4
8B (малая)	~16 ГБ	~8 ГБ	~4 ГБ
27B dense	~54 ГБ	~27 ГБ	~14 ГБ
35B-A3B MoE	~70 ГБ	~35 ГБ	~18 ГБ

Важный нюанс про MoE: активны ~3B параметров на токен (экономия вычислений), но все ~35B экспертов должны лежать в VRAM — по памяти это полноценные 35B. MoE ускоряет инференс, но не уменьшает требования к видеопамяти.

KV-кэш — память под контекст активных диалогов. Растёт линейно с числом одновременных сессий и длиной контекста. Чем больше моделей/крупнее веса на карте — тем меньше VRAM остаётся под кэш → меньше одновременных диалогов.

4. Со-размещение нескольких моделей на одном GPU¶

Да, возможно, если суммарно влезает в VRAM. Способы: - Квантизация (FP8/INT8/INT4) — сжать веса. Пример на 80 ГБ: малая 8B (INT8 ~8 ГБ) + мозг 27B (FP8 ~27 ГБ) + ~40 ГБ под KV-кэш. - MIG (Multi-Instance GPU) на A100/H100 — аппаратно «разрезать» карту на изолированные слайсы, в каждом своя модель. - MPS / несколько инстансов vLLM — деление одной карты процессами (память должна помещаться).

5. Serving¶

vLLM / SGLang с continuous batching — объединение запросов в батчи «на лету» для максимальной пропускной способности.
PagedAttention (в vLLM) — эффективное управление KV-кэшем.
LLM Gateway — маршрутизация по ярусам, батчинг, лимиты/квоты per-tenant, фолбэк на облако.

6. Расчёт нагрузки¶

Профиль одного диалога (лид → показ), допущения¶

Средний диалог: ~15 обращений к LLM (реплики + служебные вызовы).
Вход на обращение: ~2 500 токенов (системный промпт + история + RAG).
Выход на обращение: ~250 токенов.

Оценка пропускной способности¶

Консервативно один H100 (FP8, модель 27-35B, vLLM с батчингом) устойчиво держит порядка 5-8 обращений/сек агрегированно (с учётом длинного prefill-контекста). Это ориентир — уточняется нагрузочным тестированием.

Сайзинг по этапам (по числу тенантов; 30-1000 лидов/день на тенанта)¶

Нагрузка на этапе зависит и от числа тенантов, и от их активности (30 лидов/день — консервативно, 1000 — агрессивно).

Этап	Тенантов	Лидов/день (мин-макс)	Обращений к LLM/день	LLM-инфраструктура
1 — Пилот	1-20	30 – 20 000	~0,5 тыс. – 300 тыс.	Qwen API (flash+max), GPU не нужен
2 — Рост	20-100	600 – 100 000	~9 тыс. – 1,5 млн	Qwen API (flash+max), GPU не нужен
3 — Масштаб	100-1000	3 000 – 1 000 000	~45 тыс. – 15 млн	Self-host: мозг 27-35B + малый Qwen; облачный burst

GPU нужен только на этапе 3, число карт считается динамически по пиковой нагрузке (≈20% дневного объёма в час; H100 ≈ 6 обр/сек «мозг», A10/L4 ≈ 20 обр/сек ярус-0):

Этап 3	Лидов/день	Обращений/день	Пик	GPU «мозг» (H100)	Ярус-0 (A10/L4)
100 тенантов × 30	3 тыс.	~45 тыс.	~2,5 обр/сек	2× (HA)	2×
1000 тенантов × 1000	1 млн	~15 млн	~833 обр/сек	~28× (пул)	~34×

На верхней границе (гиперскейл, ~28× H100) разумны покупка/лизинг железа и мультирегион, а не только аренда. Формула сайзинга — в Excel-модели (лист «Этапы»).

Пиковая нагрузка оценена как ~20% дневного объёма в час пик; реальные коэффициенты уточняются по трафику. Резерв под всплески закрывается автоскейлингом и облачным фолбэком (Ярус 2).

7. Стратегия развёртывания по этапам¶

Пилот / малый масштаб: со-размещение малой + основной модели на одном GPU (квантизация или MIG). Роутер можно вынести на дешёвую L4 или CPU. Цель — минимальная стоимость.
Рост / масштаб: раздельные GPU-пулы под каждый ярус, каждый с автоскейлингом. vLLM выжимает максимум, владея GPU целиком; ярусы имеют разные паттерны нагрузки и масштабируются независимо.

flowchart LR
    subgraph pilot [Пилот]
        g1[1 GPU: малая + мозг co-located]
    end
    subgraph scale [Масштаб]
        pool0[Пул L4: ярус 0]
        pool1[Пул H100: ярус 1]
        cloud[Облачный Qwen: ярус 2 burst/fallback]
    end
    pilot -.рост.-> scale

8. Провайдер-агностичный LLM-слой (перенос за ~час)¶

Принцип: ни один сервис не знает конкретного вендора LLM. Между оркестратором и провайдером — единый LLM Gateway с абстрактным контрактом; вендоры подключаются адаптерами и выбираются конфигом (per-tenant / per-ярус), без изменения кода.

Почему это дёшево реализуется: почти все целевые провайдеры OpenAI-совместимы: - Qwen (Alibaba Model Studio) — эндпоинт .../compatible-mode/v1 (OpenAI SDK «из коробки»). - self-hosted (vLLM/SGLang) — OpenAI-совместимый сервер. - YandexGPT — есть OpenAI-совместимый режим. - GigaChat — собственный REST + OAuth; заворачивается тонким адаптером в общий контракт.

Что фиксирует общий контракт (порт LLMProvider): - chat(messages, tools, structured_schema, max_tokens, temperature) → унифицированный ответ + usage (токены). - Function calling / structured output — общий формат, маппинг на специфику вендора внутри адаптера. - Метаданные: provider, model, tier, стоимость запроса (для юнит-экономики).

Конфигурация вместо кода (пример ярусного роутинга):

llm:
  providers:
    qwen:    { type: openai_compatible, base_url: ".../compatible-mode/v1", api_key: env:QWEN_KEY }
    gigachat:{ type: gigachat, api_key: env:GIGACHAT_KEY }
    selfhost:{ type: openai_compatible, base_url: "http://vllm.internal/v1" }
  tiers:
    t0_router: { provider: qwen, model: qwen3.6-flash }
    t1_brain:  { provider: qwen, model: qwen3.7-plus }
    t2_hard:   { provider: qwen, model: qwen3.7-max }
  fallback: [gigachat, selfhost]      # горячий фолбэк при отказе/лимитах
  pii_masking: true                   # маскировать ПДн перед внешним облаком (152-ФЗ)

Перенос за ~час = смена значений provider/model в конфиге (например, t1_brain.provider: selfhost) + наличие ключей/эндпоинта. Код не трогаем. Для критичных тенантов включается selfhost в РФ, для остальных — облачный Qwen.

8.1. Развилка: managed API vs self-hosted GPU¶

Managed (облачный Qwen/GigaChat/YandexGPT API): быстрый старт, без capex и MLOps, оплата за токены; меньше контроля над данными, трансграничная передача ПДн у Qwen International (152-ФЗ).
Self-hosted (свой Qwen на GPU в РФ): полный контроль и изоляция данных, нет платёжно-санкционных рисков; но capex/DevOps и забота об утилизации.
Рекомендация по этапам: этапы 1-2 (до ~100 тенантов) — облачный Qwen (flash для операционки + max для рассуждений) с маскированием ПДн; этап 3 (100-1000 тенантов) — self-host в РФ, что к этому моменту выгодно и по цене (точка окупаемости ~100 тенантов при дорогом max), и по 152-ФЗ / контролю / латентности. Полные расчёты по этапам, длительности и суммам — в 06-infrastructure-cost-ru-2026.md.

8.2. Маскирование ПДн для облачного LLM (обратимая псевдонимизация)¶

Главный нюанс: буквально «зашифровать» текст запроса нельзя — модель не сможет рассуждать над шифртекстом (AES(«Иван Петров, +7…») для LLM — бессмысленный набор символов, качество ответа рухнет). Поэтому применяем не шифрование содержимого, а обратимую псевдонимизацию (tokenization): ПДн заменяются на семантические плейсхолдеры, сохраняющие тип. Реальные значения не покидают наш периметр в РФ; ответ модели детокенизируется обратно. Для модели плейсхолдеры выглядят как обычные сущности — обмен «незаметен». Настоящее (AES) шифрование применяем там, где оно уместно — к хранению карты соответствий, а не к телу промпта.

Поток (маскирование → облако → детокенизация):

flowchart LR
    msg[Промпт с ПДн] --> det[1. Детекция: regex + NER]
    det --> tok[2. Токенизация: ПДн → PERSON_1 / PHONE_1 ...]
    tok --> vault[(Карта соответствий\nRedis, AES-256, TTL диалога)]
    tok --> send[3. В Qwen уходит только обезличенный промпт]
    send --> qwen[Облачный Qwen]
    qwen --> resp[4. Ответ с теми же плейсхолдерами]
    resp --> detok[5. Детокенизация: подстановка из карты O(1)]
    vault --> detok
    detok --> post[6. Пост-фильтр утечки ПДн]
    post --> out[Ответ в канал / CRM]

Что и чем обрабатываем:

Тип данных	Детекция	Плейсхолдер
Телефон, email, карта, паспорт, ИНН/СНИЛС	regex/checksum (быстро, дёшево)	`[PHONE_1]`, `[EMAIL_1]` …
ФИО, адрес, названия объектов	лёгкая NER-модель (CPU/ярус-0)	`[PERSON_1]`, `[ADDR_1]` …
ID сделки/лида, внутренние коды	правила по схеме	`[DEAL_1]` …

Ключевые правила: - Детерминированность в пределах диалога: один и тот же телефон → один и тот же плейсхолдер (сохраняется кореферентность, модель «понимает», что речь об одном человеке). Карта — в Redis, ключ session_id, TTL = длительность диалога, шифрование at-rest (AES-256, ключ per-tenant через KMS). - Сохранение типа: плейсхолдер несёт семантику («позвоните [PHONE_1]»), поэтому ответ остаётся осмысленным. - Fail-closed: если детектор не уверен или ПДн не поддаётся обезличиванию (скан паспорта) — не отправляем в облако, а роутим на self-host/RU-API (провайдер-агностичный слой это уже умеет). - Пост-фильтр: ответ модели проверяем на «протёкшие» ПДн-паттерны до отправки дальше. - RAG и системный промпт формируем без ПДн; логи/трейсы маскируем тем же движком (mask_in_logs, см. 08).

Производительность и стоимость: токенизация/детокенизация — это regex + hash-lookup по локальному словарю, доли миллисекунды и копейки, крипто-инференса нет; заметного роста числа токенов нет (плейсхолдер ≈ длине имени). Единственная ощутимая статья — NER для ФИО/адресов: лёгкая модель на CPU или ярус-0 GPU (единицы мс). Итог: быстро, дёшево, прозрачно — ровно требуемое поведение.

Где живёт: отдельный компонент PII Redaction / Detokenization внутри LLM Gateway (единая точка перед вызовом внешнего провайдера), включается флагом pii_masking: true из конфига (см. §8). Юридический эффект: в облако уходят обезличенные данные → трансграничной передачи ПДн по 152-ФЗ фактически нет; остаточные риски закрываются согласием и/или self-host для чувствительных тенантов.

Альтернатива — format-preserving encryption (FPE, FF3-1): обратимо и без хранения карты состояния, генерит «правдоподобный» телефон/номер из реального. Годится для строго форматных полей, но хуже для ФИО/адресов и семантики диалога — поэтому по умолчанию выбираем плейсхолдеры, FPE — опционально для отдельных полей.

9. Guardrails на уровне инференса¶

Grounding: ответы только из базы знаний (RAG), запрет «выдумывать» факты (цены, сроки).
Structured output / function calling: критичные действия (назначить показ, создать сделку) — только через инструменты с валидацией.
Подтверждение критичных заявлений (скидки, обещания сроков) по правилам конфига.