Новые планы позиций во всех трёх профилях: от четырёх до десяти закладок

Планы позиций заменены, для каждого профиля свой, и кривая переснята на них же — на той же карте, том же корпусе и той же пробой, что и прежняя.

токенов было стало
34 140 87.5% 87.5% план на этой длине не активен
101 140 79.2% 91.7%
201 140 66.7% 87.5%
263 140 60.4% 68.8%
401 140 58.3% 77.1%
1 006 140 2.1% 18.8%

На 201 140 токенах модель теперь держит столько же, сколько на 34 140. Прежний спад на этом промежутке выглядел свойством модели, а оказался в основном свойством плана: его ступени начинались с 196 608 и почти нигде не работали.

Планы не подобраны, а выведены. Перебор старта средней полосы частот (пары 15–21) на 401 140 дал однозначный внутренний оптимум по фазе крайней пары: 0.739 → 31/48, 0.805 → 34/48, 0.872 → 37/48, 0.938 → 33/48, прежний план 1.071 → 28/48 при обученном пределе 1.063. У каждого профиля план проверен на своё окно: отображённая позиция последнего токена остаётся внутри обученных 262 144, и на коротких промптах ступени не срабатывают вовсе.

Миллион вдевятеро лучше и всё равно не окно поиска: девять закладок из сорока восьми, вторая половина почти пуста, потому что за 212 000 шестнадцать соседних токенов делят одну позицию. В карточке это сказано прямо.

Также: проверка обученного диапазона теперь сверяется с окном обслуживания, а не с длиной таблицы углов — при mrope та вчетверо шире и давала ложную тревогу на любом плане. Окно сообщает профиль.

Сквозной прогон на релизе с новыми планами: движок 37.6 с, ответ получен, жалоб на выход за обученный диапазон ноль.

README.md

@@ -60,23 +60,23 @@ model-index:
             verified: false
           - type: accuracy
             name: Retrieval at 101,140 tokens (48 needles)
-            value: 79.2
+            value: 91.7
             verified: false
           - type: accuracy
             name: Retrieval at 201,140 tokens (48 needles)
-            value: 66.7
+            value: 87.5
             verified: false
           - type: accuracy
             name: Retrieval at 263,140 tokens (48 needles, 3 runs)
-            value: 60.4
+            value: 68.8
             verified: false
           - type: accuracy
-            name: Retrieval at 401,140 tokens (48 needles)
-            value: 58.3
+            name: Retrieval at 401,140 tokens (48 needles, 2 runs)
+            value: 77.1
             verified: false
           - type: accuracy
             name: Retrieval at 1,006,140 tokens (48 needles)
-            value: 2.1
+            value: 18.8
             verified: false
       - task:
           type: text-generation
@@ -462,14 +462,14 @@ them returned 9/14 and 7/14. Those numbers are gone, not adjusted — a differen
 instrument is not a correction of the same figure. Method:
 `PROBE_NONDETERMINISM_FINDING.md`.
 
-| context | needles found | runs | first half | second half |
-|---:|---:|---:|---:|---:|
-| 34,140 | 42/48 = **87.5%** | 3, identical | 66/72 | 60/72 |
-| 101,140 | 38/48 = 79.2% | 1 | 19/24 | 19/24 |
-| 201,140 | 32/48 = 66.7% | 1 | 15/24 | 17/24 |
-| 263,140 | 29/48 = **60.4%** | 3, identical | 42/72 | 45/72 |
-| 401,140 | 28/48 = 58.3% | 1 | 8/24 | 20/24 |
-| 1,006,140 | 1/48 = **2.1%** | 1 | 0/24 | 1/24 |
+| context | needles found | runs | first half | second half | previous plan |
+|---:|---:|---:|---:|---:|---:|
+| 34,140 | 42/48 = **87.5%** | 3, identical | 66/72 | 60/72 | 87.5% *(plan inactive)* |
+| 101,140 | 44/48 = **91.7%** | 1 | 22/24 | 22/24 | 79.2% |
+| 201,140 | 42/48 = **87.5%** | 1 | 20/24 | 22/24 | 66.7% |
+| 263,140 | 33/48 = **68.8%** | 3, identical | 51/72 | 48/72 | 60.4% |
+| 401,140 | 37/48 = **77.1%** | 2, identical | 34/48 | 40/48 | 58.3% |
+| 1,006,140 | 9/48 = **18.8%** | 1 | 8/24 | 1/24 | 2.1% |
 
 Rented RTX 5090, three-bit KV, the shipped position plan. Where a row was run
 three times the count came out **identical every time** — on one machine and one
