Время Валеры
Мне платят за то, что я говорю другим людям что им делать. Автор книги https://www.manning.com/books/machine-learning-system-design https://venheads.io https://www.linkedin.com/in/venheads
Ko'proq ko'rsatish📈 Telegram kanali Время Валеры analitikasi
Время Валеры (@cryptovalerii) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 30 784 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 4 207-o'rinni va Rossiya mintaqasida 20 850-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 30 784 obunachiga ega bo‘ldi.
26 Avgust, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 231 ga, so‘nggi 24 soatda esa 12 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 77.52% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 32.41% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 23 860 marta ko‘riladi; birinchi sutkada odatda 9 975 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 418 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent engineer, claude, стартап, архитектура, many kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Мне платят за то, что я говорю другим людям что им делать.
Автор книги https://www.manning.com/books/machine-learning-system-design
https://venheads.io
https://www.linkedin.com/in/venheads”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 27 Avgust, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
<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Стоит заметить, что их фикс у меня вызывает много сомнений, замена среднего на минимум, для оценки загрузки - многое может пойти не так. Да и в целом, я бы даже не назвал это багами, оптимизировали под свою нагрузку - честь им и хвала, но это не значит что в среднем стало лучше, а не хуже. Самый важный вывод, что понимая систему достаточно глубоко, можно ее взять и допилить очень значимо под себя
