Инженерный замер · экономика делегирования

Делегировать bulk-работу на локальную LLM — окупается?

Замер на реальных данных: сколько токенов контекста frontier-модели экономит выгрузка объёмной обработки на локальную Qwen3-Coder 30B — и модель падений: после скольких провалов делегации выгоднее сделать самому.

Метод: solo vs delegated, tiktoken o200k как прокси Данные: 4 реальных файла, 2.5–96 КБ Стенд: RTX 4090 · qwen3-coder:30b Дата: 2026-07-10

Стенд

Железо реального замера

Конфигурация прогона

GPU

RTX 4090 · 24 ГБ

CPU

Core i9-13900KF

RAM

64 ГБ

Runtime

Ollama 0.31.1

Модель

qwen3-coder:30b

Архитектура

MoE · ~3B active

Все числа замера ниже — фактический прогон на этом железе. Токены — tiktoken o200k_base как прокси токенизатора frontier (ratio-надёжен, абсолюты ±10–15%). Конфиги 8 ГБ / 12 ГБ в таблице ниже — расчётная экстраполяция по той же физике, не отдельный прогон.

TL;DR

Три вывода

90–97%

экономия контекста на файлах ≥26 КБ. Наступает рано — не с сотен КБ.

~10 КБ

порог рентабельности. Ниже — solo проще, делегация не окупается.

N = 2

дефолт: два подряд провала → делай сам. Но тип падения важнее числа.

Метод

Что и как меряли

Задача — bulk-обработка (суммаризация лога, извлечение полей, классификация): читать сырой файл целиком в контекст frontier-модели дорого. Альтернатива — локальная модель жуёт файл у себя (0 токенов frontier) и отдаёт компактную JSON-выжимку; frontier видит только выжимку.

solo = весь файл в контекст + инструкция. Стоимость S.

delegated = локальная LLM → JSON-выжимка + обёртка вызова. Стоимость D.

Счётчик: tiktoken o200k_base как прокси токенизатора frontier (точный API-счётчик недоступен без ключа). Для отношения экономии это корректно — solo и delegated меряются одним счётчиком, systematic bias сокращается; абсолюты ±10–15%. Калибровка сошлась: 96 КБ = 27 680 ток ≈ 3.5 симв/ток.

Результат · экономия

Экономия контекста наступает рано

Файл	КБ	solo ток	deleg ток	экономия
текст-карточка	2.5	511	509	0.4%
код-анализ	26.5	6 732	579	91.4%
changelog	50.9	14 225	435	96.9%
JSON-лог	96.4	27 680	1 243	95.5%

Между break-even (~3 КБ) и 90%+ (~26 КБ) — узкая зона. Вывод: делегируй bulk уже с ~10 КБ / ~150 строк, не жди «сотен КБ и тысяч строк».

Поправка к интуитивной прикидке. Ручная оценка давала «мелкий файл → −100% (хуже)», потому что считала стоимость написать helper с нуля каждый раз. В steady-state скрипт написан один раз и лежит в проекте → overhead ≈ 0, мелкий файл выходит в break-even (+0.4%), а не в минус. На крупных файлах реальность оказалась лучше прикидки (95% против ожидаемых 83%).

Результат · деньги

Сколько это в деньгах — Fable, Opus, Sonnet

Экономия — это input-токены (файл в контексте = input; делегация меняет его на компактную выжимку). Долларовая цена = сэкономленные токены × input-цена модели:

$_saved = (S − D) × цена_in / 1 000 000 // за один файл

За один файл — десятые цента. Значимость проявляется в объёме. Ниже — экономия за 1000 файлов одного класса (типичный bulk-прогон):

Файл (×1000)	экон. ток	Fable 5 $10/1M	Opus 4.8 $5/1M	Sonnet 5 $3/1M	Sonnet intro $2/1M
текст-карточка 2.5 КБ	2 тыс	$0.02	$0.01	$0.01	<$0.01
код-анализ 26 КБ	6.15 млн	$61.53	$30.76	$18.46	$12.31
changelog 51 КБ	13.8 млн	$137.90	$68.95	$41.37	$27.58
JSON-лог 96 КБ	26.4 млн	$264.37	$132.19	$79.31	$52.87