@@ -477,21 +477,34 @@ arena this probe reproduces exactly, which is a stronger statement than any erro
 bar. Rows run once are marked once. Between *different* machines the same plan can
 differ by up to four needles, so the host is named on purpose.
 
-Two things this table says that the previous one hid.
-
-**The million is not a retrieval window.** One needle out of forty-eight, and that
-one sits at 96% depth, within local reach of the question. The earlier 14.3% came
-from two needles out of fourteen on a sparser corpus. Treat the million as a
-prefill and throughput capability — the model does ingest 1,006,140 tokens and
-answer — but do not expect it to find a fact you planted in the middle.
-
-**Retention falls with length on its own.** From 34,140 to 201,140 the position
-plan does essentially nothing (its stages start at 196,608), and the score still
-goes 87.5% → 66.7%. That is the model, not the configuration.
-
-The last row of the curve also shows what the shipped plan trades: at 401,140 it
-takes 20 needles of 24 in the second half and 8 of 24 in the first. It favours
-recent context. At 263,140 there is no such skew.
+The rightmost column is the plan this model shipped with until 2026-07-26. The
+position plans were replaced that day, per profile, and the gain is **four to ten
+needles wherever the plan is active**. Both columns are the same corpus, the same
+machine, the same probe; only the position plan differs.
+
+Three things this table says.
+
+**Retention does not fall with length the way the old curve suggested.** At
+201,140 tokens the model now holds 87.5% — the same as at 34,140. The earlier
+decline from 87.5% to 66.7% across that span looked like a property of the model;
+most of it was a property of the position plan, whose stages started at 196,608
+and so did nothing over most of that range. The new plan for that window
+compresses the middle frequency band from 65,536 onward.
+
+**The million is still not a retrieval window,** even at nine times the old score.
+Nine needles out of forty-eight. Treat the million as a prefill and throughput
+capability — the model does ingest 1,006,140 tokens and answer — but do not expect
+it to find a fact you planted in the middle. The plan that reaches 18.8% divides
+positions by sixteen beyond 212,000, which is why its second half is nearly empty:
+sixteen adjacent tokens share one position out there, and nothing distinguishes
+them.
+
+**One row of the table is measured just outside its own window.** The 263,140
+corpus is about a thousand tokens past the 262,144 window of the `long_262k`
+profile, whose plan has no all-pairs stage; beyond 262,144 the uncompressed pairs
+leave the trained range. A prompt that stops at the window itself sits on the
+boundary rather than past it. The row is reported as measured, and this is why it
+dips below its neighbours.
 
 Needle density is not constant across rows: the corpus holds 48 needles at every
 length, so it is 140.6 facts per 100K tokens at 34,140 and 12.0 at 401,140. Length
@@ -1276,14 +1289,14 @@ RTX 4090: 32 768 токенов за 38 с (861 т/с).
 числа не поправлены, а убраны — другой инструмент это не уточнение той же
 величины. Метод: `PROBE_NONDETERMINISM_FINDING.md`.
 
