d'Ivan

Используйте метод Task.WaitAll
Ссылки на все эти задачи, при этом надо, кончено не бросать без присмотра при перезаписи переменной outer, а сохранить (например, в массив Task[])

Лучше для чего именно? Какую проблему или проблемы вы этим решить хотите? Для начала определитесь, что именно вас не устраивает в вашем текущем решении - конкретные проблемы, характеристики, фичи и прочее. Скорость и качество доступа к хранилищу, объем, безопасность, надёжность и прочее. Сделайте список/документ. На основе вот этого списка и вашего опыта эксплуатации вашего решения сформулируйте требования к вашему хранилищу. И вот уже на основе этих требований подбирайте конкретное решение, которое их закроет по максимуму или, хотя бы, большей частью. Роутер и внешний диск вам тут точно не подойдут - низкая производительность и надёжность. Типовое универсальное решение - S3 хранилище в масштабируемом облаке. Альтернатива для своего сервера в своей серверной - FreeNAS.

Может все таки sln?
Это объединение проектов - солюшн. Вполне нормально, когда несколько проектов объединены, когда собирается больше одного exe например

Что-бы понять асинхронность полностью придется постепенно опустится на самый низкий уровень, вплоть до железа. Но начать стоит с самого верха - с уровня нашего приложения.

Итак, мы пишем на нашем высокоуровневом любимом языке, неважно JS/Rust/C#/Scala/Python или любой другой. В современном мире у нас скорее всего есть какая либо абстракция для работы с асинхронными апи, предоставляемая или стандартной библиотекой языка или сторонними библиотеками. Она может быть примитивной и основанной на колбэках или более продвинутой, вроде Future/Promise/Task или чем-то подобным. Иногда наш язык предоставляет синтаксис наподобие async/await для более простой работы с этими абстракциями, а иногда асинхронная работа может вообще быть скрыта от нас в рантайме языка, например как с горутинами в Go. Но в любом случае где-то под капотом у нас будет event-loop, а иногда и не один, так как никто не запрещает нам писать многопоточку в то же время используя асинхронные вызовы.

Сам event-loop - это не более чем обычный while(true) или любой другой бесконечный цикл. И внутри этого цикла наша программа имеет доступ на извлечение к некоторой очереди (если не знаете, что это за структура данных, то погуглите), которая содержит в себе результаты уже обработанных задач. Программа берет очередной результат, находит ожидающий ее колбэк/Promise/Future/Task и запускает выполнение ожидающего кода. Очередей опять же может быть несколько и обрабатываться они могут по разному, но это не важно. Важно то, что наш основной поток (или потоки) ничего не знают, о том как выполняются асинхронные задачи. Он лишь смотрит, есть ли в очереди результат, и если есть - обрабатывает его, а если нет, то принимает решение или выйти из цикла (и завершить поток, а иногда и весь процесс) или уснуть пока новых результатов не появится.

Но откуда же в очереди берутся результаты? Надо понимать, что асинхронная программа почти всегда многопоточная и результат операций попадает в очередь из фоновых потоков, которые просто блокируются в ожидании нужного ресурса (или сразу многих ресурсов, если используют системные апи вроде epoll или kqueue). Как правило такие фоновые потоки большую часть времени находятся в состоянии ожидания, а значит не потребляют ресурсы CPU и не попадают в планировщик ОС. Такая простая модель действительно позволяет сильно экономить ресурсы по сравнению с моделью, где множество потоков выполняют по 1 задаче и самостоятельно ожидают свои запросы.

Важно отметить, что в современном мире даже на среднеуровневых языках, вроде C или C++, не говоря уже о высокоуровневых, не реализуют асинхронность сами. Во-первых, на разных ОС для этого используются разные апи. Во-вторых, эти апи на разных ОС умеют обрабатывать разные типы ресурсов (с сетью вроде как умеют работать все основные ОС, но помимо сети асинхронно можно работать с пользовательским вводом, диском и периферийными устройствами, вроде сканеров, вебкамер и прочего цепляемого в usb). Наибольшую популярность (ИМХО) имеет кроссплатформенная библиотека libuv, хотя в Rust принято использовать mio (или даже абстракции над ней, вроде tokio), в C# подобные механизмы есть в .NET Core, а в Go оно уже зашито

