01 — Кейс · ML Нейросети

AI-диагностика медицинских снимков: переезд из облака на собственные серверы клиники

Мы разработали систему AI-анализа медицинских снимков для частной клиники и диагностического центра в Швейцарии и за четыре этапа перевели её из AWS на собственные серверы клиники. Свёрточные нейросети разбирают КТ, МРТ и рентген, выставляют приоритет срочным исследованиям и выводят предварительные находки в рабочий список рентгенолога. Сейчас система обрабатывает 200 тыс. снимков в месяц, анализирует снимок за 2–4 секунды, расходы на инфраструктуру снизились более чем на 95 %, а снимки пациентов не покидают здание.

2 годаNDA

Обновлено: 22 октября 2026 г.

Смотреть кейс

срок проекта: 2 года
функциональных модулей: 7
этапов разработки: 5
ключевых технологий: 6

AI-диагностика медицинских снимков: переезд из облака на собственные серверы клиники

02 — Контекст

Задача проекта

Исходная ситуация, ограничения и проблемы, которые должна была решить новая система.

Заказчик — крупная частная клиника и центр лучевой диагностики в Швейцарии, к которому едут пациенты из нескольких кантонов. Здесь делают КТ, МРТ, рентген и УЗИ, и каждое исследование должен посмотреть рентгенолог. Узких специалистов не хватает, а поток пациентов растёт, поэтому клинике был нужен AI, который поднимает срочные случаи наверх очереди, отмечает возможные отклонения и направляет исследования к нужному специалисту.

Швейцарская медицина требует строгого обращения с данными, а многие пациенты выбрали частную клинику в том числе ради конфиденциальности. Решение должно было соответствовать стандартам уровня HIPAA и работать с чувствительными данными, которые, как ожидают пациенты, останутся в Швейцарии.

Первую версию мы запустили в AWS: на этапе обучения моделей нужна была гибкость вычислений, а реальную нагрузку никто не знал. Через 18 месяцев система стала частью ежедневной работы и вышла на стабильные 200 тыс. снимков в месяц. Предсказуемая нагрузка показала проблему: облако обходилось в $167 000 в месяц, больше $2 млн в год, а прогноз на три года — около $6 млн.

Срочные случаи тонут в очереди
Рентгенологов не хватает, а исследований становится больше. Без предварительной оценки снимок с серьёзной находкой ждёт своей очереди наравне с нормой, и специалисты тратят время на разбор потока вместо самых важных случаев.
Облачный счёт рос вместе с потоком
Только GPU-инстансы для инференса стоили $47 000 в месяц, а с хранилищем, исходящим трафиком многогигабайтных снимков и резервными копиями — $167 000. Резервирование мощностей, спотовые инстансы и пересборка архитектуры не закрывали разрыв.
Снимки пациентов уходили в облако
Даже с шифрованием и сертификатами соответствия загрузка снимков в дата-центры AWS вызывала дискомфорт у пациентов и руководства клиники. Облачная обработка требовала договора с AWS как с третьей стороной, а аудит — проверки её мер защиты данных.

03 — Возможности

Что делает система

Ключевые сценарии и рабочие модули, собранные в единую систему.

Анализ снимков по модальностям
Для КТ, МРТ и рентгена обучены отдельные архитектуры свёрточных нейросетей: у этих снимков принципиально разная природа. На рентгене грудной клетки система находит пневмонию, образования в лёгких и переломы, на КТ — опухоли и кровоизлияния, на МРТ — очаги, воспаление и дегенеративные изменения. Модели учитывают анатомические варианты нормы, артефакты съёмки и следы перенесённых операций.
Вероятностная оценка находок
Система не ставит диагноз, а выдаёт вероятности находок. Например, для рентгена грудной клетки: 85 % — уплотнение, похожее на пневмонию, 12 % — узел, 3 % — пневмоторакс. Рентгенолог видит, какие исследования вероятнее всего содержат значимые находки, и начинает с них, а окончательное заключение остаётся за врачом.
Приоритеты в рабочем списке рентгенолога
Результаты анализа попадают прямо в рабочий список рентгенолога: флаги приоритета и предварительные находки стоят рядом с исследованием. Срочные случаи поднимаются наверх очереди, а исследования направляются к профильным специалистам. Врачу не нужно открывать отдельную программу — AI работает внутри привычного рабочего места.
Интеграция с PACS и РИС
Система подключена к PACS — архиву медицинских изображений — и к радиологической информационной системе клиники. Как только исследование завершено, снимки автоматически уходят в конвейер анализа, а результаты возвращаются в рабочий список. При переезде интеграцию перенастроили на локальные серверы инференса вместо загрузки в AWS.
Собственный GPU-контур клиники
Инференс работает на серверах с GPU NVIDIA, подобранных под архитектуры наших нейросетей, в серверной самой клиники. Быстрое хранилище держит рабочий набор снимков, которые нужны прямо сейчас. Мощности рассчитаны с запасом: без докупки оборудования система выдержит около 300 тыс. снимков в месяц против нынешних 200 тыс.
Резервирование и аварийное восстановление
Отказоустойчивость заложена на уровне железа: резервные узлы подхватывают нагрузку при сбое. Клиника уже имела независимые генераторы и три канала связи от разных провайдеров с автоматическим переключением. Резервные копии хранятся на площадке клиники в другом кантоне — географический разнос без облачного хранилища.
Мониторинг инфраструктуры
Мониторинг предупреждает ИТ-службу клиники, если растёт время обработки снимков, неожиданно падает загрузка GPU или какой-то компонент показывает признаки деградации. Плановое обслуживание проходит в нерабочие часы и не мешает клинической работе, а существующая ИТ-команда сопровождает новые серверы без расширения штата.