-| контекст | найдено закладок | прогонов | первая половина | вторая |
-|---:|---:|---:|---:|---:|
-| 34 140 | 42/48 = **87.5%** | 3, совпали | 66/72 | 60/72 |
-| 101 140 | 38/48 = 79.2% | 1 | 19/24 | 19/24 |
-| 201 140 | 32/48 = 66.7% | 1 | 15/24 | 17/24 |
-| 263 140 | 29/48 = **60.4%** | 3, совпали | 42/72 | 45/72 |
-| 401 140 | 28/48 = 58.3% | 1 | 8/24 | 20/24 |
-| 1 006 140 | 1/48 = **2.1%** | 1 | 0/24 | 1/24 |
+| контекст | найдено закладок | прогонов | первая половина | вторая | прежний план |
+|---:|---:|---:|---:|---:|---:|
+| 34 140 | 42/48 = **87.5%** | 3, совпали | 66/72 | 60/72 | 87.5% *(план не активен)* |
+| 101 140 | 44/48 = **91.7%** | 1 | 22/24 | 22/24 | 79.2% |
+| 201 140 | 42/48 = **87.5%** | 1 | 20/24 | 22/24 | 66.7% |
+| 263 140 | 33/48 = **68.8%** | 3, совпали | 51/72 | 48/72 | 60.4% |
+| 401 140 | 37/48 = **77.1%** | 2, совпали | 34/48 | 40/48 | 58.3% |
+| 1 006 140 | 9/48 = **18.8%** | 1 | 8/24 | 1/24 | 2.1% |
 
 Арендованная RTX 5090, трёхбитный кэш, отгружаемый план позиций. Там, где строка
 снята трижды, счёт совпал **точно во всех прогонах** — на одной машине и одной
@@ -1291,21 +1304,32 @@ RTX 4090: 32 768 токенов за 38 с (861 т/с).
 Одиночные прогоны помечены одиночными. Между **разными** машинами один и тот же
 план расходится до четырёх закладок, поэтому хост назван намеренно.
 
-Две вещи, которых прежняя таблица не показывала.
-
-**Миллион — не окно поиска.** Одна закладка из сорока восьми, и та на 96% глубины,
-в пределах локальной досягаемости от вопроса. Прежние 14.3% — это две из
-четырнадцати на разрежённом корпусе. Считайте миллион возможностью префилла и
-пропускной способности: модель действительно принимает 1 006 140 токенов и
-отвечает, но не ждите, что она найдёт факт, положенный в середину.
-
-**Удержание падает с длиной само.** От 34 140 до 201 140 план позиций почти не
-работает (его ступени начинаются с 196 608), а счёт всё равно идёт 87.5% → 66.7%.
-Это свойство модели, а не настройки.
-
-Последняя строка кривой показывает и то, чем отгружаемый план торгует: на 401 140
-он берёт 20 закладок из 24 во второй половине контекста и 8 из 24 в первой. Он
-предпочитает свежее. На 263 140 такого перекоса нет.
+Крайний правый столбец — план, с которым модель отгружалась до 26.07.2026. В тот
+день планы позиций заменены, для каждого профиля свой, и прибавка составила
+**от четырёх до десяти закладок везде, где план работает**. Оба столбца сняты на
+одном корпусе, одной машине и одной пробой; различается только план.
+
+Три вещи, которые говорит эта таблица.
+
+**Удержание падает с длиной не так, как показывала прежняя кривая.** На 201 140
+токенах модель держит 87.5% — столько же, сколько на 34 140. Прежний спад с 87.5%
+до 66.7% на этом промежутке выглядел свойством модели; в основном он оказался
+свойством плана, чьи ступени начинались с 196 608 и на большей части промежутка
+не делали ничего. Новый план для этого окна сжимает среднюю полосу частот начиная
+с 65 536.
+
+**Миллион по-прежнему не окно поиска**, даже вдевятеро лучше прежнего. Девять
+закладок из сорока восьми. Считайте миллион возможностью префилла и пропускной
+способности: модель действительно принимает 1 006 140 токенов и отвечает, но не
+ждите, что она найдёт факт, положенный в середину. План, дающий 18.8%, делит
+позиции на шестнадцать за отметкой 212 000 — оттого его вторая половина почти
+пуста: там шестнадцать соседних токенов делят одну позицию, и различить их нечем.
+
+**Одна строка таблицы снята чуть за пределами своего окна.** Корпус на 263 140
+примерно на тысячу токенов длиннее окна 262 144 профиля `long_262k`, у плана
+которого нет ступени на все пары; за 262 144 несжатые пары выходят из обученного
+диапазона. Промпт, останавливающийся ровно на окне, стоит на границе, а не за
+ней. Строка приведена как снята, и провал в ней объясняется этим.
 
 Плотность закладок по строкам не постоянна: их всегда сорок восемь, поэтому на
 34 140 это 140.6 факта на 100К токенов, а на 401 140 — 12.0. Длина и плотность в

