osukhoroslov/nis2
1
Fork 0
Code Issues Pull Requests Actions Packages Activity

first commit

Browse Source
This commit is contained in:
osukhoroslov
2026-09-06 19:26:12 +03:00
commit fe0dbbe509
84 changed files with 3266 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
seminars/01-2026-09-14-metastable-failures.md
+51
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/02-2026-09-21-foundationdb.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/03-2026-09-28-kora.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/04-2026-10-12-alea-bft.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/05-2026-10-19-rainmaker.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/06-2026-11-02-boki.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/07-2026-11-16-partitioned-synchronization.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/08-2026-11-23-oakestra.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/09-2026-11-30-dangling-resources.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/10-2026-12-14-jupiter-evolving.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/11-2027-01-11-vedb-htap.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/12-2027-01-18-manu.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/13-2027-01-25-pond.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/14-2027-02-08-who-watches-the-watchers.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/15-2027-02-15-superbench.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/16-2027-03-01-pagedattention.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/17-2027-03-09-megascale.md
+45
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/18-2027-03-15-thunderagent.md
+47
View File
@@ -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
- **Оставить в программе:** — из — ответов «да» или «скорее да»
seminars/README.md
+46
View File
@@ -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) |
## Как обновлять карточку
- Состав участников и маршрут чтения публикуются до назначения ролей или одновременно с ним.
- Выбранные тезисы добавляются после решения преподавателя; присланные, но не выбранные предложения в карточке не публикуются.
- Дополнительное чтение к подготовке и источники из обсуждения фиксируются отдельно: первые назначаются до занятия, вторые появляются по его итогам.
- Итоги обсуждения ограничиваются несколькими содержательными уточнениями: исправленной фактической ошибкой, важной границей вывода или оставшимся открытым вопросом. Полная стенограмма не требуется.
- После закрытия анонимного опроса в карточку переносятся только агрегированные показатели и число ответов. Свободные комментарии дословно не публикуются.