04 — Архитектура

Технологический стек

Технологии выбраны под нагрузку, интеграции и дальнейшее развитие продукта.

Зачем в проекте · 01 / 06

Deep Learning / CNN

Свёрточные нейросети, обученные на больших наборах размеченных медицинских снимков, распознают анатомические структуры и находят отклонения, которые требуют срочного внимания рентгенолога. Для каждой модальности — КТ, МРТ и рентгена — своя архитектура, потому что у этих снимков принципиально разная природа.

Зачем в проекте · 02 / 06

Computer Vision

Основа всей системы: модели не просто ищут патологию, а отличают её от вариантов нормы, артефактов съёмки и послеоперационных изменений, которые легко принять за отклонение. На выходе — вероятности находок, по которым рентгенолог выстраивает очередь разбора.

Зачем в проекте · 03 / 06

NVIDIA GPU

GPU подобраны под конкретные архитектуры нейросетей, которые мы развернули, чтобы получить лучшую производительность инференса. Свои серверы с запасом мощности заменили облачные GPU-инстансы, которые только на вычисления стоили $47 000 в месяц.

Зачем в проекте · 04 / 06

PACS Integration

Интеграция с PACS и радиологической информационной системой делает AI частью привычного процесса: снимок уходит на анализ автоматически, а результат появляется в рабочем списке врача. Поэтому и переезд прошёл незаметно для рентгенологов — поменялся только адрес серверов инференса.

Зачем в проекте · 05 / 06

AWS

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

Зачем в проекте · 06 / 06

Infrastructure Design

Проект локальной инфраструктуры с надёжностью не ниже облачной: спецификация серверов и хранилища, резервирование на уровне железа, оптимизация сети, план аварийного восстановления и проверка того, что ИТ-служба клиники справится с сопровождением. Именно расчёт полной стоимости владения показал, что свои серверы выгоднее.

Ещё в проекте

Medical AI
On-Premise

05 — Процесс

Как шла разработка

Последовательность работ от исследования задачи до запуска и проверки результата.

Модели и запуск в облаке
Обучили свёрточные нейросети для КТ, МРТ и рентгена, настроили вероятностную оценку находок и флаги приоритета. Развернули инференс на GPU-инстансах AWS с автомасштабированием и интегрировали систему с PACS и радиологической информационной системой клиники.
Рабочая нагрузка и расчёт стоимости
За 18 месяцев система вышла на 200 тыс. снимков в месяц. Мы посчитали стоимость владения на три года: в AWS — около $6 млн, на своих серверах — около $625 000 при вложениях $340 000 и $95 000 в год на эксплуатацию. Проверили и оптимизацию облака, но разрыв она не закрывала.
Проект локальной инфраструктуры
Подобрали серверы с GPU NVIDIA и хранилище с запасом на рост, заложили резервирование на уровне железа, оптимизировали сеть и спроектировали аварийное восстановление с копиями на площадке в другом кантоне. Убедились, что действующая ИТ-служба клиники сможет сопровождать новый контур.
Параллельная работа и переключение
Перенесли обученные модели, конфигурацию, конвейеры обработки и код интеграций на локальные серверы. Какое-то время обе системы работали параллельно, нагрузка переходила постепенно. Финальное переключение провели в выходные, когда исследований меньше всего, а первую неделю следили за системой, готовые вернуться в облако. Не понадобилось.
Оптимизация и документация
Настроили загрузку GPU, расписание пакетной обработки и управление хранилищем, внедрили мониторинг. Обновили процедуры аварийного восстановления, а служба комплаенса описала новую архитектуру для регуляторных аудитов. Весь путь — четыре этапа за два года.

06 — Итог

Результаты

Что создано в рамках проекта: рабочий контур, реализованные возможности и подтверждённые факты.

затрат на инфраструктуру: −95 %
снимков в месяц: 200 тыс.
на анализ снимка вместо 8–12 с в облаке: 2–4 с
экономии за три года: $5,4 млн