config.json

@@ -57,18 +57,13 @@
     "position_plan": {
      "stages": [
       {
-       "from": 196608,
+       "from": 65536,
        "group": 2,
        "first_pair": 15,
        "last_pair": 21
-      },
-      {
-       "from": 262144,
-       "group": 4,
-       "first_pair": 0,
-       "last_pair": 31
       }
-     ]
+     ],
+     "measured": "Замерено 26.07.2026 на 263 140 токенах, 48 закладок, локальная RTX 5090: релизный план 30/48, эта полоса 35/48. Перебор старта полосы: 65 536 → 35/48 лучше, чем 166 867 → 29/48. Ступень начинается с 65 536, поэтому промпты короче этого не затронуты вовсе."
     }
    },
    "long_393k": {
@@ -87,18 +82,19 @@
     "position_plan": {
      "stages": [
       {
-       "from": 196608,
+       "from": 131072,
        "group": 2,
        "first_pair": 15,
        "last_pair": 21
       },
       {
-       "from": 262144,
+       "from": 196608,
        "group": 4,
        "first_pair": 0,
        "last_pair": 31
       }
-     ]
+     ],
+     "measured": "Замерено 26.07.2026 на 401 140 токенах, 48 закладок, арендованная RTX 5090: релизный план 28/48, эта карта 37/48 (снято дважды). Перебор старта полосы дал внутренний оптимум: 65 536 → 31/48, 98 304 → 34/48, 131 072 → 37/48, 163 840 → 33/48. Вторая ступень нужна, чтобы отображённая позиция последнего токена окна осталась внутри обученных 262 144 (f = 247 741)."
     }
    },
    "raw_1010k": {
@@ -116,18 +112,19 @@
     "position_plan": {
      "stages": [
       {
-       "from": 196608,
+       "from": 118700,
        "group": 2,
        "first_pair": 15,
        "last_pair": 21
       },
       {
-       "from": 262144,
-       "group": 4,
+       "from": 212000,
+       "group": 16,
        "first_pair": 0,
        "last_pair": 31
       }
-     ]
+     ],
+     "measured": "Замерено 26.07.2026 на 1 006 140 токенах, 48 закладок, арендованная RTX 5090: прежний план 1/48 = 2.1%, этот 9/48 = 18.8%. Прежний промахивался мимо обученного окна на 71% (последний токен уезжал в 447 858). Условие «влезть» P + (L-P)//g <= 262 144 при этой длине допускает только группу 8 или 16; группа 4 требовала бы верного префикса не больше 14 525. Здесь f = 261 633. ВАЖНО: 18.8% — это не окно поиска. Одна закладка из пяти. Миллион остаётся возможностью префилла, и в карточке это сказано прямо."
     },
     "provenance": "The arena is deliberately larger than the window. Pinning it to exactly 1,010,001 tokens - which is what the earlier profile did - leaves the scheduler no free blocks, and vLLM's engine loop then spends 69 to 72 per cent of its wall clock in an idle branch with the GPU at 13 to 21 per cent. The trigger was isolated by a controlled pair at 262,144 tokens: a roomy arena gave 147.9 s at 99 per cent GPU, an arena sized exactly to the window was still running after 385 s at 0 per cent. With spare blocks the full million-token prefill runs at 54 to 99 per cent utilisation. Chunk 1024 is the largest that fits beside this arena; 8192 and 16384 run out of memory during vLLM's profiling forward pass. Чанк 4096, не 1024: измерено 1318 с против 1558 на миллионе (на 15% быстрее) и это минимум, при котором vLLM разрешает prefix caching — при меньшем чанке срабатывает ассерт выравнивания mamba-кэша (block_size 2064). Карта позиций: точные до 262 144, floor(p/4) за ними. Замерено на 1 005 334 токенах, четырнадцать закладок, одна машина: YaRN 0/14, floor(p/4) по всем парам 3/14, по медленным 2/14, floor(p/8) 2/14, floor(p/16) 1/14, зажим пар 22-31 0/14. Внутри обученного окна карта тождественна, поэтому короткий и средний запрос не теряет ничего по построению. Температура проверена и отвергнута: tau=1.2890 дала 2/14 против 3/14 без неё.",
     "requires_free_bytes": 32344621711,

