Автономный режим. Прод 4nodes-switch (dgx1–4, 1017 SGLang EP2/1M) не трогал
всю смену — работа только на dgx58-switch (dgx5–8).
| лейн | качество (v2.8.0, seed 42) | resp / ход | pp c1 | tg c1 / c2 / c4 | KV-пул |
|---|---|---|---|---|---|
| 1017 SGLang 4x (прод, EP2/1M) | 87/100 | 75 / 1.4 s | 3,019 | 45.6 / 67.8 / — | 9.30M |
| 1017 TensorFold 2x (EXL3) | 89/100 | 23 / 6.7 s | ~380 (2K) | 50.4 / — | 26.6M (FLARE) |
| 1017 FLARE 4x (native Rust) | не измерим — падает | — | ~2.4k | 22–27 | 26.6M |
| Beam NVFP4 4x (новый) | 90/100 | 34 / 4.7 s | 2,501 | 26.2 / 41.1 / 62.3 | 6.81M |
Вывод: прод-конфиг остаётся лучшим по задержке, Beam — лучший по качеству, TensorFold — лучший однопоточный декод среди 1017-вариантов, FLARE — не готов.
Находка: у них есть официальный gb10-пакет «DeepSeek V4.1 Flash 1017 on four
DGX Sparks» (local-inference-lab/DeepSeek-V4.1-Flash-1017-FLARE@gb10,
511 GB = 12 весовых + 5 графовых шардов), рантайм — нативный Rust, образ
multi-arch (arm64 есть), APT-репозиторий доступен.
Что сделано: поставил flare 0.1.0 на все 4 ноды, поднял орбиту
(flare orbit pair, агенты на systemd --user — требуется loginctl
enable-linger + XDG_RUNTIME_DIR, иначе systemd --user не стартует по SSH),
скачал пакет на NAS, прошёл orbit run TP4 по dgx5–8.
Результаты:
architecture sm_121, 1,048,576 ctx, 16 конкурентных, MTP 1–6,
по 74.7 GiB/ранг, 130 графов, KV-пул 26.6M токенов (22.3 GiB/ранг);roceP2p1s0f0,rocep1s0f0) — то
есть сеть не при чём;tensor-parallel peer failed: RoCE proxy
failed: two-shot op N abandoned: kernel timed out at seq N — воспроизводимо на
первом же запросе с 52 тулами (короткие чат-запросы работают). Полный
tool-eval-bench дал 0/100 (все сценарии — 500/connection closed);Итого: FLARE 1017 на нашем железе — медленнее и нестабильнее; для нас закрыт.
Отдельно проверил FLARE на Qwen3.8-Flash-Next gb10 (tp1, одна Spark,
107 GB): работает, загрузка ~1 с (графы в пакете), decode 43.3 tok/s,
TTFT 1.30 s, tool calls и json_schema — ок, а tool_choice: "required"
отдаёт HTTP 500 («required tool choice was not satisfied»). Это стоит
сообщить вендору.
Вендорский стек: vllm/vllm-openai:reflection-beam (Beam пока только в этом
образе, min vLLM 0.33.0; arm64 есть), TP4, fp8 KV, парсеры beam.
90/100 (174/194), Hard Mode 47/56 = 84% — лучший результат флота.
Декод 26.2 / 41.1 / 62.3 (c1/c2/c4), pp 2,501, KV 6.81M, boot ~17 мин (первый
старт автоподбирает FlashInfer MoE-кернелы — вендор сам просит поднять
VLLM_ENGINE_READY_TIMEOUT_S).
Грабли (все в recipes/beam-1-0-nvfp4-4x/NOTE.md):
entrypoint → launcher делает --entrypoint <model> (известная
ловушка) → entrypoint = ["vllm", "serve"];--gpu-memory-utilization 0.90 не проходит boot-gate → 0.85;reasoning, а content под thinking
пустой — probes, которые смотрят только content, видят ноль токенов;Отчёт: recipes/beam-1-0-nvfp4-4x/reports/* (quality + perf) и NOTE.md.
ghcr.io/kilork/sm121-addon:1.2.0 +
:latest), на ha.lan остаётся нажать Update.--max-running-requests 24 +
--cuda-graph-max-bs-decode 24 (закоммичено; применится при следующем
рестарте прода). Замеры: пул 9.3M, при 24 потоках — ~380K контекста на поток.dev-20261016-sparkcache-4a17f1f5198e (мы на
dev-20261013-dcp2prefill-status038-sircl-tp6).namespace::name у тулов, потеря reasoning на tool-результатах без
списка тулов. Совет: слать число 1–100 вместо имени.| dgx1–4 (прод) | 1017 SGLang EP2/1M, не тронут, ~30 ч аптайма |
| dgx5–8 | Beam NVFP4 TP4 поднят (финальный конфиг, fp8 KV, без спекуляции), API :30000, 6.55M KV |
| FLARE | орбита остановлена, пакеты закешированы (dgx5–8 по ~120 GB), flare 0.1.0 установлен |
| Диски dgx5–8 | ~120–430 GiB свободно (FLARE-пакеты занимают ~120 GB на ноду) |
TF_DSV41_SESSIONS=0
сейчас) — у Elevatormusic-форка с кэшем второй вопрос по 24K-документу
стартует за 1.1 s вместо 12.8 s; у нас это и есть главная боль TF.sparkcache — посмотреть, что даёт (возможно, кэш префиксов).