Ок. С прикладным кодом вроде разобрались. А что же происходит в ядре ОС? Ведь, как писалось выше, у нас даже есть апи, чтоб ждать запросы пачкой. Все просто. Ядра ОС стали асинхронными еще до того, как это стало мейнстримом, если мы конечно имеем дело не с ОС реального времени (но у нас же винда/линь/мак/фряха, а не ОС для бортового компа боинга, где это критично). Смотрите, когда что-то происходит на внешней периферии (ну например диск запрошенные данные прочитал или по сети данные пришли, или юзер мышкой дернул), то формируется прерывание. CPU реально прерывает свою текущую работу и бежит смотреть что случилось, точнее вызывает обработчик предоставленный ОС. Но у ОС то есть основная работа, поэтому она скорее старается освободить обработчик и просто скидывает все данные в оперативку, а разбираться будет потом, когда очередь дойдет. Ничего не напоминает? Очень похоже, на то что происходило в event-loop, только вместо фоновых потоков "результаты" попадают в очередь из прерываний. А уже когда-то потом ОС отдаст данные в драйвер устройства, ну и т.д., пока они не дойдут до нашего прикладного приложения. Вот и все, никакой магии.

Можно рассмотреть тему файтюнинга, тема более реалистичная а самое главное, прикладная. Денег много не нужно, особенно для llama 8b и подобных по размеру моделей.

Тем не менее, по гпт все же есть варианты, можно очень хорошо разобраться тут, по сути посмотрев видео от самого разработчика:
https://www.youtube.com/watch?v=kCc8FmEb1nY

Что изучать python backend разработчику?

Вы не совсем верно ставите задачу, не "что изучать", а "какие инструменты выбрать для этой задачи". Если под "python backend разработчику" понимается классическая backend разработка, по типу сервера, для каких либо приложений, то:
1. Как сделать, чтобы по указанному url отдавалась html страница с таким то данными? Django Writing views. В процессе работы Вы начнете понимать, для чего нужны какие то вьюхи и модели.
2. Оказалось, что в п1. неудобно вставлять всю страницу, что делать, если мне нужно сделать более сложную html страницу? Используем один из самых популярных шаблонизаторов Jinja for Server-Side Rendering in Django.
3. Как и где хранить данные? Пробуем SQLite. В процессе работы Вы начнете понимать, для чего нужны какие то ORM.
4. Выяснилось, что п3 не подходит для моего проекта (почему конкретно?), где еще хранить данные? Пробуем PostgreSQL.
5. Как сделать простое API на Django? Используем Django REST framework (DRF) или Django Ninja.
6. Как создать возможность аутентификации пользователей и показ им именно их личной информации? How to use sessions, JWT.
7. Как быть, если мне приходит запрос с фронта и мне нужно быстро вернуть ответ, а не ждать, пока бэк все обработает? Django Background Tasks.
8. Задач стало очень много, Django не тянет, надо выполнять все в фоне, п6. уже не подходит (почему конкретно?), что делать? Django Celery.
9. Как развернуть мой мега сайт на хостинге? Shared хостинг (если VDS много, это жестко конечно, но хозяин - барин). Для VDS идем гуглить, в каком порядке и что надо ставить.
10. Как сделать автоматическое развертывание несколько проектов на удаленном сервере и нужно ли оно мне (описываем, что, где и в каком порядке нужно развернуть)? Docker + CI/CD.

В процессе может и админка для бэка понадобиться и много чего еще по мелочи. Опять же - вначале задача, затем поиск инструмента.

Так же можно гуглить по типу Django Roadmap 2024.