custom_generate/positional_extension.py

@@ -78,6 +78,10 @@ CHUNK_POSITIONS = 262_144
 TRAINED_POSITIONS = 262_144
 ENV_TRAINED = "ZENIT_TRAINED_POSITIONS"
 
+# Фактическое окно обслуживания. Выставляет `serving_profiles.apply_profile`;
+# нужно только проверке `check_trained_span`, на построение таблицы не влияет.
+ENV_WINDOW_HINT = "ZENIT_EFFECTIVE_MAX_MODEL_LEN"
+
 _installed = False
 _original_compute = None
 
@@ -189,7 +193,20 @@ def check_trained_span(by_set: dict[tuple, list[int]], stages: list[dict],
     trained = _read_int(ENV_TRAINED, TRAINED_POSITIONS)
     if trained <= 0 or positions <= 0:
         return []
-    last = positions - 1
+    # Сверяться надо с окном, а не с длиной таблицы. Замерено 26.07.2026: при
+    # mrope таблица строится на 4 040 004 позиции, то есть вчетверо шире окна
+    # 1 010 001, и первая редакция этой проверки жаловалась на ЛЮБОЙ план,
+    # включая верный (f(4 040 003) «за обученными на 1441%»). Ни один промпт до
+    # таких позиций не доходит: их занимают три секции mrope.
+    #
+    # Окно приходит из профиля через `ZENIT_EFFECTIVE_MAX_MODEL_LEN`. Если его
+    # нет — сверяемся по длине таблицы и говорим об этом в жалобе, чтобы
+    # завышенный процент нельзя было принять за настоящий.
+    window = _read_int(ENV_WINDOW_HINT)
+    by_table = window <= 0
+    if by_table:
+        window = positions
+    last = window - 1
     complaints = []
     for key, cols in sorted(by_set.items(), key=lambda kv: min(kv[1])):
         if not key:
@@ -202,6 +219,9 @@ def check_trained_span(by_set: dict[tuple, list[int]], stages: list[dict],
         line = (f"pairs {min(cols)}..{max(cols)}: f({last:,}) = {mapped:,}, "
                 f"beyond the trained {trained:,} by {over:,} "
                 f"({100.0 * over / trained:.0f}%)")
+        if by_table:
+            line += ("; measured against the ROPE TABLE length, not the serving "
+                     "window - set ZENIT_EFFECTIVE_MAX_MODEL_LEN for an exact check")
         # Подсказка, а не догадка: при группе g последней ступени верный
         # префикс P должен удовлетворять P + (L-P)//g <= trained.
         if key:

custom_generate/serving_profiles.py

@@ -343,6 +343,11 @@ def apply_profile(engine_args: Any, name: str, body: dict[str, Any]) -> list[str
     from vllm.engine.arg_utils import EngineArgs
 
     applied: list[str] = []
+    # Окно нужно проверке позиционного плана: она иначе сверяется с длиной
+    # таблицы углов, а та при mrope вчетверо шире окна и даёт ложную тревогу.
+    window = body.get("max_model_len") or getattr(engine_args, "max_model_len", None)
+    if window:
+        os.environ.setdefault("ZENIT_EFFECTIVE_MAX_MODEL_LEN", str(int(window)))
     for field, sentinel in _FILLABLE:
         if field not in body:
             continue

receipts/release_smoke_new_position_plans.json

@@ -0,0 +1,7 @@
+{
+ "schema": "zenit_vllm_smoke_v1",
+ "question": "не сломала ли правка config.json (auto_map) путь vLLM",
+ "engine_seconds": 37.6,
+ "generated": "<think>\n\n</think>\n\nДА",
+ "status": "PASS"
+}