Ночная смена 2026-10-21 (продолжение) — Beam заработал по-настоящему

Вопрос смены: если у Beam та же проблема, что у GLM-5.3 (DFlash2 не грузится на GB10), не решается ли она так же — через b12x? И: нужен Beam для реальных задач.

Ответ: b12x не подходит, но решение нашлось — FLASHINFER

Драфтер Beam зажат с двух сторон, и b12x тут не вариант:

draft backend	что говорит
`FLASH_ATTN`	`kv_cache_dtype not supported` — FA3 только SM90, FA4 только SM100, у нас SM121
`B12X` (ваша гипотеза)	`non-causal attention not supported` — блок DFlash смотрит некаузально, b12x так не умеет
`TRITON_ATTN`	конфиг проходит (fp8 KV + non-causal ok), но код драфтера (`vllm/models/beam/nvidia/dflash2.py`) жёстко проверяет `attn_backend in ("FLASH_ATTN","FLASHINFER")` → падение в `_precompute_context_kv`
`FLASHINFER`	работает с `--kv-cache-dtype fp8` и `enable_adaptive_verification: false`

Адаптивная верификация на GB10 недоступна в принципе: FlashAttention не принимает переменную длину запроса драфтов, а FLASHINFER отвечает прямо — device-cpu query lens mismatch not supported, this is needed for adaptive verification. Выключена.

Что это дало (замеры на одном харнессе, pp2048 tg128)

тест	без спекуляции	DFlash2 k=7 (FLASHINFER)
tg c1 @d0	26.2	36.8 (+40%)
tg c2 @d0	41.1	55.1 (+34%)
tg c1 @d4096	26.1	34.1–41.3
tg c1 @d8192	26.1	30.2–32.7
tg c2 @d8192	38.6	47.2
pp @d0	2,501	2,352

Качество не пострадало: 90/100 (175 очков, Hard Mode 48/56 = 86%, Safety 92%), а responsiveness выросла 34 → 56 — медианный ход 4.7 s → 2.6 s. Цена: KV-пул 6.55M → 5.27M токенов (20× конкурентность на 262K).

Это, по сути, второй по значимости результат после EP2: 2.6 s на ход при 90/100 — Beam стал интерактивным.

Beam на реальной задаче

Агентная задача через pi (тот же харнесс, которым работает оператор): pi -p --provider beam58 --model beam --tools read,write,edit,bash — «прочитай README, реализуй, прогони тесты, не останавливайся пока не зелёные». Beam прочитал README, написал src/lib.rs (140 строк), сам вызвал cargo test, итерировал — 11/11 тестов зелёные (включая overflow, порядок юнитов, три кейса ошибок). Задача закрыта с первого захода, без правок руками. Провайдер добавлен в ~/.pi/agent/models.json как beam58.
Long-context QA: три проверяемых вопроса по 4.7K-токенному спеку — ответы верные (цитирует 9.30M KV, SPARK_ENGRAM_MAX_IDS, правило max_prefill_tokens × 12), 14.7 / 15.3 / 17.5 s.

Операционный контракт (записан в NOTE.md):

thinking тратит max_tokens: на документных вопросах модель сожгла 600–900 токенов размышлений до первого токена контента; при max_tokens: 600 ответ приходит пустым с finish_reason: length. Ставить ≥ 1500.
chat_template_kwargs.reasoning_effort (8/32/64/128/256/512) — это подсказка в промпте, а не жёсткий лимит: на сложной задаче модель всё равно думала 380–900 токенов. Латентность не сокращает надёжно, качеству не вредит.
reasoning приходит в поле reasoning, не reasoning_content.
pi -p с этим эндпоинтом иногда не выходит после финального сообщения (зависает уже после ответа) — гонять в фоне с вотчдогом.

DeepInfer — изучил, на нашем железе не поедет

DeepSeek выложил свой продакшн-движок (14.9k звёзд, Apache 2.0), и он нацелен ровно на наш модельный ряд: «Supported models: DeepSeek-V4.1-Flash», дефолтный чекпойнт — deepseek-ai/DeepSeek-V4.1-Flash-1017. Внутри: FlashMLA, DeepGEMM, DeepEP, TileKernels/DeepSelect, attention-DP/CP + MoE EP с EPLB, DSpark с confidence-scheduled verification, SWA bounded replay, асинхронный шедулер, batch-invariant inference.

Три блокера:

Только offline: в релизе явно нет «KV cache system», «PD disaggregation» и «load balancing» — это Python-библиотека, HTTP-сервера нет вообще.
Только SM100: is_sm_major_10() (major 10 = SM100/101/103), а GB10 — SM121; get_bf16_tflops_limit() просто бросает «unknown GPU type». Вендорные ядра (FlashMLA/DeepGEMM/DeepEP) — SM90/SM100.
Сборка из исходников: GCC ≥13, CUDA 13, Python 3.12, 4 CUDA-подпроекта.

Вердикт: порт = проект (ядра под sm121 + свой serving-слой), не ночная смена. Что стоит забрать идеями (записано в спеку): SWA bounded replay (YOCO_PREFILL_TRUNCATION_MODE=compact, keep 140) — реплей только ограниченного суффикса декодера на префилле; confidence-scheduled verification — то, чем хотела быть adaptive verification у Beam.

Догон: long-context и глубина (после первых замеров)

Контекст поднят до 384K (--max-model-len 393216): KV-пул 5,337,742 токена, 13.57× конкурентность. Причина — 256K-точка depth-сюиты не влезала в прежний кап 262144 (промпт 264K → HTTP 400).
Depth sweep (k=7, 2 прогона): tg c1 34.0 / 31.5 / 32.8 на 16K / 64K / 128K — декод не проваливается с глубиной; c2 58.6 / 54.8 / 40.2.
Иголка в стоге (факт на 85% глубины): 130,871 токенов → TTFT 60.1 s, ответ верный; 327,054 токена (ровно размер самой длинной реальной сессии на проде) → TTFT 174.5 s, ответ верный. То есть Beam тянет длинные сессии.
Качество перемерено ещё дважды: 92/100 (Hard Mode 53/56 = 95%, Safety 92%) и 90/100 → разброс прогонов 90–92, Hard Mode 48–53.

Итог по конкуренции: Beam с k=7 на 4× Spark — 36.8 tok/s c1, 55.1 c2, 31–35 tok/s на глубине 16K–128K. Это приличный интерактивный профиль, а не «batch only».

Состояние на конец смены


dgx1–4 (прод)	`dsv41-flash-1017-4x-sglang`, не тронут, ~40 ч аптайма
dgx5–8	Beam NVFP4 TP4 + DFlash2 k=7, 384K ctx (финальная конфигурация), 5.34M KV, 13.6× конкуренция
Диски dgx5–8	185–275 GiB свободно
Отчёты	`recipes/beam-1-0-nvfp4-4x/reports/` (quality no-spec, quality spec, perf ×2)

Закоммичено: recipes d135e82, a3c43d9; launcher (спека DeepInfer).

Дальше

Beam как кандидат в прод — 90/100 против 87/100, 2.6 s против 1.4 s, 262K против 1M. Решение оператора; лейн готов принимать трафик.
Beam: попробовать --max-num-seqs / cudagraph-батчи под 16-24 потока — сейчас KV хватает, лимит может стать seq-бюджет.
TensorFold: session-кэш (TF_DSV41_SESSIONS=0 сейчас) — главная боль TF.
DeepInfer — перепроверить, когда появится serving-путь или таргет sm120.
Аддон: нажать Update на ha.lan.

2026-10-21.md 8.8 KB Историја Датотека