night shift 2026-10-21: Beam DFlash2 speculation unlocked via FLASHINFER (+40% decode, turn 2.6s); real agentic task on Beam via pi (11/11 tests); DeepInfer assessed as SM100/offline-only

history/night-shifts/2026-10-21.md

@@ -0,0 +1,106 @@
+# Ночная смена 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 на реальной задаче
+
+1. **Агентная задача через 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`.
+2. **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.
+
+Три блокера:
+1. **Только offline**: в релизе явно нет «KV cache system», «PD disaggregation» и
+   «load balancing» — это Python-библиотека, HTTP-сервера нет вообще.
+2. **Только SM100**: `is_sm_major_10()` (major 10 = SM100/101/103), а GB10 — SM121;
+   `get_bf16_tflops_limit()` просто бросает «unknown GPU type». Вендорные ядра
+   (FlashMLA/DeepGEMM/DeepEP) — SM90/SM100.
+3. Сборка из исходников: 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.
+
+## Состояние на конец смены
+
+| | |
+|---|---|
+| dgx1–4 (прод) | `dsv41-flash-1017-4x-sglang`, не тронут, ~40 ч аптайма |
+| dgx5–8 | **Beam NVFP4 TP4 + DFlash2 k=7** (финальная конфигурация), 2 ч аптайма, 5.27M KV |
+| Диски dgx5–8 | 185–275 GiB свободно |
+| Отчёты | `recipes/beam-1-0-nvfp4-4x/reports/` (quality no-spec, quality spec, perf ×2) |
+
+Закоммичено: recipes `d135e82`, `a3c43d9`; launcher (спека DeepInfer).
+
+## Дальше
+
+1. **Beam как кандидат в прод** — 90/100 против 87/100, 2.6 s против 1.4 s,
+   262K против 1M. Решение оператора; лейн готов принимать трафик.
+2. Beam: попробовать `--max-num-seqs` / cudagraph-батчи под 16-24 потока —
+   сейчас KV хватает, лимит может стать seq-бюджет.
+3. TensorFold: session-кэш (`TF_DSV41_SESSIONS=0` сейчас) — главная боль TF.
+4. DeepInfer — перепроверить, когда появится serving-путь или таргет sm120.
+5. Аддон: нажать Update на ha.lan.