Время Валеры
Мне платят за то, что я говорю другим людям что им делать. Автор книги https://www.manning.com/books/machine-learning-system-design https://venheads.io https://www.linkedin.com/in/venheads
نمایش بیشتر📈 تحلیل کانال تلگرام Время Валеры
کانال Время Валеры (@cryptovalerii) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 30 784 مشترک است و جایگاه 4 207 را در دسته فناوری و برنامهها و رتبه 20 850 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 30 784 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 26 اوت, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر 231 و در ۲۴ ساعت گذشته برابر 12 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 77.52% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 32.41% واکنش نسبت به کل مشترکان کسب میکند.
- دسترسی پستها: هر پست به طور میانگین 23 860 بازدید دریافت میکند. در اولین روز معمولاً 9 975 بازدید جمعآوری میشود.
- واکنشها و تعامل: مخاطبان بهطور فعال حمایت میکنند؛ میانگین واکنش به هر پست 418 است.
- علایق موضوعی: محتوا بر موضوعات کلیدی مانند engineer, claude, стартап, архитектура, many تمرکز دارد.
📝 توضیح و سیاست محتوایی
نویسنده این فضا را محل بیان دیدگاههای شخصی توصیف میکند:
“Мне платят за то, что я говорю другим людям что им делать.
Автор книги https://www.manning.com/books/machine-learning-system-design
https://venheads.io
https://www.linkedin.com/in/venheads”
به لطف بهروزرسانیهای پرتکرار (آخرین داده در تاریخ 27 اوت, 2026)، کانال همواره بهروز و دارای دسترسی بالاست. تحلیلها نشان میدهد مخاطبان بهطور فعال با محتوا تعامل دارند و آن را به نقطه اثرگذاری مهم در دسته فناوری و برنامهها تبدیل کردهاند.
<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Стоит заметить, что их фикс у меня вызывает много сомнений, замена среднего на минимум, для оценки загрузки - многое может пойти не так. Да и в целом, я бы даже не назвал это багами, оптимизировали под свою нагрузку - честь им и хвала, но это не значит что в среднем стало лучше, а не хуже. Самый важный вывод, что понимая систему достаточно глубоко, можно ее взять и допилить очень значимо под себя