Цена растёт с моделью, экономия % — нет. Процент экономии контекста инвариантен к модели (тот же файл, тот же токенизатор); в деньги он превращается по input-цене, поэтому на Fable дороже контекст → делегация окупается вдвое сильнее, чем на Opus, и в 3–5 раз сильнее, чем на Sonnet. Чем дороже frontier — тем ценнее выгрузка на локальную LLM.

×ходыЧисла — за однократное чтение. Пока файл висит в контексте многоходового диалога, input переотправляется каждый ход → фактическая экономия × (число ходов). Делегация выгружает его один раз.
кэшPrompt caching удешевляет повторный input (cached ≈ 10% цены) — это верхняя граница денежной экономии; с активным кэшем разрыв меньше, но выжимка всё равно не раздувает контекст.
прайсInput-цены — публичный прайс Anthropic (снимок 2026-06-24); Sonnet 5 intro $2/1M действует до 2026-08-31. Output здесь не участвует: и solo, и делегация тратят на файл только input.

Прикидка · другое железо

А если карта слабее — что меняется

Замер сделан на RTX 4090 с qwen3-coder:30b. На слабом железе ставят модель поменьше. Две независимые оси, не путать:

Ось $ — frontier-модель. Долларовая экономия зависит только от того, какая frontier-модель платит за контекст (Fable/Opus/Sonnet). Локальная LLM бесплатна — её размер на $-экономию не влияет.

Ось надёжности — локальное железо. Меньше карта → меньше модель → ниже скорость и надёжность выжимки, чуть больше D (±20–30%). Экономия % почти та же.

Проверка пессимизмом (мелкая модель, D×2, JSON-лог): (27 680−2 500)/27 680 = 91% вместо 95.5% — всё ещё 90%+. Порог рентабельности (~10 КБ) и цифры экономии переносятся на 7b/14b почти без изменений.

Параметр	Ноут 3070 · 8 ГБ	Десктоп 3060 · 12 ГБ	Референс 4090 · 24 ГБ
Модель класса	qwen2.5-coder:7b	qwen2.5-coder:14b	qwen3-coder:30b✓ замер
VRAM модели (Q4)	~4.4 ГБ	~9 ГБ	18 ГБ (MoE)
Экономия % (≥26 КБ)	83–94%	88–96%	91–97% ✓
Порог рентабельности	~10 КБ / 150 стр	тот же	тот же
$-экономия / 1000 файлов	одинакова на любом железе — задаётся frontier-моделью (см. секцию «деньги»), не картой
Скорость ген. (оценка)	50–90 tok/s	20–30 tok/s	~34 tok/s
Надёжность выжимки	ниже	средняя	якорь
Дефолт N подряд → solo	1	2	2
Делегировать числа	нет	осторожно, строже валидация	да, со сверкой

Скорости — грубая оценка по VRAM-bandwidth (3060 ≈360 ГБ/с, 4090 ≈1008 ГБ/с); 30b — MoE с ~3B активных, потому быстрая несмотря на 18 ГБ веса. 8/12 ГБ — расчёт, не прогон.

Модель + настройки Ollama под железо

Железо	VRAM	Модель	Quant	num_ctx	keep_alive
Ноут 3070 / 4060	8 ГБ	qwen2.5-coder:7b	Q4_K_M	8192	5m
Десктоп 3060	12 ГБ	qwen2.5-coder:14b	Q4_K_M	16384	10m
Десктоп 4090 (замер)	24 ГБ	qwen3-coder:30b	Q4·MoE	32768	30m
CPU-only fallback	—	qwen2.5-coder:3b	Q4	4096	2m

