From fe0dbbe509c88a10aa8af702842e2c37a17b7625 Mon Sep 17 00:00:00 2001 From: Oleg Sukhoroslov Date: Sun, 6 Sep 2026 19:26:12 +0300 Subject: [PATCH] first commit --- README.md | 28 +++ about.md | 30 ++++ grading.md | 164 ++++++++++++++++++ llm.md | 7 + project-checkpoints/01-project-plan.md | 53 ++++++ project-checkpoints/02-working-result.md | 24 +++ .../03-intermediate-results.md | 26 +++ project-checkpoints/README.md | 53 ++++++ project-final.md | 47 +++++ project-repository-template/README.md | 31 ++++ .../nis/checkpoints/01.md | 36 ++++ .../nis/checkpoints/02.md | 39 +++++ .../nis/checkpoints/03.md | 35 ++++ .../nis/experiment-plan.md | 33 ++++ project-repository-template/nis/final.md | 42 +++++ project-repository-template/nis/project.md | 25 +++ project-repository-template/nis/results.md | 27 +++ project-repository-template/nis/status.md | 19 ++ project-repository.md | 50 ++++++ project-tasks/README.md | 86 +++++++++ project-tasks/p01-remix.md | 29 ++++ project-tasks/p02-dupchecker.md | 29 ++++ project-tasks/p03-a-acto-state-search.md | 29 ++++ .../p03-b-acto-oracles-and-shrinking.md | 29 ++++ project-tasks/p04-legolas.md | 29 ++++ project-tasks/p05-sieve.md | 29 ++++ project-tasks/p06-superbench.md | 29 ++++ .../p07-a-deathstarbench-tail-latency.md | 29 ++++ .../p07-b-deathstarbench-placement.md | 29 ++++ project-tasks/p08-pgval.md | 29 ++++ .../p09-a-foundationdb-transactions.md | 29 ++++ .../p09-b-foundationdb-simulation.md | 29 ++++ project-tasks/p10-detock.md | 29 ++++ project-tasks/p11-clay-codes.md | 29 ++++ .../p12-a-clickhouse-data-skipping.md | 29 ++++ .../p12-b-clickhouse-vectorized-pipeline.md | 29 ++++ project-tasks/p13-noria.md | 29 ++++ project-tasks/p14-a-flink-checkpoints.md | 29 ++++ .../p14-b-flink-rescaling-recovery.md | 29 ++++ project-tasks/p15-autothrottle.md | 29 ++++ project-tasks/p16-oakestra.md | 29 ++++ project-tasks/p17-skypilot.md | 29 ++++ project-tasks/p18-faasm.md | 29 ++++ project-tasks/p19-serverless-cold-starts.md | 29 ++++ project-tasks/p20-cloudcast.md | 29 ++++ project-tasks/p21-dbsp-feldera.md | 29 ++++ project-tasks/p22-dctcp.md | 29 ++++ project-tasks/p23-pagedattention.md | 29 ++++ project-tasks/p24-llumnix.md | 29 ++++ project-tasks/p25-a-ray-task-graphs.md | 29 ++++ project-tasks/p25-b-ray-actors-recovery.md | 29 ++++ .../p26-a-parrot-graph-scheduling.md | 29 ++++ project-tasks/p26-b-parrot-prefix-locality.md | 29 ++++ project-tasks/p27-dede.md | 29 ++++ project-tasks/p28-distserve.md | 29 ++++ project-tasks/p29-mooncake.md | 29 ++++ project-tasks/p30-pollux.md | 29 ++++ project-tasks/p31-a-gc3-correctness.md | 29 ++++ .../p31-b-gc3-topology-optimization.md | 29 ++++ project-tasks/p32-alea-bft.md | 33 ++++ project.md | 155 +++++++++++++++++ projects/README.md | 13 ++ projects/_template.md | 31 ++++ schedule.md | 41 +++++ seminars.md | 143 +++++++++++++++ seminars/01-2026-09-14-metastable-failures.md | 51 ++++++ seminars/02-2026-09-21-foundationdb.md | 45 +++++ seminars/03-2026-09-28-kora.md | 45 +++++ seminars/04-2026-10-12-alea-bft.md | 45 +++++ seminars/05-2026-10-19-rainmaker.md | 45 +++++ seminars/06-2026-11-02-boki.md | 45 +++++ ...-2026-11-16-partitioned-synchronization.md | 45 +++++ seminars/08-2026-11-23-oakestra.md | 45 +++++ seminars/09-2026-11-30-dangling-resources.md | 45 +++++ seminars/10-2026-12-14-jupiter-evolving.md | 45 +++++ seminars/11-2027-01-11-vedb-htap.md | 45 +++++ seminars/12-2027-01-18-manu.md | 45 +++++ seminars/13-2027-01-25-pond.md | 45 +++++ .../14-2027-02-08-who-watches-the-watchers.md | 45 +++++ seminars/15-2027-02-15-superbench.md | 45 +++++ seminars/16-2027-03-01-pagedattention.md | 45 +++++ seminars/17-2027-03-09-megascale.md | 45 +++++ seminars/18-2027-03-15-thunderagent.md | 47 +++++ seminars/README.md | 46 +++++ 84 files changed, 3266 insertions(+) create mode 100644 README.md create mode 100644 about.md create mode 100644 grading.md create mode 100644 llm.md create mode 100644 project-checkpoints/01-project-plan.md create mode 100644 project-checkpoints/02-working-result.md create mode 100644 project-checkpoints/03-intermediate-results.md create mode 100644 project-checkpoints/README.md create mode 100644 project-final.md create mode 100644 project-repository-template/README.md create mode 100644 project-repository-template/nis/checkpoints/01.md create mode 100644 project-repository-template/nis/checkpoints/02.md create mode 100644 project-repository-template/nis/checkpoints/03.md create mode 100644 project-repository-template/nis/experiment-plan.md create mode 100644 project-repository-template/nis/final.md create mode 100644 project-repository-template/nis/project.md create mode 100644 project-repository-template/nis/results.md create mode 100644 project-repository-template/nis/status.md create mode 100644 project-repository.md create mode 100644 project-tasks/README.md create mode 100644 project-tasks/p01-remix.md create mode 100644 project-tasks/p02-dupchecker.md create mode 100644 project-tasks/p03-a-acto-state-search.md create mode 100644 project-tasks/p03-b-acto-oracles-and-shrinking.md create mode 100644 project-tasks/p04-legolas.md create mode 100644 project-tasks/p05-sieve.md create mode 100644 project-tasks/p06-superbench.md create mode 100644 project-tasks/p07-a-deathstarbench-tail-latency.md create mode 100644 project-tasks/p07-b-deathstarbench-placement.md create mode 100644 project-tasks/p08-pgval.md create mode 100644 project-tasks/p09-a-foundationdb-transactions.md create mode 100644 project-tasks/p09-b-foundationdb-simulation.md create mode 100644 project-tasks/p10-detock.md create mode 100644 project-tasks/p11-clay-codes.md create mode 100644 project-tasks/p12-a-clickhouse-data-skipping.md create mode 100644 project-tasks/p12-b-clickhouse-vectorized-pipeline.md create mode 100644 project-tasks/p13-noria.md create mode 100644 project-tasks/p14-a-flink-checkpoints.md create mode 100644 project-tasks/p14-b-flink-rescaling-recovery.md create mode 100644 project-tasks/p15-autothrottle.md create mode 100644 project-tasks/p16-oakestra.md create mode 100644 project-tasks/p17-skypilot.md create mode 100644 project-tasks/p18-faasm.md create mode 100644 project-tasks/p19-serverless-cold-starts.md create mode 100644 project-tasks/p20-cloudcast.md create mode 100644 project-tasks/p21-dbsp-feldera.md create mode 100644 project-tasks/p22-dctcp.md create mode 100644 project-tasks/p23-pagedattention.md create mode 100644 project-tasks/p24-llumnix.md create mode 100644 project-tasks/p25-a-ray-task-graphs.md create mode 100644 project-tasks/p25-b-ray-actors-recovery.md create mode 100644 project-tasks/p26-a-parrot-graph-scheduling.md create mode 100644 project-tasks/p26-b-parrot-prefix-locality.md create mode 100644 project-tasks/p27-dede.md create mode 100644 project-tasks/p28-distserve.md create mode 100644 project-tasks/p29-mooncake.md create mode 100644 project-tasks/p30-pollux.md create mode 100644 project-tasks/p31-a-gc3-correctness.md create mode 100644 project-tasks/p31-b-gc3-topology-optimization.md create mode 100644 project-tasks/p32-alea-bft.md create mode 100644 project.md create mode 100644 projects/README.md create mode 100644 projects/_template.md create mode 100644 schedule.md create mode 100644 seminars.md create mode 100644 seminars/01-2026-09-14-metastable-failures.md create mode 100644 seminars/02-2026-09-21-foundationdb.md create mode 100644 seminars/03-2026-09-28-kora.md create mode 100644 seminars/04-2026-10-12-alea-bft.md create mode 100644 seminars/05-2026-10-19-rainmaker.md create mode 100644 seminars/06-2026-11-02-boki.md create mode 100644 seminars/07-2026-11-16-partitioned-synchronization.md create mode 100644 seminars/08-2026-11-23-oakestra.md create mode 100644 seminars/09-2026-11-30-dangling-resources.md create mode 100644 seminars/10-2026-12-14-jupiter-evolving.md create mode 100644 seminars/11-2027-01-11-vedb-htap.md create mode 100644 seminars/12-2027-01-18-manu.md create mode 100644 seminars/13-2027-01-25-pond.md create mode 100644 seminars/14-2027-02-08-who-watches-the-watchers.md create mode 100644 seminars/15-2027-02-15-superbench.md create mode 100644 seminars/16-2027-03-01-pagedattention.md create mode 100644 seminars/17-2027-03-09-megascale.md create mode 100644 seminars/18-2027-03-15-thunderagent.md create mode 100644 seminars/README.md diff --git a/README.md b/README.md new file mode 100644 index 0000000..1f227a1 --- /dev/null +++ b/README.md @@ -0,0 +1,28 @@ +# НИС «Распределённые системы 2» + +НИС для студентов 4 курса специализации «Распределённые системы». Курс проходит онлайн с сентября по март и сочетает обсуждение современных научных статей с командным исследовательско-инженерным проектом. + +## Важные ссылки + +- [Канал курса](https://t.me/+qHWHUT_ZYFU2M2My) +- [Чат курса](https://t.me/+0Q-7K_sKtSQyN2Yy) +- [Подключение к онлайн-занятию](https://my.mts-link.ru/j/19605137/24631961487) +- Таблица с оценками +- Записи занятий +- Форма подачи тезисов +- Опрос после семинара + +## Навигация + +- [О курсе](about.md) — цели, содержание и формат курса. +- [Расписание](schedule.md) — даты, номера и статьи ролевых семинаров, контрольные точки и экзаменационные дни. +- [Ролевые семинары](seminars.md) — подготовка, задачи ролей, порядок и продолжительность выступлений, оценивание, тезисы, обмены и пропуски. +- [Карточки ролевых семинаров](seminars/README.md) — статьи, участники, маршруты чтения, выбранные тезисы, записи и итоги обсуждений. +- [Командный проект](project.md) — календарь проекта, формирование команд, общие требования, опросы и защита. +- [Репозиторий команды](project-repository.md) — обязательные файлы, доступ преподавателя и сдача через PR/MR. +- [Контрольные точки проекта](project-checkpoints/README.md) — порядок сдачи, статусы и требования к трём этапам. +- [Финальная версия проекта](project-final.md) — подготовка итогового комплекта перед защитой. +- [Карточки выполняемых проектов](projects/README.md) — команды, репозитории, статусы сдач и итоговые материалы. +- [Банк проектных заданий](project-tasks/README.md) — варианты статей, технических результатов и экспериментов. +- [Оценивание и пересдачи](grading.md) — компоненты оценки, формулы, пороги и порядок пересдач. +- [Использование LLM](llm.md) — разрешённые способы применения, требования к описанию использования и ограничения во время индивидуальных ответов. diff --git a/about.md b/about.md new file mode 100644 index 0000000..229cab4 --- /dev/null +++ b/about.md @@ -0,0 +1,30 @@ +# О курсе + +НИС «Распределённые системы 2» проходит на 4 курсе специализации «Распределённые системы». Курс идёт онлайн с сентября по март и посвящён современной исследовательской и инженерной работе в области распределённых систем. + +На НИС-2 вы будете читать и обсуждать современные научные статьи, разбирать происхождение и развитие их идей, оценивать качество исследований и практическую применимость результатов. Параллельно ролевым семинарам команда воспроизводит и экспериментально проверяет существенный результат выбранной статьи, оформляет воспроизводимые материалы и защищает выводы. + +Регулярных письменных домашних заданий нет. Основная работа состоит из двух ролевых выступлений, командного исследовательско-инженерного проекта и его защиты. + +## Цели курса + +К концу курса вы сможете: + +- самостоятельно разбираться в новой научной работе и необходимых связанных источниках; +- выделять исследовательский вопрос, предпосылки, метод, доказательства и ограничения; +- критически оценивать экспериментальную методику и границы выводов; +- формулировать проверяемые вопросы и проводить воспроизводимые эксперименты; +- объяснять принятые решения, аргументировать выводы и защищать собственный результат. + +Курс также расширяет научно-инженерный кругозор: знакомит с современными системами, основаниями их архитектурных решений и компромиссами, которые возникают при переходе от исследовательской идеи к практике. + +## Как устроен курс + +| Часть курса | Что предстоит сделать | +|---|---| +| **Ролевые семинары** | Выступить дважды: один раз как автор или рецензент и один раз как археолог, исследователь или практик. Всего в расписании 18 статей. | +| **Командный проект** | В команде обычно из трёх человек получить готовое проектное задание, создать технический результат, провести корректный эксперимент и пройти три контрольные точки. | +| **Защита проекта** | Представить общий результат команды и индивидуально ответить на вопросы о своей работе, методике, результатах и ограничениях. | +| **Дополнительные тезисы** | В день без назначенной роли можно заранее предложить тезис к статье и принять участие в его обсуждении. Зачтённые обсуждения входят в условия оценок 9–10. | + +Посещение обязательно, если на занятии назначена роль. На остальные ролевые семинары можно приходить по интересу. Подробная формула и условия итоговой оценки приведены в [правилах оценивания](grading.md). diff --git a/grading.md b/grading.md new file mode 100644 index 0000000..3c5c73c --- /dev/null +++ b/grading.md @@ -0,0 +1,164 @@ +# Оценивание + +В курсе три формальных элемента контроля: + +| Элемент | Вес | +|---|---:| +| Первое ролевое выступление `Р1` | 15% | +| Второе ролевое выступление `Р2` | 15% | +| Проектный экзамен `Экз` | 70% | + +Проектный экзамен объединяет оценивание итоговых материалов проекта `ПР` и защиту `ЗП`. Балл `ПР` выставляется в конце курса по результатам проекта и свидетельствам работы в течение курса. Блокирующих элементов нет. Итог определяется общей формулой, правилами об индивидуальном участии и понимании, минимальном экспериментальном результате и дополнительными условиями для 9–10. + +## Обозначения + +В формулах используются краткие русские обозначения. Цифры в `Р1` и `Р2` обозначают первое и второе выступления. + +| Обозначение | Значение | +|---|---| +| `Р1`, `Р2` | Ролевые выступления | +| `Р` | Сумма оценок за два ролевых выступления | +| `Экз` | Проектный экзамен | +| `ПР` | Работа над проектом | +| `ЗП` | Защита проекта | +| `КР` | Командный результат | +| `КТ` | Контрольные точки | +| `ТР` | Технический результат | +| `Э` | Эксперимент и выводы | +| `ВО` | Воспроизводимость и отчёт | +| `ИР` | Индивидуальная работа | +| `Д` | Командный доклад | +| `ПП` | Понимание проекта | +| `Б` | Базовая оценка до округления | +| `Бокр` | Базовая оценка после округления | + +## Ролевые выступления + +Каждое выступление получает целое число `Р1` или `Р2` от 0 до 10 как сумму [пяти критериев](seminars.md#оценивание-выступления) по 0–2 балла: + +```text +Р = Р1 + Р2 +``` + +Первичные баллы по критериям и компонентам используются в расчёте. Удовлетворительной или неудовлетворительной является итоговая десятибалльная оценка по дисциплине после применения общей формулы, округления и ограничений. + +## Материалы проекта + +Командный результат `КР` складывается из четырёх критериев. Полный результат по `ТР` и `Э` определяется обязательным результатом назначенного проектного задания. + +| Критерий | 0 баллов | 1 балл: пригодный, но ограниченный результат | 2 балла: полный результат | +|---|---|---|---| +| `КТ` — контрольные точки | Условие для 1 балла не выполнено. | Как минимум две точки зачтены хотя бы частично, но не все три — полностью. | Все три точки зачтены. | +| `ТР` — технический результат | Проверяемого технического результата нет. | Работает существенная часть обязательного пути, но один центральный механизм, baseline или автоматическая проверка корректности заменены ограниченным вариантом. | Выполнен обязательный технический результат задания, центральные варианты запускаются на сопоставимых входах, корректность проверяется автоматически. | +| `Э` — эксперимент и выводы | Корректного эксперимента и обоснованных выводов нет. | Есть корректное сравнение хотя бы в одном содержательном режиме, но не исследована часть обязательных метрик, режимов или повторов. | Проведены обязательные сравнения и повторы, разобрана вариативность, а выводы следуют из данных и учитывают альтернативные объяснения. | +| `ВО` — воспроизводимость и технический отчёт | Проверяемых материалов недостаточно для воспроизведения и оценки результата. | Результат воспроизводится после ручной подготовки; часть конфигураций, сырых данных или ограничений описана неполно. | Сокращённый запуск воспроизводится по инструкции, полный протокол и сырые данные сохранены, графики перестраиваются автоматически, отчёт ясно отделяет полученное от опубликованного. | + +Критерии `КТ`, `ТР` и `ВО` оцениваются по фактически выполненным требованиям каждого из них. Ноль за `Э` не снижает эти оценки: технические проблемы и неполнота материалов учитываются в соответствующих критериях. Корректный отрицательный результат или доказательно разобранное расхождение со статьёй оцениваются по обычной шкале `Э`. + +Точка зачтена, если её требования выполнены по существу в установленный срок; частично зачтена, если есть проверяемый содержательный результат, но существенная часть требований отсутствует, либо результат исправлен поздно; не зачтена, если материалов недостаточно для подтверждения содержательного результата этапа. Мелкие редакторские недостатки отражаются в обратной связи и сами по себе не снижают статус. + +Документированная блокировка может считаться зачтённой контрольной точкой, если команда представляет воспроизводимую диагностику, предпринятые проверки, анализ причин, влияние на обязательный результат и обновлённый план. Одного сообщения о проблеме недостаточно; блокировка сама по себе не заменяет итоговый эксперимент. Добросовестно проверенная и документированная ошибка задания не снижает статус точки. Требования к результатам и свидетельствам приведены в [описании контрольных точек](project-checkpoints/README.md). + +Индивидуальная работа `ИР`: + +- `ИР=0`: проверяемого содержательного вклада нет; +- `ИР=1`: есть полезная, но частичная или неустойчивая работа без полной ответственности за согласованную часть; +- `ИР=2`: студент самостоятельно и надёжно выполнил согласованную содержательную часть и включил её в общий результат. + +При `ИР=0` студент получает `ПР=0` и `ЗП=0` независимо от результатов команды. Правило применяется индивидуально и не меняет оценки остальных участников. + +При `ИР≥1` балл за материалы проекта вычисляется без промежуточного округления: + +```text +КР = КТ + ТР + Э + ВО +ПР = 0,75 × КР + 2 × ИР +``` + +`ИР=2` — полное выполнение обычной командной роли. Оно не требует лидерства или исключительного результата и может быть у всех участников. Число коммитов, строк кода и затраченное время не оцениваются. + +Для `ИР` используются карточки ответственности, результаты контрольных точек, код, данные, эксперименты, решения, разделы отчёта, конфиденциальная обратная связь и индивидуальные ответы. Если решение между соседними уровнями пограничное, требуются согласующиеся свидетельства минимум из двух каналов. Объём активности в репозитории сам по себе отдельным каналом не считается. До окончательной фиксации `ИР` и `ПП` студент может указать пропущенное проверяемое свидетельство. + +Конфиденциальные опросы дают дополнительную информацию и не образуют автоматических коэффициентов. Пропуск опроса сам по себе не снижает оценку. Ответы и авторство не публикуются дословно. + +Промежуточная числовая оценка `ИР` не выставляется. Если свидетельств недостаточно или есть риск `ИР≤1`, преподаватель оставляет адресное предупреждение с ожидаемым проверяемым результатом и сроком. После второго опроса такое предупреждение получают также студенты, для которых пока нет оснований ожидать `ИР=2`. Командную и индивидуальную обратную связь, включая предупреждения, можно размещать в публичных PR/MR; отдельное личное сообщение не требуется. Конфиденциальные ответы и личные обстоятельства публично не раскрываются. Предупреждение не меняет оценку автоматически. Отсутствие предупреждения не гарантирует итоговый уровень `ИР`. + +## Защита + +Командный доклад `Д` оценивается так: + +- `Д=0`: проверяемый командный результат не представлен; +- `Д=1`: постановка и основные результаты представлены, но изложение или обоснование имеют существенные ограничения; +- `Д=2`: постановка, основные результаты, выводы и ограничения представлены ясно, доказательно и с соблюдением времени. + +Индивидуальное понимание `ПП`: + +- `ПП=0`: студент не может объяснить свои решения и основные результаты; +- `ПП=1`: объясняет собственную часть, но имеет существенные пробелы в понимании общей методики, результатов или ограничений; +- `ПП=2`: самостоятельно объясняет свою работу, основную методику, ключевые результаты и ограничения. + +При `ИР≥1` и состоявшейся защите: + +```text +ЗП = Д + 4 × ПП +``` + +`ПП=2` также означает полное обычное понимание проекта и может быть у всех участников. + +## Итоговая оценка + +```text +Экз = (5 × ПР + 2 × ЗП) / 7 +Б = 0,15 × Р1 + 0,15 × Р2 + 0,70 × Экз +``` + +Эта запись сохраняет веса `ПР` и `ЗП` в итоговой оценке равными 50% и 20%. Промежуточные значения, включая `ПР`, `ЗП` и `Экз`, не округляются. `Б` округляется до ближайшего целого, причём 0,5 округляется вверх; округлённый результат обозначается `Бокр`. + +Сначала определяется оценка с учётом расширенной части курса: + +- по умолчанию — `min(Бокр, 8)`; +- для **9** нужны `Бокр≥8` и одно из сочетаний: два зачтённых обсуждения тезисов либо проектное достижение и хотя бы одно зачтённое обсуждение; +- для **10** нужны `Бокр≥9`, проектное достижение и два зачтённых обсуждения тезисов. + +Выбирается наибольшая оценка, для которой выполнены условия. Повышение относительно `Бокр` составляет максимум один балл: при `Бокр=8` даже проектное достижение и два обсуждения позволяют получить только 9. + +Затем применяются ограничения итоговой оценки: + +| Условие | Максимальный итог | +|---|---:| +| Неявка на ролевое выступление без своевременного обращения | 7 | +| `ПП=0` | 5 | +| `ИР<2` или `ПП<2` | 7 | +| `Э=0` | 7 | + +При сочетании условий действует наиболее строгий предел; оценка ниже предела не повышается. Дополнительные достижения и тезисы не отменяют этих ограничений. Итог ниже 4 означает, что курс не пройден. + +Подробные требования к [дополнительному достижению по проекту](project-final.md#дополнительное-достижение) и правила подачи и зачёта [дополнительных тезисов](seminars.md#дополнительные-тезисы) приведены в описаниях соответствующих работ. + +Проектное достижение и обсуждения тезисов не дают дополнительных баллов в `ИР`, `ПП` и `Б`. Полное обычное выполнение программы даёт не более 8; оценки 9–10 не ограничены квотой, но требуют проверяемого результата сверх обычной программы. + +## Примеры расчёта + +- При полном обычном выполнении (`Р1=Р2=10`, `КТ=ТР=Э=ВО=2`, `ИР=ПП=Д=2`) получается `ПР=10`, `ЗП=10`, `Б=10`, а итог без расширенной части равен 8. +- При том же результате два зачтённых обсуждения дают 9; проектное достижение и два обсуждения дают 10. +- Одно пропущенное выступление при втором выступлении на 10 и максимальных проектных баллах даёт `Б=8,5`. При неявке без своевременного обращения итог ограничивается 7; при своевременном обращении применяется обычный порядок расчёта. +- При `ИР=0` значения `ПР` и `ЗП` равны 0. При `ПП=0` итог ограничен 5, при `Э=0` — 7. +- При неявке на защиту `ЗП=0`, а рассчитанный по представленным материалам `ПР` сохраняется. +- Возможна ситуация `Экз≥4` при итоговой оценке ниже 4. Например, при `Р1=Р2=0`, `ПР=4,25` и `ЗП=5` получаем `Экз≈4,46`, `Б=3,125` и итог 3. В ведомость вносится итог 3; первичный балл `Экз` не понижается. + +## Пропуск защиты и пересдачи + +При неявке на защиту студент получает `ПП=0` и `ЗП=0`, а оценка представленных материалов `ПР` сохраняется. Отсутствие одного участника не снижает `Д` остальных. Уважительность отсутствия и новый срок оформляются через учебный офис. + +В экзаменационную ведомость вносится итоговая оценка по дисциплине. Итог ниже 4 образует академическую задолженность, в том числе при первичном балле `Экз≥4`. В этом случае студент пересдаёт проектный экзамен целиком: представляет материалы проекта и проходит индивидуальную защиту. Оценки за `Р1`, `Р2` и исходный `КТ` сохраняются. + +На пересдаче можно использовать достаточные исходные материалы без обязательного расширения проекта. При необходимости студент индивидуально исправляет или развивает работу. Если исходный проект объективно недоступен, преподаватель назначает задачу на воспроизведение с сопоставимыми результатами обучения. При `ИР′≥1` без промежуточного округления действуют формулы: + +```text +ПР′ = 0,75 × (КТ + ТР′ + Э′ + ВО′) + 2 × ИР′ +ЗП′ = Д′ + 4 × ПП′ +Экз′ = (5 × ПР′ + 2 × ЗП′) / 7 +``` + +При `ИР′=0` значения `ПР′` и `ЗП′` равны 0. Исходный `ИР=0` не препятствует подтверждению работы на пересдаче. При неявке на защиту выставляются `ПП′=0` и `ЗП′=0`, а представленные материалы оцениваются как `ПР′`. + +Первую пересдачу принимает преподаватель, вторую — комиссия не менее чем из трёх преподавателей. После каждой попытки итог рассчитывается заново по общей формуле с сохранёнными `Р1`, `Р2` и `КТ`. Например, при нулевых ролевых выступлениях и `КТ=0` максимально возможны `ПР′=8,5`, `ЗП′=10` и итог 6, поэтому закрыть задолженность можно. Задолженность ликвидирована при итоговой оценке не ниже 4. Положительная итоговая оценка не пересдаётся для повышения. Ограничения итоговой оценки сохраняются при пересдаче; пересдача не заменяет тезисы и достижения, требуемые для 9–10. diff --git a/llm.md b/llm.md new file mode 100644 index 0000000..5abc5be --- /dev/null +++ b/llm.md @@ -0,0 +1,7 @@ +# Использование LLM + +LLM можно использовать как вспомогательный инструмент при чтении статей, программировании, разборе ошибок, планировании экспериментов и редактировании текста. Студент и команда отвечают за корректность кода, достоверность результатов и понимание работы. + +Если генеративная модель использовалась при подготовке оцениваемого материала, в нём должен быть раздел «Описание применения генеративной модели» с целью, конкретной моделью, её источником и способом применения. Требование соответствует [правилам использования ИИ студентами НИУ ВШЭ](https://www.hse.ru/studyspravka/ai_guidelines/). + +Во время индивидуальных ответов на ролевом семинаре и экзаменационной защите запрещены LLM, внешняя помощь и общение с другими лицами. diff --git a/project-checkpoints/01-project-plan.md b/project-checkpoints/01-project-plan.md new file mode 100644 index 0000000..3a8c70d --- /dev/null +++ b/project-checkpoints/01-project-plan.md @@ -0,0 +1,53 @@ +# Первая контрольная точка: план проекта и эксперимента + +- **Сдать материалы:** до 03.11.2026, 23:59. +- **Ветка:** `nis/checkpoint-1`. +- **Файл точки:** `nis/checkpoints/01.md`. + +Команда уточняет обязательный результат назначенного задания и проверяет, что выбранный технический путь реалистичен в доступном окружении. Полный сквозной эксперимент на этом этапе не требуется. + +## Требуемый результат + +В `nis/project.md` нужно зафиксировать: + +- состав реализации и поддерживаемые сценарии; +- допустимые упрощения; +- способы проверки завершённости обязательной работы; +- выбранный технический путь. + +Технические предпосылки проверяются с учётом выбранного пути: + +- для авторского артефакта — доступность кода и данных, сборка и минимальный запуск; +- для самостоятельной реализации — достаточность описания метода, минимальный прототип и способ проверки корректности; +- для симулятора — допущения, доступный эталон и способ проверки адекватности. + +Команда фиксирует фактически доступные ресурсы, проверяет их достаточность и измеримость показателей, прикладывает краткую инструкцию и воспроизводимые свидетельства выполненных проверок. + +В `nis/experiment-plan.md` описываются baseline, данные или нагрузки, конфигурации, метрики, параметры, серии, повторы, проверка корректности и способ обработки и анализа результатов. + +Если добросовестная проверка выявила ошибочную предпосылку проектного задания, команда прикладывает диагностику и проверяемые свидетельства. Документированная ошибка задания не снижает статус точки. Преподаватель уточняет задание или, если сопоставимое уточнение невозможно, назначает другое свободное задание и письменно корректирует сроки и объём. + +## Структура `nis/checkpoints/01.md` + +```markdown +# Контрольная точка 1 + +## Краткий результат + +## Проверенные технические предпосылки + +## Фактические ресурсы и измеримость показателей + +## Инструкция и воспроизводимые свидетельства + +## Ссылки на детализацию и план эксперимента + +- [Детализация проекта](../project.md) +- [План эксперимента](../experiment-plan.md) + +## Открытые риски и следующие действия + +## Ответственность участников +``` + +Общие правила сдачи и карточка ответственности приведены на [странице контрольных точек](README.md). diff --git a/project-checkpoints/02-working-result.md b/project-checkpoints/02-working-result.md new file mode 100644 index 0000000..7ce9bc6 --- /dev/null +++ b/project-checkpoints/02-working-result.md @@ -0,0 +1,24 @@ +# Вторая контрольная точка: первый работающий результат + +- **Сдать материалы:** до 02.12.2026, 23:59. +- **Ветка:** `nis/checkpoint-2`. +- **Файл точки:** `nis/checkpoints/02.md`. + +Команда показывает один содержательный сквозной сценарий: входные данные проходят через работающий центральный механизм, после чего собираются метрики и получается обработанный результат. Масштаб может быть небольшим. + +## Требуемый результат + +Материалы включают: + +- инструкцию запуска и использованную конфигурацию; +- короткую запись демонстрации; +- пример исходных измерений и результат их обработки; +- свидетельства проверки корректности; +- для модели — проверку адекватности на доступном эталоне; +- действующие упрощения и ещё не реализованные обязательные части. + +К этой точке достаточно одного работающего варианта. Baseline, полная экспериментальная серия и устойчивые выводы пока не требуются. + +Результат и ссылки оформляются в `nis/checkpoints/02.md`. Файл содержит краткий итог, команды запуска, конфигурацию, ссылки на демонстрацию, исходные и обработанные данные, проверку корректности, ограничения, риски и карточки ответственности участников. Можно начать с [шаблона файла](../project-repository-template/nis/checkpoints/02.md). + +Общие правила сдачи и статусы приведены на [странице контрольных точек](README.md). diff --git a/project-checkpoints/03-intermediate-results.md b/project-checkpoints/03-intermediate-results.md new file mode 100644 index 0000000..a776b7a --- /dev/null +++ b/project-checkpoints/03-intermediate-results.md @@ -0,0 +1,26 @@ +# Третья контрольная точка: промежуточные результаты + +- **Сдать материалы:** до 27.01.2027, 23:59. +- **Ветка:** `nis/checkpoint-3`. +- **Файл точки:** `nis/checkpoints/03.md`. + +Команда представляет промежуточное сравнение основного метода с предусмотренным заданием baseline и уточняет план завершения проекта. + +## Требуемый результат + +Материалы включают: + +- хотя бы одно содержательное сравнение основного метода с baseline; +- сопоставимые входы и конфигурации; +- исходные измерения и обработанную таблицу или график; +- необходимые повторы: для недетерминированных измерений не менее трёх, если задание явно не требует большего числа; +- предварительную интерпретацию и сопоставление с результатами статьи; +- разбор расхождений, альтернативных объяснений и ограничений; +- оставшуюся обязательную работу, сроки и ответственных; +- отдельное описание возможного самостоятельного продолжения. + +Сопоставление со статьёй учитывает различия стендов и может проверять тенденции и механизм. Совпадение абсолютных значений не требуется. Корректный отрицательный результат допускается на общих основаниях. Основное воспроизведение завершается к итоговой сдаче **19 марта 2027 года, 23:59**. + +Результат и ссылки оформляются в `nis/checkpoints/03.md`. Можно начать с [шаблона файла](../project-repository-template/nis/checkpoints/03.md). + +Общие правила сдачи и статусы приведены на [странице контрольных точек](README.md). diff --git a/project-checkpoints/README.md b/project-checkpoints/README.md new file mode 100644 index 0000000..7161505 --- /dev/null +++ b/project-checkpoints/README.md @@ -0,0 +1,53 @@ +# Контрольные точки проекта + +Контрольные точки фиксируют проверяемый результат команды и помогают вовремя обнаружить технические и организационные риски. Подробные требования к этапам: + +1. [Проверка и детализация проектного задания, план эксперимента](01-project-plan.md). +2. [Первый работающий результат](02-working-result.md). +3. [Промежуточные результаты и уточнение плана](03-intermediate-results.md). + +Даты сдачи материалов, занятий и обратной связи приведены в [календаре проекта](../project.md#сроки-контрольных-точек). + +## Порядок сдачи + +Каждая точка сдаётся через отдельную ветку и PR/MR по [общим правилам репозитория](../project-repository.md#сдача-через-prmr). В описании PR/MR команда указывает полный хеш сдаваемого коммита, краткий результат и ссылки на файл точки и связанные материалы. После срока историю ветки нельзя переписывать с помощью перебазирования или `force-push`. + +Материалы включают запись об ответственности каждого участника: + +```text +Участник: +Согласованная ответственность за период: +Полученный результат и ссылки на материалы: +Существенное изменение, решение или блокировка: +Следующая ответственность: +Виды работы (необязательно): +``` + +Запись кратко фиксирует результаты без учёта затраченного времени. В необязательном поле можно указать постановку, методику, программную реализацию, данные, эксперимент, анализ, проверку, визуализацию или работу над отчётом. Название вида работы на оценку не влияет. + +## Статус точки + +- **Зачтена** — требования выполнены по существу в установленный срок. +- **Частично зачтена** — получен проверяемый содержательный результат, но существенная часть требований отсутствует или содержательный результат исправлен после срока. +- **Не зачтена** — материалов недостаточно для подтверждения содержательного результата этапа. + +Мелкие редакторские недостатки отражаются в обратной связи и сами по себе не снижают статус. + +Документированная блокировка может быть зачтена, если команда представляет воспроизводимую диагностику, предпринятые проверки, анализ причин, влияние на обязательный результат и обновлённый план. Сообщения о проблеме без этих материалов недостаточно. Блокировка не заменяет итоговый эксперимент. + +## Обратная связь и исправления + +Преподаватель проверяет указанный в описании PR/MR коммит, оставляет построчные замечания и итоговый комментарий: + +```text +Проверенный коммит: +Статус точки: +Подтверждённый результат: +Обязательные исправления: +Срок исправлений: +Влияние на возможное значение КТ: +``` + +Исправления добавляются новыми коммитами в ту же ветку. После проверки команда объединяет PR/MR с `main`. Если часть исправлений перенесена на следующий этап, команда отражает их в следующей ветке и файле точки. + +Промежуточная числовая оценка `ИР` не выставляется. Командная и индивидуальная обратная связь, включая адресные предупреждения о недостатке свидетельств или риске `ИР≤1`, может размещаться в публичном обсуждении PR/MR. В предупреждении указываются студент, ожидаемый проверяемый результат и срок; отдельное личное сообщение не требуется. Конфиденциальные ответы опросов и личные обстоятельства публично не раскрываются. diff --git a/project-final.md b/project-final.md new file mode 100644 index 0000000..5af1ab0 --- /dev/null +++ b/project-final.md @@ -0,0 +1,47 @@ +# Финальная версия проекта + +Финальная версия сдаётся до **19 марта 2027 года, 23:59** через ветку `nis/final` и итоговый PR/MR в `main`. По этим материалам в конце курса определяется компонент `ПР` проектного экзамена; защита образует компонент `ЗП`. Подробная командная и индивидуальная обратная связь преподавателя остаётся в PR/MR. + +## Подготовка материалов + +1. Проверить код, зависимости, инструкции и сокращённый сквозной запуск на обычной машине. +2. Оформить конфигурации, исходные и обработанные данные, команды построения результатов, внешние ссылки и контрольные суммы в `nis/results.md`. +3. Подготовить технический отчёт с постановкой, отличием от опубликованной исходной точки, методикой, угрозами достоверности, результатами, отрицательными наблюдениями и границами выводов. +4. Заполнить `nis/final.md`. +5. Создать от актуальной `main` ветку `nis/final`, опубликовать её и открыть итоговый PR/MR в `main`. +6. Указать в описании PR/MR полный хеш оцениваемого коммита, краткий итог и ссылки на материалы. +7. Получить итоговый комментарий преподавателя и добавить согласованные исправления новыми коммитами. + +Срок считается соблюдённым, если к нему опубликован указанный коммит и открыт PR/MR. Преподаватель оценивает зафиксированный полный хеш. + +## Лист итоговой сдачи + +`nis/final.md` содержит: + +- команду и назначенное проектное задание; +- полный хеш оцениваемого коммита; +- ключевой график или таблицу; +- основной вывод и его ограничения; +- ссылки на технический отчёт, данные и презентацию; +- вклад каждого участника со ссылками на подтверждающие материалы; +- описание применения генеративных моделей; +- при наличии — обоснование дополнительного достижения по четырём признакам ниже. + +Итоговый комплект включает репозиторий с сокращённым сквозным запуском, данные и конфигурации полного протокола, технический отчёт, презентацию и заполненный `nis/final.md`. + +После срока содержательные изменения не учитываются. Редакторские изменения презентации и согласованные технические исправления добавляются отдельными коммитами и не меняют зафиксированную оцениваемую версию. + +## Дополнительное достижение + +Проектное достижение — проверенный индивидуальный результат, который по содержанию или сложности заметно превосходит обычное полное выполнение согласованной части проекта. Для оценок 9 и 10 применяется единый уровень достижения. Проверяются четыре признака: + +- **выход за обычные ожидания** — явно указано, что получено сверх проектного задания и согласованной ответственности студента; +- **содержательная значимость** — результат расширяет выводы исследования, проверяет существенное предположение или позволяет проверить исследовательский вопрос самостоятельным техническим решением; +- **проверяемость** — представлены код, данные, эксперимент или доказательный анализ, проверена корректность и обозначены ограничения; +- **личный вклад** — работа студента прослеживается в материалах, и студент способен объяснить и защитить её. + +Совместный результат может быть признан достижением нескольких участников при подтверждённом вкладе каждого. Лидерство или определяющая роль в команде не требуются. + +Примеры подходящих результатов: дополнительный эксперимент по самостоятельному вопросу, проверенная модификация метода, доказательное объяснение существенного расхождения со статьёй или самостоятельное техническое решение повышенной сложности. Обязательные эксперименты, обычная настройка окружения, исправление ошибок собственной реализации и механическое увеличение числа прогонов входят в обычную работу. Корректный отрицательный результат может быть достижением, если он удовлетворяет четырём признакам. + +Отдельная форма и предварительное согласование достижения не требуются. Достижение описывается в техническом отчёте и `nis/final.md`, проверяется по материалам проекта и ответам на защите. Условия высокой оценки приведены в [правилах оценивания](grading.md#итоговая-оценка). diff --git a/project-repository-template/README.md b/project-repository-template/README.md new file mode 100644 index 0000000..c45d3f3 --- /dev/null +++ b/project-repository-template/README.md @@ -0,0 +1,31 @@ +# Название проекта + +**Проектное задание:** [название и ссылка] + +**Участники:** + +- Полное имя +- Полное имя +- Полное имя + +## Сокращённый запуск + +Укажите минимальные требования и команды, которые воспроизводят небольшой сквозной пример на обычной машине. + +```text +команды запуска +``` + +## Навигация + +- [Детализация проекта](nis/project.md) +- [План эксперимента](nis/experiment-plan.md) +- [Контрольная точка 1](nis/checkpoints/01.md) +- [Контрольная точка 2](nis/checkpoints/02.md) +- [Контрольная точка 3](nis/checkpoints/03.md) +- [Состояние проекта](nis/status.md) +- [Результаты](nis/results.md) +- [Финальная версия](nis/final.md) +- Код: [путь] +- Тесты: [путь] +- Данные: [путь или описание внешнего хранилища] diff --git a/project-repository-template/nis/checkpoints/01.md b/project-repository-template/nis/checkpoints/01.md new file mode 100644 index 0000000..b78c96d --- /dev/null +++ b/project-repository-template/nis/checkpoints/01.md @@ -0,0 +1,36 @@ +# Контрольная точка 1 + +## Краткий результат + +[Что проверено и что зафиксировано по итогам этапа.] + +## Проверенные технические предпосылки + +[Сборка, минимальный запуск, прототип, допущения и проверки выбранного пути.] + +## Фактические ресурсы и измеримость показателей + +[Доступные ресурсы и свидетельства того, что требуемые показатели можно измерить.] + +## Инструкция и воспроизводимые свидетельства + +[Команды и ссылки на журналы, тесты, данные или другие материалы.] + +## Ссылки на детализацию и план эксперимента + +- [Детализация проекта](../project.md) +- [План эксперимента](../experiment-plan.md) + +## Открытые риски и следующие действия + +[Риски, действия, сроки и ответственные.] + +## Ответственность участников + +### Участник: полное имя + +- Согласованная ответственность за период: +- Полученный результат и ссылки на материалы: +- Существенное изменение, решение или блокировка: +- Следующая ответственность: +- Виды работы (необязательно): diff --git a/project-repository-template/nis/checkpoints/02.md b/project-repository-template/nis/checkpoints/02.md new file mode 100644 index 0000000..9691dec --- /dev/null +++ b/project-repository-template/nis/checkpoints/02.md @@ -0,0 +1,39 @@ +# Контрольная точка 2 + +## Краткий результат + +[Какой сквозной сценарий работает.] + +## Запуск и конфигурация + +[Команды, версии, параметры и использованные ресурсы.] + +## Демонстрация + +[Ссылка на короткую запись.] + +## Исходные и обработанные данные + +[Ссылки на пример измерений и полученную таблицу или график.] + +## Проверка корректности + +[Тесты, инварианты, эталоны; для модели — проверка адекватности.] + +## Упрощения и отсутствующие обязательные части + +[Что пока ограничено или не реализовано.] + +## Риски и следующие действия + +[Риски, действия, сроки и ответственные.] + +## Ответственность участников + +### Участник: полное имя + +- Согласованная ответственность за период: +- Полученный результат и ссылки на материалы: +- Существенное изменение, решение или блокировка: +- Следующая ответственность: +- Виды работы (необязательно): diff --git a/project-repository-template/nis/checkpoints/03.md b/project-repository-template/nis/checkpoints/03.md new file mode 100644 index 0000000..622c768 --- /dev/null +++ b/project-repository-template/nis/checkpoints/03.md @@ -0,0 +1,35 @@ +# Контрольная точка 3 + +## Краткий результат + +[Какое сравнение выполнено.] + +## Метод и baseline + +[Сопоставимые варианты, входы и конфигурации.] + +## Исходные и обработанные данные + +[Ссылки на измерения, повторы, таблицу или график.] + +## Предварительная интерпретация + +[Вывод, сопоставление со статьёй, расхождения, альтернативные объяснения и ограничения.] + +## Оставшаяся обязательная работа + +[Задачи, сроки и ответственные.] + +## Возможное самостоятельное продолжение + +[Отдельный вопрос или технический результат сверх обязательной работы.] + +## Ответственность участников + +### Участник: полное имя + +- Согласованная ответственность за период: +- Полученный результат и ссылки на материалы: +- Существенное изменение, решение или блокировка: +- Следующая ответственность: +- Виды работы (необязательно): diff --git a/project-repository-template/nis/experiment-plan.md b/project-repository-template/nis/experiment-plan.md new file mode 100644 index 0000000..f888703 --- /dev/null +++ b/project-repository-template/nis/experiment-plan.md @@ -0,0 +1,33 @@ +# План эксперимента + +## Проверяемый вопрос + +[Какой результат или утверждение статьи проверяется.] + +## Сравниваемые варианты и baseline + +[Основной метод, baseline и условия сопоставимости.] + +## Данные или нагрузки + +[Источники, подготовка, размеры и правила формирования выборок.] + +## Конфигурации и параметры + +[Среда, версии, ресурсы, фиксированные и изменяемые параметры.] + +## Метрики + +[Определение, единицы измерения и способ сбора каждой метрики.] + +## Серии и повторы + +[Матрица экспериментов, число повторов и порядок запусков.] + +## Проверка корректности + +[Тесты, инварианты, эталоны и проверки адекватности.] + +## Обработка и анализ + +[Команды, статистическая обработка, таблицы, графики и правила интерпретации.] diff --git a/project-repository-template/nis/final.md b/project-repository-template/nis/final.md new file mode 100644 index 0000000..29b9efc --- /dev/null +++ b/project-repository-template/nis/final.md @@ -0,0 +1,42 @@ +# Финальная версия + +## Команда и задание + +- Команда: +- Проектное задание: + +## Оцениваемая версия + +- Полный хеш коммита: + +## Ключевой результат + +- Ключевой график или таблица: +- Основной вывод: +- Ограничения вывода: + +## Материалы + +- Технический отчёт: +- Данные и конфигурации: +- Презентация: +- Сокращённый сквозной запуск: + +## Вклад участников + +### Участник: полное имя + +- Полученный результат: +- Ссылки на подтверждающие материалы: + +## Применение генеративных моделей + +[Инструменты, задачи, способ проверки и доработки результата человеком. Если модели не применялись, укажите это.] + +## Дополнительное достижение при наличии + +- Участник: +- Результат сверх обычных ожиданий: +- Содержательная значимость: +- Проверяемые материалы и проверка корректности: +- Личный вклад: diff --git a/project-repository-template/nis/project.md b/project-repository-template/nis/project.md new file mode 100644 index 0000000..3e934c4 --- /dev/null +++ b/project-repository-template/nis/project.md @@ -0,0 +1,25 @@ +# Детализация проекта + +## Назначенное задание + +[Ссылка на карточку задания и краткое описание обязательного результата.] + +## Выбранный технический путь + +[Авторский артефакт, самостоятельная реализация, симулятор или их сочетание.] + +## Обязательный результат + +[Состав реализации и результат, который должен быть проверяемым к итоговой сдаче.] + +## Поддерживаемые сценарии + +[Входы, режимы работы и границы применимости.] + +## Упрощения + +[Принятые упрощения и их влияние на допустимые выводы.] + +## Критерии завершённости + +[Наблюдаемые условия, по которым можно проверить выполнение обязательной работы.] diff --git a/project-repository-template/nis/results.md b/project-repository-template/nis/results.md new file mode 100644 index 0000000..cf3a33b --- /dev/null +++ b/project-repository-template/nis/results.md @@ -0,0 +1,27 @@ +# Результаты + +## Конфигурации + +[Окружение, версии, ресурсы и параметры сравниваемых вариантов.] + +## Исходные данные + +[Расположение файлов, формат, происхождение и контрольные суммы.] + +## Обработанные данные + +[Расположение таблиц, графиков и промежуточных файлов.] + +## Построение результатов + +```text +команды, которые строят итоговые таблицы и графики +``` + +## Внешние материалы + +[Ссылки, условия доступа, версии и контрольные суммы материалов вне репозитория.] + +## Ограничения воспроизводимости + +[Ресурсные ограничения, недоступные материалы и допустимый сокращённый запуск.] diff --git a/project-repository-template/nis/status.md b/project-repository-template/nis/status.md new file mode 100644 index 0000000..fe9da09 --- /dev/null +++ b/project-repository-template/nis/status.md @@ -0,0 +1,19 @@ +# Состояние проекта + +## Лучший полученный результат + +[Краткое описание и ссылки на проверяемые материалы.] + +## Состояние обязательной работы + +[Что завершено и что пока не завершено.] + +## Риски и блокировки + +[Риск, его влияние и предпринятые действия.] + +## План до итоговой сдачи + +| Задача | Срок | Ответственный | Ожидаемое свидетельство | +|---|---|---|---| +| | | | | diff --git a/project-repository.md b/project-repository.md new file mode 100644 index 0000000..d82d36d --- /dev/null +++ b/project-repository.md @@ -0,0 +1,50 @@ +# Репозиторий команды + +Каждая команда ведёт отдельный публичный Git-репозиторий. Он должен поддерживать PR/MR, а преподаватель должен иметь возможность открыть страницу PR/MR и оставить общий или построчный комментарий. Конкретный сервис команда выбирает самостоятельно. + +Репозиторий материалов курса редактирует преподаватель. Команда один раз передаёт адрес своего репозитория через основной канал курса, после чего преподаватель добавляет его в [карточку проекта](projects/README.md). Изменения проекта команда вносит в свой репозиторий; дополнительные формы для передачи материалов не используются. + +До первой сдачи команда проверяет, что преподавателю доступны репозиторий, PR/MR и оба вида комментариев. + +## Обязательные файлы + +Корневой `README.md` содержит: + +- название проекта и ссылку на назначенное задание; +- полные имена участников; +- сокращённую инструкцию запуска; +- навигацию по коду, данным и материалам в `nis/`. + +Каталог `nis/` включает: + +- `project.md` — выбранный технический путь, детализацию обязательного результата, поддерживаемые сценарии, упрощения и критерии завершённости; +- `experiment-plan.md` — baseline, данные или нагрузки, конфигурации, метрики, параметры, серии, повторы, проверку корректности и обработку результатов; +- `checkpoints/01.md`, `02.md`, `03.md` — результаты этапов, проверяемые свидетельства и ответственность участников; +- `status.md` — состояние обязательной работы, риски, оставшиеся задачи, сроки и ответственных; +- `results.md` — конфигурации, исходные и обработанные данные, команды построения результатов, внешние ссылки и контрольные суммы; +- `final.md` — лист итоговой сдачи. + +Код, тесты и данные располагаются с учётом устройства конкретного проекта. Секреты и материалы без права публичного распространения в репозиторий не помещаются. Для начала работы можно скопировать [готовый шаблон](project-repository-template/README.md). + +## Сдача через PR/MR + +| Сдача | Ветка | +|---|---| +| Первая контрольная точка | `nis/checkpoint-1` | +| Вторая контрольная точка | `nis/checkpoint-2` | +| Третья контрольная точка | `nis/checkpoint-3` | +| Сверка состояния проекта | `nis/status` | +| Финальная версия | `nis/final` | + +Для каждой сдачи команда: + +1. создаёт указанную ветку от актуальной `main`; +2. к сроку публикует ветку и открывает PR/MR в `main`; +3. указывает в описании полный хеш сдаваемого коммита, краткий результат и ссылки на соответствующие файлы в `nis/`; +4. после срока не перебазирует ветку и не выполняет `force-push`; +5. добавляет исправления новыми коммитами в ту же ветку; +6. объединяет PR/MR с `main` после проверки преподавателем. + +Срок соблюдён, если к нему опубликован указанный коммит и открыт PR/MR. Преподаватель проверяет именно этот коммит. Исправления, перенесённые на следующий этап, отражаются в следующей ветке и файле контрольной точки. + +Подробная обратная связь остаётся в PR/MR. В преподавательской карточке проекта фиксируются полный хеш, статус и ссылка на итоговый комментарий. diff --git a/project-tasks/README.md b/project-tasks/README.md new file mode 100644 index 0000000..e3abdd6 --- /dev/null +++ b/project-tasks/README.md @@ -0,0 +1,86 @@ +# Банк проектных заданий + +Банк содержит 40 готовых проектных заданий по 32 основным статьям; отложенных вариантов сейчас нет. По одному заданию подготовлено для каждой статьи; для восьми широких работ выделены по две независимые постановки. Варианты A и B различаются центральным вопросом, техническим результатом и обязательным экспериментом. Изменение только нагрузки, параметра или типа отказа оставлено как возможное продолжение одного задания. + +Одно проектное задание назначается одной команде. Если по одной статье назначены две команды, они работают независимо: используют разные репозитории и не передают друг другу код, экспериментальные данные или результаты до завершения оценивания. Общими остаются только опубликованные статья и исходный артефакт. + +Во всех заданиях исходный обязательный путь рассчитан на CPU и бесплатную инфраструктуру. Команда с подтверждённым доступом к GPU может по согласованию включить GPU-реализацию и эксперименты в обязательный план по [общим правилам проекта](../project.md#ресурсы-данные-и-лицензии). Ссылки, закреплённые ревизии и лицензии документально проверены 5 сентября 2026 года; известных блокеров для назначения нет. Технические предпосылки команда проверяет по [правилам первой контрольной точки](../project-checkpoints/01-project-plan.md). + +Наличие опубликованного артефакта в задании не означает, что команда обязательно строит проект на его коде. В зависимости от проверяемого вопроса допустимым путём может быть работа с авторским артефактом, самостоятельная реализация центрального механизма, собственный симулятор или их сочетание. Конкретные варианты задаются формулировкой технического результата либо отдельным полем «Допустимый технический путь». Если разрешено несколько путей, они равноправны и оцениваются по полученному результату, корректности эксперимента и обоснованности выводов. + +Общий порядок выбора, контрольные точки и требования к результатам описаны в [правилах проекта](../project.md), а место `ТР`, `Э` и `ВО` в итоговой оценке — в [правилах оценивания](../grading.md). + +## Тематические группы + +- [Проверка корректности и надёжности](#проверка-корректности-и-надёжности) — спецификации, тестирование, поиск ошибок и проверка поведения при отказах. +- [Хранилища, базы данных и потоковая обработка](#хранилища-базы-данных-и-потоковая-обработка) — транзакции, кэширование, хранение и обработка данных. +- [Облачные, edge- и serverless-системы](#облачные-edge--и-serverless-системы) — микросервисы, оркестрация, размещение и бессерверные вычисления. +- [Сети и распределённые протоколы](#сети-и-распределённые-протоколы) — передача данных, управление перегрузкой и отказоустойчивое согласование. +- [Распределённое выполнение и управление ресурсами](#распределённое-выполнение-и-управление-ресурсами) — графы задач, планирование, восстановление и коллективные операции. +- [Инфраструктура инференса LLM](#инфраструктура-инференса-llm) — память, планирование и раздельное выполнение запросов к большим языковым моделям. + +Группировка помогает ориентироваться в банке и не влияет на требования или оценивание. Некоторые задания относятся сразу к нескольким областям; в перечне они помещены в основную группу по центральному вопросу проекта. + +## Проверка корректности и надёжности + +- [P01. Remix: спецификации разной гранулярности для проверки распределённых систем](p01-remix.md) +- [P02. DUPChecker: статическая проверка совместимости форматов при обновлении](p02-dupchecker.md) +- [P03-A. Acto: поиск состояний](p03-a-acto-state-search.md) +- [P03-B. Acto: проверки и уменьшение](p03-b-acto-oracles-and-shrinking.md) +- [P04. Legolas: поиск ошибок частичных отказов по состояниям системы](p04-legolas.md) +- [P06. SuperBench: упреждающая проверка вычислительной инфраструктуры](p06-superbench.md) +- [P08. PGVal: сквозная проверка гарантий потоковой обработки](p08-pgval.md) +- [P09-B. FoundationDB: детерминированная имитация](p09-b-foundationdb-simulation.md) + +## Хранилища, базы данных и потоковая обработка + +- [P05. SIEVE: простая политика вытеснения веб-кэша](p05-sieve.md) +- [P09-A. FoundationDB: транзакции и отказы](p09-a-foundationdb-transactions.md) +- [P10. Detock: транзакции между регионами без глобального упорядочивания](p10-detock.md) +- [P11. Clay Codes: восстановление данных с меньшим сетевым обменом](p11-clay-codes.md) +- [P12-A. ClickHouse: отсечение данных](p12-a-clickhouse-data-skipping.md) +- [P12-B. ClickHouse: векторизованный конвейер](p12-b-clickhouse-vectorized-pipeline.md) +- [P13. Noria: частично материализованный потоковый граф для веб-приложений](p13-noria.md) +- [P14-A. Flink: режимы контрольных точек](p14-a-flink-checkpoints.md) +- [P14-B. Flink: rescaling и восстановление](p14-b-flink-rescaling-recovery.md) +- [P21. DBSP/Feldera: инкрементальное выполнение запросов](p21-dbsp-feldera.md) + +## Облачные, edge- и serverless-системы + +- [P07-A. DeathStarBench: хвостовая задержка](p07-a-deathstarbench-tail-latency.md) +- [P07-B. DeathStarBench: размещение и интерференция](p07-b-deathstarbench-placement.md) +- [P15. Autothrottle: двухуровневое управление ресурсами микросервисов](p15-autothrottle.md) +- [P16. Oakestra: иерархическая оркестрация edge-кластера](p16-oakestra.md) +- [P17. SkyPilot: планирование заданий между облаками](p17-skypilot.md) +- [P18. Faasm: WebAssembly-изоляция для stateful serverless](p18-faasm.md) +- [P19. Serverless Cold Starts: проверка обобщений на производственных трассах](p19-serverless-cold-starts.md) + +## Сети и распределённые протоколы + +- [P20. Cloudcast: стоимость и скорость многоадресной передачи между облаками](p20-cloudcast.md) +- [P22. DCTCP: управление перегрузкой в сети дата-центра через ECN](p22-dctcp.md) +- [P32. Alea-BFT: асинхронная репликация с византийскими отказами](p32-alea-bft.md) + +## Распределённое выполнение и управление ресурсами + +- [P25-A. Ray: динамические графы задач](p25-a-ray-task-graphs.md) +- [P25-B. Ray: акторы и восстановление](p25-b-ray-actors-recovery.md) +- [P27. DeDe: декомпозиция задач распределения ресурсов](p27-dede.md) +- [P30. Pollux: совместная адаптация обучения и кластерного планировщика](p30-pollux.md) +- [P31-A. GC3: корректность расписаний](p31-a-gc3-correctness.md) +- [P31-B. GC3: оптимизация под топологию](p31-b-gc3-topology-optimization.md) + +## Инфраструктура инференса LLM + +- [P23. PagedAttention: управление памятью KV-кэша](p23-pagedattention.md) +- [P24. Llumnix: динамическое перепланирование LLM-запросов](p24-llumnix.md) +- [P26-A. Parrot: планирование графа](p26-a-parrot-graph-scheduling.md) +- [P26-B. Parrot: префиксы и локальность](p26-b-parrot-prefix-locality.md) +- [P28. DistServe: раздельное выполнение prefill и decode](p28-distserve.md) +- [P29. Mooncake: глобальный многоуровневый KV-кэш](p29-mooncake.md) + +## Как читать проектное задание + +Поле «Кратко о статье» объясняет решаемую авторами проблему, основную идею работы и связь с конкретным проектом; поле «Почему результат актуален» описывает современное состояние и сохраняющееся значение результата. «Артефакты и данные» фиксируют доступные исходные материалы, но не определяют способ реализации. Раздел «Обязательный результат» задаёт минимальный содержательный объём и допустимый технический путь, а «Содержательные направления» помогают команде распределить работу без назначения готовых персональных ролей. «Возможное продолжение» не входит в обязательную часть и высокой оценки не гарантирует. + +Общие [итоговые материалы](../project.md#итоговые-материалы-и-защита) и [шкала `ТР`, `Э` и `ВО`](../grading.md#материалы-проекта) действуют для всех заданий. Оценивается новое приращение относительно опубликованных кода, данных и результатов. diff --git a/project-tasks/p01-remix.md b/project-tasks/p01-remix.md new file mode 100644 index 0000000..5354a39 --- /dev/null +++ b/project-tasks/p01-remix.md @@ -0,0 +1,29 @@ +# P01. Remix: спецификации разной гранулярности для проверки распределённых систем + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Lingzhi Ouyang и соавт. — [Multi-Grained Specifications for Distributed System Model Checking and Verification](https://tianyin.github.io/pub/mspec.pdf). EuroSys 2025, DOI `10.1145/3689031.3696069`. +- **Кратко о статье:** Авторы проверяют ZooKeeper с помощью TLA+ и рассматривают конфликт между точностью модели и размером пространства состояний. Remix позволяет сочетать детальные спецификации целевых модулей с более грубыми спецификациями остальной системы и проверять соответствие модели коду. Подход помог обнаружить шесть серьёзных ошибок. В проекте сравниваются разные гранулярности спецификаций на сокращённых сценариях ZooKeeper. +- **Почему результат актуален:** работа 2025 года проверяет развивающуюся производственную систему; исправления шести найденных ошибок были приняты в ZooKeeper. Локальный демонстрационный путь использует Java 11, Python 3 и Maven и не требует кластера или специализированного оборудования. +- **Артефакты и данные:** [Lingzhi-Ouyang/Remix](https://github.com/Lingzhi-Ouyang/Remix) под Apache-2.0, с ZooKeeper 3.9.1, TLC, генерацией модельных трасс, проверкой соответствия и детерминированным воспроизведением; комитет EuroSys присвоил артефакту знаки Available и Functional. Зафиксированные ревизии: `Lingzhi-Ouyang/Remix@81869f1accc1` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** смешанная гранулярность спецификации уменьшает стоимость model checking относительно полностью детальной модели и обнаруживает расхождения, которые теряются в полностью грубой модели. +- **Технический результат:** Собрать воспроизводимый конвейер для трёх вариантов спецификации: генерация трасс в TLC, преобразование в формат проигрывателя, запуск на малой конфигурации ZooKeeper и автоматический отчёт о совпадениях и расхождениях. Все варианты должны использовать общие сценарии и одинаковые ограничения поиска. +- **Эксперимент:** воспроизвести генерацию и проигрывание трасс для ZooKeeper, затем сравнить грубую, детальную и смешанную спецификации по числу состояний, времени проверки и найденным расхождениям на 2–3 сценариях. +- **Границы выводов:** сравнение относится к выбранным сценариям ZooKeeper и ограничениям поиска TLC; оно не доказывает полноту спецификаций и не оценивает все возможные ошибки реализации. +- **Ресурсный профиль:** локально, Linux, CPU, 8–16 ГБ памяти. Если полная генерация пространства состояний слишком долгая, использовать демонстрационные трассы и уменьшенную конфигурацию ZooKeeper, сохранив сравнение трёх вариантов спецификации и проверку соответствия. + +## Содержательные направления + +- спецификации и конфигурации TLC. +- воспроизведение трасс и инструментирование ZooKeeper. +- сравнение гранулярностей, контролируемые расхождения и анализ результатов. + +## Возможное продолжение + +Детализировать один дополнительный модуль или изменение ZooKeeper, внести контролируемое расхождение между моделью и кодом либо исследовать границу, после которой дополнительная детализация перестаёт окупаться. diff --git a/project-tasks/p02-dupchecker.md b/project-tasks/p02-dupchecker.md new file mode 100644 index 0000000..01b4eb0 --- /dev/null +++ b/project-tasks/p02-dupchecker.md @@ -0,0 +1,29 @@ +# P02. DUPChecker: статическая проверка совместимости форматов при обновлении + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Yongle Zhang и соавт. — [Understanding and Detecting Software Upgrade Failures in Distributed Systems](https://yonglezh-purdue.github.io/files/sosp21-upgrade.pdf). SOSP 2021. +- **Кратко о статье:** Авторы исследуют 123 сбоя при обновлении восьми распределённых систем и показывают, что многие из них возникают только при взаимодействии разных версий через хранилище или сетевые сообщения. На основе исследования созданы средство тестирования обновлений DUPTester и статические проверки форматов DUPChecker. В проекте воспроизводится именно проверка межверсионной совместимости форматов на небольших примерах. +- **Почему результат актуален:** инструмент — снимок состояния на момент публикации, но проверяемые правила межверсионной совместимости сохраняют значение для современных систем. Полный авторский эксперимент рассчитан на 4 ГБ памяти и примерно час работы, а отдельная пара версий проверяется быстрее. +- **Артефакты и данные:** [jwjwyoung/DUPChecker](https://github.com/jwjwyoung/DUPChecker) под MIT, с Python 3-инструментами, примерами для HBase и сценариями воспроизведения опубликованной таблицы; артефакт получил знаки Available, Functional и Results Reproduced на SOSP 2021. Зафиксированные ревизии: `jwjwyoung/DUPChecker@01ba1d490465` (MIT). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** статическая проверка изменений схем находит потенциальные межверсионные несовместимости, которые обычная проверка каждой версии по отдельности не обнаруживает. +- **Технический результат:** Подготовить воспроизводимый анализатор зафиксированных пар выпусков для 2–3 открытых систем, реализовать простой синтаксический diff как baseline и собрать размеченный набор предупреждений с подтверждениями из истории изменений и тестов. Один сценарий должен запускать оба анализатора на одинаковых входах и формировать сопоставимый отчёт. +- **Эксперимент:** выбрать 2–3 открытые системы, проверить несколько последовательных выпусков, вручную классифицировать предупреждения по истории изменений и тестам и сравнить DUPChecker с простым синтаксическим diff по точности и времени. +- **Границы выводов:** оценки точности и времени относятся к выбранным системам, выпускам и размеченным предупреждениям; они не характеризуют все виды межверсионной несовместимости и другие форматы схем. +- **Ресурсный профиль:** локально, CPU, 4–8 ГБ памяти. Если крупный репозиторий неудобно анализировать целиком, использовать зафиксированные пары выпусков и отдельно подготовленный набор совместимых и несовместимых изменений схем. + +## Содержательные направления + +- подбор выпусков и эталонная разметка. +- запуск и расширение анализатора. +- базовые методы, метрики, проверка предупреждений и анализ ошибок. + +## Возможное продолжение + +Уточнить одно правило для снижения ложных срабатываний, добавить поддержку ещё одного изменения схемы или сопоставить статические предупреждения с реальными тестами совместного чтения старой и новой версией. diff --git a/project-tasks/p03-a-acto-state-search.md b/project-tasks/p03-a-acto-state-search.md new file mode 100644 index 0000000..9d581dd --- /dev/null +++ b/project-tasks/p03-a-acto-state-search.md @@ -0,0 +1,29 @@ +# P03-A. Acto: поиск состояний + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Jiawei Tyler Gu и соавт. — [Acto: Automatic End-to-End Testing for Operation Correctness of Cloud System Management](https://research.ibm.com/publications/acto-automatic-end-to-end-testing-for-operation-correctness-of-cloud-system-management). SOSP 2023. +- **Кратко о статье:** Операторы Kubernetes должны многократно приводить управляемую систему к объявленному состоянию, поэтому отдельные тесты обработчиков не покрывают поведение длинных последовательностей операций. Acto представляет операции как переходы состояния, систематически строит их последовательности и проверяет фактическое состояние системы на соответствие требуемому. В проекте основной акцент сделан на стратегии поиска состояний и её преимуществе перед случайной генерацией. +- **Почему результат актуален:** Acto продолжает развиваться и применён уже к одиннадцати операторам; [работа NSDI 2026 о надёжности операторов](https://www.usenix.org/conference/nsdi26/presentation/gu) подтверждает, что ошибки во взаимодействии оператора с управляемой системой остаются существенным классом отказов. +- **Артефакты и данные:** [xlab-uiuc/acto](https://github.com/xlab-uiuc/acto) под Apache-2.0, с локальными режимами Kind, Minikube и K3d, воспроизводимыми ошибками и конфигурациями реальных операторов. При [проверке артефакта](https://sysartifacts.github.io/sosp2023/summaries/acto) подтверждены его доступность, работоспособность и воспроизведение результатов. Зафиксированные ревизии: `xlab-uiuc/acto@a0d0fb7bb840` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** генерация последовательностей переходов и сквозная проверка состояния позволяют находить ошибки согласования, которые пропускают отдельные тесты обработчиков и случайная генерация операций. +- **Технический результат:** Развернуть небольшой оператор и управляемую систему в Kind, подключить генератор переходов Acto и воспроизводимый случайный baseline. Добавить сбор покрытия переходов и автоматическую проверку достижения желаемого состояния. +- **Эксперимент:** На одном операторе выполнить не менее трёх серий систематической и случайной генерации с одинаковым бюджетом. Сравнить покрытие переходов, число уникальных расхождений и время до первого сбоя; для найденного сбоя подтвердить воспроизводимость отдельным тестом. +- **Границы выводов:** результат показывает покрытие и обнаружение сбоев для выбранного оператора, модели переходов и бюджета генерации; он не доказывает полноту поиска или корректность оператора во всех конфигурациях. +- **Ресурсный профиль:** расширенно локально, Linux, Docker, Kind, CPU, желательно 16 ГБ памяти. Если выбранный оператор слишком тяжёл, использовать демонстрационную конфигурацию Cassandra либо собственный минимальный оператор с намеренно внесёнными ошибками согласования. + +## Содержательные направления + +- оператор и локальный стенд. +- генератор переходов и стратегии обхода. +- проверки состояния, уменьшение сбоев и сравнительный анализ. + +## Возможное продолжение + +Перенести Acto на новый оператор, добавить новый тип перехода или вид проверки, исследовать раннюю остановку либо автоматическое уменьшение ошибочной последовательности. diff --git a/project-tasks/p03-b-acto-oracles-and-shrinking.md b/project-tasks/p03-b-acto-oracles-and-shrinking.md new file mode 100644 index 0000000..32b3fe1 --- /dev/null +++ b/project-tasks/p03-b-acto-oracles-and-shrinking.md @@ -0,0 +1,29 @@ +# P03-B. Acto: проверки и уменьшение + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Jiawei Tyler Gu и соавт. — [Acto: Automatic End-to-End Testing for Operation Correctness of Cloud System Management](https://research.ibm.com/publications/acto-automatic-end-to-end-testing-for-operation-correctness-of-cloud-system-management). SOSP 2023. +- **Кратко о статье:** Операторы Kubernetes должны многократно приводить управляемую систему к объявленному состоянию, поэтому отдельные тесты обработчиков не покрывают поведение длинных последовательностей операций. Acto представляет операции как переходы состояния и автоматически проверяет, достигла ли система требуемого состояния. В проекте основной акцент сделан на качестве сквозных проверок состояния и уменьшении найденной последовательности до воспроизводимого объяснения сбоя. +- **Почему результат актуален:** Acto продолжает развиваться и применён уже к одиннадцати операторам; [работа NSDI 2026 о надёжности операторов](https://www.usenix.org/conference/nsdi26/presentation/gu) подтверждает, что ошибки во взаимодействии оператора с управляемой системой остаются существенным классом отказов. +- **Артефакты и данные:** [xlab-uiuc/acto](https://github.com/xlab-uiuc/acto) под Apache-2.0, с локальными режимами Kind, Minikube и K3d, воспроизводимыми ошибками и конфигурациями реальных операторов. При [проверке артефакта](https://sysartifacts.github.io/sosp2023/summaries/acto) подтверждены его доступность, работоспособность и воспроизведение результатов. Зафиксированная основная ревизия: `xlab-uiuc/acto@a0d0fb7bb840` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** Сквозная проверка состояния и автоматическое уменьшение последовательности превращают сбой оператора в воспроизводимый диагноз; качество результата зависит от полноты наблюдаемого состояния и правил эквивалентности сценариев. +- **Технический результат:** Развернуть небольшой оператор и управляемую систему в Kind. Реализовать две независимые проверки — достижения желаемого состояния и предметного инварианта — и средство уменьшения ошибочной последовательности с сохранением сбоя. +- **Эксперимент:** На наборе не менее чем из пяти известных или намеренно внесённых ошибок сравнить исходные последовательности без уменьшения как baseline, удаление суффикса и структурное уменьшение. Измерить долю воспроизведённых сбоев, длину результата, число перезапусков, время и ложные срабатывания проверок. +- **Границы выводов:** качество проверок и уменьшения оценивается на выбранных известных или намеренно внесённых ошибках; результат не определяет точность на неизвестных естественных сбоях и других операторах. +- **Ресурсный профиль:** расширенно локально, Linux, Docker, Kind, CPU, желательно 16 ГБ памяти. Если выбранный оператор слишком тяжёл, использовать демонстрационную конфигурацию Cassandra либо собственный минимальный оператор с намеренно внесёнными ошибками согласования. + +## Содержательные направления + +- локальный оператор и набор ошибок. +- проверки состояния и эталонная разметка. +- алгоритмы уменьшения, повторные запуски и анализ ошибок. + +## Возможное продолжение + +Добавить причинно-зависимое уменьшение, новый вид проверки, восстановление после промежуточного сброса состояния или перенос на второй оператор. diff --git a/project-tasks/p04-legolas.md b/project-tasks/p04-legolas.md new file mode 100644 index 0000000..443fe60 --- /dev/null +++ b/project-tasks/p04-legolas.md @@ -0,0 +1,29 @@ +# P04. Legolas: поиск ошибок частичных отказов по состояниям системы + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Haoze Wu и соавт. — [Efficient Exposure of Partial Failure Bugs in Distributed Systems with Inferred Abstract States](https://www.usenix.org/conference/nsdi24/presentation/wu-haoze). NSDI 2024. +- **Кратко о статье:** Ошибки частичных отказов часто проявляются только при редком сочетании внутреннего состояния системы, места сбоя и момента инъекции. Legolas статически анализирует код, выводит абстрактные состояния и использует их для выбора более содержательных точек отказа. Авторы применили систему к шести распределённым системам и нашли 20 новых ошибок. Проект сравнивает управляемую состояниями и случайную инъекцию при одинаковом бюджете запусков. +- **Почему результат актуален:** репозиторий поддерживает локальную сборку Maven на обычном Linux-стенде; задача управляемой инъекции отказов сохраняется при переходе к новым версиям систем, поскольку проект сравнивает стратегии исследования состояний независимо от фиксированного набора найденных ошибок. +- **Артефакты и данные:** [OrderLab/Legolas](https://github.com/OrderLab/Legolas) под Apache-2.0, со статическим анализатором, инструментированием Java-кода, оркестратором экспериментов и примерами для ZooKeeper. Зафиксированные ревизии: `OrderLab/Legolas@84278d313f98` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** выбор точек отказа по выведенным состояниям быстрее и стабильнее обнаруживает ошибки частичных отказов, чем случайная инъекция при том же бюджете запусков. +- **Технический результат:** Развернуть малую конфигурацию ZooKeeper, инструментировать её средствами Legolas и реализовать два режима инъекции — случайный и управляемый состояниями. Общий исполнитель должен фиксировать состояние, место инъекции и исход запуска, определять сбой по явному критерию и объединять повторения одного дефекта. +- **Эксперимент:** на малой конфигурации ZooKeeper воспроизвести один опубликованный сценарий, затем сравнить случайную и управляемую состояниями инъекцию по времени до первого сбоя, числу уникальных сбоев и доле полезных запусков. +- **Границы выводов:** преимущество стратегии инъекции проверяется на малой конфигурации ZooKeeper и выбранном наборе классов и исключений; оно не означает полного покрытия дефектов или той же эффективности на производственном кластере. +- **Ресурсный профиль:** расширенно локально, Linux, Java, Maven, CPU, желательно 16 ГБ памяти. Если полный анализ выбранной системы слишком тяжёл, использовать ZooKeeper и ограниченный набор классов и исключений, сохранив сравнение стратегий. + +## Содержательные направления + +- сборка и инструментирование системы. +- оркестрация отказов и критерии сбоев. +- стратегии выбора состояний, статистика и перенос на новый сценарий. + +## Возможное продолжение + +Перенести сокращённый конвейер на другую Java-систему, улучшить группировку состояний или предложить стратегию выбора точек, учитывающую историю предыдущих запусков. diff --git a/project-tasks/p05-sieve.md b/project-tasks/p05-sieve.md new file mode 100644 index 0000000..2697412 --- /dev/null +++ b/project-tasks/p05-sieve.md @@ -0,0 +1,29 @@ +# P05. SIEVE: простая политика вытеснения веб-кэша + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Yazhuo Zhang и соавт. — [SIEVE is Simpler than LRU: an Efficient Turn-Key Eviction Algorithm for Web Caches](https://www.usenix.org/system/files/nsdi24-zhang-yazhuo.pdf). NSDI 2024. +- **Кратко о статье:** Политика вытеснения веб-кэша должна одновременно давать хорошую долю попаданий и допускать дешёвую конкурентную реализацию. SIEVE использует однобитную отметку востребованности и последовательный указатель вытеснения, поэтому попадания не требуют перестройки общей структуры. Авторы показывают, что простая политика конкурентоспособна с более сложными алгоритмами. Проект проверяет этот результат на нескольких трассах и размерах кэша. +- **Почему результат актуален:** авторы предлагают очень простую политику вытеснения SIEVE и показывают на веб-трассах, что она часто сочетает высокую скорость с хорошей долей попаданий. +- **Артефакты и данные:** [cacheMon/NSDI24-SIEVE](https://github.com/cacheMon/NSDI24-SIEVE) с симулятором, прототипами и открытыми трассами. Зафиксированные ревизии: `cacheMon/NSDI24-SIEVE@0861f8261c37` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** очень простая политика SIEVE может одновременно давать высокую пропускную способность и меньшую долю промахов, чем существенно более сложные политики, но результат зависит от следа и размера кэша. +- **Технический результат:** Независимо реализовать SIEVE, LRU и ещё одну сильную политику в общем симуляторе кэша. Симулятор должен читать одинаковый формат трасс, проверять инварианты ёмкости и учёта запросов и формировать сопоставимую статистику попаданий, вытеснений и служебных операций. +- **Эксперимент:** на нескольких открытых трассах сравнить SIEVE, LRU и ещё одну сильную политику по доле промахов и служебным операциям, воспроизвести часть результатов статьи и проверить чувствительность к размеру кэша. +- **Границы выводов:** сравнение характеризует долю попаданий и алгоритмические накладные расходы на выбранных трассах и размерах кэша; без работающего сервера оно не подтверждает производственную пропускную способность и цену синхронизации. +- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; можно использовать подвыборки трасс с проверкой устойчивости выводов. + +## Содержательные направления + +- реализации политик. +- подготовка трасс и стенда. +- анализ режимов, визуализация и дополнительные гипотезы. + +## Возможное продолжение + +Искать классы нагрузок, на которых SIEVE проигрывает, исследовать влияние размера объектов или предложить небольшую модификацию без заметного усложнения. diff --git a/project-tasks/p06-superbench.md b/project-tasks/p06-superbench.md new file mode 100644 index 0000000..70bd35c --- /dev/null +++ b/project-tasks/p06-superbench.md @@ -0,0 +1,29 @@ +# P06. SuperBench: упреждающая проверка вычислительной инфраструктуры + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Yifan Xiong и соавт. — [SuperBench: Improving Cloud AI Infrastructure Reliability with Proactive Validation](https://www.usenix.org/system/files/atc24-xiong.pdf). USENIX ATC 2024, Best Paper. +- **Кратко о статье:** В крупных кластерах для задач ИИ отдельные компоненты могут деградировать, не вызывая явного отказа, но заметно замедляя распределённые задания. SuperBench объединяет направленные микротесты и проверки на разных этапах жизненного цикла инфраструктуры, чтобы заранее находить такие узлы и локализовать причину. В проекте строится доступный CPU-аналог этого подхода и сравниваются стратегии выбора проверок. +- **Почему результат актуален:** SuperBench запускает короткие целевые тесты оборудования и коммуникаций до выдачи ресурсов ИИ-задачам, чтобы заранее исключать деградировавшие узлы из кластера. +- **Артефакты и данные:** [microsoft/superbenchmark](https://github.com/microsoft/superbenchmark) с CPU- и GPU-тестами, профилями и документацией. Зафиксированные ревизии: `microsoft/superbenchmark@2e2c52b80f4e` (MIT). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** набор направленных микротестов и обоснованный выбор их поднабора выявляют заданные виды скрытой деградации с меньшей стоимостью, чем неизбирательный запуск всех проверок. +- **Технический результат:** Собрать CPU-набор проверок вычислений, памяти, диска и сети с управляемыми режимами деградации, единым сбором результатов и простым алгоритмом выбора поднабора тестов. Стенд должен автоматически подтверждать, что нормальный и деградированный режимы действительно различаются по заданным признакам. +- **Эксперимент:** на CPU построить несколько воспроизводимых режимов деградации, сравнить отдельные тесты и проверить простой алгоритм выбора поднабора проверок; при временном доступе к одной GPU можно добавить отдельную необязательную серию. +- **Границы выводов:** стенд проверяет различимость заданных CPU-, memory-, disk- и network-деградаций и качество отбора тестов; он не подтверждает диагностику GPU-сбоев или предсказание отказов крупного производственного кластера. +- **Ресурсный профиль:** локально, CPU, сеть, диск и 8–16 ГБ памяти; GPU не требуется. Обязательная часть проверяет сам механизм отбора и не переносит выводы на крупный AI-кластер. + +## Содержательные направления + +- сценарии деградации. +- интеграция тестов и сбор метрик. +- алгоритм выбора и оценка качества обнаружения. + +## Возможное продолжение + +Учитывать стоимость ложных тревог и пропусков, добавить дрейф производительности или сравнить статический и адаптивный графики проверок. diff --git a/project-tasks/p07-a-deathstarbench-tail-latency.md b/project-tasks/p07-a-deathstarbench-tail-latency.md new file mode 100644 index 0000000..9adbfe9 --- /dev/null +++ b/project-tasks/p07-a-deathstarbench-tail-latency.md @@ -0,0 +1,29 @@ +# P07-A. DeathStarBench: хвостовая задержка + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Yu Gan и соавт. — [An Open-Source Benchmark Suite for Microservices and Their Hardware-Software Implications for Cloud & Edge Systems](https://ygan397.github.io/publication/2019.asplos.deathstarbench/2019.asplos.deathstarbench.pdf). ASPLOS 2019. +- **Кратко о статье:** DeathStarBench — открытый набор сквозных приложений, представляющих типичные графы облачных и edge-микросервисов. Авторы показывают, что зависимости между сервисами, программный стек и совместное использование ресурсов создают узкие места, которые не видны в изолированном микротесте. В этом проекте исследуется распространение задержки по графу и поведение её хвостовых квантилей. +- **Почему результат актуален:** набор нагрузок продолжает использоваться как открытый стенд для исследований микросервисов. Конкретные зависимости отдельных приложений могут устаревать, поэтому перед проектом фиксируется собираемая версия. Выводы ограничиваются исследуемым графом сервисов и не распространяются на весь современный облачный стек. +- **Артефакты и данные:** [delimitrou/DeathStarBench](https://github.com/delimitrou/DeathStarBench) под Apache-2.0, с несколькими приложениями, контейнерами и генераторами нагрузки. Зафиксированные ревизии: `delimitrou/DeathStarBench@6ecb09706140` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** при приближении графа микросервисов к насыщению хвостовая задержка растёт заметнее средней, а трассировка критического пути позволяет локализовать сервис, причинно влияющий на этот рост. +- **Технический результат:** Развернуть сокращённый сквозной граф Hotel Reservation или Social Network, добавить генератор нагрузки, трассировку запросов и сбор метрик по каждому сервису. +- **Эксперимент:** Провести ступенчатую нагрузку от ненасыщенного режима до перегрузки не менее чем в трёх сериях. Сопоставить медиану, p95/p99, очереди и загрузку ресурсов; локализовать хотя бы одно узкое место и подтвердить причинность контролируемым изменением его ресурса. +- **Границы выводов:** причинный анализ относится к выбранному сокращённому графу сервисов, нагрузке и локальным ограничениям ресурсов; он не воспроизводит хвостовые задержки полной производственной конфигурации DeathStarBench. +- **Ресурсный профиль:** расширенно локально, Docker, CPU, желательно 16–32 ГБ памяти. Запасной вариант — оставить один опубликованный сервис и уменьшить число реплик, сохранив сквозной граф вызовов. + +## Содержательные направления + +- развёртывание и наблюдаемость. +- генератор нагрузки и контролируемые воздействия. +- анализ хвостов, причин и альтернативных конфигураций. + +## Возможное продолжение + +Сравнить две схемы размещения, ограничение одного ресурса, кэширование либо политику перегрузки и проверить перенос вывода между двумя графами вызовов. diff --git a/project-tasks/p07-b-deathstarbench-placement.md b/project-tasks/p07-b-deathstarbench-placement.md new file mode 100644 index 0000000..aae62ae --- /dev/null +++ b/project-tasks/p07-b-deathstarbench-placement.md @@ -0,0 +1,29 @@ +# P07-B. DeathStarBench: размещение и интерференция + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Yu Gan и соавт. — [An Open-Source Benchmark Suite for Microservices and Their Hardware-Software Implications for Cloud & Edge Systems](https://ygan397.github.io/publication/2019.asplos.deathstarbench/2019.asplos.deathstarbench.pdf). ASPLOS 2019. +- **Кратко о статье:** DeathStarBench — открытый набор сквозных приложений, представляющих типичные графы облачных и edge-микросервисов. Поведение приложения зависит от отдельных сервисов, их взаимодействия с аппаратными ресурсами и программным стеком. В этом проекте исследуется, как размещение сервисов и фоновая конкуренция меняют сквозную хвостовую задержку. +- **Почему результат актуален:** набор нагрузок продолжает использоваться как открытый стенд для исследований микросервисов. Конкретные зависимости отдельных приложений могут устаревать, поэтому перед проектом фиксируется собираемая версия. Выводы ограничиваются исследуемым графом сервисов и не распространяются на весь современный облачный стек. +- **Артефакты и данные:** [delimitrou/DeathStarBench](https://github.com/delimitrou/DeathStarBench) под Apache-2.0, с несколькими приложениями, контейнерами и генераторами нагрузки. Зафиксированная основная ревизия: `delimitrou/DeathStarBench@6ecb09706140` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** Совместное размещение и фоновая конкуренция меняют хвостовую задержку сквозного запроса в зависимости от структуры графа; равномерное распределение CPU не всегда даёт лучший результат. +- **Технический результат:** Развернуть один сокращённый сквозной граф DeathStarBench, добавить управляемое размещение контейнеров, фоновую CPU- и memory-нагрузку и трассировку критического пути. +- **Эксперимент:** Сравнить изолированное и случайное размещение как baselines с размещением, учитывающим граф, при двух уровнях нагрузки и двух видах интерференции. Выполнить не менее трёх серий; измерить throughput, p50/p95/p99, длины очередей, загрузку ресурсов и вклад сервисов в критический путь. +- **Границы выводов:** эффект размещения и интерференции проверяется на одном сокращённом графе и доступных локальных узлах; результат не оценивает качество полноценного кластерного планировщика и переносимость политики на производственную топологию. +- **Ресурсный профиль:** расширенно локально, Docker, CPU, желательно 16–32 ГБ памяти. Запасной вариант — оставить один опубликованный сервис и уменьшить число реплик, сохранив сквозной граф вызовов. + +## Содержательные направления + +- развёртывание и управление размещением. +- генератор нагрузки, интерференция и наблюдаемость. +- политика размещения, повторные серии и причинный анализ. + +## Возможное продолжение + +Добавить сетевую интерференцию, динамическое перемещение одного сервиса, ограничение мощности либо проверить перенос политики на второй граф вызовов. diff --git a/project-tasks/p08-pgval.md b/project-tasks/p08-pgval.md new file mode 100644 index 0000000..4064fee --- /dev/null +++ b/project-tasks/p08-pgval.md @@ -0,0 +1,29 @@ +# P08. PGVal: сквозная проверка гарантий потоковой обработки + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Jawad Tahir и соавт. — [How Reliable Are Streams? End-to-End Processing-Guarantee Validation and Performance Benchmarking of Stream Processing Systems](https://www.vldb.org/pvldb/vol18/p585-tahir.pdf). PVLDB 2024. +- **Кратко о статье:** Заявленная системой гарантия обработки потока ещё не доказывает, что входные события дали правильный сквозной результат при сбое. PGVal сопоставляет выход с независимо рассчитанным ожидаемым результатом, вводит процессные и сетевые отказы и измеряет надёжность, надёжную пропускную способность и стоимость отказа. Авторы показывают зависимость результата от топологии, разбиения и параллелизма. Проект воспроизводит такую проверку для одной потоковой системы. +- **Почему результат актуален:** Flink и Kafka Streams активно развиваются, а сквозная гарантия по-прежнему зависит от источника, приёмника, топологии и конфигурации. Модульный расчёт ожидаемого результата и модель отказов позволяют проверять современные версии систем и новые операторы вместо буквального повторения снимка 2024 года. +- **Артефакты и данные:** [jawadtahir/DSPF-BM](https://github.com/jawadtahir/DSPF-BM) под Apache-2.0, с Docker-развёртыванием Kafka Streams, Apache Storm и Apache Flink, генератором данных, модулем независимого расчёта ожидаемого результата и инъекцией отказов. Зафиксированные ревизии: `jawadtahir/DSPF-BM@d74c9b80a3a1` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** заявленной гарантии обработки недостаточно для правильного сквозного результата: надёжность существенно меняется с топологией, разбиением данных, параллелизмом и типом отказа. +- **Технический результат:** Развернуть локальные Kafka и одну потоковую систему, реализовать воспроизводимый источник, оконную топологию, независимый расчёт ожидаемого результата и управляемую инъекцию отказов. Один сценарий должен запускать нагрузку, вводить выбранный отказ, собирать выход и автоматически сравнивать его с эталоном. +- **Эксперимент:** на подготовленном стенде сравнить обычный режим, перезапуск процесса и сетевую задержку по доле правильных результатов, надёжной пропускной способности, задержке и времени восстановления. +- **Границы выводов:** сквозная гарантия проверяется для одной потоковой системы, выбранной топологии и заданных отказов; выводы не распространяются на все операторы, конфигурации и крупные кластеры поддерживаемых систем. +- **Ресурсный профиль:** расширенно локально, Docker, CPU, желательно 16 ГБ памяти. Если полный PGVal требует слишком много процессов, сохранить Kafka, одну систему, эталонную проверку результата и два вида отказов на одном компьютере. + +## Содержательные направления + +- нагрузка и эталонная проверка результата. +- потоковая топология и инъекция отказов. +- метрики корректности, повторные запуски и исследование новой конфигурации. + +## Возможное продолжение + +Добавить соединение двух потоков, другой приёмник, поздние события, изменение числа разделов либо вторую систему и проверить переносимость выводов статьи. diff --git a/project-tasks/p09-a-foundationdb-transactions.md b/project-tasks/p09-a-foundationdb-transactions.md new file mode 100644 index 0000000..5476e71 --- /dev/null +++ b/project-tasks/p09-a-foundationdb-transactions.md @@ -0,0 +1,29 @@ +# P09-A. FoundationDB: транзакции и отказы + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** FoundationDB Team — [FoundationDB: A Distributed Unbundled Transactional Key Value Store](https://www.foundationdb.org/files/fdb-paper.pdf). SIGMOD 2021. +- **Кратко о статье:** FoundationDB строит распределённую базу вокруг небольшого строго упорядоченного транзакционного ядра, отделяя обработку транзакций, журналирование и хранение данных. Более сложные модели данных реализуются слоями поверх упорядоченного key-value-интерфейса, а архитектура рассчитана на заменяемость внутренних ролей и восстановление после отказов. В этом проекте проверяются транзакционная семантика и поведение сокращённой конфигурации при сбоях. +- **Почему результат актуален:** статья описывает архитектуру FoundationDB: небольшое транзакционное ядро, разделение ролей хранения и обработки и детерминированную имитацию отказов для проверки системы. +- **Артефакты и данные:** [apple/foundationdb](https://github.com/apple/foundationdb), открытая система с локальным многопроцессным режимом и детерминированными simulation tests. Зафиксированные ревизии: `apple/foundationdb@ddec61a629a9` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** FoundationDB сохраняет сериализуемость и подтверждённые записи при конфликтующих транзакциях и отказе процесса, хотя рост конфликтности увеличивает число повторов и хвостовую задержку. +- **Технический результат:** Развернуть малый многопроцессный кластер FoundationDB и реализовать повторяемую нагрузку с конфликтующими транзакциями, журналом исходов и проверкой сериализуемости. +- **Эксперимент:** Сравнить не менее трёх уровней конфликтности в штатном режиме и при одном управляемом отказе процесса. Измерить долю конфликтов и повторов, пропускную способность, p95/p99 и время восстановления; отдельно проверить отсутствие потерянных подтверждённых записей. +- **Границы выводов:** проверяются сериализуемость, конфликты и восстановление для выбранной нагрузки и одного отказа в малом кластере; эксперимент не подтверждает производительность и отказоустойчивость FoundationDB в производственном масштабе. +- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти. Сборка всей системы может быть долгой; запасной вариант — использовать готовый выпуск для реального эксперимента и исходный код только для simulation tests. + +## Содержательные направления + +- транзакционная нагрузка. +- отказы и имитация. +- слой или исследование параметров и анализ семантики. + +## Возможное продолжение + +Реализовать небольшой слой поверх упорядоченного KV-интерфейса либо систематически исследовать влияние размера транзакции, конфликтности или размещения ролей. diff --git a/project-tasks/p09-b-foundationdb-simulation.md b/project-tasks/p09-b-foundationdb-simulation.md new file mode 100644 index 0000000..d063ef4 --- /dev/null +++ b/project-tasks/p09-b-foundationdb-simulation.md @@ -0,0 +1,29 @@ +# P09-B. FoundationDB: детерминированная имитация + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** FoundationDB Team — [FoundationDB: A Distributed Unbundled Transactional Key Value Store](https://www.foundationdb.org/files/fdb-paper.pdf). SIGMOD 2021. +- **Кратко о статье:** FoundationDB сочетает рабочую распределённую базу с детерминированной имитацией, в которой тот же код выполняется под управляемым временем, сетью и инъекцией отказов. Фиксация начального зерна позволяет точно повторять редкие последовательности событий и отлаживать нарушения инвариантов. В этом проекте воспроизводится принцип детерминированного планирования и сравнивается повторяемость диагностики с обычным многопроцессным запуском. +- **Почему результат актуален:** статья описывает архитектуру FoundationDB: небольшое транзакционное ядро, разделение ролей хранения и обработки и детерминированную имитацию отказов для проверки системы. +- **Артефакты и данные:** [apple/foundationdb](https://github.com/apple/foundationdb), открытая система с локальным многопроцессным режимом и детерминированными simulation tests. Зафиксированная основная ревизия: `apple/foundationdb@ddec61a629a9` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** Детерминированная имитация позволяет систематически проверять последовательности отказов и точно воспроизводить редкие нарушения, которые трудно диагностировать в обычном многопроцессном запуске. +- **Технический результат:** Собрать или использовать зафиксированный simulation-режим FoundationDB, подготовить малую нагрузку, один проверяемый инвариант и сценарии отказов, управляемые seed. Добавить автоматическое повторное проигрывание найденной трассы. +- **Эксперимент:** Сравнить обычный локальный fault-injection и детерминированную имитацию по числу исследованных сценариев, времени до обнаружения, доле точных повторов и размеру диагностической трассы. Обязательны несколько seed, два вида отказа и намеренно внесённое либо уже известное нарушение. +- **Границы выводов:** сравнение характеризует воспроизводимость и исследованное пространство для выбранной нагрузки, инварианта и видов отказа; оно не доказывает корректность FoundationDB и не оценивает частоту таких сбоев в эксплуатации. +- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти. Сборка всей системы может быть долгой; запасной вариант — использовать готовый выпуск для реального эксперимента и исходный код только для simulation tests. + +## Содержательные направления + +- имитационный стенд и нагрузка. +- инварианты, отказы и воспроизведение. +- базовые варианты, покрытие, уменьшение трасс и анализ. + +## Возможное продолжение + +Уменьшать трассу, добавить новый инвариант или отказ, направлять выбор seed по покрытию либо сопоставить simulation trace с реальным локальным кластером. diff --git a/project-tasks/p10-detock.md b/project-tasks/p10-detock.md new file mode 100644 index 0000000..bc64280 --- /dev/null +++ b/project-tasks/p10-detock.md @@ -0,0 +1,29 @@ +# P10. Detock: транзакции между регионами без глобального упорядочивания + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Cuong D. T. Nguyen, Johann K. Miller и Daniel J. Abadi — [Detock: High Performance Multi-region Transactions at Scale](https://drum.lib.umd.edu/items/8c710897-0b8c-4693-9041-e75209e792d7). SIGMOD 2023. +- **Кратко о статье:** Межрегиональные транзакции затрагивают несколько первичных регионов и при высокой конфликтности приводят либо к частым откатам, либо к распределённым взаимоблокировкам. Detock предлагает протоколы управления конкурентностью и детерминированного разрешения взаимоблокировок, сохраняя строгую сериализуемость без глобального упорядочивания всех операций. Проект проверяет этот механизм на сокращённой реализации или дискретно-событийной модели. +- **Почему результат актуален:** код собирается на обычном Linux-стеке и допускает локальный функциональный запуск; вопрос о цене межрегиональной координации и конфликтов остаётся центральным для геораспределённых транзакционных систем. +- **Артефакты и данные:** [umd-dslam/Detock](https://github.com/umd-dslam/Detock) под MIT, с C++-реализацией, однопроцессной конфигурацией, многорегиональным стендом и отдельными данными экспериментов. Зафиксированные ревизии: `umd-dslam/Detock@9f75dbdf93b6` (MIT). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** графовое управление зависимостями и детерминированное разрешение взаимоблокировок сохраняют строгую сериализуемость и уменьшают потери при высокой конфликтности по сравнению с глобальным упорядочиванием или откатами по тайм-ауту. +- **Технический результат:** Запустить сокращённую конфигурацию Detock в нескольких локальных процессах либо независимо реализовать его дискретно-событийную модель. Добавить реализации глобального порядка и простой стратегии отката, общий генератор транзакций и автоматическую проверку допустимости и сериализуемости по журналу. +- **Эксперимент:** при выбранном техническом пути сравнить Detock с глобальным порядком и простой стратегией отката, варьируя конфликтность и межрегиональную задержку и контролируя сериализуемость всех результатов. +- **Границы выводов:** сериализуемость и относительная эффективность проверяются для выбранной модели транзакций, конфликтности и межрегиональной задержки; локальный стенд или модель не подтверждают производительность Detock в реальной глобальной сети. +- **Ресурсный профиль:** расширенно локально или имитация, Linux, C++, CPU, желательно 16 ГБ памяти. Исходная оценка использует несколько физических узлов; обязательный результат допускает несколько локальных процессов или независимую модель с проверкой сериализуемости по журналу. + +## Содержательные направления + +- сборка и модель транзакций. +- алгоритмы зависимостей, взаимоблокировок и проверка сериализуемости. +- нагрузки, сетевая модель и статистический анализ. + +## Возможное продолжение + +Исследовать перекос ключей, долю межрегиональных транзакций, хвостовую задержку, миграцию данных либо гибридную стратегию для разных уровней конфликтности. diff --git a/project-tasks/p11-clay-codes.md b/project-tasks/p11-clay-codes.md new file mode 100644 index 0000000..e770eaa --- /dev/null +++ b/project-tasks/p11-clay-codes.md @@ -0,0 +1,29 @@ +# P11. Clay Codes: восстановление данных с меньшим сетевым обменом + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Myna Vajha и соавт. — [Clay Codes: Moulding MDS Codes to Yield an MSR Code](https://www.usenix.org/conference/fast18/presentation/vajha). FAST 2018. +- **Кратко о статье:** Обычные MDS-коды экономно хранят данные, но восстановление потерянного узла может потребовать чтения и передачи большого объёма фрагментов. Clay Codes строят minimum-storage regenerating code, который сохраняет MDS-свойство и сокращает объём данных, загружаемых от вспомогательных узлов. В проекте Clay сравнивается с Reed–Solomon по трафику, вычислениям и полному времени восстановления. +- **Почему результат актуален:** [Ceph планирует прекратить поддержку плагина CLAY](https://ceph.io/en/news/blog/2025/ending-support-for-ec-plugins/) в будущем выпуске V, но открытая переносимая реализация позволяет прямо проверить механизм. [Современные работы о векторных кодах](https://www.usenix.org/conference/osdi26/presentation/cai) по-прежнему исследуют тот же обмен между сетевым трафиком, вычислениями и дробностью данных. +- **Артефакты и данные:** независимая библиотека [spool-labs/clay](https://github.com/spool-labs/clay) под Apache-2.0 реализует Clay Codes и коды Рида — Соломона на Rust, содержит тесты и измерения производительности на CPU. Зафиксированные ревизии: `spool-labs/clay@aa6a1f986866` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** Clay уменьшает объём чтения и сетевой передачи при восстановлении, но выигрывает по полному времени только в режимах, где экономия ввода-вывода превышает дополнительные вычисления и накладные расходы разбиения. +- **Технический результат:** Создать CPU-стенд, который кодирует одни и те же данные кодами Clay и Рида — Соломона, удаляет один фрагмент и восстанавливает его. Стенд должен автоматически проверять побайтовое равенство результата и учитывать объём чтения и передачи, процессорное и полное время. +- **Эксперимент:** на одной CPU-машине сравнить Clay и Reed–Solomon при разных параметрах кода, размерах блоков и числе помощников; проверить восстановление одного узла и измерить прочитанные и переданные байты, процессорное и полное время. +- **Границы выводов:** стенд проверяет корректность восстановления и объём чтения и передачи для выбранных параметров кода; модель сети на одной машине не воспроизводит полное время ремонта в распределённом хранилище с реальными дисками и сетью. +- **Ресурсный профиль:** локально, Rust, CPU, 8–16 ГБ памяти. Сеть моделируется ограничением пропускной способности или задержкой; при проблемах с библиотекой обязательная часть использует независимый малый кодировщик и аналитически проверяемый объём восстановления. + +## Содержательные направления + +- корректность кодирования и восстановления. +- стенд и базовые реализации. +- модель сети, измерения и поиск границы выигрыша. + +## Возможное продолжение + +Найти границу выигрыша при ограничении сети, исследовать неоднородных помощников, несколько отказов, выбор размера фрагмента либо адаптивный выбор кода по наблюдаемой цене CPU и сети. diff --git a/project-tasks/p12-a-clickhouse-data-skipping.md b/project-tasks/p12-a-clickhouse-data-skipping.md new file mode 100644 index 0000000..e6f669e --- /dev/null +++ b/project-tasks/p12-a-clickhouse-data-skipping.md @@ -0,0 +1,29 @@ +# P12-A. ClickHouse: отсечение данных + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Robert Schulze и соавт. — [ClickHouse — Lightning Fast Analytics for Everyone](https://www.vldb.org/pvldb/vol17/p3731-schulze.pdf). VLDB 2024. +- **Кратко о статье:** Статья описывает архитектуру ClickHouse — столбцовой аналитической СУБД, рассчитанной на быстрое выполнение запросов над большими объёмами данных. Производительность обеспечивают совместно порядок хранения, разреженный первичный индекс, пропуск ненужных гранул, сжатие и векторизованное выполнение. В этом проекте изолируется вклад порядка данных и отсечения гранул при разной селективности запросов. +- **Почему результат актуален:** статья описывает устройство открытой аналитической СУБД ClickHouse: столбцовое хранение, фоновые слияния частей, векторизованный конвейер исполнения запросов и отсечение ненужных данных. +- **Артефакты и данные:** [ClickHouse/ClickHouse](https://github.com/ClickHouse/ClickHouse) под Apache-2.0 и [ClickHouse/ClickBench](https://github.com/ClickHouse/ClickBench) с воспроизводимой аналитической нагрузкой и конфигурациями разных СУБД. Зафиксированные ревизии: `ClickHouse/ClickHouse@2da63c1b42ca` (Apache-2.0); `ClickHouse/ClickBench@fa52f8524ad9` (CC BY-NC-SA 4.0; лицензии отдельных входных наборов проверяются отдельно). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** порядок данных и пропуск ненужных гранул дают измеримый выигрыш для аналитических запросов, когда фильтр согласован с физической организацией таблицы. +- **Технический результат:** Развернуть ClickHouse и подготовить уменьшенный ClickBench с двумя физическими вариантами одной таблицы, различающимися ключом сортировки и размером гранул. +- **Эксперимент:** Для не менее чем пяти запросов сравнить варианты хранения по прочитанным строкам и байтам, времени, CPU и памяти. Выполнить прогрев и не менее трёх измеряемых повторов; объяснить результат через `EXPLAIN` и системные таблицы. +- **Границы выводов:** эффект отсечения данных оценивается для выбранных ключей сортировки, размеров гранул и запросов уменьшенного ClickBench; он не характеризует все оптимизации ClickHouse и производительность распределённого кластера. +- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти, готовый бинарный выпуск или контейнер. Полный ClickBench не требуется: объём данных и набор запросов сокращаются с проверкой того, что выбранные режимы остаются различимы. + +## Содержательные направления + +- данные, схема и варианты хранения. +- планы и измерения исполнения. +- распределённый режим или дополнительная оптимизация и анализ результатов. + +## Возможное продолжение + +Добавить реплицированный двухузловой стенд, сравнить локальный и распределённый запрос, исследовать компрессию, проекции, пропускную способность загрузки либо сопоставимый столбцовый baseline. diff --git a/project-tasks/p12-b-clickhouse-vectorized-pipeline.md b/project-tasks/p12-b-clickhouse-vectorized-pipeline.md new file mode 100644 index 0000000..0e2bff7 --- /dev/null +++ b/project-tasks/p12-b-clickhouse-vectorized-pipeline.md @@ -0,0 +1,29 @@ +# P12-B. ClickHouse: векторизованный конвейер + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Robert Schulze и соавт. — [ClickHouse — Lightning Fast Analytics for Everyone](https://www.vldb.org/pvldb/vol17/p3731-schulze.pdf). VLDB 2024. +- **Кратко о статье:** Статья описывает архитектуру ClickHouse — столбцовой аналитической СУБД, которая обрабатывает данные блоками и строит параллельный конвейер операторов. Блочная обработка уменьшает накладные расходы на отдельную строку и лучше использует процессор, память и сжатое представление столбцов. В этом проекте исследуется вклад блочной векторизации и выбор размера блока. +- **Почему результат актуален:** статья описывает устройство открытой аналитической СУБД ClickHouse: столбцовое хранение, фоновые слияния частей, векторизованный конвейер исполнения запросов и отсечение ненужных данных. +- **Артефакты и данные:** [ClickHouse/ClickHouse](https://github.com/ClickHouse/ClickHouse) под Apache-2.0 и [ClickHouse/ClickBench](https://github.com/ClickHouse/ClickBench) с воспроизводимой аналитической нагрузкой и конфигурациями разных СУБД. Зафиксированные ревизии: `ClickHouse/ClickHouse@2da63c1b42ca` (Apache-2.0); `ClickHouse/ClickBench@fa52f8524ad9` (CC BY-NC-SA 4.0; лицензии отдельных входных наборов проверяются отдельно). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** Блочная обработка столбцов уменьшает накладные расходы на строку, но выигрыш зависит от селективности, сложности выражения и размера блока. +- **Технический результат:** Реализовать эквивалентные row-at-a-time и блочный конвейеры scan–filter–project–aggregate над одним столбцовым набором данных. Проверять результаты обоих вариантов по эталонному запросу ClickHouse. +- **Эксперимент:** Варьировать размер блока, селективность и вычислительную стоимость выражения. Сравнить построчный baseline и блочный конвейер по времени, throughput, CPU, аллокациям и памяти после прогрева минимум в трёх сериях; отдельно сопоставить тренд с профилем эквивалентного запроса ClickHouse. +- **Границы выводов:** сравнение относится к самостоятельно реализованному конвейеру и выбранному профилю ClickHouse; оно не измеряет вклад векторизации внутри полного движка и не подтверждает производительность распределённых запросов. +- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти, готовый бинарный выпуск или контейнер. Полный ClickBench не требуется: объём данных и набор запросов сокращаются с проверкой того, что выбранные режимы остаются различимы. + +## Содержательные направления + +- эталон и генератор данных. +- два исполнительных конвейера и проверка эквивалентности. +- профилирование, серии параметров и анализ границы выигрыша. + +## Возможное продолжение + +Добавить сжатие, строковые операции, многопоточность, векторизацию SIMD или исследовать режим, где большой блок ухудшает локальность и задержку. diff --git a/project-tasks/p13-noria.md b/project-tasks/p13-noria.md new file mode 100644 index 0000000..32c3212 --- /dev/null +++ b/project-tasks/p13-noria.md @@ -0,0 +1,29 @@ +# P13. Noria: частично материализованный потоковый граф для веб-приложений + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Jon Gjengset и соавт. — [Noria: Dynamic, Partially-Stateful Data-Flow for High-Performance Web Applications](https://www.usenix.org/conference/osdi18/presentation/gjengset). OSDI 2018. +- **Кратко о статье:** Веб-приложениям нужны быстрые чтения производных представлений, но полная материализация всех результатов требует много памяти и усложняет обновления. Noria превращает запросы в потоковый граф, поддерживает результаты инкрементально и хранит состояние только там, где оно нужно текущим чтениям. В проекте сравниваются полная, частичная и отсутствующая материализация на изменяющейся нагрузке. +- **Почему результат актуален:** исходный Noria больше не развивается, однако его практическим преемником стал [ReadySet](https://github.com/readysettech/readyset), продолжающий идею инкрементально поддерживаемого кэша SQL-запросов. У ReadySet действует Business Source License 1.1 с переходом указанной версии в открытую лицензию через четыре года; условия нужно проверить перед заимствованием кода. +- **Артефакты и данные:** [mit-pdos/noria](https://github.com/mit-pdos/noria) под MIT/Apache-2.0, с сервером, встраиваемым примером, MySQL-интерфейсом и нагрузкой `vote` из статьи. Зафиксированные ревизии: `mit-pdos/noria@465184ee4b57` (MIT/Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** частичная материализация позволяет сохранить быстрые чтения и инкрементальные обновления, расходуя меньше памяти, чем полная материализация результатов всех запросов. +- **Технический результат:** Подготовить в Noria или собственном малом потоковом прототипе общий граф операторов с тремя режимами: без материализации, с полной и с частичной материализацией. Реализовать одинаковый генератор обновлений и чтений, автоматическую проверку эквивалентности результатов и учёт занятого и восстановленного состояния. +- **Эксперимент:** на локальном стенде или в собственном малом dataflow-прототипе сравнить отсутствие материализации, полную и частичную материализацию для read-heavy нагрузки; измерять задержку чтений и записей, память и стоимость восстановления вытесненного состояния. +- **Границы выводов:** компромисс памяти и задержки проверяется на выбранном графе операторов и read-heavy-нагрузке; собственный прототип не подтверждает производительность полной реализации Noria и других классов запросов. +- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти. Исследовательский код использует старое Rust-окружение; если его сборка блокирует проект, команда независимо реализует ограниченный граф операторов и проверяет тот же механизм на синтетической и веб-нагрузке. + +## Содержательные направления + +- генератор нагрузки и базовые варианты. +- граф операторов и материализация. +- политика памяти, инструментирование и динамические сценарии. + +## Возможное продолжение + +Динамически добавить запрос, изменить долю популярных ключей, распределить граф между процессами либо предложить другую политику вытеснения и восстановления состояния. diff --git a/project-tasks/p14-a-flink-checkpoints.md b/project-tasks/p14-a-flink-checkpoints.md new file mode 100644 index 0000000..e9b40f8 --- /dev/null +++ b/project-tasks/p14-a-flink-checkpoints.md @@ -0,0 +1,29 @@ +# P14-A. Flink: режимы контрольных точек + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Paris Carbone и соавт. — [Apache Flink: Stream and Batch Processing in a Single Engine](https://asterios.katsifodimos.com/assets/publications/flink-deb.pdf). IEEE Data Engineering Bulletin 2015, 11 страниц. +- **Кратко о статье:** Apache Flink объединяет потоковую и пакетную обработку в общем распределённом движке с состоянием операторов. Для согласованного восстановления система строит распределённые снимки состояния, не останавливая весь поток обработки. В этом проекте сравниваются режимы контрольных точек по накладным расходам, задержке и времени exactly-once-восстановления. +- **Почему результат актуален:** исходная статья описывает раннюю архитектуру, но система стала устойчивой отраслевой платформой и продолжает активно развиваться; [Flink 2.3.0](https://flink.apache.org/2026/06/25/apache-flink-2.3.0-release-announcement/) выпущен в июне 2026 года. Проект использует современную фиксированную версию и проверяет сохраняющийся механизм распределённых контрольных точек. +- **Артефакты и данные:** [apache/flink](https://github.com/apache/flink) под Apache-2.0; доступны актуальная стабильная ветвь, отдельная LTS-ветвь и [официальный локальный режим](https://nightlies.apache.org/flink/flink-docs-stable/docs/getting-started/local_installation/) без обязательного облака. Зафиксированные ревизии: `apache/flink@81389aca7136` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** асинхронные контрольные точки обеспечивают exactly-once-восстановление состояния с измеримым компромиссом между накладными расходами, задержкой обработки и временем восстановления после отказа. +- **Технический результат:** Построить stateful-конвейер Flink с повторяемым источником, уникальными идентификаторами событий, файловым приёмником и автоматической проверкой эквивалентности результатов. Автоматизировать противодавление и отказ TaskManager. +- **Эксперимент:** Сравнить выровненные и невыровненные контрольные точки при двух уровнях противодавления и одном отказе. Измерить throughput, p95/p99, длительность и размер checkpoint, время восстановления, пропуски, дубликаты и ошибки агрегатов; выполнить не менее трёх серий. +- **Границы выводов:** накладные расходы и exactly-once-восстановление проверяются для одного локального конвейера, двух режимов противодавления и отказа TaskManager; результат не охватывает внешние источники и приёмники или крупный кластер. +- **Ресурсный профиль:** одна машина, CPU, 4–8 ГБ памяти и локальная файловая система; Docker и облако необязательны. При нехватке памяти уменьшаются параллелизм и состояние, но сохраняются отдельные процессы, контрольные точки, отказ и автоматическая проверка корректности. + +## Содержательные направления + +- нагрузка и эталон корректности. +- отказоустойчивость, контрольные точки и инструментирование. +- экспериментальные серии, статистический анализ и собственное расширение. + +## Возможное продолжение + +Варьировать размер состояния и период контрольных точек, исследовать savepoint и rescaling, сравнить хранилища состояния либо предложить политику переключения режима при противодавлении. diff --git a/project-tasks/p14-b-flink-rescaling-recovery.md b/project-tasks/p14-b-flink-rescaling-recovery.md new file mode 100644 index 0000000..69d4778 --- /dev/null +++ b/project-tasks/p14-b-flink-rescaling-recovery.md @@ -0,0 +1,29 @@ +# P14-B. Flink: rescaling и восстановление + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Paris Carbone и соавт. — [Apache Flink: Stream and Batch Processing in a Single Engine](https://asterios.katsifodimos.com/assets/publications/flink-deb.pdf). IEEE Data Engineering Bulletin 2015, 11 страниц. +- **Кратко о статье:** Apache Flink объединяет потоковую и пакетную обработку в общем распределённом движке с состоянием операторов. Согласованные контрольные точки и savepoint позволяют восстанавливать вычисление и переносить состояние при изменении параллелизма. В этом проекте исследуется корректность перераспределения состояния и зависимость паузы восстановления от его размера и структуры. +- **Почему результат актуален:** исходная статья описывает раннюю архитектуру, но система стала устойчивой отраслевой платформой и продолжает активно развиваться; [Flink 2.3.0](https://flink.apache.org/2026/06/25/apache-flink-2.3.0-release-announcement/) выпущен в июне 2026 года. Проект использует современную фиксированную версию и проверяет сохраняющийся механизм распределённых контрольных точек. +- **Артефакты и данные:** [apache/flink](https://github.com/apache/flink) под Apache-2.0; доступны актуальная стабильная ветвь, отдельная LTS-ветвь и [официальный локальный режим](https://nightlies.apache.org/flink/flink-docs-stable/docs/getting-started/local_installation/) без обязательного облака. Зафиксированная основная ревизия: `apache/flink@81389aca7136` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** Контрольная точка или savepoint позволяет корректно перераспределить состояние при изменении параллелизма, однако время восстановления и пауза обработки зависят от размера и распределения состояния. +- **Технический результат:** Построить key-partitioned stateful-конвейер Flink с повторяемым источником, автоматической проверкой эквивалентности результатов и автоматизированным сохранением состояния. Реализовать остановку и восстановление с прежним и изменённым параллелизмом. +- **Эксперимент:** Для не менее чем трёх размеров состояния сравнить обычный restart без изменения параллелизма как baseline и восстановление с rescaling. Измерить паузу, полное время восстановления, размер сохранения, throughput после запуска, пропуски, дубликаты и ошибки агрегатов; выполнить по три серии. +- **Границы выводов:** корректность и пауза восстановления измеряются для выбранного stateful-конвейера, размеров состояния и параллелизма на одной машине; результат не характеризует эластичность производственного кластера и удалённого хранилища. +- **Ресурсный профиль:** одна машина, CPU, 4–8 ГБ памяти и локальная файловая система; Docker и облако необязательны. При нехватке памяти уменьшаются параллелизм и состояние, но сохраняются отдельные процессы, контрольные точки, отказ и автоматическая проверка корректности. + +## Содержательные направления + +- нагрузка, состояние и эталон корректности. +- автоматизация savepoint/restart/rescaling. +- измерения восстановления, повторные серии и новый режим. + +## Возможное продолжение + +Исследовать перекос ключей, incremental checkpoints, разные state backend, автоматический выбор параллелизма или последовательность нескольких rescaling. diff --git a/project-tasks/p15-autothrottle.md b/project-tasks/p15-autothrottle.md new file mode 100644 index 0000000..2c6eb86 --- /dev/null +++ b/project-tasks/p15-autothrottle.md @@ -0,0 +1,29 @@ +# P15. Autothrottle: двухуровневое управление ресурсами микросервисов + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Zibo Wang и соавт. — [Autothrottle: A Practical Bi-Level Approach to Resource Management for SLO-Targeted Microservices](https://www.usenix.org/conference/nsdi24/presentation/wang-zibo). NSDI 2024, Outstanding Paper. +- **Кратко о статье:** В графе микросервисов трудно связать сквозной SLO по задержке с CPU, выделенным каждому отдельному сервису. Autothrottle разделяет управление на верхний контроллер, задающий сервисам целевые коэффициенты throttling, и локальные контроллеры, подбирающие CPU для выполнения этих целей. В проекте двухуровневый подход сравнивается с фиксированными лимитами и одноуровневым управлением на сокращённом графе. +- **Почему результат актуален:** двухуровневый контроллер используется как baseline и расширяется в [Galileo](https://www.usenix.org/conference/nsdi26/presentation/saxena), опубликованной на NSDI 2026. Центральный вопрос о связи сквозного SLO с локальным распределением CPU сохраняется независимо от конкретной версии Kubernetes и обученной модели статьи. +- **Артефакты и данные:** [microsoft/autothrottle](https://github.com/microsoft/autothrottle) под MIT, с тремя приложениями, производственными трассами и автоматизированной оценкой. Полное воспроизведение рассчитано на пять крупных машин, поэтому проект использует уменьшенный стенд и собственную калибровку. Зафиксированные ревизии: `microsoft/autothrottle@d237d7f3d765` (MIT; архивирован). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** разделение управления на сквозной и локальный уровни позволяет экономить CPU при соблюдении SLO устойчивее, чем фиксированные лимиты и один общий либо только локальные контроллеры. +- **Технический результат:** Развернуть сокращённый граф из 3–5 сервисов или вариант DeathStarBench, реализовать локальные контроллеры CPU и упрощённый верхний контроллер сквозной цели. Добавить фиксированные лимиты и одноуровневую политику как baselines, общий генератор нагрузки и автоматическую проверку соблюдения SLO. +- **Эксперимент:** на подготовленном графе сравнить двухуровневое управление с фиксированными лимитами и одноуровневой политикой при ступенчатой и переменной нагрузке по соблюдению SLO, потреблению CPU и устойчивости управления. +- **Границы выводов:** соблюдение SLO и экономия CPU проверяются для сокращённого графа, выбранных нагрузок и упрощённых контроллеров; эксперимент не подтверждает устойчивость исходной политики на крупном производственном кластере. +- **Ресурсный профиль:** расширенно локально, Linux, Docker или Kubernetes, CPU, желательно 16–32 ГБ памяти. Если DeathStarBench не помещается, использовать собственную цепочку сервисов с реальной очередью и управляемым потреблением CPU; имитация допустима только для дополнительного масштабирования. + +## Содержательные направления + +- стенд, нагрузка и измерение SLO. +- локальные и верхний контроллеры. +- базовые политики, устойчивость, повторные запуски и новая политика. + +## Возможное продолжение + +Исследовать задержку обратной связи, ошибку модели, изменение графа вызовов, интерференцию фоновой нагрузки либо правило, ограничивающее колебания контроллера. diff --git a/project-tasks/p16-oakestra.md b/project-tasks/p16-oakestra.md new file mode 100644 index 0000000..b84766a --- /dev/null +++ b/project-tasks/p16-oakestra.md @@ -0,0 +1,29 @@ +# P16. Oakestra: иерархическая оркестрация edge-кластера + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Giovanni Bartolomeo и соавт. — [Oakestra: A Lightweight Hierarchical Orchestration Framework for Edge Computing](https://www.usenix.org/system/files/atc23-bartolomeo.pdf). USENIX ATC 2023. +- **Кратко о статье:** Edge-инфраструктура состоит из географически распределённых и неоднородных узлов, поэтому единый центральный оркестратор плохо масштабируется и не всегда видит локальные условия. Oakestra организует управление иерархически: верхний уровень координирует систему, а локальные уровни принимают решения в своих кластерах. В проекте иерархическая политика размещения сравнивается с централизованной на изменяющихся ресурсах и отказах. +- **Почему результат актуален:** проект продолжает развиваться после публикации и остаётся специализированной открытой платформой для edge orchestration. Проверяемый механизм охватывает распределённое размещение и управление при слабых узлах и нестабильных связях и выходит за пределы конкретного edge-приложения. +- **Артефакты и данные:** [oakestra/oakestra](https://github.com/oakestra/oakestra) под Apache-2.0, с оркестраторами, worker-компонентами, сетевым слоем и документацией локального развёртывания. Зафиксированные ревизии: `oakestra/oakestra@2d74107a14d8` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** делегирование решений по иерархии уменьшает нагрузку на центральный уровень и позволяет учитывать локальные ресурсы, сохраняя приемлемое время размещения сервисов. +- **Технический результат:** Развернуть корневой оркестратор, один кластерный оркестратор и 2–4 рабочих процесса или контейнера. Реализовать централизованный baseline, общий генератор запросов на размещение и автоматическую проверку ограничений CPU и памяти и фактического назначения сервисов. +- **Эксперимент:** на подготовленном стенде сравнить централизованную и иерархическую политику на серии размещений при ограничениях CPU и памяти, измеряя время решения, успешность размещения, служебный трафик и потребление ресурсов control plane. +- **Границы выводов:** сравнение проверяет механизм размещения при одном корневом и одном кластерном оркестраторе и 2–4 рабочих узлах; оно не оценивает масштабирование многоуровневой edge-топологии и нестабильность реальной сети. +- **Ресурсный профиль:** расширенно локально, Linux, Docker, CPU, желательно 16 ГБ памяти. При проблемах со сборкой полного сетевого слоя сохранить реальные компоненты планирования и заменить worker-узлы контролируемыми локальными агентами. + +## Содержательные направления + +- стенд и наблюдаемость управляющего уровня. +- политики размещения и инъекция ограничений. +- метрики масштабирования, отказов и новая политика. + +## Возможное продолжение + +Добавить задержку или разрыв связи между уровнями, неоднородность узлов, предпочтение локальности либо собственную политику повторного размещения после отказа. diff --git a/project-tasks/p17-skypilot.md b/project-tasks/p17-skypilot.md new file mode 100644 index 0000000..390489f --- /dev/null +++ b/project-tasks/p17-skypilot.md @@ -0,0 +1,29 @@ +# P17. SkyPilot: планирование заданий между облаками + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Zongheng Yang и соавт. — [SkyPilot: An Intercloud Broker for Sky Computing](https://www.usenix.org/system/files/nsdi23-yang-zongheng.pdf). NSDI 2023. +- **Кратко о статье:** Облачное задание можно разместить у разных провайдеров, в разных регионах и на разных типах машин, которые различаются ценой и доступностью. SkyPilot выступает межоблачным брокером: подбирает выполнимый план, автоматизирует запуск и при необходимости меняет размещение. В проекте исследуется именно выбор плана по сохранённому каталогу ресурсов без расходов на реальные облачные машины. +- **Почему результат актуален:** система активно развивается и используется как самостоятельный слой управления облачными заданиями. Статья сохраняет ценность как ясная постановка распределённого выбора ресурсов при различиях цен, квот и доступности, хотя конкретные провайдеры и их тарифы требуют свежего снимка перед экспериментом. +- **Артефакты и данные:** [skypilot-org/skypilot](https://github.com/skypilot-org/skypilot) под Apache-2.0, с активно развиваемым планировщиком, каталогами ресурсов и поддержкой нескольких облаков и локальных кластеров. Зафиксированные ревизии: `skypilot-org/skypilot@fff7b16adc0c` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** совместный выбор облака, региона и ресурсов позволяет чаще находить выполнимое и дешёвое размещение, чем фиксированный провайдер или жадный выбор самого дешёвого типа машины. +- **Технический результат:** Подготовить автономный планировочный стенд с зафиксированным открытым или синтетическим каталогом ресурсов и набором CPU-заданий. Добавить две простые политики размещения, единый формат планов и проверку ограничений по сроку, региону и ёмкости без запуска платных облачных ресурсов. +- **Эксперимент:** на зафиксированном каталоге сравнить SkyPilot с двумя простыми политиками для CPU-заданий с ограничениями по сроку, региону и ёмкости, измеряя стоимость плана, долю размещённых заданий и устойчивость решения к дефициту ресурсов. +- **Границы выводов:** качество планов оценивается на зафиксированном каталоге и заданных ограничениях; эксперимент не подтверждает текущие цены и доступность реальных облаков или время исполнения размещённых заданий. +- **Ресурсный профиль:** локально, CPU, 4–8 ГБ памяти; облачная учётная запись и реальные расходы не требуются. Если интерфейс текущей версии изменится, команда независимо реализует оптимизатор по модели статьи и проверяет его на сохранённом каталоге. + +## Содержательные направления + +- модель заданий и каталог. +- политики выбора и исполнитель. +- сценарии неопределённости, проверка стоимости и собственное расширение. + +## Возможное продолжение + +Добавить устаревшие сведения о цене и ёмкости, пакет заданий с общей квотой, прерываемые экземпляры, стоимость переноса данных либо онлайн-перепланирование после отказа. diff --git a/project-tasks/p18-faasm.md b/project-tasks/p18-faasm.md new file mode 100644 index 0000000..c3b3134 --- /dev/null +++ b/project-tasks/p18-faasm.md @@ -0,0 +1,29 @@ +# P18. Faasm: WebAssembly-изоляция для stateful serverless + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Simon Shillaker и Peter Pietzuch — [Faasm: Lightweight Isolation for Efficient Stateful Serverless Computing](https://www.usenix.org/conference/atc20/presentation/shillaker). USENIX ATC 2020. +- **Кратко о статье:** Обычная serverless-платформа изолирует функции процессами или контейнерами, из-за чего запуск и обмен состоянием между функциями становятся дорогими. Faasm использует лёгкую WebAssembly-изоляцию, совместное размещение функций и средства общего состояния, уменьшая копирование и сериализацию данных. В проекте этот компромисс воспроизводится на CPU и сравнивается с процессной изоляцией. +- **Почему результат актуален:** система продолжает развиваться, а линия работы получила продолжение в [GRANNY](https://www.usenix.org/conference/nsdi25/presentation/segarra) с поддержкой OpenMP, MPI и динамического управления ресурсами. Исходный механизм программной изоляции и совместного состояния остаётся доступен в текущем runtime. +- **Артефакты и данные:** [faasm/faasm](https://github.com/faasm/faasm) под Apache-2.0, с локальным кластером через Docker Compose, C++-функциями, тестами и поддержкой распределённого состояния. Зафиксированные ревизии: `faasm/faasm@3127fe5aee8e` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** совместное размещение WebAssembly-функций с разделяемой памятью уменьшает стоимость запуска, копирования данных и потребление памяти относительно изолированных процессов или контейнеров с сериализацией состояния. +- **Технический результат:** В локальном Faasm-кластере реализовать две CPU-функции, которые обмениваются массивом или состоянием через разделяемую память. Подготовить функционально эквивалентный baseline с сериализацией через файл, сокет или Redis, единый запуск и автоматическую проверку равенства результатов. +- **Эксперимент:** на подготовленных функциях сравнить разделяемую память Faasm с передачей сериализованных данных через файл, сокет или Redis. Измерять холодный и тёплый запуск, задержку, объём копирования, RSS и пропускную способность при нескольких уровнях параллелизма. +- **Границы выводов:** стоимость обмена состоянием проверяется для двух CPU-функций и выбранного baseline в локальном окружении; результат не оценивает межузловую сеть, многоарендную изоляцию и масштабирование облачного кластера. +- **Ресурсный профиль:** локально, Linux или Docker, CPU, желательно 16 ГБ памяти. Если распределённый режим нестабилен, обязательная часть сохраняет реальные Faaslets и разделяемую память на одном узле, а межузловой обмен исследуется в отдельной модели с калибровкой по локальным измерениям. + +## Содержательные направления + +- функции и базовый вариант с сериализацией. +- развёртывание Faasm и инструментирование. +- серии нагрузок, анализ памяти и собственный режим. + +## Возможное продолжение + +Исследовать размер разделяемого состояния, снимки и восстановление, конкуренцию функций, размещение между workers либо границу, после которой удалённый обмен устраняет выигрыш от совместной памяти. diff --git a/project-tasks/p19-serverless-cold-starts.md b/project-tasks/p19-serverless-cold-starts.md new file mode 100644 index 0000000..b9655ce --- /dev/null +++ b/project-tasks/p19-serverless-cold-starts.md @@ -0,0 +1,29 @@ +# P19. Serverless Cold Starts: проверка обобщений на производственных трассах + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Artjom Joosen и соавт. — [Serverless Cold Starts and Where to Find Them](https://arxiv.org/pdf/2410.06145). EuroSys 2025. +- **Кратко о статье:** Авторы анализируют месячную производственную трассу Huawei, содержащую 85 миллиардов запросов и 11,9 миллиона холодных запусков в пяти дата-центрах. Исследование разделяет задержку на выделение pod, доставку кода и зависимостей и планирование и показывает, что причины заметно различаются между регионами и типами функций. Проект повторяет часть анализа на открытых трассах и проверяет переносимость обобщений. +- **Почему результат актуален:** авторы анализируют крупные производственные трассы и проверяют, какие свойства функций действительно объясняют холодные старты и насколько выводы переносятся между нагрузками. +- **Артефакты и данные:** [sir-lab/data-release](https://github.com/sir-lab/data-release) с обезличенными и агрегированными трассами Huawei Cloud под CC BY 4.0 и примерами анализа. Зафиксированные ревизии: `sir-lab/data-release@84a9d7727aef` (CC BY 4.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** частота cold start и связанные с ней наблюдаемые характеристики заметно различаются между регионами, функциями и периодами; популярные упрощённые модели не описывают весь производственный набор. +- **Технический результат:** Создать воспроизводимый конвейер загрузки, проверки, нормализации и выборки открытых трасс холодных запусков. Конвейер должен фиксировать происхождение данных, одинаково строить группы по периоду, региону и популярности и автоматически воспроизводить выбранные таблицы и графики. +- **Эксперимент:** на доступной части трасс воспроизвести 2–3 основных наблюдения статьи и проверить, сохраняются ли они на разных периодах, регионах и группах популярности. +- **Границы выводов:** наблюдения относятся к доступным периодам, регионам и выбранной части опубликованных трасс; статистические связи не устанавливают причины cold start и не описывают текущее состояние всех облачных платформ. +- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; использовать агрегированные файлы или стратифицированную выборку, если полный объём не помещается. Выводы ограничивать выбранной частью данных. + +## Содержательные направления + +- подготовка и аудит данных. +- воспроизведение статистик. +- модель или политика и проверка переноса. + +## Возможное продолжение + +Построить и честно оценить простую модель риска cold start, проверить устойчивость агрегирования либо смоделировать одну политику keep-alive. diff --git a/project-tasks/p20-cloudcast.md b/project-tasks/p20-cloudcast.md new file mode 100644 index 0000000..81b45d0 --- /dev/null +++ b/project-tasks/p20-cloudcast.md @@ -0,0 +1,29 @@ +# P20. Cloudcast: стоимость и скорость многоадресной передачи между облаками + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Sarah Wooders и соавт. — [Cloudcast: High-Throughput, Cost-Aware Overlay Multicast in the Cloud](https://www.usenix.org/system/files/nsdi24-wooders.pdf). NSDI 2024. +- **Кратко о статье:** Репликация большого набора данных сразу в несколько облачных регионов ограничена пропускной способностью и платой за исходящий трафик. Cloudcast строит оверлейное дерево с промежуточными узлами, учитывая цены и измеренную скорость каналов при заданном сроке передачи. В проекте оптимизатор сравнивается с прямой репликацией и простыми деревьями на воспроизводимой модели сети. +- **Почему результат актуален:** Cloudcast строит прикладное дерево многоадресной передачи между облачными регионами, совместно учитывая пропускную способность, цены трафика и ограничения виртуальных машин. +- **Артефакты и данные:** статья сообщает, что Cloudcast опубликован как часть открытого проекта [Skyplane](https://github.com/skyplane-project/skyplane) с подключаемыми алгоритмами планирования; в зафиксированной ревизии доступны планировщик и решатели. Центральный оптимизатор также можно воспроизвести независимо по псевдокоду и модели стоимости. Зафиксированная ревизия: `skyplane-project/skyplane@4602d9cec208` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** промежуточные узлы и разбиение данных позволяют уменьшить стоимость исходящего трафика при заданном сроке передачи по сравнению с прямой репликацией. +- **Технический результат:** Реализовать модель малой межрегиональной топологии и три построителя плана передачи: оптимизатор Cloudcast, прямую звезду и минимальное остовное дерево. Стенд должен проверять связность дерева, ограничения пропускной способности, стоимость и выполнение заданного срока на общих матрицах входных данных. +- **Эксперимент:** на опубликованных либо синтетических матрицах стоимости и пропускной способности сравнить Cloudcast с прямой звездой и минимальным остовным деревом по стоимости, сроку передачи и допустимости плана. +- **Границы выводов:** модель проверяет стоимость и выполнимость планов на выбранных матрицах цен и пропускной способности; она не учитывает всю изменчивость реальных межоблачных каналов, тарифов и времени запуска узлов. +- **Ресурсный профиль:** имитация, CPU, 4–8 ГБ памяти; платные межоблачные передачи не нужны. Допустимы небольшие локальные измерения между контейнерами для проверки модели исполнения. + +## Содержательные направления + +- оптимизатор. +- исполнитель или симулятор передачи. +- базовые планы, сценарии неопределённости и анализ компромиссов. + +## Возможное продолжение + +Добавить неопределённость пропускной способности, изменение цен, отказ промежуточного узла или онлайн-перестройку дерева. diff --git a/project-tasks/p21-dbsp-feldera.md b/project-tasks/p21-dbsp-feldera.md new file mode 100644 index 0000000..4e4386e --- /dev/null +++ b/project-tasks/p21-dbsp-feldera.md @@ -0,0 +1,29 @@ +# P21. DBSP/Feldera: инкрементальное выполнение запросов + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Mihai Budiu и соавт. — [DBSP: Automatic Incremental View Maintenance for Rich Query Languages](https://www.vldb.org/pvldb/vol16/p1601-budiu.pdf). PVLDB 2023. +- **Кратко о статье:** Повторное выполнение полного запроса после каждого изменения данных тратит работу на уже известный результат. DBSP задаёт алгебраическую модель потоковых вычислений и преобразует пакетную программу в инкрементальную, которая обновляет представление по дельте входа и состояния. В проекте такой план сравнивается с полным пересчётом при разных размерах обновлений. +- **Почему результат актуален:** DBSP перестал быть только теоретическим прототипом и развивается внутри Feldera. Механизм автоматической инкрементализации актуален для совмещения потоковой обработки, materialized views и аналитики над меняющимися данными. +- **Артефакты и данные:** идеи статьи реализованы в активно развиваемой системе [Feldera](https://github.com/feldera/feldera), объединяющей SQL-компилятор и потоковую среду выполнения. Зафиксированная ревизия: `feldera/feldera@ab74092c6a0c` (MIT для открытой редакции; лицензии сторонних компонентов и данных проверяются отдельно). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** инкрементальная программа выполняет работу, зависящую преимущественно от размера изменения и затронутого состояния, и поэтому выигрывает у полного пересчёта при достаточно малых обновлениях. +- **Технический результат:** Реализовать в Feldera или собственном малом инкрементальном движке зафиксированные запросы с фильтрацией, агрегацией и соединением. Добавить пакетный пересчёт как baseline, общий генератор обновлений и автоматическую проверку эквивалентности результатов после каждой серии. +- **Эксперимент:** на сериях обновлений сравнить инкрементальное выполнение с полным пересчётом для запросов с фильтрацией, агрегацией и соединением, измеряя время, память и порог, после которого преимущество исчезает. +- **Границы выводов:** преимущество инкрементального выполнения проверяется для выбранных операторов, запросов и серий обновлений; результат не характеризует полный SQL и распределённую производительность Feldera на производственных данных. +- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти. Если полный стек Feldera слишком тяжёл, обязательная часть использует самостоятельно реализованный набор операторов и проверяет эквивалентность результата пакетному вычислению. + +## Содержательные направления + +- запросы, данные и пакетный пересчёт. +- инкрементальный конвейер и проверка корректности. +- профилирование состояния, границы применимости и новый режим. + +## Возможное продолжение + +Исследовать перекос ключей, размер пакета обновлений, поздние исправления, стоимость хранения состояния либо запрос, для которого автоматическая инкрементализация даёт неожиданно слабый результат. diff --git a/project-tasks/p22-dctcp.md b/project-tasks/p22-dctcp.md new file mode 100644 index 0000000..5984c06 --- /dev/null +++ b/project-tasks/p22-dctcp.md @@ -0,0 +1,29 @@ +# P22. DCTCP: управление перегрузкой в сети дата-центра через ECN + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Mohammad Alizadeh и соавт. — [Data Center TCP (DCTCP)](https://people.csail.mit.edu/alizadeh/papers/dctcp-sigcomm10.pdf). SIGCOMM 2010, Test of Time Award 2021. +- **Кратко о статье:** В сети дата-центра обычный TCP реагирует на перегрузку только после потерь или грубых сигналов, поэтому короткие очереди трудно сочетать с высокой загрузкой канала. DCTCP использует ECN и оценивает долю помеченных пакетов, пропорционально изменяя окно передачи. В проекте этот механизм сравнивается с обычным TCP при смешении коротких и длинных потоков. +- **Почему результат актуален:** работа получила Test of Time Award за долговременное влияние на сети дата-центров; алгоритм также описан в [RFC 8257](https://datatracker.ietf.org/doc/html/rfc8257). Поддерживаемая модель ns-3 снимает зависимость от старого исследовательского артефакта и специализированного оборудования. +- **Артефакты и данные:** актуальный [пример DCTCP в ns-3](https://www.nsnam.org/doxygen/d4/dc2/dctcp-example_8cc_source.html) под GPL-2.0 моделирует ECN-коммутаторы, 40 конкурирующих потоков, несколько узких мест и собирает пропускную способность, справедливость и длину очередей. Для независимой реализации фиксируются версии всех зависимостей и использованных наборов данных. + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** пропорциональная реакция на ECN позволяет DCTCP поддерживать меньшие очереди и хвостовые задержки, чем обычный TCP, сохраняя высокую загрузку канала при смешанных потоках. +- **Технический результат:** Подготовить параметризованный сценарий ns-3 с ECN-коммутатором, DCTCP и TCP Cubic или NewReno, генераторами incast и смешанных потоков. Стенд должен проверять доставку заданного объёма данных и собирать время завершения потоков, длину очереди, загрузку канала и справедливость. +- **Эксперимент:** воспроизвести пример ns-3 и сравнить DCTCP с TCP Cubic или NewReno при incast и смеси коротких и длинных потоков по времени завершения, p95/p99, длине очереди, загрузке и справедливости. +- **Границы выводов:** эксперимент проверяет поведение модели DCTCP в ns-3 для заданной топологии и потоков; он не воспроизводит особенности конкретных сетевых карт, коммутаторов и трафика крупного дата-центра. +- **Ресурсный профиль:** локальная имитация, CPU, 4–8 ГБ памяти. Если полная топология даёт слишком длинные серии, уменьшить число потоков и длительность, сохранив ECN, два режима нагрузки, несколько повторов и проверку загрузки канала. + +## Содержательные направления + +- топология и проверка модели. +- генераторы нагрузок и базовые варианты TCP. +- метрики, статистический анализ и новые режимы. + +## Возможное продолжение + +Исследовать чувствительность к порогу ECN, размеру буфера, числу отправителей, неоднородным RTT или сосуществованию DCTCP и обычного TCP. diff --git a/project-tasks/p23-pagedattention.md b/project-tasks/p23-pagedattention.md new file mode 100644 index 0000000..8d5f9bb --- /dev/null +++ b/project-tasks/p23-pagedattention.md @@ -0,0 +1,29 @@ +# P23. PagedAttention: управление памятью KV-кэша + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Woosuk Kwon и соавт. — [Efficient Memory Management for Large Language Model Serving with PagedAttention](https://arxiv.org/pdf/2309.06180). SOSP 2023. +- **Кратко о статье:** При обслуживании LLM память под KV-кэш обычно резервируется непрерывными областями, что приводит к фрагментации и избыточному резервированию. PagedAttention делит кэш на блоки и размещает их по принципу виртуальной памяти, выделяя место по мере необходимости и допуская безопасное совместное использование. В проекте механизм изолируется от GPU-вычислений и сравнивается с непрерывным размещением на CPU-стенде. +- **Почему результат актуален:** PagedAttention разбивает KV-кэш на страницы и устраняет необходимость непрерывного резервирования памяти, позволяя обслуживать больше параллельных LLM-запросов. +- **Артефакты и данные:** [vllm-project/vllm](https://github.com/vllm-project/vllm), активно развиваемая открытая система с реализацией PagedAttention. Зафиксированные ревизии: `vllm-project/vllm@3e9d364ff727` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** блочное размещение KV-кэша уменьшает фрагментацию и позволяет обслуживать больший динамический пакет запросов, чем непрерывное резервирование памяти. +- **Технический результат:** Реализовать минимальный исполняемый обработчик авторегрессионных запросов на CPU с взаимозаменяемыми непрерывным и страничным аллокаторами KV-кэша. Добавить планирование динамического пакета, проверку инвариантов размещения и учёт реально выделенной памяти и отказов. +- **Эксперимент:** на подготовленном обработчике и реально выделяемых массивах сравнить непрерывный и страничный аллокаторы по занятой памяти, внутренней фрагментации, отказам размещения, размеру динамического пакета и задержке. +- **Границы выводов:** стенд проверяет управление памятью и планирование динамического пакета на CPU; он не оценивает GPU-ядро PagedAttention, качество модели и сквозную производительность полноценного LLM-сервера. +- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; вместо большой модели допустим детерминированный генератор токенов, но обязательный результат включает работающий аллокатор и обработчик запросов. Имитация используется только для расширения масштаба; небольшая GPU-проверка необязательна. + +## Содержательные направления + +- модель запросов и аллокаторы. +- планировщик и метрики. +- анализ чувствительности и дополнительный механизм. + +## Возможное продолжение + +Выбрать размер блока, добавить prefix sharing, swap или предсказание длины и проверить компромисс памяти, метаданных и задержки. diff --git a/project-tasks/p24-llumnix.md b/project-tasks/p24-llumnix.md new file mode 100644 index 0000000..7cec249 --- /dev/null +++ b/project-tasks/p24-llumnix.md @@ -0,0 +1,29 @@ +# P24. Llumnix: динамическое перепланирование LLM-запросов + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Biao Sun и соавт. — [Llumnix: Dynamic Scheduling for Large Language Model Serving](https://www.usenix.org/system/files/osdi24-sun-biao.pdf). OSDI 2024. +- **Кратко о статье:** При одноразовом назначении LLM-запросов экземплярам со временем возникают дисбаланс очередей и фрагментация KV-кэша, а приоритетные запросы могут ждать за длинными. Llumnix переносит выполняющийся запрос вместе с его KV-состоянием и использует миграцию для балансировки, дефрагментации и соблюдения приоритетов. В проекте проверяется, когда выигрыш от перепланирования превышает стоимость переноса. +- **Почему результат актуален:** Llumnix переносит активные LLM-запросы и их KV-состояние между экземплярами, чтобы динамически исправлять дисбаланс нагрузки и фрагментацию памяти. +- **Артефакты и данные:** [llumnix-project/llumnix-ray](https://github.com/llumnix-project/llumnix-ray); исследовательская ветка содержит сценарии основных экспериментов. Зафиксированная ревизия: `llumnix-project/llumnix-ray@3fb6c0376b3b` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** перенос активного запроса вместе с KV-состоянием позволяет выравнивать загрузку, устранять фрагментацию и поддерживать приоритеты лучше одноразового назначения. +- **Технический результат:** Построить дискретно-событийный симулятор нескольких экземпляров с профилями запросов, очередями, стоимостью миграции и тремя политиками: статическое назначение, least-loaded и перепланирование Llumnix. Добавить проверки сохранения запросов и согласованности учёта времени и очередей. +- **Эксперимент:** в симуляторе сравнить статическое назначение, least-loaded и перепланирование Llumnix при неоднородных длинах и интенсивности запросов по времени ожидания, нарушению SLO, использованию памяти и числу миграций. +- **Границы выводов:** выводы относятся к очередям, профилям и стоимости миграции, заданным в симуляторе; без GPU-стенда они не подтверждают фактическую цену переноса KV-кэша и соблюдение SLO в реальном LLM-сервисе. +- **Ресурсный профиль:** имитация, CPU и 4–8 ГБ памяти; полное авторское воспроизведение требует 16 GPU, поэтому обязательная часть проверяет алгоритмический механизм и калибрует стоимость по опубликованным данным. + +## Содержательные направления + +- симулятор исполнения. +- политики и миграция. +- нагрузка, SLO-метрики и анализ устойчивости. + +## Возможное продолжение + +Учесть стоимость миграции, ошибку прогноза длины, разные SLO или автоподбор порога переноса. diff --git a/project-tasks/p25-a-ray-task-graphs.md b/project-tasks/p25-a-ray-task-graphs.md new file mode 100644 index 0000000..3dba074 --- /dev/null +++ b/project-tasks/p25-a-ray-task-graphs.md @@ -0,0 +1,29 @@ +# P25-A. Ray: динамические графы задач + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Philipp Moritz и соавт. — [Ray: A Distributed Framework for Emerging AI Applications](https://www.usenix.org/conference/osdi18/presentation/moritz). OSDI 2018. +- **Кратко о статье:** Приложения машинного обучения сочетают динамические графы коротких задач с долгоживущим изменяемым состоянием, которое неудобно выражать в традиционных пакетных системах. Ray объединяет удалённые функции и акторы в одном распределённом движке с масштабируемым планированием и восстановлением. В этом проекте исследуются накладные расходы и масштабирование динамических графов задач. +- **Почему результат актуален:** Ray объединяет задачи и акторы в одном распределённом runtime, рассчитанном на динамические графы вычислений, возникающие в обучении с подкреплением и других ИИ-приложениях. +- **Артефакты и данные:** [ray-project/ray](https://github.com/ray-project/ray), открытая система с локальным кластерным режимом и актуальной документацией. Зафиксированные ревизии: `ray-project/ray@2ff4d94078ee` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** единый динамический движок задач и акторов способен поддерживать высокую частоту коротких задач и сложные зависимые вычисления без специализированного планировщика для каждого приложения. +- **Технический результат:** Подготовить локальный кластер Ray, генератор динамических DAG из коротких CPU-задач и сопоставимый baseline на процессном пуле. Добавить трассировку постановки, ожидания и исполнения задач. +- **Эксперимент:** Варьировать гранулярность, ширину и глубину графа; сравнить Ray и baseline по времени выполнения, накладным расходам планирования, загрузке CPU и масштабированию. Для каждого режима выполнить не менее трёх серий и проверить равенство результатов. +- **Границы выводов:** накладные расходы планирования измеряются для коротких CPU-задач и выбранных DAG на одном компьютере; результат не характеризует многоузловое масштабирование, неоднородные ресурсы и восстановление Ray после отказов. +- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; масштаб статьи не воспроизводится, проверяется механизм на одном компьютере с несколькими процессами. + +## Содержательные направления + +- нагрузки и базовый вариант. +- инструментирование планировщика и отказы. +- новая политика и анализ масштабирования. + +## Возможное продолжение + +Реализовать собственную политику размещения, backpressure, locality-aware вариант либо сравнить Ray с простым процессным baseline на том же workload. diff --git a/project-tasks/p25-b-ray-actors-recovery.md b/project-tasks/p25-b-ray-actors-recovery.md new file mode 100644 index 0000000..ee70234 --- /dev/null +++ b/project-tasks/p25-b-ray-actors-recovery.md @@ -0,0 +1,29 @@ +# P25-B. Ray: акторы и восстановление + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Philipp Moritz и соавт. — [Ray: A Distributed Framework for Emerging AI Applications](https://www.usenix.org/conference/osdi18/presentation/moritz). OSDI 2018. +- **Кратко о статье:** Приложения машинного обучения сочетают динамические графы задач с долгоживущим изменяемым состоянием. Ray предоставляет для них общую модель удалённых функций и акторов, дополняя её распределённым планированием, объектным хранилищем и механизмами восстановления. В этом проекте исследуется граница между состоянием актора, повторным выполнением задач и внешним сохранением данных при сбоях. +- **Почему результат актуален:** Ray объединяет задачи и акторы в одном распределённом runtime, рассчитанном на динамические графы вычислений, возникающие в обучении с подкреплением и других ИИ-приложениях. +- **Артефакты и данные:** [ray-project/ray](https://github.com/ray-project/ray), открытая система с локальным кластерным режимом и актуальной документацией. Зафиксированная основная ревизия: `ray-project/ray@2ff4d94078ee` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** Модель акторов упрощает долгоживущее изменяемое состояние, но гарантии восстановления и цена повторного выполнения зависят от границы между состоянием актора, задачами и внешним хранилищем. +- **Технический результат:** Реализовать локальное приложение из нескольких stateful-акторов и клиентов с журналом операций, контрольными суммами и управляемыми падениями. Добавить как минимум две стратегии восстановления состояния. +- **Эксперимент:** Сравнить restart без внешнего состояния, checkpoint/replay и простой процессный baseline при отказе worker и актора. Измерить время восстановления, потерянные или повторные операции, p95/p99, объём повторной работы и правильность конечного состояния минимум в трёх сериях. +- **Границы выводов:** гарантии и цена восстановления проверяются для выбранного приложения акторов, стратегий хранения и локальных отказов; результат не устанавливает общую семантику долговечности Ray и поведение крупного кластера. +- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; масштаб статьи не воспроизводится, проверяется механизм на одном компьютере с несколькими процессами. + +## Содержательные направления + +- модель состояния и эталон корректности. +- приложение акторов, отказы и восстановление. +- базовый вариант, нагрузка, повторные серии и анализ гарантий. + +## Возможное продолжение + +Добавить placement groups, репликацию состояния, backpressure, цепочку акторов или отказ во время checkpoint. diff --git a/project-tasks/p26-a-parrot-graph-scheduling.md b/project-tasks/p26-a-parrot-graph-scheduling.md new file mode 100644 index 0000000..3f55a22 --- /dev/null +++ b/project-tasks/p26-a-parrot-graph-scheduling.md @@ -0,0 +1,29 @@ +# P26-A. Parrot: планирование графа + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Chaofan Lin и соавт. — [Parrot: Efficient Serving of LLM-based Applications with Semantic Variable](https://www.usenix.org/conference/osdi24/presentation/lin-chaofan). OSDI 2024. +- **Кратко о статье:** LLM-приложение часто состоит из зависимых вызовов модели, но обычный сервис видит их как отдельные непрозрачные запросы и не может учитывать общий критический путь. Parrot вводит семантические переменные, раскрывающие зависимости и повторно используемый контекст, и планирует весь граф приложения. В этом проекте графовое планирование сравнивается с последовательной и простой очередной обработкой. +- **Почему результат актуален:** Parrot добавляет в интерфейс LLM-сервиса семантические переменные, которые раскрывают зависимости между вызовами и структуру промптов для совместной оптимизации всего приложения. +- **Артефакты и данные:** [microsoft/ParrotServe](https://github.com/microsoft/ParrotServe) под MIT, с клиентской частью, примерами составных приложений, планировщиком и тестами. Зафиксированные ревизии: `microsoft/ParrotServe@2e1825ee2bc3` (MIT). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** знание графа вызовов и общих префиксов позволяет сервису распараллеливать независимые запросы, переиспользовать состояние и оптимизировать время выполнения приложения лучше, чем при обработке непрозрачных запросов по отдельности. +- **Технический результат:** Реализовать исполняемый сервис составного приложения с семантическими переменными, реальной очередью и двумя DAG, содержащими последовательные и независимые вызовы. Исполнитель должен поддерживать последовательную и графовую политики. +- **Эксперимент:** Сравнить последовательное выполнение, обычную пакетную обработку и планирование по критическому пути при нескольких уровнях параллелизма. Измерить полное время приложения, p95, загрузку исполнителей и ожидание узлов; проверить корректность зависимостей и выполнить не менее трёх серий. +- **Границы выводов:** эффект планирования графа проверяется для двух составных DAG и локального исполнителя с измеряемой стоимостью вызовов; он не характеризует качество LLM, GPU-планирование и производственную нагрузку Parrot. +- **Ресурсный профиль:** локально, CPU, до 16 ГБ памяти; вызов LLM можно заменить малой локальной моделью или детерминированной функцией с измеряемым временем, но сам исполнитель и планировщик должны работать на реальных запросах. Симулятор допустим только для масштабных серий. + +## Содержательные направления + +- графы приложений и нагрузки. +- реализации политик и инструментирование. +- метрики, граничные случаи и новое правило планирования. + +## Возможное продолжение + +Исследовать неполные или ошибочные аннотации, динамически раскрываемые зависимости, изоляцию между пользователями либо компромисс между локальностью префикса и критическим путём. diff --git a/project-tasks/p26-b-parrot-prefix-locality.md b/project-tasks/p26-b-parrot-prefix-locality.md new file mode 100644 index 0000000..d261601 --- /dev/null +++ b/project-tasks/p26-b-parrot-prefix-locality.md @@ -0,0 +1,29 @@ +# P26-B. Parrot: префиксы и локальность + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Chaofan Lin и соавт. — [Parrot: Efficient Serving of LLM-based Applications with Semantic Variable](https://www.usenix.org/conference/osdi24/presentation/lin-chaofan). OSDI 2024. +- **Кратко о статье:** В LLM-приложениях разные вызовы часто используют общие части промптов, однако обычный сервис не знает ни об этой связи, ни о зависимостях между запросами. Parrot представляет значения семантическими переменными и использует открывшийся граф для переиспользования контекста и совместного планирования. В этом проекте исследуется компромисс между локальностью общих префиксов и балансировкой очередей. +- **Почему результат актуален:** Parrot добавляет в интерфейс LLM-сервиса семантические переменные, которые раскрывают зависимости между вызовами и структуру промптов для совместной оптимизации всего приложения. +- **Артефакты и данные:** [microsoft/ParrotServe](https://github.com/microsoft/ParrotServe) под MIT, с клиентской частью, примерами составных приложений, планировщиком и тестами. Зафиксированная основная ревизия: `microsoft/ParrotServe@2e1825ee2bc3` (MIT). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** Знание общих частей промптов позволяет уменьшать повторные вычисления, но политика локальности может конфликтовать с балансировкой очередей и критическим путём приложения. +- **Технический результат:** Реализовать исполнитель составных запросов с явными семантическими переменными, блочным кэшем префиксов и двумя политиками маршрутизации: least-loaded и prefix-aware. Допустима малая локальная модель или детерминированная функция с измеряемой стоимостью. +- **Эксперимент:** Варьировать долю общих префиксов, размер кэша, интенсивность и перекос запросов. Сравнить least-loaded baseline и prefix-aware-политику по hit rate, объёму повторной работы, полному времени приложения, p95 и загрузке исполнителей минимум в трёх сериях; проверить правильность изоляции результатов разных запросов. +- **Границы выводов:** компромисс локальности и балансировки проверяется для выбранной модели стоимости, кэша и распределения префиксов; результат не подтверждает совместимость реального KV-кэша модели и производительность GPU-сервера. +- **Ресурсный профиль:** локально, CPU, до 16 ГБ памяти; вызов LLM можно заменить малой локальной моделью или детерминированной функцией с измеряемым временем, но сам исполнитель и планировщик должны работать на реальных запросах. Симулятор допустим только для масштабных серий. + +## Содержательные направления + +- нагрузки и графы с общими префиксами. +- кэш и маршрутизация. +- метрики, проверка изоляции, граничные режимы и новая политика. + +## Возможное продолжение + +Добавить многоарендность, ошибочные аннотации, стоимость переноса состояния, совместную политику критического пути и локальности или предсказание повторного использования. diff --git a/project-tasks/p27-dede.md b/project-tasks/p27-dede.md new file mode 100644 index 0000000..d003eed --- /dev/null +++ b/project-tasks/p27-dede.md @@ -0,0 +1,29 @@ +# P27. DeDe: декомпозиция задач распределения ресурсов + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Zhiying Xu и соавт. — [Decouple and Decompose: Scaling Resource Allocation with DeDe](https://www.usenix.org/conference/osdi25/presentation/xu). OSDI 2025. +- **Кратко о статье:** Крупные задачи распределения ресурсов в облаке перерастают возможности универсальных решателей, а специализированные алгоритмы обычно привязаны к одной системе. DeDe использует общую разделимость многих постановок: разъединяет ограничения ресурсов и запросов и решает чередующиеся подзадачи независимо и параллельно. В проекте этот подход сравнивается с монолитным решением по времени, допустимости и качеству распределения. +- **Почему результат актуален:** опубликованный пакет предоставляет высокоуровневый интерфейс, тесты и три разные прикладные задачи. Статья свежая, поэтому статус влияния предварительный, но общий механизм не привязан к закрытому кластеру или специальному оборудованию и уже допускает независимую проверку на CPU. +- **Артефакты и данные:** [illinois-nsai/dede](https://github.com/illinois-nsai/dede) под MIT, доступен как Python-пакет и содержит примеры для кластерного планирования, балансировки нагрузки и управления трафиком. Для обязательного сравнения достаточно свободного решателя CVXPY; Gurobi не требуется. Зафиксированные ревизии: `illinois-nsai/dede@11c97f786a1e` (MIT). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** разделение связанных ограничений на подзадачи для ресурсов и запросов ускоряет решение крупных задач распределения, сохраняя допустимость и качество результата относительно монолитного решателя. +- **Технический результат:** Формализовать одну задачу кластерного размещения или балансировки нагрузки и реализовать её в DeDe и как монолитную модель CVXPY. Подготовить общий генератор входов, проверку допустимости решения и единый расчёт целевой функции и невязок. +- **Эксперимент:** для выбранной задачи на открытых или синтетических данных сравнить DeDe и монолитное решение CVXPY по времени, целевой функции, невязкам и масштабированию по числу ресурсов и запросов. +- **Границы выводов:** сравнение относится к одной формализации задачи, выбранным входам и размерам, доступным точному решателю; оно не устанавливает преимущество DeDe для других задач распределения и производственных масштабов. +- **Ресурсный профиль:** локально, CPU, Python, 8–16 ГБ памяти. Если высокоуровневый интерфейс нестабилен на большой задаче, использовать опубликованные низкоуровневые примеры и уменьшить размер, сохранив сравнение с точным решением на тех же входах. + +## Содержательные направления + +- постановка и генератор задач. +- реализации DeDe и монолитного варианта. +- проверка допустимости, масштабирование и исследование нового ограничения. + +## Возможное продолжение + +Добавить неоднородные ресурсы, онлайн-прибытие запросов, ограничение миграций, новый критерий справедливости либо собственное правило адаптации параметра декомпозиции. diff --git a/project-tasks/p28-distserve.md b/project-tasks/p28-distserve.md new file mode 100644 index 0000000..be9cd43 --- /dev/null +++ b/project-tasks/p28-distserve.md @@ -0,0 +1,29 @@ +# P28. DistServe: раздельное выполнение prefill и decode + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Yinmin Zhong и соавт. — [DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving](https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin). OSDI 2024. +- **Кратко о статье:** Обработка LLM-запроса состоит из вычислительно насыщенного prefill и последовательного decode с другим профилем нагрузки, поэтому совместное выполнение мешает независимо масштабировать стадии. DistServe размещает их на разных наборах устройств и передаёт между ними KV-кэш, оптимизируя полезную пропускную способность при ограничениях на TTFT и TPOT. Проект воспроизводит этот компромисс на CPU-модели. +- **Почему результат актуален:** исходная реализация остаётся исследовательским артефактом, однако раздельные prefill и decode вошли в современные системы инференса, включая экспериментальный режим [vLLM](https://docs.vllm.ai/en/v0.14.0/features/disagg_prefill/). Поэтому проект проверяет уже применяемое архитектурное решение и его границу выгодности. +- **Артефакты и данные:** [LLMServe/DistServe](https://github.com/LLMServe/DistServe) под Apache-2.0; включает код системы, профилировщик, сценарии оценки и `simdistserve`. Зафиксированные ревизии: `LLMServe/DistServe@82831f1604cc` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** разделение prefill и decode увеличивает goodput при одновременных ограничениях на TTFT и TPOT, если выигрыш от независимого масштабирования превышает стоимость передачи KV-кэша. +- **Технический результат:** Реализовать CPU-симулятор фаз prefill и decode с очередями, профилями выполнения и моделью сети. Добавить совместное и раздельное размещение, общий генератор запросов и проверки сохранения запросов, пропускной способности и разложения задержки по фазам. +- **Эксперимент:** на профилях или синтетической модели сравнить совместное и раздельное размещение для нескольких распределений длин входа и выхода, явно варьируя пропускную способность сети и проверяя обе задержки и goodput. +- **Границы выводов:** выигрыш раздельного выполнения определяется профилями и сетевой моделью симулятора; без GPU-стенда он не подтверждает фактические TTFT, TPOT, goodput и цену передачи KV-кэша в DistServe. +- **Ресурсный профиль:** локально, CPU и 8–16 ГБ памяти для имитации; полная система требует как минимум два GPU и остаётся необязательной. Калибровку можно провести по опубликованным профилям и небольшому локальному измерению. + +## Содержательные направления + +- модель фаз и профили. +- политики размещения и маршрутизации. +- SLO, сетевые ограничения и анализ чувствительности. + +## Возможное продолжение + +Динамически переключать совместный и раздельный режим, учитывать неоднородные ускорители, искать неблагоприятные режимы либо предложить новую политику выбора числа экземпляров каждой фазы. diff --git a/project-tasks/p29-mooncake.md b/project-tasks/p29-mooncake.md new file mode 100644 index 0000000..bc1b2d7 --- /dev/null +++ b/project-tasks/p29-mooncake.md @@ -0,0 +1,29 @@ +# P29. Mooncake: глобальный многоуровневый KV-кэш + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Ruoyu Qin и соавт. — [Mooncake: Trading More Storage for Less Computation — A KVCache-centric Architecture for Serving LLM Chatbot](https://www.usenix.org/conference/fast25/presentation/qin). FAST 2025, Best Paper. +- **Кратко о статье:** Для длинных диалогов и повторяющихся префиксов повторный prefill расходует дорогие вычисления, хотя готовый KV-кэш можно сохранить и передать. Mooncake отделяет стадии prefill и decode и строит глобальный многоуровневый KV-кэш на памяти и накопителях вычислительных узлов. В проекте сравниваются повторное вычисление, локальный кэш и общее блочное хранилище при разных сетевых ограничениях. +- **Почему результат актуален:** Mooncake разделяет prefill и decode и превращает память GPU, DRAM и SSD кластера в общий KV-кэш, управляемый с учётом повторного использования и требований к задержке. +- **Артефакты и данные:** [kvcache-ai/Mooncake](https://github.com/kvcache-ai/Mooncake) под Apache-2.0 с движком передачи и [FAST’25-трассами](https://github.com/kvcache-ai/Mooncake/tree/main/FAST25-release), включая отдельную агентную нагрузку. Зафиксированные ревизии: `kvcache-ai/Mooncake@408b831bfeff` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** глобальное хранение KV-блоков может выгодно заменить повторный prefill для длинных общих префиксов, но результат определяется пропускной способностью хранилища, конкуренцией за сеть и политикой допуска в кэш. +- **Технический результат:** Построить из нескольких процессов общий блочный кэш поверх RAM и локального SSD с сетевым чтением, вытеснением и предварительной загрузкой. Добавить локальный LRU и модель повторного вычисления, проигрыватель открытых трасс и проверку целостности возвращаемых блоков. +- **Эксперимент:** на подготовленном блочном кэше и открытых трассах сравнить глобальную политику с локальным LRU и повторным вычислением по доле попаданий, переданным байтам, задержке и goodput. +- **Границы выводов:** стенд проверяет политики блочного кэша на RAM, SSD и локальной сети при заданной стоимости повторного вычисления; он не воспроизводит RDMA, GPU-prefill и конкуренцию производственного кластера Mooncake. +- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти, несколько процессов; RDMA и GPU не требуются. Стоимость prefill задаётся реальной малой функцией или калиброванной задержкой, а при тяжёлой трассе используется воспроизводимая подвыборка. + +## Содержательные направления + +- разбор трасс и модель стоимости. +- реализации кэшей и маршрутизации. +- SLO, сетевые эксперименты и новая политика. + +## Возможное продолжение + +Добавить объединение одновременных загрузок, ограничение полосы, несколько арендаторов, ошибку предсказания повторного использования либо совместное решение о маршрутизации и вытеснении. diff --git a/project-tasks/p30-pollux.md b/project-tasks/p30-pollux.md new file mode 100644 index 0000000..e341c6f --- /dev/null +++ b/project-tasks/p30-pollux.md @@ -0,0 +1,29 @@ +# P30. Pollux: совместная адаптация обучения и кластерного планировщика + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Aurick Qiao и соавт. — [Pollux: Co-adaptive Cluster Scheduling for Goodput-Optimized Deep Learning](https://www.usenix.org/conference/osdi21/presentation/qiao). OSDI 2021, Best Paper. +- **Кратко о статье:** Скорость обучения зависит от числа выделенных ускорителей и размера пакета. Размер пакета меняет системную производительность и статистическую эффективность оптимизации. Pollux объединяет эти факторы в метрике goodput и совместно адаптирует конфигурацию задания и распределение ресурсов кластера. В проекте такая политика сравнивается с планированием только по throughput на симуляции CPU. +- **Почему результат актуален:** ветка AdaptDL в основном сохранилась как снимок статьи, но совместная оптимизация размещения и goodput получила прямое развитие в [Sia](https://shouxulin.github.io/pubs/sia.pdf), учитывающей неоднородные кластеры. Базовый проект использует Pollux как понятный исходный механизм и сравнивает его с современным продолжением постановки. +- **Артефакты и данные:** ветка [petuum/adaptdl для OSDI 2021](https://github.com/petuum/adaptdl/tree/osdi21-artifact) под Apache-2.0 содержит реализацию и дискретный симулятор кластера. Зафиксированные ревизии: `petuum/adaptdl@542e123e50e9` (Apache-2.0). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** совместный учёт системной скорости и статистической эффективности обучения позволяет перераспределять ресурсы с меньшим средним временем завершения, сохраняя справедливость между задачами. +- **Технический результат:** Создать исполнитель нескольких малых CPU-задач обучения как реальных процессов и три планировщика: фиксированный, простой динамический и упрощённый Pollux с изменением параллелизма и размера пакета. Добавить единый журнал событий, проверку завершения задач и расчёт goodput, JCT и справедливости. +- **Эксперимент:** на нескольких наборах одновременно выполняющихся задач сравнить фиксированное распределение, простую динамическую политику и упрощённый Pollux, измеряя goodput, JCT и справедливость. +- **Границы выводов:** сравнение относится к малым CPU-задачам, упрощённой модели goodput и выбранным политикам; оно не подтверждает статистическую эффективность и время завершения много-GPU-обучения в производственном кластере. +- **Ресурсный профиль:** локально, CPU, 8–16 ГБ памяти; достаточно малых моделей и наборов данных, поэтому несколько реальных задач входят в обязательную часть. Синтетические профили используются для калибровки и расширения масштаба; при несовместимости артефакта планировщик реализуется независимо. + +## Содержательные направления + +- профили и модель прогресса. +- планировщики и симулятор. +- справедливость, чувствительность и новая целевая функция. + +## Возможное продолжение + +Добавить неоднородные ускорители, ошибку профиля, стоимость перераспределения, приоритеты либо новую цель, объединяющую JCT и справедливость. diff --git a/project-tasks/p31-a-gc3-correctness.md b/project-tasks/p31-a-gc3-correctness.md new file mode 100644 index 0000000..74c3f4d --- /dev/null +++ b/project-tasks/p31-a-gc3-correctness.md @@ -0,0 +1,29 @@ +# P31-A. GC3: корректность расписаний + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Meghan Cowan и соавт. — [GC3: An Optimizing Compiler for GPU Collective Communication](https://arxiv.org/pdf/2201.11840). ASPLOS 2023. +- **Кратко о статье:** Быстрые коллективные операции для GPU-кластеров обычно реализуются вручную под конкретную топологию, что усложняет проверку и перенос оптимизаций. GC3 задаёт коллектив как структурированную программу пересылок и компилирует её в специализированное выполнение, применяя преобразования и конвейеризацию. В этом проекте строится CPU-модель для проверки корректности расписаний и сохранения семантики после преобразований. +- **Почему результат актуален:** исходный набор MSCCL tools обновляется редко, но линия программируемых коллективов продолжается в активно развиваемом [MSCCL++](https://github.com/microsoft/mscclpp) под MIT. Проект сосредоточен на переносимом языке расписаний, проверке корректности и компиляции; устаревшая версия runtime не входит в его основной предмет. +- **Артефакты и данные:** [microsoft/msccl-tools](https://github.com/microsoft/msccl-tools) под MIT, с Python DSL MSCCLang, компилятором, примерами и тестами. Зафиксированные ревизии: `microsoft/msccl-tools@030a750fc56e` (MIT). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** явное описание алгоритма на уровне блоков вместе с компиляторными преобразованиями позволяет безопасно получать специализированные конвейерные коллективы без ручного написания низкоуровневого GPU-кода. +- **Технический результат:** Выразить ring AllReduce и один AllToAll в MSCCLang, построить независимый эталон семантики блоков и автоматическую проверку полученного расписания. +- **Эксперимент:** Для нескольких размеров топологии проверить отсутствие потерь, дублирования, чтения до записи и взаимоблокировки, затем сопоставить IR и имитационную стоимость с эталонным расписанием. Обязательны положительные тесты и не менее трёх намеренно испорченных расписаний. +- **Границы выводов:** проверка относится к семантике блоков, выбранным коллективам и сгенерированному IR; без исполнения на GPU она не подтверждает производительность расписаний и корректность низкоуровневого runtime. +- **Ресурсный профиль:** локально, CPU и 4–8 ГБ памяти для компиляции и имитации; исполнение через MSCCL на нескольких GPU необязательно и не входит в минимальный результат. + +## Содержательные направления + +- DSL-программы и эталоны. +- анализ и модификация компилятора. +- проверка расписаний, модель стоимости и эксперименты. + +## Возможное продолжение + +Реализовать проверку корректности, новую оптимизацию порядка или слияния передач, поддержку новой топологии либо автоматический выбор числа каналов. diff --git a/project-tasks/p31-b-gc3-topology-optimization.md b/project-tasks/p31-b-gc3-topology-optimization.md new file mode 100644 index 0000000..958e7a5 --- /dev/null +++ b/project-tasks/p31-b-gc3-topology-optimization.md @@ -0,0 +1,29 @@ +# P31-B. GC3: оптимизация под топологию + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Meghan Cowan и соавт. — [GC3: An Optimizing Compiler for GPU Collective Communication](https://arxiv.org/pdf/2201.11840). ASPLOS 2023. +- **Кратко о статье:** Быстрые коллективные операции для GPU-кластеров обычно реализуются вручную под конкретную топологию и доступные параллельные каналы. GC3 отделяет описание алгоритма обмена от низкоуровневого выполнения и компилирует специализированные расписания с конвейеризацией. В этом проекте исследуется, как учёт топологии сокращает критический путь коллектива без изменения результата. +- **Почему результат актуален:** исходный набор MSCCL tools обновляется редко, но линия программируемых коллективов продолжается в активно развиваемом [MSCCL++](https://github.com/microsoft/mscclpp) под MIT. Проект сосредоточен на переносимом языке расписаний, проверке корректности и компиляции; устаревшая версия runtime не входит в его основной предмет. +- **Артефакты и данные:** [microsoft/msccl-tools](https://github.com/microsoft/msccl-tools) под MIT, с Python DSL MSCCLang, компилятором, примерами и тестами. Зафиксированная основная ревизия: `microsoft/msccl-tools@030a750fc56e` (MIT). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** Специализированное расписание, учитывающее топологию и параллельные каналы, может сократить критический путь коллектива без изменения его семантики. +- **Технический результат:** Построить CPU-симулятор топологии и расписаний MSCCLang, реализовать хотя бы одно преобразование порядка, разбиения или назначения каналов. Корректность каждого результата проверяется независимой моделью движения блоков. +- **Эксперимент:** Сравнить исходный ring либо AllToAll и оптимизированное расписание на двух топологиях и нескольких размерах сообщения. Измерить критический путь, переданные байты, загрузку узких каналов и число шагов; проверить корректность и устойчивость к изменению параметров. +- **Границы выводов:** выигрыш оценивается по модели критического пути на двух заданных топологиях; он не учитывает все эффекты реальной сети, GPU-ядер и конкуренции каналов при исполнении коллектива. +- **Ресурсный профиль:** локально, CPU и 4–8 ГБ памяти для компиляции и имитации; исполнение через MSCCL на нескольких GPU необязательно и не входит в минимальный результат. + +## Содержательные направления + +- модель топологии и исходное расписание. +- компиляторное преобразование и генерация расписаний. +- проверка корректности, модель стоимости и экспериментальные серии. + +## Возможное продолжение + +Добавить иерархическую топологию, автоматический поиск числа каналов, отказ одного канала, слияние передач или сравнение с ещё одним опубликованным коллективом. diff --git a/project-tasks/p32-alea-bft.md b/project-tasks/p32-alea-bft.md new file mode 100644 index 0000000..5070211 --- /dev/null +++ b/project-tasks/p32-alea-bft.md @@ -0,0 +1,33 @@ +# P32. Alea-BFT: асинхронная репликация с византийскими отказами + +- **Версия и дата проверки:** 1.0, 05.09.2026. +- **Статус:** готово к назначению. + +## Статья и исходные материалы + +- **Основная статья:** Diogo S. Antunes и соавт. — [Alea-BFT: Practical Asynchronous Byzantine Fault Tolerance](https://www.usenix.org/conference/nsdi24/presentation/antunes). NSDI 2024. +- **Кратко о статье:** Классические BFT-протоколы обычно полагаются на частичную синхронность, лидера и тайм-ауты, которые плохо работают при непредсказуемых задержках. Alea-BFT использует рандомизированную асинхронную модель и простой двухступенчатый конвейер: рассылку от назначенной реплики и последующее бинарное согласование. В проекте протокол сравнивается с опубликованным baseline на локальных процессах при задержках, потерях и crash-отказах. +- **Почему результат актуален:** прототип — снимок состояния на момент публикации, но асинхронная BFT-репликация остаётся самостоятельной базовой темой распределённых систем; две интеграции в системы распределённых валидаторов дают более сильный сигнал практической применимости, чем один экспериментальный стенд. +- **Артефакты и данные:** [diogoantunes25/AleaBFT](https://github.com/diogoantunes25/AleaBFT) — Java-прототип с Alea-BFT, HoneyBadger и Dumbo, режимами штатной работы, crash- и Byzantine-отказов и возможностью запускать несколько реплик на одной машине. [Официальная страница проекта](https://alea-bft.org/) указывает для прототипа лицензию MIT и приводит две интеграции протокола. Зафиксированная ревизия: `diogoantunes25/AleaBFT@543786ef199a` (MIT по официальной странице проекта; файл лицензии в репозитории отсутствует). + +## Обязательный результат + +- **Проверяемый вопрос или утверждение:** двухступенчатый конвейер сохраняет прогресс при непредсказуемых задержках и отказах без настройки таймаутов и даёт меньшую задержку, чем сравниваемые асинхронные протоколы в части режимов. +- **Технический результат:** Развернуть 4–7 локальных процессов Alea-BFT и хотя бы одного опубликованного baseline, подготовить общий клиент и управляемую инъекцию задержек, потерь и crash-отказов. Стенд должен автоматически проверять единый порядок доставки, отсутствие потерь подтверждённых запросов и прогресс допустимого числа реплик. +- **Эксперимент:** на подготовленном стенде сравнить Alea-BFT хотя бы с одним опубликованным baseline при контролируемых задержках, потерях и crash-отказах по порядку доставки, прогрессу, задержке и пропускной способности. +- **Границы выводов:** безопасность и прогресс проверяются для 4–7 локальных процессов, выбранного baseline и управляемых задержек, потерь и crash-отказов; эксперимент не подтверждает устойчивость ко всем византийским стратегиям и производительность геораспределённого развёртывания. +- **Ресурсный профиль:** расширенно локально, Linux или Docker, CPU, желательно 16 ГБ памяти. Если полный benchmark service нестабилен, оставить реальные локальные реплики Alea-BFT и один простой baseline, а сетевые режимы задавать через управляемый прокси или `tc netem`. + +## Содержательные направления + +- сборка реплик и автоматическая проверка согласованности порядка. +- базовый протокол и инъекция отказов. +- нагрузка, статистический анализ и новый режим. + +## Возможное продолжение + +Исследовать неравномерные задержки, медленного или византийского лидера, размер пакета, восстановление пропущенных запросов либо границу, при которой синхронный baseline становится выгоднее. + +## Известное ограничение + +На зафиксированной ревизии нет файла лицензии, хотя официальная страница проекта указывает MIT. До появления однозначного файла лицензии исходный код прототипа не копируется в репозиторий команды. Его можно запускать как внешнюю зависимость; изменения реализуются независимо либо после разрешения правообладателя. diff --git a/project.md b/project.md new file mode 100644 index 0000000..361bb9a --- /dev/null +++ b/project.md @@ -0,0 +1,155 @@ +# Командный проект + +Проект посвящён воспроизведению и экспериментальной проверке результата научной статьи. Полное воспроизведение статьи не требуется: команда должна разобраться в работе, восстановить существенную часть её методики и независимо проверить значимый результат. + +Обычная команда состоит из трёх человек. Пары формируются только для выравнивания числа студентов; для них преподаватель сокращает объем обязательной работы. Команды из четырёх человек не создаются. + +В проектном задании перечислены три содержательных направления. Они служат ориентирами для планирования и не задают готовых ролей по числу участников. Команда распределяет работу самостоятельно; каждый студент отвечает за законченный проверяемый результат. + +## Календарь проекта + +### Начало проекта + +- **14.09.2026, 23:59** — заполнить профиль. +- **18.09.2026** — получить окончательный состав команды и ознакомиться с окончательным банком заданий. +- **21.09.2026, 23:59** — указать три предпочтительных задания от команды. +- **23.09.2026** — получить назначенное проектное задание. + +### Сроки контрольных точек + +Для каждой точки команда заранее сдаёт материалы. На общем занятии ведущий даёт обратную связь и разбирает несколько показательных проектов, после чего команда получает письменный статус и обязательные исправления. + +| Контрольная точка | Материалы | Занятие | Статус | Опрос | +|---|---|---|---|---| +| [Проверка и детализация проектного задания, план эксперимента](project-checkpoints/01-project-plan.md) | 03.11.2026, 23:59 | 09.11.2026 | до 13.11.2026 | — | +| [Первый работающий результат](project-checkpoints/02-working-result.md) | 02.12.2026, 23:59 | 07.12.2026 | до 11.12.2026 | до 18.12.2026, 23:59 | +| [Промежуточные результаты воспроизведения и уточнение плана](project-checkpoints/03-intermediate-results.md) | 27.01.2027, 23:59 | 01.02.2027 | до 05.02.2027 | до 12.02.2027, 23:59 | + +### Завершение проекта + +- **26.02.2027, 23:59** — сдать короткую сверку состояния проекта через ветку `nis/status` и PR/MR. Опросы и сверка отдельно не оцениваются. +- **01.03.2027** — при отсутствии оцениваемого участия получить предупреждение о риске `ИР=0` и требуемом результате к итоговой сдаче. +- **05.03.2027** — получить адресную обратную связь, если у команды выявлены риски или блокировки. +- **19.03.2027, 23:59** — сдать технический отчёт, репозиторий и лист итоговой сдачи через PR/MR; указать полный хеш оцениваемого коммита. + +После срока 19 марта разрешены только редакторские изменения презентации и согласованные технические исправления. Даты защит приведены в [расписании](schedule.md). + +## Формирование команды и выбор проектного задания + +До **14 сентября, 23:59** каждый студент заполняет короткий профиль. Названия групп приведены в [тематическом указателе банка](project-tasks/README.md#тематические-группы). Профили видит преподаватель; общая таблица имён и интересов не публикуется. Если профиль не заполнен, команда и проектное задание могут быть назначены без учёта предпочтений. + +```text +Имя: +Команда: готовая тройка / пара / команды нет +Участники готовой команды: +Интересующие проектные задания: +2–3 тематические группы из банка: +Своя статья, если есть: название и ссылка +Чем статья связана с курсом: +Какой результат интересно проверить: +Код и данные, если есть: +``` + +К 18 сентября публикуются окончательные составы команд и окончательный [банк готовых проектных заданий](project-tasks/README.md). До 21 сентября, 23:59, команда совместно ранжирует три задания. 23 сентября проектные задания распределяются между командами. После этого команда создаёт репозиторий по [общим правилам](project-repository.md), передаёт его адрес преподавателю и фиксирует начальные содержательные ответственности. Отдельная проектная заявка не нужна. + +## Что требуется от проекта + +Обязательный объём задаёт назначенное проектное задание. Существовавшие до начала курса код, данные и результаты считаются исходной точкой; оценивается новая работа команды. + +Простого запуска готового кода недостаточно. Нужны: + +- проверяемый технический результат; +- корректный эксперимент с сопоставимыми вариантами, метриками и повторами; +- проверка корректности и доказательный анализ результатов; +- воспроизводимый репозиторий и полный протокол основных серий; +- технический отчёт и презентация. + +Сравниваемые варианты запускаются на одинаковых входах или на одинаково сформированных выборках. Для недетерминированных измерений выполняется не менее трёх повторов, если проектное задание явно не требует большего числа. + +Корректный отрицательный результат или расхождение со статьёй могут быть полноценным итогом, если эксперимент корректен, данные пригодны для анализа, а причины разобраны по свидетельствам. Техническая блокировка без корректного эксперимента итоговым результатом не считается. + +## Технический путь проекта + +Проверяется утверждение или метод статьи, поэтому опубликованный программный артефакт не обязан быть основой реализации. Проектное задание может предусматривать один или несколько равноправных путей: + +- восстановить, адаптировать или модифицировать авторский артефакт; +- самостоятельно реализовать центральный механизм в объёме, достаточном для проверки; +- построить собственный симулятор или модель существенного механизма; +- сочетать реальный прототип с имитацией для более широких экспериментальных серий. + +Допустимые пути указаны в конкретном проектном задании. Если их несколько, команда выбирает путь самостоятельно и фиксирует выбор к первой контрольной точке. Переход к пути, которого нет в задании, оформляется как его уточнение: команда показывает технические основания, после чего преподаватель выпускает новую версию задания. + +Самостоятельная реализация должна явно отделять сохранённые свойства метода от упрощений и иметь автоматическую проверку корректности. Для симулятора нужно описать допущения, проверить его на аналитических примерах, опубликованных данных или доступной реализации и ограничить выводы областью применимости модели. При любом пути сохраняются заданные проверяемый вопрос, baseline, основные показатели и требования к анализу. + +## Ресурсы, данные и лицензии + +Каждое выданное задание имеет содержательный обязательный путь на CPU, обычном личном компьютере или бесплатно доступной инфраструктуре. Личные расходы не требуются. По согласованию команда с подтверждённым доступом к GPU может включить GPU-реализацию и эксперименты в обязательный план. Доступ должен сохраняться до окончания проверки, а преподавателю должна быть обеспечена возможность выборочно повторить запуски на сопоставимом ресурсе. Оценка зависит от полученного результата; сам доступ к оборудованию преимуществ не даёт. При утрате доступа команда возвращается к исходному CPU-пути. По согласованию могут быть выделены ресурсы Яндекс Облака, но их наличие, объём и срок не гарантируются. + +Если у артефакта нет явной лицензии, команда не копирует его код: нужно получить разрешение правообладателя или реализовать механизм независимо по описанию статьи. Закрытые данные, код и сервисы можно использовать только при законном доступе и возможности проверки преподавателем. + +## Воспроизводимость + +Состав и оформление репозитория определены в [отдельной памятке](project-repository.md). Итоговый репозиторий должен содержать: + +- зафиксированные версии кода, данных, зависимостей и параметров; +- автоматизированную настройку или точную инструкцию; +- сокращённый сквозной запуск на обычной машине; +- полный протокол основных серий, сырые и обработанные данные; +- сценарий, который перестраивает итоговые таблицы и графики. + +Если в обязательный план входят GPU-эксперименты, преподавателю достаточно обеспечить выборочный повторный запуск; полное повторение всех дорогих серий не требуется. + +Контейнеризация не обязательна. Секреты, токены и закрытые данные в репозиторий не помещаются. + +## Контрольные точки + +Каждая точка сдаётся через отдельную ветку и PR/MR. Полный хеш в описании PR/MR фиксирует версию, сданную к сроку. Материалы содержат краткий результат, ссылки на проверяемые свидетельства и карточки ответственности участников. На занятии разбираются общие ошибки и несколько показательных проектов. Статусы, порядок обратной связи, исправлений и документирования блокировок приведены в [общих правилах контрольных точек](project-checkpoints/README.md). + +1. [Проверка и детализация проектного задания, план эксперимента](project-checkpoints/01-project-plan.md) — команда уточняет обязательный результат, проверяет технические предпосылки выбранного пути и готовит план эксперимента. Полный сквозной эксперимент пока не требуется. +2. [Первый работающий результат](project-checkpoints/02-working-result.md) — команда показывает один содержательный сквозной сценарий, исходные измерения, обработанный результат и свидетельства проверки корректности. Baseline и полная серия пока не требуются. +3. [Промежуточные результаты и уточнение плана](project-checkpoints/03-intermediate-results.md) — команда сравнивает основной метод с baseline, представляет промежуточные данные и уточняет обязательный план завершения проекта. Возможное самостоятельное продолжение описывается отдельно. + +## Конфиденциальные опросы и риск-сигналы + +Каждый студент заполняет опрос о себе и каждом участнике команды до **18 декабря, 23:59**, и до **12 февраля, 23:59**. По шкале «да», «частично», «нет», «недостаточно данных» оцениваются выполнение согласованных задач, проверяемость результата, своевременность сообщения о блокировках, участие в проверке и интеграции и необходимость вмешательства преподавателя. При ответе «частично» или «нет» нужен конкретный пример. + +Опросы не образуют автоматического коэффициента и не изменяют командный балл напрямую. Они помогают рано обнаружить проблемы и служат одним из свидетельств индивидуальной работы. + +Между точками можно подать риск-сигнал, если блокировка угрожает обязательному результату, нужно пересогласовать объём или возникла документированная командная проблема: + +```text +Команда и тема: +Ссылка на проверяемые материалы: +Конкретная блокировка: +Что уже сделано: +Влияние на обязательный результат: +Какое решение требуется от преподавателя: +``` + +Риск-сигналы, поданные до среды 23:59, разбираются до пятницы 23:59. Обычная отладка, предварительное рецензирование черновиков и управление внутренними задачами команды в этот порядок не входят. + +## Итоговые материалы и защита + +Итоговый комплект включает репозиторий с сокращённым сквозным запуском, данные и конфигурации полного протокола, технический отчёт, презентацию и лист итоговой сдачи `nis/final.md`. До **19 марта 2027 года, 23:59** команда открывает итоговый PR/MR и указывает в его описании полный хеш оцениваемого коммита. Материалы оцениваются в конце курса как компонент `ПР` проектного экзамена; второй компонент `ЗП` определяется на защите. Порядок подготовки и оформления комплекта приведён на странице [«Финальная версия проекта»](project-final.md). + +Защиты ориентировочно проходят 25, 29 и 31 марта; точные даты будут уточнены ближе к концу курса. На команду отводится 20 минут: до 7 минут на доклад, 12 минут на индивидуальные вопросы и 1 минута на смену команды. Каждый участник отвечает на вопросы о своей работе, общей методике, проверке результатов и ограничениях. + +Ведущий обеспечивает каждому участнику сопоставимое время для индивидуальных ответов. Превышение времени доклада не сокращает время вопросов. Посещение защит других команд добровольное, без контроля посещаемости и влияния на оценку. + +Проект может быть связан с ВКР, но должен иметь самостоятельный законченный результат к марту. Подробная шкала проекта приведена в [памятке по оцениванию](grading.md). + +## Дополнительное достижение по проекту + +Дополнительное достижение описывается в техническом отчёте и `nis/final.md`, подтверждается материалами проекта и ответами на защите. Отдельная форма или предварительное согласование не требуются. Четыре признака достижения и примеры приведены в [порядке итоговой сдачи](project-final.md#дополнительное-достижение), условия высокой оценки — в [правилах оценивания](grading.md#итоговая-оценка). + +## Риски и порядок действий + +Риски фиксируются в материалах контрольной точки или через риск-сигнал. Своевременное сообщение позволяет скорректировать дальнейшую работу; обещание будущего результата и затраченное время сами по себе не учитываются. + +| Риск | Порядок действий | Как учитывается | +|---|---|---| +| Ошибочная предпосылка проектного задания | Команда прикладывает воспроизводимую диагностику. Преподаватель уточняет задание или назначает другое свободное задание и корректирует сроки и объём. | Документированная ошибка задания не снижает статус контрольной точки. | +| Утрата внешнего ресурса | Команда возвращается к обязательному CPU-пути и при необходимости подаёт риск-сигнал. | Доступ к GPU, облаку или закрытому сервису преимуществ в оценке не даёт. | +| Техническая блокировка или отрицательный результат | Команда сохраняет материалы, анализирует причины и обновляет план. | Документированная блокировка может быть зачтена как контрольная точка, но сама по себе не заменяет итоговый результат. Корректный отрицательный результат оценивается на общих основаниях. | +| Проблема внутри команды | Участники фиксируют ответственность и результаты в материалах точек, конфиденциальных опросах и при необходимости в риск-сигнале. | `ИР` оценивается индивидуально. Если своевременно документированная проблема не зависит от студента и делает продолжение исходного проекта объективно невозможным, ему может быть назначено одно из заранее подготовленных резервных заданий. | +| К сверке нет оцениваемого участия студента | До 1 марта студент получает в PR/MR адресное предупреждение о риске `ИР=0`, требуемом результате и сроке. Конфиденциальные ответы и личные обстоятельства публично не раскрываются. | Студент продолжает работу в исходном проекте. Отдельный индивидуальный проект из-за отсутствия вклада не назначается; при итоговом `ИР=0` применяются общие правила оценивания и пересдачи. | diff --git a/projects/README.md b/projects/README.md new file mode 100644 index 0000000..1414beb --- /dev/null +++ b/projects/README.md @@ -0,0 +1,13 @@ +# Карточки выполняемых проектов + +После распределения заданий 23 сентября преподаватель создаёт в этом каталоге отдельную Markdown-карточку для каждой команды на основе [_template.md](_template.md). + +Карточки входят в репозиторий материалов курса и редактируются только преподавателем. Команда ведёт технические материалы в своём публичном репозитории и передаёт его адрес один раз через основной канал курса. + +В карточке фиксируются состав команды, назначенное задание, репозиторий, выбранный технический путь, состояние сдач и история согласованных изменений задания. Для каждой сдачи указываются полный хеш проверенного коммита, статус и ссылка на итоговый комментарий преподавателя в PR/MR. Подробная обратная связь остаётся в PR/MR и в карточку не копируется. + +Оценки, конфиденциальные ответы и сведения о личных обстоятельствах или конфликтах в карточках не публикуются. Командная и индивидуальная обратная связь, включая адресные предупреждения, может оставаться в PR/MR команды. + +## Проекты + +Карточки будут добавлены после распределения заданий. diff --git a/projects/_template.md b/projects/_template.md new file mode 100644 index 0000000..6f7bd66 --- /dev/null +++ b/projects/_template.md @@ -0,0 +1,31 @@ +# Проект: название + +## Команда и задание + +- **Участники:** полные имена +- **Назначенное задание:** [название и ссылка] +- **Публичный репозиторий:** [ссылка] +- **Выбранный технический путь:** [краткое описание] + +## Сдачи + +| Сдача | Полный хеш коммита | Статус | Итоговый комментарий | +|---|---|---|---| +| Первая контрольная точка | — | — | — | +| Вторая контрольная точка | — | — | — | +| Третья контрольная точка | — | — | — | +| Сверка состояния проекта | — | — | — | +| Финальная версия | — | — | — | + +## История согласованных изменений задания + +| Дата | Изменение | Основание и ссылка | +|---|---|---| +| — | Исходная версия задания | [ссылка] | + +## Итоговые материалы + +- **Финальная версия:** [полный хеш коммита и ссылка] +- **Технический отчёт:** [ссылка] +- **Данные и результаты:** [ссылка] +- **Презентация:** [ссылка] diff --git a/schedule.md b/schedule.md new file mode 100644 index 0000000..4c6d1ab --- /dev/null +++ b/schedule.md @@ -0,0 +1,41 @@ +# Расписание НИС на 2026/2027 учебный год + +## Занятия + +Занятия проходят онлайн по понедельникам в 18:10. [Ссылка для подключения](https://my.mts-link.ru/j/19605137/24631961487). + +| Дата | Формат | № статьи | Тема | +|---|---|---:|---| +| 07.09.2026 | Организационное занятие | — | Новый формат НИС | +| 14.09.2026 | Ролевой семинар | 1 | [Metastable Failures in the Wild](seminars/01-2026-09-14-metastable-failures.md) | +| 21.09.2026 | Ролевой семинар | 2 | [FoundationDB: A Distributed Unbundled Transactional Key Value Store](seminars/02-2026-09-21-foundationdb.md) | +| 28.09.2026 | Ролевой семинар | 3 | [Kora: A Cloud-Native Event Streaming Platform for Kafka](seminars/03-2026-09-28-kora.md) | +| 05.10.2026 | Методический старт | — | Проектные задания, экспериментальная методика и типичные риски | +| 12.10.2026 | Ролевой семинар | 4 | [Alea-BFT: Practical Asynchronous Byzantine Fault Tolerance](seminars/04-2026-10-12-alea-bft.md) | +| 19.10.2026 | Ролевой семинар | 5 | [Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker](seminars/05-2026-10-19-rainmaker.md) | +| 02.11.2026 | Ролевой семинар | 6 | [Boki: Stateful Serverless Computing with Shared Logs](seminars/06-2026-11-02-boki.md) | +| 09.11.2026 | Контрольная точка | — | [Проверка и детализация проектного задания, план эксперимента](project-checkpoints/01-project-plan.md) | +| 16.11.2026 | Ролевой семинар | 7 | [Scaling Large Production Clusters with Partitioned Synchronization](seminars/07-2026-11-16-partitioned-synchronization.md) | +| 23.11.2026 | Ролевой семинар | 8 | [Oakestra: A Lightweight Hierarchical Orchestration Framework for Edge Computing](seminars/08-2026-11-23-oakestra.md) | +| 30.11.2026 | Ролевой семинар | 9 | [Cloudy with a Chance of Cyberattacks: Dangling Resources Abuse on Cloud Platforms](seminars/09-2026-11-30-dangling-resources.md) | +| 07.12.2026 | Контрольная точка | — | [Первый работающий результат](project-checkpoints/02-working-result.md) | +| 14.12.2026 | Ролевой семинар | 10 | [Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking](seminars/10-2026-12-14-jupiter-evolving.md) | +| 11.01.2027 | Ролевой семинар | 11 | [veDB-HTAP: a Highly Integrated, Efficient and Adaptive HTAP System](seminars/11-2027-01-11-vedb-htap.md) | +| 18.01.2027 | Ролевой семинар | 12 | [Manu: A Cloud Native Vector Database Management System](seminars/12-2027-01-18-manu.md) | +| 25.01.2027 | Ролевой семинар | 13 | [Pond: CXL-Based Memory Pooling Systems for Cloud Platforms](seminars/13-2027-01-25-pond.md) | +| 01.02.2027 | Контрольная точка | — | [Промежуточные результаты воспроизведения и уточнение плана](project-checkpoints/03-intermediate-results.md) | +| 08.02.2027 | Ролевой семинар | 14 | [Who Watches the Watchers? On the Reliability of Softwarizing Cloud Application Management](seminars/14-2027-02-08-who-watches-the-watchers.md) | +| 15.02.2027 | Ролевой семинар | 15 | [SuperBench: Improving Cloud AI Infrastructure Reliability with Proactive Validation](seminars/15-2027-02-15-superbench.md) | +| 01.03.2027 | Ролевой семинар | 16 | [Efficient Memory Management for Large Language Model Serving with PagedAttention](seminars/16-2027-03-01-pagedattention.md) | +| 09.03.2027 | Ролевой семинар | 17 | [MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs](seminars/17-2027-03-09-megascale.md) | +| 15.03.2027 | Ролевой семинар | 18 | [ThunderAgent: A Simple, Fast and Program-Aware Agentic Inference System](seminars/18-2027-03-15-thunderagent.md) | + +22.02.2027 занятия нет. 22.03.2027 — резервная дата, которая используется только после отдельного объявления. + +## Сроки проекта + +Все сроки формирования команд, контрольных точек, опросов и сдачи итоговых материалов приведены в [календаре проекта](project.md#календарь-проекта). + +## Защиты проектов + +Защиты проектов планируется провести в течение сессии 3 модуля. Их расписание будет добавлено ближе к концу курса. diff --git a/seminars.md b/seminars.md new file mode 100644 index 0000000..e4b90ac --- /dev/null +++ b/seminars.md @@ -0,0 +1,143 @@ +# Ролевые семинары + +В курсе 18 семинаров по современным статьям. На каждом из них студенты совместно разбирают одну статью с разных точек зрения: восстанавливают её постановку и результаты, оценивают качество исследования, помещают работу в научный контекст, предлагают продолжение и обсуждают практическое значение. Роли распределяют эти задачи между участниками и создают основу для общего обсуждения. + +Посещение обязательно для студентов с назначенной ролью и добровольно для остальных. + +У каждого занятия есть отдельная [карточка ролевого семинара](seminars/README.md). В ней публикуются состав участников, маршрут чтения и выбранные дополнительные тезисы, а после занятия могут появиться запись, источники из обсуждения, краткие содержательные уточнения и агрегированная оценка статьи студентами. + +## Распределение ролей + +Каждый студент получает две роли: одну в группе «основная статья» — автора или рецензента — и одну в группе «контекст и развитие» — археолога, исследователя или практика. Перед общим распределением студенты указывают предпочтения по статьям и ролям. При составлении расписания эти предпочтения по возможности учитываются. Одинаковая роль дважды не назначается; выступления по возможности разносятся по времени. + +На первый семинар 14 сентября проводится добровольная запись с указанием предпочтительных ролей. Если желающих больше восьми, места распределяются жеребьёвкой. Выступившие 14 сентября получают приоритет при распределении своего второго выступления. Первое выступление оценивается по общим правилам. В [карточке первого семинара](seminars/01-2026-09-14-metastable-failures.md) приведены дополнительные рекомендации по подготовке. + +## Общие требования к подготовке + +Выступление должно решать задачу назначенной роли. Полный пересказ статьи для этого не нужен. При подготовке нужно: + +- подготовить презентацию и показывать её во время выступления; авторы и археологи готовят по одной общей презентации на совместный блок; +- прочитать основную статью и необходимые для роли первичные источники; +- отделять утверждения авторов от собственной оценки и предположений; +- опираться на конкретные разделы, рисунки, таблицы, формулы, код или данные; +- объяснять существенные предпосылки и ограничения, влияющие на выводы; +- отобрать материал под отведённое время и заранее согласовать части совместного выступления; +- быть готовым ответить на вопрос по своей части и по основным идеям статьи. + +Во время подготовленной части, обязательных вопросов и связанного с ролевым блоком обсуждения выступающие держат камеры включёнными. + +Слайды должны помогать аргументации: у графиков и таблиц указываются источник, оси, единицы измерения и смысл результата. Список фактов без связного вывода или пересказ аннотации задачу роли не выполняет. + +## Требования к ролям + +### Авторы + +Три автора готовят единое выступление: ориентир — 12–14 минут, максимум — 15 минут. Оно должно дать аудитории достаточно материала для последующей критики и обсуждения: + +- сформулировать проблему, мотивацию, проверяемые утверждения и существенные предпосылки; +- объяснить устройство предложенного метода или системы на уровне, необходимом для понимания результата; +- разобрать экспериментальную методику: нагрузки и данные, baselines, метрики и условия сравнения; +- показать основные результаты и объяснить, какие выводы из них следуют; +- отделить новизну работы от известных идей и назвать важные ограничения. + +Части авторов образуют общий рассказ и не должны повторять друг друга. Каждый автор глубоко отвечает за свою часть, но должен понимать постановку, метод и основные результаты всей статьи. + +### Рецензент + +Рецензент готовит аргументированную оценку исследования: ориентир — 6–7 минут, максимум — 8 минут. Нужно: + +- кратко сформулировать вклад статьи и общий вывод рецензии; +- оценить новизну относительно ближайших работ и значимость решаемой задачи; +- проверить, соответствуют ли метод и эксперимент заявленным вопросам; +- разобрать выбор baselines, данных, метрик, параметров и масштаб эксперимента; +- оценить воспроизводимость, угрозы достоверности и переносимость выводов; +- привести конкретные сильные и слабые стороны и объяснить, что могло бы изменить итоговую оценку. + +Рецензия оценивает саму работу; качество выступления авторов в неё не входит. Сильные и слабые стороны подтверждаются материалом статьи или связанных первичных источников. + +### Археологи + +Два археолога готовят совместное выступление: ориентир — 6–7 минут, максимум — 8 минут. Их задача — восстановить содержательную линию, которая привела к текущей работе: + +- выбрать две ключевые предшествующие академические публикации, обычно по одной на каждого археолога; +- для каждой выбранной работы объяснить её вопрос, ключевую идею и результат; +- показать, какой механизм, предположение или ограничение текущая статья наследует, изменяет либо устраняет; +- отделить реальную новизну текущей статьи от уже известных решений; +- если это помогает оценить вклад основной статьи, кратко показать, была ли её ключевая идея позднее подтверждена, развита или пересмотрена. + +Основная часть выступления должна быть посвящена предшествующим публикациям. Дальнейшая судьба идеи может быть только кратким дополнением. При необходимости можно добавить третью публикацию, если она связывает важные этапы развития идеи или помогает точнее определить новизну текущей статьи. Археологи согласуют общий маршрут и явно делят аналитические части. В список источников можно включить больше работ, но превращать выступление в их хронологический перечень не следует. + +### Исследователь + +Исследователь рассматривает одно содержательное продолжение основной работы и показывает, как его проверить: ориентир — 5–6 минут, максимум — 7 минут. Можно предложить собственную идею или опереться на последующую публикацию, которая развивает результат статьи. Выступление включает: + +- конкретное ограничение, открытый вопрос или новое условие, связанное с основной статьёй; +- предлагаемое продолжение и проверяемую гипотезу либо исследовательский вопрос; +- способ проверки; для экспериментальной проверки — сравниваемые варианты, baseline, данные или нагрузку и метрики; +- возможные исходы проверки, допустимые выводы и главное ограничение предлагаемого исследования. + +От студента не требуется доказывать научную новизну предложения. Если продолжение взято из последующей публикации, нужно объяснить его связь с конкретным ограничением или открытым вопросом основной статьи, а затем самостоятельно разобрать методику проверки и возможные выводы. Простого пересказа последующей работы недостаточно. Обычно достаточно одной центральной последующей публикации; вторую можно использовать для контекста. Предложение «проверить на большем масштабе» без объяснения нового вопроса и методики также не считается содержательным продолжением. + +### Практик + +Практик разбирает практическое значение результатов статьи на одном реалистичном сценарии: ориентир — 5–6 минут, максимум — 7 минут. Нужно: + +- описать конкретный сценарий: пользователя или организацию, задачу, условия и существенные требования; +- определить, какие результаты, знания, механизмы или методы из статьи могут быть полезны в этом сценарии; +- оценить, переносятся ли на него предположения статьи и приведённые авторами экспериментальные свидетельства; +- сопоставить предлагаемое применение с одной реалистичной альтернативой и выделить существенные затраты, ограничения внедрения и риски; +- сформулировать обоснованный вывод: что следует применять, проверить пилотом, учитывать при принятии решений либо не использовать и каких свидетельств для решения пока не хватает. + +Если статья не предлагает непосредственно внедряемого решения, практик объясняет, как её результаты меняют проектирование, эксплуатацию, тестирование или диагностику системы. Оценивать ресурсы и стоимость нужно только тогда, когда они существенны для выбранного сценария. Рекламного описания преимуществ недостаточно: вывод должен учитывать ограничения и недостающие свидетельства. + +## Тайминг занятия + +Основная часть занятия рассчитана на 80 минут и может быть продлена до 90 минут. Вопросы и обсуждение проходят по ходу семинара. После основной части может проводиться добровольный дополнительный блок для тезисов, не вошедших в основную часть. + +Стандартная последовательность ролевых блоков: авторы, рецензент, археологи, исследователь, практик. После каждого блока участникам задаются обязательные вопросы, затем обсуждается связанный с ним дополнительный тезис, если он выбран. Преподаватель может изменить порядок, если особенности статьи или содержание тезисов требуют другой последовательности. + +Указанные в описаниях ролей пределы относятся только к подготовленной части выступления. Каждому участнику задаётся хотя бы один содержательный вопрос; на вопрос и ответ отводится ориентировочно до двух минут. Более короткое выступление не снижает оценку, если задача роли выполнена полностью. Преподаватель может остановить подготовленную часть после достижения максимального времени. + +Если выбраны три дополнительных тезиса, на них вместе с обсуждением отводится до 15 минут. + +## Оценивание выступления + +Каждое выступление оценивается целым числом от 0 до 10. По 0–2 балла даётся за: + +1. понимание статьи и связанного материала; +2. выполнение задачи роли; +3. аргументацию и опору на конкретные свидетельства; +4. ясность, связность и соблюдение времени; +5. содержательный ответ на вопрос. + +За каждый критерий ставится 2 балла, если он выполнен по существу, 1 балл, если он выполнен частично с существенным содержательным пробелом, и 0 баллов, если он по существу не выполнен. Мелкие недочёты не снижают оценку с 2 до 1. Критерий выполнения роли проверяется по требованиям соответствующего раздела выше. Аргументация опирается на конкретные свидетельства; одного личного мнения недостаточно. Каждому выступающему задаётся хотя бы один содержательный вопрос. В совместных выступлениях общая задача и качество общей презентации оцениваются одинаково, а понимание, аргументация своей части и ответ — индивидуально. Формула итоговой оценки приведена [здесь](grading.md). + +## Дополнительные тезисы + +Студент без роли может не позднее чем за 48 часов до занятия предложить через форму краткий тезис: вопрос, критическое замечание, гипотезу, связь с другой работой или дополнительный эксперимент. Ссылка на форму будет добавлена перед началом приёма тезисов. Нужно сослаться на конкретное место или результат статьи и объяснить, почему тезис стоит обсудить. + +В основную часть семинара выбирается до трёх тезисов. Каждый из них ставится сразу после тематически связанного ролевого блока и обязательных вопросов его участникам. Уточнение постановки или результатов обычно обсуждается после авторов, критика методики или свидетельств — после рецензента, связь с другой работой — после археологов, гипотеза или дополнительный эксперимент — после исследователя, практическое применение — после практика. Окончательное место определяет преподаватель. При сопоставимом качестве приоритет получает студент с меньшим числом зачтённых обсуждений, затем учитывается время подачи. Отвечающие требованиям тезисы, не вошедшие в основную часть только из-за ограничения времени, сохраняются в очереди без повторной подачи. Список тезисов, порядок и ожидаемое время окончания дополнительного блока публикуются до занятия. + +Тезис представляет подавший его студент; на краткое представление тезиса отводится до полутора минут, на представление и обсуждение вместе — до пяти минут. Участвовать в обсуждении могут все присутствующие. Ведущий сначала предлагает ответить участнику наиболее близкого ролевого блока, затем открывает короткое общее обсуждение. Оно не заменяет обязательного индивидуального вопроса участнику роли. + +Дополнительная активность засчитывается только автору обсуждённого тезиса, если он содержательно представил его и участвовал в обсуждении; сама отправка тезиса зачёта не даёт. Условия получения оценок 9–10 приведены в разделе [«Итоговая оценка»](grading.md#итоговая-оценка). + +За курс студент может получить не более двух зачётов за обсуждение тезисов. После двух зачётов новые тезисы от него не принимаются; участие в общих обсуждениях остаётся открытым. Незачтённый тезис можно заменить тезисом к одной из следующих статей. + +Реплики остальных участников отдельного зачёта не дают. Ответ участника связанного ролевого блока учитывается при оценке критерия «понимание статьи и связанного материала» его выступления, если вопрос относится к статье и ожидаемому пониманию в рамках назначенной роли. Добровольные реплики других участников при оценивании их ролевых выступлений не учитываются. + +Если все тезисы невозможно обсудить сразу после семинара, оставшиеся переносятся на общие добровольные обсуждения до защиты проекта; резервом служит 22 марта. Индивидуальные обсуждения не проводятся. Участие в дополнительном блоке добровольно и не влияет на оценку ролевого выступления. + +## Оценка статьи после семинара + +В конце занятия всем присутствующим предлагается короткий анонимный опрос. Все отвечающие оценивают полезность статьи для курса и указывают, стоит ли оставить её в программе; студенты, прочитавшие основную статью или указанный маршрут чтения, также оценивают сложность чтения. Опрос открыт до 23:59 следующего дня, не влияет на оценки и посещаемость. + +В карточке семинара публикуются число ответов, средняя полезность, средняя сложность среди прочитавших основную статью или указанный маршрут чтения и число ответов «да» или «скорее да» за сохранение статьи. Свободные комментарии дословно не публикуются и используются при пересмотре банка статей и маршрутов чтения. + +## Обмен ролью и пропуск + +Согласованный обмен ролями внутри соответствующей группы разрешён не позднее чем за 72 часа до начала семинара. + +При внезапном обстоятельстве нужно обратиться к преподавателю не позднее 23:59 следующего дня после семинара. По своевременному обращению преподаватель индивидуально решает, можно ли предоставить альтернативное выступление из той же группы ролей без изменения опубликованного расписания. Одному студенту альтернативное выступление может быть предоставлено не более одного раза за курс; автоматического права на новый слот нет. + +При пропуске выступления учитывается 0. Если студент не сообщил о пропуске до начала семинара и не обратился при внезапном обстоятельстве до 23:59 следующего дня, итоговая оценка не может превышать 7. Согласованное альтернативное выступление заменяет пропущенное. diff --git a/seminars/01-2026-09-14-metastable-failures.md b/seminars/01-2026-09-14-metastable-failures.md new file mode 100644 index 0000000..58a6791 --- /dev/null +++ b/seminars/01-2026-09-14-metastable-failures.md @@ -0,0 +1,51 @@ +# 1. Metastable Failures in the Wild + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 14 сентября 2026 года, 18:10 +- **Статья:** Lexiang Huang и соавт., [Metastable Failures in the Wild](https://www.usenix.org/system/files/osdi22-huang-lexiang.pdf), OSDI 2022 +- **Центральный вопрос:** почему распределённая система может остаться в состоянии перегрузки после устранения первоначальной причины отказа? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Рекомендуемый маршрут чтения + +Все участники читают аннотацию, разделы 1–2, обзор модели и рисунок 1 в разделе 3, раздел 6 и заключение. Нужно уметь различать обычную перегрузку, уязвимое состояние и метастабильный отказ, а также объяснять роль триггера и самоподдерживающейся обратной связи. Доказательства в приложении в обязательный маршрут не входят. + +- **Авторы:** полностью разделы 3–5; распределить между собой обзор реальных инцидентов, модель с примером Twitter и три экспериментальных воспроизведения. +- **Рецензент:** сосредоточиться на методике отбора и классификации публичных отчётов в разделе 2, достаточности модели и постановке экспериментов в разделе 5. +- **Археологи:** начать с Nathan Bronson и соавт., [Metastable Failures in Distributed Systems](https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s11-bronson.pdf), затем выбрать ещё одну предшествующую работу о лавинообразных повторных запросах, каскадном отказе, перегрузке или медленном отказе и показать различие понятий. +- **Исследователь:** выбрать одно продолжение, связанное с обнаружением, прогнозированием или автоматическим прекращением самоподдерживающейся обратной связи, и предложить способ проверки. +- **Практик:** рассмотреть один эксплуатационный сценарий и сравнить меры предотвращения и восстановления: запас мощности, ограничение повторов, сброс нагрузки, изменение тайм-аутов, изоляцию компонентов или масштабирование. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +Тезис можно предложить не позднее чем за 48 часов до занятия по общей процедуре курса. + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения по итогам обсуждения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/02-2026-09-21-foundationdb.md b/seminars/02-2026-09-21-foundationdb.md new file mode 100644 index 0000000..c77b97d --- /dev/null +++ b/seminars/02-2026-09-21-foundationdb.md @@ -0,0 +1,45 @@ +# 2. FoundationDB: A Distributed Unbundled Transactional Key Value Store + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 21 сентября 2026 года, 18:10 +- **Статья:** [FoundationDB: A Distributed Unbundled Transactional Key Value Store](https://www.foundationdb.org/files/fdb-paper.pdf) +- **Центральный вопрос:** как разделение хранения, журналирования и обработки транзакций помогает масштабировать строго согласованное хранилище? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. Особое внимание стоит уделить архитектурному разделению компонентов, пути транзакции, восстановлению после отказов, экспериментальным свидетельствам масштабируемости и границам производственного опыта авторов. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/03-2026-09-28-kora.md b/seminars/03-2026-09-28-kora.md new file mode 100644 index 0000000..fd411cb --- /dev/null +++ b/seminars/03-2026-09-28-kora.md @@ -0,0 +1,45 @@ +# 3. Kora: A Cloud-Native Event Streaming Platform for Kafka + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 28 сентября 2026 года, 18:10 +- **Статья:** [Kora: A Cloud-Native Event Streaming Platform for Kafka](https://www.vldb.org/pvldb/vol16/p3822-povzner.pdf) +- **Центральный вопрос:** какие архитектурные изменения нужны, чтобы превратить Kafka в управляемую облачную платформу с предсказуемой эффективностью и изоляцией? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. Важно связать заявленные свойства Kora с конкретными механизмами управления ресурсами, многоарендностью и эксплуатацией, а экспериментальные результаты — с выбранными нагрузками и альтернативами. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/04-2026-10-12-alea-bft.md b/seminars/04-2026-10-12-alea-bft.md new file mode 100644 index 0000000..965ebe9 --- /dev/null +++ b/seminars/04-2026-10-12-alea-bft.md @@ -0,0 +1,45 @@ +# 4. Alea-BFT: Practical Asynchronous Byzantine Fault Tolerance + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 12 октября 2026 года, 18:10 +- **Статья:** [Alea-BFT: Practical Asynchronous Byzantine Fault Tolerance](https://www.usenix.org/system/files/nsdi24-antunes.pdf) +- **Центральный вопрос:** за счёт каких механизмов полностью асинхронный BFT-протокол становится практически применимым? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. При подготовке нужно отделить модель системы и гарантии от инженерных оптимизаций, восстановить путь протокола и проверить корректность и практическую убедительность сравнений с другими BFT-решениями. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/05-2026-10-19-rainmaker.md b/seminars/05-2026-10-19-rainmaker.md new file mode 100644 index 0000000..d99eab3 --- /dev/null +++ b/seminars/05-2026-10-19-rainmaker.md @@ -0,0 +1,45 @@ +# 5. Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 19 октября 2026 года, 18:10 +- **Статья:** [Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker](https://www.usenix.org/system/files/nsdi23-chen-yinfang.pdf) +- **Центральный вопрос:** как автоматически строить реалистичные проверки надёжности приложений, зависящих от облачных сервисов? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. Следует проследить путь от модели внешних зависимостей и генерации отказов до механизма подтверждения обнаруженных ошибок, а также оценить подтверждённые ошибки, полноту эксперимента и переносимость метода на другие приложения. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/06-2026-11-02-boki.md b/seminars/06-2026-11-02-boki.md new file mode 100644 index 0000000..177ce21 --- /dev/null +++ b/seminars/06-2026-11-02-boki.md @@ -0,0 +1,45 @@ +# 6. Boki: Stateful Serverless Computing with Shared Logs + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 2 ноября 2026 года, 18:10 +- **Статья:** [Boki: Stateful Serverless Computing with Shared Logs](https://www.cs.utexas.edu/users/witchel/pubs/jia21sosp-boki.pdf) +- **Центральный вопрос:** как общий журнал меняет архитектуру, согласованность и стоимость stateful serverless-приложений? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. Важно связать устройство общего журнала с моделью исполнения функций, состоянием и отказами, затем проверить, какие преимущества действительно подтверждены экспериментами и какой ценой они достигаются. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/07-2026-11-16-partitioned-synchronization.md b/seminars/07-2026-11-16-partitioned-synchronization.md new file mode 100644 index 0000000..b74854f --- /dev/null +++ b/seminars/07-2026-11-16-partitioned-synchronization.md @@ -0,0 +1,45 @@ +# 7. Scaling Large Production Clusters with Partitioned Synchronization + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 16 ноября 2026 года, 18:10 +- **Статья:** [Scaling Large Production Clusters with Partitioned Synchronization](https://www.usenix.org/system/files/atc21-feng-yihui.pdf) +- **Центральный вопрос:** как разделение синхронизации позволяет масштабировать управление большим производственным кластером? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. Следует выделить исходное узкое место, механизм разбиения состояния и синхронизации, влияние на согласованность и отказоустойчивость, а также границы производственных свидетельств. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/08-2026-11-23-oakestra.md b/seminars/08-2026-11-23-oakestra.md new file mode 100644 index 0000000..be503b5 --- /dev/null +++ b/seminars/08-2026-11-23-oakestra.md @@ -0,0 +1,45 @@ +# 8. Oakestra: A Lightweight Hierarchical Orchestration Framework for Edge Computing + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 23 ноября 2026 года, 18:10 +- **Статья:** [Oakestra: A Lightweight Hierarchical Orchestration Framework for Edge Computing](https://www.oakestra.io/pubs/Oakestra-ATC2023.pdf) +- **Центральный вопрос:** когда и почему иерархическая оркестрация подходит для неоднородной периферийной инфраструктуры? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. Нужно связать ограничения периферийной среды с иерархией управления, размещением и сетевыми механизмами, а затем проверить масштаб, реалистичность и сопоставимость оценки. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/09-2026-11-30-dangling-resources.md b/seminars/09-2026-11-30-dangling-resources.md new file mode 100644 index 0000000..bdd78ae --- /dev/null +++ b/seminars/09-2026-11-30-dangling-resources.md @@ -0,0 +1,45 @@ +# 9. Cloudy with a Chance of Cyberattacks: Dangling Resources Abuse on Cloud Platforms + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 30 ноября 2026 года, 18:10 +- **Статья:** [Cloudy with a Chance of Cyberattacks: Dangling Resources Abuse on Cloud Platforms](https://www.usenix.org/system/files/nsdi24-friess.pdf) +- **Центральный вопрос:** как жизненный цикл облачных ресурсов создаёт возможность перехвата забытых зависимостей и кто должен предотвращать такие атаки? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. Следует разобрать модель угроз, метод обнаружения уязвимых зависимостей, этические границы измерения, подтверждённый масштаб проблемы и распределение ответственности между пользователем и облачной платформой. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/10-2026-12-14-jupiter-evolving.md b/seminars/10-2026-12-14-jupiter-evolving.md new file mode 100644 index 0000000..47b363e --- /dev/null +++ b/seminars/10-2026-12-14-jupiter-evolving.md @@ -0,0 +1,45 @@ +# 10. Jupiter Evolving + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 14 декабря 2026 года, 18:10 +- **Статья:** [Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking](https://storage.googleapis.com/gweb-research2023-media/pubtools/6752.pdf) +- **Центральный вопрос:** как оптическая коммутация и программное управление изменили архитектуру и развитие сети центра обработки данных Google? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. Важно восстановить последовательность поколений сети, причины архитектурных изменений, роль оптических коммутаторов и SDN, а также отделить общие инженерные выводы от возможностей инфраструктуры масштаба Google. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/11-2027-01-11-vedb-htap.md b/seminars/11-2027-01-11-vedb-htap.md new file mode 100644 index 0000000..41d9b28 --- /dev/null +++ b/seminars/11-2027-01-11-vedb-htap.md @@ -0,0 +1,45 @@ +# 11. veDB-HTAP: a Highly Integrated, Efficient and Adaptive HTAP System + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 11 января 2027 года, 18:10 +- **Статья:** [veDB-HTAP: a Highly Integrated, Efficient and Adaptive HTAP System](https://www.vldb.org/pvldb/vol18/p4896-chen.pdf) +- **Центральный вопрос:** как совместить транзакционную и аналитическую обработку в одной системе, сохраняя изоляцию нагрузок и свежесть данных? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. Следует связать архитектуру хранения и выполнения запросов с согласованностью и изоляцией OLTP/OLAP, затем проверить адаптивность, выбор сравнений и применимость результатов к другим нагрузкам. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/12-2027-01-18-manu.md b/seminars/12-2027-01-18-manu.md new file mode 100644 index 0000000..a25b9ef --- /dev/null +++ b/seminars/12-2027-01-18-manu.md @@ -0,0 +1,45 @@ +# 12. Manu: A Cloud Native Vector Database Management System + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 18 января 2027 года, 18:10 +- **Статья:** [Manu: A Cloud Native Vector Database Management System](https://www.vldb.org/pvldb/vol15/p3548-yan.pdf) +- **Центральный вопрос:** как построить облачную векторную базу данных, одновременно поддерживающую масштабирование, обновления и поиск по свежим данным? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. Нужно связать архитектуру журналов, сегментов, индексов и запросов с требованиями к свежести и масштабированию, а также проверить репрезентативность нагрузок, метрик и альтернатив. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/13-2027-01-25-pond.md b/seminars/13-2027-01-25-pond.md new file mode 100644 index 0000000..8aa5ff4 --- /dev/null +++ b/seminars/13-2027-01-25-pond.md @@ -0,0 +1,45 @@ +# 13. Pond: CXL-Based Memory Pooling Systems for Cloud Platforms + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 25 января 2027 года, 18:10 +- **Статья:** [Pond: CXL-Based Memory Pooling Systems for Cloud Platforms](https://huaicheng.github.io/p/asplos23-pond.pdf) +- **Центральный вопрос:** когда объединение памяти через CXL экономит ресурсы облачной платформы без неприемлемого ухудшения производительности? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. Следует понять модель локальной и удалённой памяти, механизм размещения и управления риском замедления, затем проверить исходные трассы, метрики, аппаратные предпосылки и экономический смысл результата. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/14-2027-02-08-who-watches-the-watchers.md b/seminars/14-2027-02-08-who-watches-the-watchers.md new file mode 100644 index 0000000..c8f0407 --- /dev/null +++ b/seminars/14-2027-02-08-who-watches-the-watchers.md @@ -0,0 +1,45 @@ +# 14. Who Watches the Watchers? + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 8 февраля 2027 года, 18:10 +- **Статья:** [Who Watches the Watchers? On the Reliability of Softwarizing Cloud Application Management](https://www.usenix.org/system/files/nsdi26-gu.pdf) +- **Центральный вопрос:** какие новые отказовые зависимости возникают, когда управление облачным приложением переносится в программные контроллеры? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. Важно восстановить модель плоскости управления и её отказов, понять метод исследования и проверить, насколько выводы покрывают реальные системы, конфигурации и способы восстановления. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/15-2027-02-15-superbench.md b/seminars/15-2027-02-15-superbench.md new file mode 100644 index 0000000..879a3c8 --- /dev/null +++ b/seminars/15-2027-02-15-superbench.md @@ -0,0 +1,45 @@ +# 15. SuperBench: Improving Cloud AI Infrastructure Reliability with Proactive Validation + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 15 февраля 2027 года, 18:10 +- **Статья:** [SuperBench: Improving Cloud AI Infrastructure Reliability with Proactive Validation](https://www.usenix.org/system/files/atc24-xiong.pdf) +- **Центральный вопрос:** как проактивно выявлять слабые узлы инфраструктуры ИИ до того, как они нарушат дорогое распределённое обучение? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. Следует связать виды аппаратных и сетевых отклонений с выбранными тестами и политикой допуска узлов, а затем оценить полноту обнаружения, цену проверок и переносимость производственных результатов. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/16-2027-03-01-pagedattention.md b/seminars/16-2027-03-01-pagedattention.md new file mode 100644 index 0000000..0c2d970 --- /dev/null +++ b/seminars/16-2027-03-01-pagedattention.md @@ -0,0 +1,45 @@ +# 16. Efficient Memory Management for Large Language Model Serving with PagedAttention + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 1 марта 2027 года, 18:10 +- **Статья:** [Efficient Memory Management for Large Language Model Serving with PagedAttention](https://arxiv.org/pdf/2309.06180) +- **Центральный вопрос:** как страничная организация KV-кэша меняет использование памяти, пакетирование запросов и пропускную способность LLM-сервинга? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. Нужно отделить механизм PagedAttention от планировщика vLLM, понять причины фрагментации KV-кэша, а также проверить нагрузки, baselines, метрики и границы переноса результатов на современные модели и аппаратные платформы. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/17-2027-03-09-megascale.md b/seminars/17-2027-03-09-megascale.md new file mode 100644 index 0000000..dce468b --- /dev/null +++ b/seminars/17-2027-03-09-megascale.md @@ -0,0 +1,45 @@ +# 17. MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 9 марта 2027 года, 18:10 +- **Статья:** [MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs](https://www.usenix.org/system/files/nsdi24-jiang-ziheng.pdf) +- **Центральный вопрос:** какие системные механизмы делают обучение больших моделей эффективным и устойчивым на более чем десяти тысячах GPU? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +По умолчанию основной текст читается полностью. Следует связать параллелизм, коммуникации, планирование и обработку отказов с измеренной эффективностью, затем отделить общие принципы от решений, доступных только оператору инфраструктуры такого масштаба. + +**Дополнительное чтение к подготовке:** пока не назначено. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/18-2027-03-15-thunderagent.md b/seminars/18-2027-03-15-thunderagent.md new file mode 100644 index 0000000..b2a29ef --- /dev/null +++ b/seminars/18-2027-03-15-thunderagent.md @@ -0,0 +1,47 @@ +# 18. ThunderAgent: A Simple, Fast and Program-Aware Agentic Inference System + +[К списку семинаров](README.md) · [Общие правила](../seminars.md) · [Расписание](../schedule.md) + +- **Дата:** 15 марта 2027 года, 18:10 +- **Статья:** [ThunderAgent: A Simple, Fast and Program-Aware Agentic Inference System](https://arxiv.org/pdf/2602.13692v3) +- **Центральный вопрос:** как знание структуры агентной программы меняет планирование исполнения и использование повторяющегося контекста при LLM-инференсе? + +## Участники + +| Роль | Участник | +|---|---| +| Автор 1 | — | +| Автор 2 | — | +| Автор 3 | — | +| Рецензент | — | +| Археолог 1 | — | +| Археолог 2 | — | +| Исследователь | — | +| Практик | — | + +## Маршрут чтения и акценты + +Для этой статьи обязателен сокращённый маршрут: полный текст объёмом 34 страницы не входит в обязательное чтение целиком. Точные разделы для всех участников и дополнительные разделы по ролям будут опубликованы в этой карточке до назначения ролей. + +При подготовке нужно будет связать модель агентной программы с механизмами планирования и повторного использования контекста, проверить набор нагрузок и сравнения, а рецензенту — отдельно разобрать отсутствие прямого экспериментального сравнения с Agentix или Autellix. + +**Дополнительное чтение к подготовке:** будет указано вместе с сокращённым маршрутом. + +## Выбранные дополнительные тезисы + +| После блока | Автор тезиса | Формулировка | +|---|---|---| +| — | — | — | + +## После семинара + +- **Запись:** — +- **Источники из обсуждения:** — +- **Содержательные уточнения:** — + +### Оценка статьи студентами + +- **Ответов:** —; из них участников с ролями: — +- **Полезность:** — из 5 +- **Сложность среди участников с ролями:** — из 5 +- **Оставить в программе:** — из — ответов «да» или «скорее да» diff --git a/seminars/README.md b/seminars/README.md new file mode 100644 index 0000000..897bd2c --- /dev/null +++ b/seminars/README.md @@ -0,0 +1,46 @@ +# Карточки ролевых семинаров + +Для каждого из 18 ролевых семинаров заведена отдельная карточка. Карточка служит общей точкой входа в занятие и дополняется по мере подготовки. + +До семинара в ней фиксируются: + +- основная статья, дата и центральный вопрос занятия; +- состав участников; +- обязательный и рекомендуемый маршрут чтения; +- акценты конкретных ролей; +- выбранные дополнительные тезисы. + +После семинара можно добавить запись, источники из обсуждения, короткие содержательные уточнения и агрегированную оценку статьи студентами. Оценки выступлений, индивидуальная обратная связь и отдельные ответы на опрос в карточках не размещаются. + +Если в карточке не указан сокращённый маршрут, участники с ролями читают основной текст статьи полностью и самостоятельно подбирают дополнительные первичные источники, необходимые для своей роли. Общие требования приведены в [описании ролевых семинаров](../seminars.md). + +## Семинары + +| № | Дата | Статья | +|---:|---|---| +| 1 | 14.09.2026 | [Metastable Failures in the Wild](01-2026-09-14-metastable-failures.md) | +| 2 | 21.09.2026 | [FoundationDB: A Distributed Unbundled Transactional Key Value Store](02-2026-09-21-foundationdb.md) | +| 3 | 28.09.2026 | [Kora: A Cloud-Native Event Streaming Platform for Kafka](03-2026-09-28-kora.md) | +| 4 | 12.10.2026 | [Alea-BFT: Practical Asynchronous Byzantine Fault Tolerance](04-2026-10-12-alea-bft.md) | +| 5 | 19.10.2026 | [Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker](05-2026-10-19-rainmaker.md) | +| 6 | 02.11.2026 | [Boki: Stateful Serverless Computing with Shared Logs](06-2026-11-02-boki.md) | +| 7 | 16.11.2026 | [Scaling Large Production Clusters with Partitioned Synchronization](07-2026-11-16-partitioned-synchronization.md) | +| 8 | 23.11.2026 | [Oakestra: A Lightweight Hierarchical Orchestration Framework for Edge Computing](08-2026-11-23-oakestra.md) | +| 9 | 30.11.2026 | [Cloudy with a Chance of Cyberattacks: Dangling Resources Abuse on Cloud Platforms](09-2026-11-30-dangling-resources.md) | +| 10 | 14.12.2026 | [Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking](10-2026-12-14-jupiter-evolving.md) | +| 11 | 11.01.2027 | [veDB-HTAP: a Highly Integrated, Efficient and Adaptive HTAP System](11-2027-01-11-vedb-htap.md) | +| 12 | 18.01.2027 | [Manu: A Cloud Native Vector Database Management System](12-2027-01-18-manu.md) | +| 13 | 25.01.2027 | [Pond: CXL-Based Memory Pooling Systems for Cloud Platforms](13-2027-01-25-pond.md) | +| 14 | 08.02.2027 | [Who Watches the Watchers? On the Reliability of Softwarizing Cloud Application Management](14-2027-02-08-who-watches-the-watchers.md) | +| 15 | 15.02.2027 | [SuperBench: Improving Cloud AI Infrastructure Reliability with Proactive Validation](15-2027-02-15-superbench.md) | +| 16 | 01.03.2027 | [Efficient Memory Management for Large Language Model Serving with PagedAttention](16-2027-03-01-pagedattention.md) | +| 17 | 09.03.2027 | [MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs](17-2027-03-09-megascale.md) | +| 18 | 15.03.2027 | [ThunderAgent: A Simple, Fast and Program-Aware Agentic Inference System](18-2027-03-15-thunderagent.md) | + +## Как обновлять карточку + +- Состав участников и маршрут чтения публикуются до назначения ролей или одновременно с ним. +- Выбранные тезисы добавляются после решения преподавателя; присланные, но не выбранные предложения в карточке не публикуются. +- Дополнительное чтение к подготовке и источники из обсуждения фиксируются отдельно: первые назначаются до занятия, вторые появляются по его итогам. +- Итоги обсуждения ограничиваются несколькими содержательными уточнениями: исправленной фактической ошибкой, важной границей вывода или оставшимся открытым вопросом. Полная стенограмма не требуется. +- После закрытия анонимного опроса в карточку переносятся только агрегированные показатели и число ответов. Свободные комментарии дословно не публикуются.