Переезд дал ту экономию, которую мы заложили в расчёт. Эксплуатация теперь стоит около $95 000 в год вместо $2 млн — это минус 95 % с лишним, а вложения в оборудование на $340 000 окупились за семь месяцев. За три года клиника сэкономит около $5,4 млн. Вместо облачного счёта, который рос вместе с числом пациентов, — фиксированные расходы, которые легко планировать.

Система стала быстрее: снимок анализируется за 2–4 секунды вместо 8–12 с отправкой в AWS. Мы рассчитывали сравняться с облаком, а не обогнать его, — выигрыш дала обработка внутри локальной сети без загрузки и скачивания через интернет. Для рентгенологов ничего не изменилось: снимки разбираются автоматически, находки и приоритеты появляются в рабочем списке, надёжность не ниже облачной.

Вопрос хранения данных закрыт полностью: снимки пациентов не покидают здание клиники на всём пути анализа. Договоры об обработке данных с AWS больше не нужны, а аудит безопасности теперь проверяет физическую защиту и локальную сеть. Для снимков, которые клиника хранит 30 лет и больше, это ещё и защита от будущих уязвимостей шифрования.

Детали проекта

Почему кейс без имени клиента

Название клиники мы не раскрываем. Для частной медицины конфиденциальность — часть того, за чем к ней приходят пациенты, поэтому закрытыми остаются имя заказчика, его внутренние показатели и всё, что позволяет их вычислить. Открыто можно сказать одно: это частная больничная группа с центром лучевой диагностики в Швейцарии.

При этом мы свободно рассказываем, как устроена система и как прошёл переезд: свёрточные нейросети для КТ, МРТ и рентгена, интеграция с PACS, расчёт стоимости облака и собственных серверов и четыре этапа за два года. По этому описанию несложно прикинуть, как такая система и такой переезд выглядели бы у вас, — а конкретику под вашу клинику и нагрузку разберём уже на встрече.

FAQ

Вопросы о проекте

Нет. Модели выдают вероятности находок, а не окончательный диагноз. Например, по рентгену грудной клетки: 85 % — уплотнение, похожее на пневмонию, 12 % — узел, 3 % — пневмоторакс. Рентгенолог использует эти оценки, чтобы выстроить очередь и в первую очередь смотреть исследования, где значимая находка наиболее вероятна. Заключение по-прежнему пишет врач, а система помогает ему не пропустить срочное.

КТ, МРТ и рентген — для каждой модальности обучена своя архитектура нейросети. На рентгене грудной клетки система находит пневмонию, образования в лёгких и переломы, на КТ — опухоли, кровоизлияния и структурные изменения, на МРТ — очаги, воспаление и дегенеративные изменения мягких тканей. Модели учитывают варианты нормы, артефакты съёмки и следы операций, чтобы не принимать их за патологию.

На старте облако было разумным выбором: обучение моделей требовало гибких вычислений, а реальную нагрузку предсказать было нельзя. Через 18 месяцев картина изменилась: стабильные 200 тыс. снимков в месяц, счёт $167 000 в месяц и растущие требования к хранению данных в клинике. Решение «сначала облако» не обязано быть решением «облако навсегда» — инфраструктуру стоит пересматривать, когда меняются нагрузка и приоритеты.

Когда нагрузка большая и предсказуемая. В этом проекте оборудование и установка обошлись примерно в $340 000, эксплуатация — около $95 000 в год, а облако стоило $167 000 в месяц. Вложения окупились за семь месяцев, экономия за три года — около $5,4 млн. Помогло и то, что у клиники уже были своё здание и ИТ-служба: строить дата-центр с нуля не пришлось.

Мы запустили локальные серверы параллельно с облаком и переводили нагрузку постепенно, проверяя каждую модальность и возврат результатов на рабочие места рентгенологов. Финальное переключение провели в выходные, когда исследований меньше всего, а первую неделю держали наготове возврат в облако. Он не понадобился: локальная инфраструктура приняла всю рабочую нагрузку, и врачи переезда не заметили.

Надёжность не ниже облачной. Отказоустойчивость заложена на уровне железа, у клиники есть независимые генераторы и три канала связи от разных провайдеров с автоматическим переключением. Резервные копии хранятся на площадке клиники в другом кантоне. Это не мультирегиональное облако, но такой уровень соответствует требованиям регулятора и допустимому для клиники риску, а обслуживание проходит в нерабочие часы.

Снимки пациентов больше не покидают здание клиники, кроме явно разрешённых передач в другие медучреждения. Договоры об обработке данных с AWS стали не нужны, и часть требований комплаенса упростилась: аудит проверяет физическую защиту и локальную сеть, а не настройки облака. Для снимков, которые хранятся 30 лет и больше, это ещё и защита от будущих уязвимостей шифрования.