Время Валеры
Мне платят за то, что я говорю другим людям что им делать. Автор книги https://www.manning.com/books/machine-learning-system-design https://venheads.io https://www.linkedin.com/in/venheads
Show more📈 Analytical overview of Telegram channel Время Валеры
Channel Время Валеры (@cryptovalerii) in the Russian language segment is an active participant. Currently, the community unites 30 784 subscribers, ranking 4 207 in the Technologies & Applications category and 20 850 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 30 784 subscribers.
According to the latest data from 26 August, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 231 over the last 30 days and by 12 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 77.52%. Within the first 24 hours after publication, content typically collects 32.41% reactions from the total number of subscribers.
- Post reach: On average, each post receives 23 860 views. Within the first day, a publication typically gains 9 975 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 418.
- Thematic interests: Content is focused on key topics such as engineer, claude, стартап, архитектура, many.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Мне платят за то, что я говорю другим людям что им делать.
Автор книги https://www.manning.com/books/machine-learning-system-design
https://venheads.io
https://www.linkedin.com/in/venheads”
Thanks to the high frequency of updates (latest data received on 27 August, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
<GIST_1>, <GIST_2> и так далее.
Дальше:
* Все веса модели замораживаются. Обучаются только эмбединги новых gist-токенов.
* Teacher-версия модели получает полный системный промпт, запрос пользователя и начало правильного ответа. На каждой позиции она выдаёт распределение вероятностей следующего токена.
* Student-версия той же самой модели получает тот же запрос и ответ, но вместо 6 000 токенов системного промпта видит 1 500 gist-токенов;
* Распределения teacher и student сравниваются через KL divergence.
* Градиент меняет только эмбединги gist-токенов, пока student не начинает выдавать практически те же распределения ответов, что и teacher.
* Изначально новые эмбединги можно было бы задать случайно. Но Shopify нашли более эффективную инициализацию: исходный промпт разделили на группы по четыре токена, а каждый gist-embedding инициализировали средним значением эмбедингов соответствующей четвёрки. Это снизило начальный loss в семь раз.
При этом <GIST_1> не становится сокращённым обозначением первых четырёх токенов. Все 1 500 embeddings обучаются совместно и в итоге кодируют не текст промпта, а его влияние на поведение модели.
Получаем сжатие поведения: модель учат реагировать на короткую последовательность обучаемых векторов так же, как на длинную текстовую инструкцию.
В результате примерно 6 000 обычных токенов превратились в 1 500 обученных токенов. Модель ведёт себя так, будто прочитала полный промпт, хотя фактически получает его сжатое представление.
После обучения никакой отдельной архитектуры не требуется. Эмбединги записываются в embedding matrix, токены регистрируются в tokenizer, а длинный промпт при запросе просто заменяется их последовательностью. Нет дополнительного encoder, специального attention mask или отдельного serving path.
Результаты при нагрузке 350 запросов в минуту:
— time to first token: с 438 до 354 мс, −19%;
— полная задержка: с 6,8 до 4,2 секунды, −38%;
— throughput: с 20,2 до 23,4 запроса в секунду, +16%;
— требуемое количество GPU: −14%.
Качество при этом не ухудшилось.
Как они подбирали рецепт: Autoresearch-цикл сам менял гиперпараметры, запускал обучение и оценивал результат.
Так нашли оптимальное сжатие 4:1. При дальнейшем уменьшении количества gist-токенов качество начинало падать. Для другой модели, промпта и предметной области граница будет другой.
Предварительный расчёт teacher logits и токенизация сократили один обучающий прогон с 30 до 6 часов.
Оказалось также, что усреднение функции потерь по токенам ответа приводило к галлюцинациям, а усреднение по batch сохраняло больше сигнала от длинных ответов. Хорошее напоминание, что даже в относительно простой оптимизации детали функции потерь могут полностью изменить поведение системы.
Prompt engineering постепенно превращается в обычный ML engineering.
Системный промпт можно рассматривать как исходный код, а gist-токены — как его скомпилированную версию. Здесь всё знакомо: датасет, distillation, loss, evaluation, нагрузочное тестирование, мониторинг качества и стоимости.
#ArticleReviewСожми документ максимально, не потеряв никакой информации.Превратили этот подход в отдельный open-source skill — lossless-doc-compress. Скилл читает документ целиком и относит каждый фрагмент к одной из трёх категорий: KEEP — содержит информацию и остаётся без изменений; REMOVE — доказуемо избыточен и удаляется; FLAG — требует решения автора, поэтому остаётся в документе с пометкой. Он удаляет filler, пустой hedging, LLM-slop, дословные повторы и избыточные формулировки. Сохраняет факты, цифры, решения, оговорки, ограничения, названия систем, код и таблицы. Если есть сомнение — не удалять, дает отметку для автора Результат: три артефакта: Сжатый документ. Лог всех удалений и спорных мест. Scorecard: число слов до/после, процент сокращения и подтверждение сохранности содержания.
npx skills add ML-SystemDesign/MLSystemDesign
Код и инструкция:
https://github.com/ML-SystemDesign/MLSystemDesign/tree/main/skills/lossless-doc-compress
Это пост был прогнан через скилл🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨🎨🎨 В программе четыре продуктовых трека — AI, Data, Security и Hybrid Infrastructure & DevOps, — и отдельный углублённый технологический трек DeepTech, который пройдёт только онлайн.
🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨🎨🎨 В треке DeepTech откроем программу докладом о том, как мы ускорили Lua в Valkey — добавили LuaJIT и Lua 5.5 без патчей интерпретатора и получили прирост скорости до 2–5 раз. Расскажем, как строим экономически эффективный инференс LLM для агентских сценариев в Yandex AI Studio — на примере DeepSeek-V3.2 и DeepSeek-V4-Flash. Разберём, что разваливается в поиске, когда он должен быть одновременно распределённым, транзакционным и линейно масштабируемым — на примере векторного, полнотекстового и гибридного поиска в YDB. Покажем, какая инфраструктура превращает недетерминированную модель в управляемый и наблюдаемый сервис, когда агент выходит из демо в продакшн. Расскажем, как мы первыми в РФ научились мониторить ИИ-агентов внутри «чёрного ящика» LLM. И заглянем под капот сети облака — Interconnect, Private Link, Inbound DNS и DNS Firewall, которые складываются в герметичный контур между Yandex Cloud, on-premises и другими облаками.
🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 Плюс демозоны, питчинг решений, IT-квест и мерч для тех, кто в Москве. А кто смотрит онлайн, помимо трека DeepTech, есть ещё отдельная онлайн-студия: розыгрыш призов и секретный гость.Полную программу можно посмотреть на сайте, там же — зарегистрироваться. Участие бесплатное
Прочитал с кайфом и даже взял на вооружениеНадеюсь, к концу года допишем.
“And you have to realize that there are not very many things that have aged as well as the scheduler. Which is just another proof that scheduling is easy.” Linus Torvalds, 200120 + лет спустя
As a central part of resource management, the OS thread scheduler must maintain the following, simple, invariant: make sure that ready threads are scheduled on available cores. As simple as it may seem, we found that this invariant is often broken in Linux. Cores may stay idle for seconds while ready threads are waiting in runqueues. In our experiments, these performance bugs caused many-fold performance degradation for synchronization-heavy scientific applications, 13% higher latency for kernel make, and a 14-23% decrease in TPC-H throughput for a widely used commercial databaseи
The Group Imbalance bug The bug. We encountered this bug on a multi-user machine which we used to perform kernel compilation and data analsis using the R machine learning package. We suspected that this system, a 64-core, eight-node NUMA server, did not use all available cores for highly-threaded computations, instead crowding all threads on a few nodes. We illustrate this bug with the output from our visual toolСтоит заметить, что их фикс у меня вызывает много сомнений, замена среднего на минимум, для оценки загрузки - многое может пойти не так. Да и в целом, я бы даже не назвал это багами, оптимизировали под свою нагрузку - честь им и хвала, но это не значит что в среднем стало лучше, а не хуже. Самый важный вывод, что понимая систему достаточно глубоко, можно ее взять и допилить очень значимо под себя
