Заявление о запуске Qwen3.8-27B с контекстом 1 048 576 токенов через форк NInfer на C++20/CUDA нужно трактовать как описание конкретной конфигурации, а не как подтверждённую возможность любой сборки NInfer или любой пары RTX 5090. В предоставленных материалах нет commit форка, лога запуска, параметров YaRN, данных о занятой VRAM и результатов тестов качества. Поэтому нельзя честно подтвердить сам рекорд, его скорость или стабильность.
Технически такая схема выглядит правдоподобной как направление эксперимента: две GPU могут делить веса и вычисления через tensor parallelism без NVLink, а YaRN способен расширить позиционное кодирование за пределы исходного окна. Практическая ценность зависит от пяти вещей: фактической длины обработанного промпта, качества на удалённых позициях, объёма KV-кэша, времени prefill и скорости decode после заполнения контекста.
Что именно заявлено: Qwen3.8-27B, 1 048 576 токенов и две RTX 5090
В описании кейса фигурируют форк NInfer, сборка на C++20/CUDA, модель Qwen3.8-27B, две RTX 5090 без NVLink, tensor parallelism и YaRN с коэффициентом x4. Целевой размер окна указан точно: 1 048 576 токенов. Это число нужно отделять от доказанной обработки промпта такой длины и от способности модели извлекать информацию из всех его участков.
Короткий вывод для читателя
Параметр max context = 1048576 сам по себе ничего не доказывает. Для признания кейса рабочим нужны успешный prefill длинного токенизированного ввода, генерация после него, отсутствие OOM, замер пиковой VRAM и тесты retrieval на начале, середине и конце последовательности. Даже при успешном запуске это остаётся свойством конкретного форка, версии CUDA, квантизации и PCIe-топологии.
Для ориентира по более коротким сценариям полезен разбор Qwen3.8-27B на RTX PRO 4000 Blackwell с контекстом 128K. Он хорошо показывает разницу между резервированием памяти под контекст и фактическим NIAH-тестом на длинном промпте.
Какие данные необходимы для подтверждения кейса
- Ссылка на конкретный commit форка NInfer или его архив с идентификатором ревизии.
- Версии ОС, драйвера NVIDIA, CUDA Toolkit, компилятора C++20 и зависимостей.
- Точный формат Qwen3.8-27B, квантизация весов, precision KV-кэша и объём памяти каждой GPU.
- Настройки tensor parallelism, YaRN и RoPE scaling.
- Длина токенизированного промпта, а не размер исходного текста в символах или словах.
- Пиковая VRAM, скорость prefill, latency до первого токена, скорость decode и итоговое время обработки.
- Тесты удержания информации в нескольких позициях контекста и лог успешной генерации после prefill.
Почему 1 млн токенов не появляется от одного параметра context
Длинное окно складывается из трёх независимых частей: движок должен выделить память, модель должна принять позиции за пределами исходного диапазона, а внимание должно сохранять полезное поведение на этой длине. Ошибка в любом звене превращает красивое число в настройку без практической пользы.
Нативный контекст Qwen3.8-27B и расширение за его пределы
Нативное контекстное окно Qwen3.8-27B нельзя указывать без документации именно для используемого чекпойнта. В материалах к задаче это значение не подтверждено. Его нужно сверить с карточкой модели перед расчётом коэффициента масштабирования и до запуска тестов.
Выход за обученный диапазон меняет условия работы позиционного кодирования. Модель способна принять последовательность с большей позицией, но принятие входа не равно сохранению точности. На длинных промптах часто проявляются потеря фактов в середине, неверные ссылки между фрагментами, повторение ответа и снижение устойчивости многошагового рассуждения.
Что меняет YaRN x4
YaRN относится к методам RoPE scaling. Он меняет способ представления позиций, чтобы модель могла обрабатывать более длинную последовательность, чем базовое окно. Коэффициент x4 обычно означает намерение расширить целевую длину примерно в четыре раза относительно выбранной исходной точки, но точная трактовка зависит от реализации и параметров форка.
YaRN не добавляет память GPU и не ускоряет prefill. Он решает задачу позиционного масштабирования. Память под KV-кэш продолжает расти с каждым токеном, а качество нужно проверять отдельно на позициях, разделённых сотнями тысяч токенов.
Техническое окно против полезного окна
Техническое окно отвечает на вопрос, может ли рантайм обработать последовательность заданной длины. Полезное окно отвечает на другой вопрос: находит ли Qwen3.8-27B нужный факт в этой последовательности и корректно использует его в ответе.
- Поместите контрольный факт в первые 5% контекста.
- Добавьте второй факт около середины.
- Разместите третий факт в последних 5%.
- Задайте вопросы на прямое извлечение и вопросы, требующие связать два удалённых фрагмента.
- Повторите тест с шумом, похожими сущностями и отвлекающими инструкциями.
Если модель отвечает лишь на факт в конце промпта, миллион токенов остаётся доступным, но полезное окно значительно меньше заявленного.
Как две RTX 5090 работают без NVLink
Отсутствие NVLink не мешает разделить инференс между двумя GPU. Карты обмениваются данными через PCIe, если драйвер, платформа и рантайм поддерживают нужный путь peer-to-peer либо используют промежуточный обмен через память хоста. Цена такого обмена зависит от топологии системы и характера вычислений.
Tensor parallelism: что делится между GPU
Tensor parallelism не дублирует полную модель на каждой карте. Рантайм распределяет части тензоров матричных операций между GPU. Каждая карта вычисляет свою часть результата, затем участникам нужны коллективные операции, например объединение или суммирование промежуточных значений.
Разбиение весов освобождает VRAM под крупную модель и KV-кэш. Распределение KV-кэша зависит от архитектуры движка и выбранного шардирования. Его нельзя считать ровно делённым пополам без замера: часть буферов, служебные структуры и временная память могут присутствовать на обеих GPU.
Цена отсутствия NVLink
PCIe добавляет задержку синхронизаций. Decode особенно чувствителен к ней: генерация идёт последовательно, и на каждом новом токене участники tensor parallelism обмениваются промежуточными данными. Prefill обрабатывает большой блок входных токенов и сильнее зависит от пропускной способности памяти, эффективности attention kernels, размера чанков и поведения CUDA graph.
Без воспроизводимого сравнения нельзя назвать процент потери скорости относительно NVLink. Проверять нужно фактическую PCIe-топологию, ширину линии для каждой GPU, доступность peer-to-peer, параметры Resizable BAR и загрузку CPU. Две карты в слотах с разной пропускной способностью могут вести себя заметно иначе при одинаковой модели.
Что нужно проверить перед запуском
- Свободную VRAM после загрузки весов и создания служебных буферов.
- Топологию PCIe, режимы линков и peer-to-peer-доступ между GPU.
- Совместимость версии драйвера с CUDA Toolkit и собранными CUDA-ядрами.
- Формат весов, точность KV-кэша и поддержку нужной квантизации в форке.
- Размер batch, число параллельных запросов и резерв памяти для временных тензоров.
- Стабильность на последовательностях 128K, 256K, 512K и 1 048 576 токенов.
Память и скорость: где упирается длинный контекст
Веса Qwen3.8-27B занимают фиксированный объём для выбранного формата. KV-кэш растёт вместе с длиной входа. Поэтому конфигурация, которая уверенно генерирует ответ на 8K токенов, может исчерпать VRAM задолго до миллиона при том же batch и precision.
Prefill и decode решают разные задачи
Prefill обрабатывает исходный промпт и создаёт KV-кэш. На контексте в сотни тысяч токенов это главный источник задержки до первого токена. Даже высокая скорость decode не компенсирует длительный prefill, если пользователь ждёт ответ после загрузки большого архива или репозитория.
Decode генерирует новые токены последовательно, используя готовый KV-кэш. Здесь растут стоимость attention по длинной истории, давление на память и влияние синхронизаций между GPU. Метрика токенов в секунду без указания длины промпта не описывает реальный пользовательский опыт.
Как растёт KV-кэш на длинной последовательности
Упрощённая оценка памяти KV-кэша выглядит так:
KV bytes ≈ layers × tokens × batch × 2 × kv_heads × head_dim × bytes_per_elementМножитель 2 учитывает key и value. В реальном рантайме к расчёту добавляются выравнивание блоков, paging, временные буферы attention, графы CUDA и служебные структуры. При tensor parallelism часть величин шардируется, но характер распределения определяет конкретная реализация NInfer.
Сжатие KV-кэша может снизить требования к VRAM, но меняет компромисс между памятью, пропускной способностью и качеством. Перед переходом к экстремальным настройкам полезно сравнить подходы к fp8 KV-cache и распределённому хранению кэша в материале о локальном стеке Qwen3.8-27B на двух RTX 3090.
Какие метрики публиковать
| Метрика | Что показывает |
|---|---|
| Фактические prompt tokens | Реальную длину обработанного входа после токенизации |
| Prompt processing speed | Скорость prefill на конкретной длине |
| Latency до первого токена | Ожидание пользователя перед началом ответа |
| Decode tokens/s | Скорость генерации после заполнения KV-кэша |
| Пиковая VRAM на каждой GPU | Запас памяти и риск OOM |
| Время полного прогона | Практическую цену обработки длинного документа |
| Успех retrieval-тестов | Полезность контекста, а не факт выделения памяти |
Speculative decoding в NInfer и vLLM за пределами нативного окна
Speculative decoding ускоряет генерацию, когда более лёгкая draft-модель предлагает несколько следующих токенов, а target-модель проверяет их одним проходом. Ускорение появляется лишь при достаточно высокой доле принятых предложений и приемлемой цене работы draft-модели.
Как работает speculative decoding
Draft-модель генерирует короткую цепочку кандидатов. Target-модель проверяет эту цепочку и принимает совпадающий префикс. Отклонённый токен требует продолжить генерацию с позиции расхождения. Длина speculative sequence, температура, sampling и архитектура обеих моделей влияют на итоговую пользу.
На длинном контексте target-модель всё равно должна читать большой KV-кэш во время проверки. Поэтому speculative decoding не отменяет цену attention и не ускоряет prefill уже поступившего миллиона токенов.
Почему acceptance rate становится критическим
Acceptance rate показывает долю draft-токенов, которые target-модель принимает. Низкий показатель создаёт лишнюю работу: draft-модель генерирует кандидаты, target-модель часто их отклоняет, а итоговая скорость может не вырасти или снизиться.
За пределами нативного окна расхождение распределений target- и draft-модели способно стать сильнее. На acceptance rate влияют YaRN-настройки обеих моделей, длина контекста, тип задачи, температура, top-p, повторяющиеся документы и качество самой draft-модели. Публиковать нужно среднее значение, распределение по длинам контекста и параметры генерации.
Сравнение NInfer и vLLM: единый протокол
Сравнение NInfer и vLLM имеет смысл только при одинаковых условиях. Иначе один движок может выглядеть быстрее из-за иной квантизации, меньшего промпта, warm cache или другого sampling.
- Зафиксировать target-модель, draft-модель, веса, формат, precision KV-кэша и параметры YaRN.
- Использовать одинаковый токенизированный промпт и одинаковые точки длины контекста.
- Отдельно измерить prefill без speculative decoding.
- Измерить decode с выключенным и включённым speculative decoding.
- Собрать acceptance rate, latency до первого токена, decode tokens/s, VRAM и ошибки.
- Повторить каждый сценарий после прогрева и после холодного старта.
Практику измерений prefill и decode на длинных контекстах можно сопоставить с разбором разницы между prefill и decode в GPU-рантаймах. Цифры из другого теста нельзя переносить на NInfer и Qwen3.8-27B без повторения условий.
Практический протокол воспроизведения запуска
Воспроизводимый кейс начинается не с флага контекста, а с фиксации окружения. Любое изменение драйвера, CUDA, компилятора, квантизации или топологии GPU способно поменять расход памяти и производительность.
Исходные данные и окружение
- Идентификатор commit форка NInfer и состояние рабочих патчей.
- Версия компилятора с поддержкой C++20.
- Версии ОС, драйвера NVIDIA, CUDA Toolkit и библиотек.
- Название модели, источник весов внутри используемого окружения, формат и квантизация.
- Число GPU, режим tensor parallelism, PCIe-топология и доступность peer-to-peer.
- Настройки RoPE scaling или YaRN, размер batch, лимит параллельных запросов.
- Формат KV-кэша, лимит памяти и параметры speculative decoding.
Тесты на длину контекста
Тестируйте длины ступенями: 128K, 256K, 512K и 1 048 576 токенов, если предыдущая точка завершилась успешно. После каждого прогона очищайте или явно учитывайте кэш, чтобы warm state не маскировал расход памяти и время prefill.
| Точка | Фиксировать в логе |
|---|---|
| 128K | Пиковую VRAM, prefill, first-token latency, decode и retrieval |
| 256K | Те же метрики, плюс стабильность нескольких повторов |
| 512K | Поведение PCIe, ошибки, изменение acceptance rate |
| 1 048 576 | Фактическое число токенов, успешную генерацию и полный набор проверок качества |
Тесты качества и удержания информации
NIAH-подобная проверка полезна, но одного скрытого факта мало. Добавьте несколько сущностей с похожими именами, факты в разных позициях, ссылки между разделами и вопрос, который требует объединить сведения. Для кода подойдут поиск определения в начале репозитория, зависимость в середине и ошибка в конце.
Проверяйте результаты при фиксированных sampling-параметрах. Случайный ответ на одном запуске не подтверждает устойчивость длинного контекста.
Кому подойдет Qwen3.8-27B на 1 млн токенов, а кому нет
Конфигурация с двумя RTX 5090 и экстремальным контекстом ориентирована на задачи, где большой объём исходного материала важнее мгновенного ответа. Она требует времени на prefill, запаса VRAM, устойчивого охлаждения, корректной PCIe-топологии и готовности самостоятельно проверять форк.
Когда длинный контекст оправдан
- Офлайн-анализ крупных технических документов, спецификаций и архивов.
- Работа с большими репозиториями, когда важны связи между удалёнными файлами.
- Исследовательские задачи с длинными стенограммами, журналами и собранными материалами.
- Проверка гипотез, где выборочная выдача RAG рискует пропустить критичный фрагмент.
Даже в этих сценариях стоит измерить цену полного prefill. Если обработка документа занимает слишком долго, удобнее заранее разбить поток работы на части и кэшировать промежуточные результаты.
Когда лучше использовать RAG или разбиение документов
RAG разумнее, когда вопрос касается небольшой доли корпуса, требуется много параллельных запросов или критична latency до первого токена. Retrieval сокращает объём входа и нагрузку на KV-кэш. Его слабое место - поиск может не вернуть нужный фрагмент, особенно при неоднозначных запросах или сложных связях между документами.
Иерархическая сводка подходит для длинных материалов с понятной структурой. Полный контекст полезен, когда нужен широкий охват без предварительного отбора, но его нужно подтвердить тестом на конкретных данных.
Итоговый выбор между NInfer и vLLM
NInfer стоит оценивать по поддержке нужной модели, работе с двумя GPU, доступности требуемого RoPE scaling, качеству kernels и повторяемости результатов. vLLM стоит оценивать по тем же критериям, добавив удобство серверной интеграции, управление batch, документацию и поведение speculative decoding.
Для одиночной экспериментальной машины может подойти специализированный форк с агрессивными настройками. Для сервиса с несколькими пользователями важнее предсказуемость памяти, мониторинг, восстановление после ошибок и стабильный throughput. Универсального победителя здесь нет.
Выводы и ограничения кейса
Заявление о Qwen3.8-27B с контекстом 1 048 576 токенов на двух RTX 5090 без NVLink пока нельзя считать подтверждённым по предоставленным данным. Отсутствуют первоисточник форка, параметры запуска, логи, показатели VRAM, скорость prefill и decode, а также тесты качества на реальном миллионе токенов.
Что можно считать доказанным только после публикации логов
- Фактическую длину токенизированного входа.
- Успешное завершение prefill и генерацию после него.
- Пиковое потребление VRAM на каждой GPU.
- Версии NInfer, CUDA, драйвера и параметры YaRN.
- Настройки tensor parallelism и данные о PCIe-топологии.
- Скорость prefill, latency первого токена, decode throughput и acceptance rate.
- Качество retrieval на начале, середине и конце длинного контекста.
Главный практический вывод
Ценность такого форка определяет не число в параметре контекста. Нужна связка из достаточной VRAM, приемлемого prefill, устойчивого decode, качественного RoPE scaling, работоспособного tensor parallelism через PCIe и высокого acceptance rate при speculative decoding. Пока нет полного набора измерений, разумно воспринимать миллион токенов как гипотезу для проверки, а не как готовую характеристику локального inference-стека.