// extraction-вызов, Ollama HTTP API
"format": "json", // форс JSON-грамматики → режет bad_json
"options": { "temperature": 0, // детерминизм → меньше галлюцинаций
"num_ctx": 16384, // по VRAM: 8ГБ→8192, 24ГБ→32768+
"num_predict": 2048 // потолок выхода = потолок D }

num_ctxМасштабируй по VRAM — KV-cache ест память сверх весов. Превысишь → выгрузка в RAM и обвал скорости 2–5×.
8 ГБЧисла / метрология / финансы — НЕ делегировать на 7b/4b: только грубая классификация/шаблон, где ошибка дёшева и видна глазом.
не тяни14b на 8 ГБ — частичная выгрузка слоёв даёт 2–5× замедление; проще 7b целиком в VRAM.

Модель падений

Делегация падает — когда бросить и сделать самому

Каждый провал делегации тоже жжёт токены frontier: надо прочитать ошибку/мусор и решить «повторить или escalate». Обозначим цену одного провала f. Решение forward-looking (уже потраченное — sunk cost, в расчёт не идёт):

E[retry] = D + f·(1−p)/p // ожидаемая стоимость «повторять до успеха»
solo выгоднее, когда E[retry] > S

Провалы на одном входе не независимы — патологичный файл ломает систематически. Оценка вероятности успеха по Лапласу после k провалов подряд: p̂ = 1/(k+2) → (1−p)/p = k+1. Критерий сворачивается в порог:

N_switch = ⌊(S − D) / f⌋ // столько провалов подряд терпим, дальше — solo

Цена провала

Тип падения решает — не количество

Измеренная стоимость f одного провала в токенах контекста frontier:

Тип падения	f, ток	Как измерено
пустой ответ	130	обёртка вызова
HTTP 500	143	строка ошибки
timeout	145	traceback
VRAM-guard	150	строка
bad_json (проза вместо JSON)	885	реальный прогон, 755 ток прозы
галлюцинация	D + α·S	валидация дочитывает долю α источника

Инфра-сбои дёшевы (~140 ток), bad_json дороже, галлюцинация — самая дорогая: она невидима, и проверка выжимки заставляет дочитывать сам источник.

Матрица порога

Сколько провалов терпеть — N_switch

Файл	S−D	инфра ~140	bad_json 885	галлюц α=0.25	галлюц α=0.5
текст-карточка 2.5 КБ	2	0	0	0	0
код-анализ 26 КБ	6 153	41–47	6	2	1
changelog 51 КБ	13 790	91–106	15	3	1
JSON-лог 96 КБ	26 437	176–203	29	3	1

Токен-порог нельзя брать буквально. Для инфры он огромен (40–200), но ретраить 200 раз нельзя: доминирует время (N × timeout) и политика «краш локальной модели → отчёт, не молчаливый бесконечный ретрай». Реальный порог = min(токен-порог, practical cap).

Правило

Операциональный критерий

дефолт2 подряд провала → solo. Безопасный cap по времени и надёжности.
N=1сразу сам, если файл <~10 КБ (делегация не окупалась) или галлюцинация на крупном/критичном (метрология, финансы — там α≥0.5 → порог 1).
N=3терпи третий ретрай, если провал — чистая инфра (перезапуск локальной модели / подождать VRAM) на файле >50 КБ и время терпит; иначе — отчёт.

Суть: дешёвый и видимый провал (пусто/HTTP/timeout) — ретрай почти бесплатен, не паникуй. Дорогой и скрытый (галлюцинация) — уходи в solo рано, пока не потратил больше, чем сэкономил.

Честные оговорки

Границы применимости

проксиСчётчик — tiktoken, не токенизатор frontier. Отношения (экономия %, порог) устойчивы; абсолютные токены ±10–15%.
steady-stateЭкономия измерена при готовом helper-скрипте. Первый прогон несёт разовую стоимость написания скрипта.
αЦена галлюцинации параметризована долей источника на сверку (α∈{0.1, 0.25, 0.5}) — не измерена напрямую, дан диапазон.
токены≠всёМодель считает токены. Качество и надёжность выжимки — отдельная ось: каждое число из выжимки сверять с источником (anti-hallucination).
capPractical cap (2–3) — инженерное решение по wall-clock и политике, а не токен-оптимум. Чистый токен-оптимум для инфры выше, но нереализуем по времени.

Воспроизводимо: bench_delegation.py (экономия) + bench_failures.py (модель падений) + bench_dollars.py (перевод в деньги). Данные анонимизированы; числа и метод — как измерены, цены — публичный прайс. · 2026-07-10