Обновить

В связи с интенсивным сокращением максимального срока действия TLS-сертификатов (пока что обещают 47 дней, но для всех и к 2030 году), коллеги саркастически поинтересовались, можно ли сделать так, чтобы сертификат выписывался на каждый TLS-запрос. Шутки - шутками, но сделать-то можно. И даже не требуется переделывать протокол TLS - есть готовое решение.

Если внимательно посмотреть на алгоритм TLS-хендшейка, то окажется, что секретный ключ, соответствующий открытому ключу из серверного сертификата, требуется там только один раз - для формирования подписи в сообщении CertificateVerify. Соответственно, секретного ключа от сертификата вообще может не быть на сервере, а сервер будет обращаться к некоторому подписывающему узлу, у которого этот ключ есть и который подтвердит TLS-сессию, подписав значение для CertificateVerify. Это вовсе не теоретическое рассуждение, именно так делается на практике, когда входящие соединения принимает прокси-провайдер (CDN, обычно), но передавать этому провайдеру секретные ключи от сертификатов для своих доменов клиент не желает. Первыми в промышленных масштабах такую услугу сделали в Cloudflare, более десяти лет назад. Называется Keyless SSL.

Так что, вместо возни с автоматическим перевыпуском суперкоротких сертификатов, центральный сервис может выдавать квитанции доступа на каждую TLS-сессию. Естественно, TLS-сертифкат сервера должен быть предъявлен раньше, чем отправлено сообщение с подписью CertificateVerify. Однако эти сообщения в TLS передаются сервером одной серией, поэтому, в процессе создания TLS-сессии, сервер сможет сразу же получить от центрального узла и сгенерированный только что сертификат, и соответствующую подпись, собрать это всё вместе и отправить клиенту.

Сертификат, таким образом, окончательно превратится в безотзывный тикет доступа, мгновенного действия, а сервер будет привязан к центральному провайдеру (можно совместить с крупными CDN, у которых и так есть собственные хорошо известные УЦ). Проверку совпадения подписей, серверной и на сертификате, будет всё так же проводить браузер (речь, напомню, про веб). В браузере ничего не нужно переделывать совсем: если сервер не смог предъявить корректную подпись в CertificateVerify - TLS-сессия браузером установлена не будет.

Это, если что, была минутка технологического юмора. Но вот то, что развитие инфраструктуры TLS-сертификатов в вебе движется в сторону тикетов доступа (или, скорее, квитанций) - отрицать всё сложнее.

Теги:
Всего голосов 4: ↑4 и ↓0+6
Комментарии5

Как мы запустили 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 токенов/с

Публикации