Обновить

Критические расширения - классная и простая идея проектирования, которую я нашел в X.509

Расширение (не имени файла) - хороший способ сделать формат файла или протокола достаточно универсальным. Мы до сих пор пользуемся древними протоколами TCP, HTTP - потому что они расширяемы и поэтому пригодны и сейчас. В HTTP можно напихать любые хидеры, которые его создателям в страшном сне не приснились бы - и все будет работать! В идеальном мире, вы могли бы купить древнюю машинку с Win95 / Office 7.0 и открыть на нем современный документ. Да, лишившись всех новых плюшечек, но хотя бы смогли бы прочитать текст. (Жаль, разработчики Office 7.0 не читали этот пост).

Так вот, в X.509 (RFC 5280) (та самая PKI инфраструктура, на которой все держится, все вот эти вот SSL/TLS/сертификаты) тоже есть расширения. У каждого расширения - идентификатор (естественно, старые реализации не могут знать новые расширения), а еще, внимание - булевый флажок - critical. Всего 1 флаг, 1 бит, но дает огромные возможности! Мы из будущего можем сказать старой программе - либо "ты не знаешь это расширение, но не парься, просто проигнорь и обрабатывай остальное содержимое файла (или запроса) как раньше" либо же "если ты не знаешь, как обрабатывать это - даже не пытайся!". Это просто и удобнее чем версия файла-протокола (мол, если не совпадает - отказ, апгрейд, галя, отмена).

Удивительный способ, как одним битом создать канал для общения между прошлым и будущим, а ПО или устройство сделать условно вечно полезным.

Теги:
Всего голосов 5: ↑3 и ↓2+1
Комментарии1

Как мы запустили Qwen3.8–27B целиком на RTX 5060 8 GB и получили ~30 токенов/с

Наш проект называется ExVRAM Lab. Это открытая исследовательская лаборатория, в которой мы проверяем, насколько большие локальные LLM можно запускать на обычных видеокартах с ограниченным объёмом VRAM, если использовать ultra‑low‑bit quantization, полное размещение весов на GPU и существующие open‑source inference‑технологии.

ExVRAM расшифровывается как Exchange Compute for VRAM. Основная идея проекта — в ряде сценариев выгоднее потратить часть свободной вычислительной мощности GPU на работу с более компактным представлением весов, чем хранить часть модели в оперативной памяти и постоянно передавать данные через PCIe.

Когда мы начинали проект, исходный вопрос был достаточно простой: можно ли запустить dense‑модель примерно на 27 миллиардов параметров на видеокарте всего с 8 ГБ VRAM так, чтобы она не просто «запустилась», а работала полностью на GPU, поддерживала длинный контекст и обеспечивала нормальную интерактивную скорость генерации.

В качестве основной тестовой системы мы используем NVIDIA GeForce RTX 5060 8 GB на архитектуре Blackwell. Основная модель в текущих экспериментах — Qwen3.8–27B.

Сначала результат выглядел не слишком впечатляюще. Модель запускалась, но значительная часть весов оставалась в системной памяти. Около 5,7 GiB весов находилось на GPU, ещё примерно 2,5 GiB — на CPU. Скорость генерации составляла порядка 3,8–5,5 токена в секунду.

При этом сама видеокарта была загружена далеко не полностью.

Это стало одним из первых важных наблюдений проекта. Проблема заключалась не столько в нехватке вычислительной мощности RTX 5060, сколько в том, что часть decoder weights находилась в RAM. Во время autoregressive generation данные приходилось постоянно передавать между CPU и GPU через PCIe.

Как мы запустили Qwen3.8–27B целиком на RTX 5060 8 GB и получили ~30 токенов/с

Публикации