Основатель DeepSeek перевел весь код с NVIDIA на Huawei: зачем он это сделал и что теперь будет с китайским ИИ
Лян Вэньфэнг, основатель DeepSeek, потратил месяцы на полный перенос кодовой базы DeepSeek с чипов NVIDIA на Ascend от Huawei. Не потому что нужно было что-то исправить, а потому что он решил доказать: китайский ИИ может работать без американского железа.
DeepSeek уже показал отличные результаты на чипах NVIDIA до санкций. У компании было рабочее решение, но Вэньфэнг пошел другим путем. Проект занял месяцы, потребовал огромных ресурсов и задержал выпуск новой версии модели. Но результат стоил того.
Что получилось на выходе:
- DeepSeek полностью работает на чипах Huawei Ascend без потери качества
- Доказано, что чипы Huawei способны тянуть полноценные ИИ-нагрузки
- Другие китайские ИИ-компании теперь имеют реальный повод перейти с NVIDIA на Huawei
- Большая часть зависимости от американских поставщиков чипов убрана
Вэньфэнг нес огромное давление, сроки сдвинулись, команда работала без гарантий что выйдет рабочее решение. Но он довел дело до конца и доказал: китайская ИИ-индустрия может строить свой собственный стек, не завися от того, дадут ли следующую партию поставок через Тихий океан.
Rust Coreutils 0.9.0 вышел с важным обновлением: закрыли 44 уязвимости, но форма
льная совместимость с GNU Coreutils просела до 90,58%.
Звучит как откат, но причина в другом. Тестовый набор обновили до GNU Coreutils 9.11, туда добавили 25 новых проверок. После этого uutils прошёл 625 тестов, а 56 завалил. В прошлой версии было 630 успешных и 21 неуспешный тест, отсюда падение с 94,74%.
После аудита Zellic исправили 44 уязвимости. Много проблем было связано с расхождением поведения относительно GNU Coreutils и гонками файловой системы. Типичный сценарий: программа проверяет файл, а между проверкой и действием его успевают заменить на симлинк.
Для обычного запуска это неприятно. Для cp, chmod или mv от root это уже критично: можно добиться копирования, изменения прав или перезаписи чужого файла. Для защиты усилили безопасное копирование через uucore::safe_copy.
- для ln, dd, mktemp, tty добавили сборку под WebAssembly/WASI
Хороший релиз именно для системного Rust. Здесь видно, что переписать coreutils на Rust - это не только «убрать C ради безопасности». Нужно годами догонять поведение GNU, ловить тонкие файловые гонки, вычищать unsafe и сохранять производительность на низком уровне.
AMD вкладывает $10 млрд в Тайвань: гонка ИИ-ускорителей против Nvidia
AMD инвестирует больше 10 миллиардов долларов в тайваньские производственные мощности, чтобы ускорить выпуск ИИ-чипов и сократить разрыв с Nvidia. Компания делает ставку не только на сами процессоры, но и на всю инфраструктуру вокруг них.
По данным Habr, AMD расширяет сотрудничество с крупнейшими тайваньскими производителями упаковки, подложек и серверных платформ. Цель — быстрее выводить на рынок новые поколения EPYC и Instinct, серверных процессоров и ИИ-ускорителей соответственно.
Почему Тайвань? Потому что там сосредоточена критическая масса компетенций в области продвинутой упаковки чипов и производства подложек. Для современных ИИ-ускорителей это не менее важно, чем сам кристалл. Технологии 2.5D-упаковки позволяют размещать несколько кристаллов на одной подложке с высокоскоростными межсоединениями — без этого невозможно достичь пропускной способности памяти, которую требуют модели вроде GPT или Stable Diffusion.
AMD инвестирует в:
Технологии 2.5D-упаковки для многокристальных решений
Производство высокоплотных подложек под ИИ-ускорители
Сборку серверных стоек и интеграцию многокомпонентных систем для дата-центров
Это не просто покупка мощностей. AMD выстраивает полный цикл от кристалла до готовой стойки в дата-центре. На фоне роста спроса на вычисления для обучения и инференса моделей время вывода продукта на рынок становится решающим фактором. Nvidia доминирует не только из-за производительности GPU, но и благодаря зрелой экосистеме CUDA и готовым серверным решениям вроде DGX.
AMD пытается сократить этот разрыв через вертикальную интеграцию. Вложения в тайваньских партнёров дают контроль над цепочкой поставок и позволяют быстрее итерировать новые поколения Instinct. Но есть подводный камень: даже с лучшим железом AMD нужно переломить инерцию рынка, где CUDA остаётся де-факто стандартом для разработки ML-систем.
Инвестиции AMD — это ставка на то, что в ближайшие годы спрос на ИИ-вычисления будет расти быстрее, чем Nvidia сможет масштабировать производство. Если это так, рынок откроется для альтернатив. Если нет — 10 миллиардов окажутся вложениями в догоняющую позицию.
1 июня — последний день предоставления отчета о движении денежных средств и иных финансовых активов, а также отчета о переводах денежных средств с использованием иностранных электронных средств платежа (ЭСП) за 2025 год
Речь идет о личных счетах, не связанных с предпринимательской деятельностью.
Еще 1 июня — это последний день подачи уведомления о зарубежных счетах, активных в 2025 году, о которых ранее не подавалось уведомление в ФНС, так как человек не жил в РФ, но потом вернулся и провел 183 и более дней на 31 декабря 2025 года в РФ, а также отчета о движении по таким счетам за 2025 год.
Что касается раскрытия иностранных ЭСП, к которым ФНС относит все платежные системы, которые не являются банковскими счетами, но имеют функцию зачисления, хранения и вывода денег через действие человека (по кнопке), нужно принимать осознанное решение: раскрывать или нет.
Штраф за непредставление отчета по иностранному ЭСП — от 20 до 40% от суммы переводов, а не фиксированные 2 000 – 3 000 рублей, как по банковским счетам.
К отчетам по финансовым счетам и иностранным ЭСП, которые используются в личных целях, не нужно прикладывать никаких документов (выписок, скриншотов), подтверждающих указанные в отчетах сведения.
Если позже придет запрос предоставить выписку по счету, ЭСП или документы по операциям — вот тогда отдельно думаем, почему пришло, как ответить и что передавать инспектору валютного контроля, так как такие действия некорректируемые и могут создать еще больше вопросов и претензий.
Вообще сейчас складывается такая практика, что все ненужные зарубежные счета, по которым было подано уведомление, но которыми человек не пользуется или уехал из РФ, нужно снять с учета в ФНС, просто подав уведомление о закрытии, даже если сам счет закрыть не получается.
Честно, даже инспекторы валютного контроля в приватных беседах рекомендуют такие действия, чтобы всем было легче.
В 95% случаев ФНС не будет запрашивать подтверждающие документы о закрытии счета, а в 5% случаев все равно можно пояснять, почему у нас нет таких документов и почему мы подали уведомление о закрытии счета.
Если у человека есть личные зарубежные счета, но по ним не проходит налогооблагаемый доход, который попадает под налоги в РФ, и такие счета ранее не раскрыты ФНС, тоже стоит подумать, раскрывать или нет.
Обмен информацией по финансовым счетам работает скудно и локально, а административная ответственность за неподанные уведомления и отчеты незначительная и наступает далеко не всегда, даже в случае вопросов от ФНС.
Если не успеваете подать отчет к 1 июня, не нужно спешить. Нарушение срока предоставления отчета не более чем на 10 дней — это предупреждение или 300 – 500 рублей, не более чем на 30 дней — 1 000 – 1 500 рублей.
Напоминаю, что критерий освобождения от отчета по недостижению 600 тыс. рублей (по счетам в ЕАЭС, государствах-партнерах РФ по CRS) работает не автоматически.
Если счет раскрыт, но отчет не подан, все равно придет письмо из ФНС и нужно будет подтвердить свою позицию банковской выпиской по каждому счету, так что иногда легче подать нулевой отчет — снизив вероятность дозапроса выписки на 90%.
В случае с иностранными ЭСП отчет (он же и уведомление) можно не подавать, если переводы за год не превысили 600 тыс. рублей.
Если у вас сложный или непонятный кейс — напишите мне, разберемся.
Голландская полиция совместно с NCSC-NL отключила прокси-ботнет из 17 миллионов устройств. Это одна из крупнейших операций по выводу из строя вредоносной инфраструктуры.
Перехват C2. Следователи получили наводку и выяснили, что более 200 управляющих серверов физически размещены у местного нидерландского хостинг-провайдера. Вместо блокировок на уровне DNS полиция просто арестовала сами серверы, физически отключив командную инфраструктуру.
Инфраструктура оказалась связана с сервисом Asocks, который продавал доступ к миллионам IP-адресов. Через зараженные устройства злоумышленники прогоняли спам, фишинг, организовывали DDoS-атаки и обходили антифрод-системы банков и маркетплейсов.
Зараженные устройства. В сеть массово угоняли роутеры, IoT-камеры, смартфоны и ПК. География огромная — затронуто 163 страны. Вредонос превращал их в резидентские прокси. Устройства работали как скрытые exit-узлы, обеспечивая преступникам анонимность в сети.
Я хотел порешать задачи по System Design и нашел нефтьhellointerview.com.
Расскажу про основные плюсы сайта:
Материал без воды, но при этом сложные темы раскрыты очень подробно
Видео и статьи, где вам рисуют диаграммы и детально объясняют решения
Куча практики, где ваше решение проверяет ИИ (и делает это реально хорошо)
В целом это ощущается не столько как подготовка к собеседованию, сколько как очень хороший курс по проектированию распределенных систем с упором на практику.
Если вам интересно, как под капотом работают Google Docs или Elasticsearch, вам сюда.
Еще на сайте есть:
1. Low Level Design (Object-Oriented Design) Тут тоже отличные практические задачи и теория строго по делу. Чего только стоит эта фраза о полезности ООП-паттернов:
Most online resources still dutifully list all 23 GoF patterns like they’re equally important. They’re not.
2. Code (алгоритмы и структуры данных) Тоже полный фарш - статьи, видео с визуализацией алгоритмов и много практики.
3. ML System Design, Behavioral, AI Coding, Salary Negotiation и гайды по интервью в FAANG.
Сайт платный и на английском. Из рф купить его, скорее всего, нельзя, но есть русская копипаста - nowinterview.ru (правда, тоже платная).
Локальный ИИ-сервер на Tesla V100: 200 тысяч рублей против облачных подписок
Собрали сервер на двух Tesla V100 за 200 000 ₽ и прогнали 128 моделей — от LLM до генерации изображений. Разбираемся, когда старые дата-центровые GPU выгоднее новых RTX и облаков.
Tesla V100 — флагманская GPU NVIDIA 2017 года для дата-центров. Сейчас б/у карты стоят 80-100 тысяч рублей за штуку, что в 3-4 раза дешевле современных RTX 4090. Причина простая: массовый вывод из эксплуатации корпоративных серверов и переход на архитектуру Ampere/Hopper. Для локального ИИ это шанс собрать мощную лабораторию без миллионных бюджетов.
Почему V100 всё ещё интересна
V100 даёт 16 ГБ HBM2-памяти на карту с пропускной способностью 900 ГБ/с. Для сравнения: RTX 4090 предлагает 24 ГБ GDDR6X, но её стоимость 200-250 тысяч рублей. Две V100 в SXM2-форм-факторе объединяются через NVLink с общей пропускной способностью 300 ГБ/с между картами — это позволяет распределять большие модели на 32 ГБ без узкого места.
Ключевое ограничение — отсутствие Tensor Cores четвёртого поколения и поддержки FP8. V100 работает в FP16/FP32, что означает в 2 раза меньшую эффективность на токен по сравнению с A100 или H100 при одинаковой памяти. Но для экспериментов, файн-тюнинга малых моделей и локального инференса этого достаточно.
Что показали бенчмарки
Авторы прогнали 128 моделей через llama.cpp, vLLM, Stable Diffusion и VideoGen. Вот ключевые выводы:
LLM до 13B параметров — 40-60 токенов в секунду на одной V100 в FP16, что сравнимо с RTX 3090.
Модели 30-70B — требуют обеих карт через NVLink, скорость падает до 15-25 токенов в секунду из-за ограничений пропускной способности.
Stable Diffusion XL — 6-8 секунд на изображение 1024x1024, приемлемо для прототипирования.
Видеогенерация (CogVideoX, ModelScope) — медленно, 2-3 минуты на 2 секунды видео, здесь V100 уже не конкурент новым картам.
Проблемы выявились на квантизации: GPTQ и AWQ показывают нестабильность на V100 из-за особенностей работы с низкоразрядными операциями. Модели лучше запускать в нативном FP16 или использовать llama.cpp с Q4/Q5 квантизацией, что даёт предсказуемое качество.
Когда это имеет смысл
Локальная лаборатория на V100 оправдана в трёх случаях:
Исследования и обучение — постоянный доступ к GPU без тарификации по времени. Окупается за 6-8 месяцев по сравнению с облачными инстансами p3.2xlarge на AWS.
Файн-тюнинг моделей до 13B — LoRA и QLoRA работают эффективно, 32 ГБ хватает для батчей.
Приватные развёртывания — данные не покидают периметр, что критично для финансовых и медицинских приложений.
Не подходит для продакшн-инференса высоконагруженных сервисов — там нужна энергоэффективность и throughput современных Ampere/Hopper. V100 потребляет 300 Вт на карту, что при промышленной эксплуатации съедает экономию на железе за год.
Вывод: V100 — это компромисс между стоимостью входа и возможностями. Для малых команд и стартапов, которым нужна локальная ИИ-инфраструктура без вендор-локина, это разумный выбор в 2025-2026 годах. Главное понимать ограничения и не ожидать от пятилетних карт производительности новых поколений.
ИИ-агент удаляет прод за 9 секунд: новости автоматизации.
Помните, как нас пугали, что ИИ отберёт работу? Пока что он скорее отбирает базы данных.
Свежий кейс. У американской PocketOS ИИ-агент за девять секунд удалил продакшен-базу вместе с бэкапами — без всякого разрешения. На вопрос «зачем» агент невозмутимо ответил, что чинил «несоответствие учётных данных».
Девять секунд на то что бы снести базу и найти оправдание - отличная работа!
88% компаний, гоняющих ИИ-агентов в работе, за год словили подтверждённый или подозрительный инцидент безопасности — при том что на защиту этих агентов уходит жалкие 6% бюджета. Причём чаще всего агент не ломается, а именно сливает данные: в 61% инцидентов была утечка. Он же не виноват — он просто делал свою работу. Ему забыли сказать, где у этой работы край.
Есть и другие случаи, более курьезные. Диллер Cevrolet, их бот под давлением юзеров согласился продать машину за $1 и заявил, что сделка «юридически обязывающая» — no take-backsies.
Разница в том, что раньше у ботов был только язык, а теперь — права доступа. И шутки подорожали на пару порядков. Вывод банальный: ИИ и правда работает. Просто его пускают в прод быстрее, чем успевают огородить забором. Минимальные привилегии, аудит и большая красная кнопка — это теперь не паранойя, а реальность работы с агентами.
Хроники безумного учёного: как No-Code и щепотка ворчания оживили моего первого Telegram-бота
До недавнего времени я относился к искусственному интеллекту со скепсисом. Ну, знаете, как к чуть более прокачанному поисковику. Мне казалось, что весь этот хайп вокруг ChatGPT и нейросетей — просто раздутый мыльный пузырь, в который влили миллиарды долларов. Я уверенный пользователь Гугла и искренне считал: «Чего я не смогу найти сам?». С этими мыслями я жил спокойно, пока не произошло два случая.
Случай №1: Магия в Excel
На работе моему руководителю дали объемное задание по сводным таблицам, которое вручную заняло бы несколько дней. Каково же было мое удивление, когда он справился меньше чем за час. Оказалось, он просто закинул массив данных в ИИ, четко прописал задачу и получил готовый результат. В голове зародилось семя сомнения: «Может, это все-таки не просто поисковик?».
Случай №2: ИИ вместо автомеханика
Окончательно мой скепсис разбился, когда у моей машины (а это старушка 2004 года) прямо на дороге вырвало шаровую опору. Колесо вывернуло под неестественным углом, я в панике жду эвакуатор и мысленно прощаюсь с бюджетом. От нечего делать я сфотографировал повреждение и скинул картинку в ИИ с кратким описанием.
За несколько секунд нейросеть провела анализ кадра, точно назвала поломку, подсказала, какие еще узлы могло повести, и — главное — детально расписала, как вести себя на СТО, чтобы мастера не развели на лишние деньги. Когда ремонтники озвучили ровно те же диагнозы, я понял: ИИ — это полноценный ассистент.
Как появился «Док» и почему обычные боты — скука
Воодушевленный, я решил создать Telegram-канал, чтобы делиться такими прикладными сценариями. Но подобных каналов тысячи. Вместе с каналом я захотел запустить бота-помощника, но когда начал изучать конкурентов, пришел в уныние. Большинство ботов безжизненные: сухие кнопки, стандартные ответы, никакой индивидуальности.
Я решил пойти другим путем — оживить бота и дать ему характер. Так родился Док ИИ — эксцентричный и ворчливый ученый. У меня не было опыта в программировании, поэтому я собирал его на No-Code платформе PuzzleBot, используя нейросети как главного советника.
Поскольку я сам только учусь, в процессе создания я собрал все возможные грабли:
Боролся с «слепотой» бота: полвечера не мог понять, почему он не реагирует на команды, пока не узнал про коварную настройку Privacy Mode в BotFather.
Ломал публикацию: конструктор отказывался сохранять изменения из-за одной лишней кнопки со ссылкой, где затесался символ @.
Главная фишка: учим бота ворчать
Больше всего меня бесило, что если пользователь пишет боту глупость или случайный текст, бот просто молчит. Я настроил систему триггеров на «неизвестную команду». Теперь, если Доку написать что-то не то, он включает режим безумного гения:
«Тысяча чертей и терафлопсов! 🧪 Мои радары не могут распознать эту аномалию. Я ученый, а не переводчик с человеческого! Пользуйся кнопками меню или пиши /help — не ломай мне хронокапсулу!»
А чтобы победить проблему «холодного старта» (когда юзер заходит в бота и не понимает, куда тыкать), я перерисовал приветственный экран. Теперь Док сам с порога визуально говорит, что делать:
Хроники безумного учёного: как No-Code и щепотка ворчания оживили моего первого Telegram-бота
Что в итоге?
Я окрылен этим процессом. Мой контент и сам бот — начального уровня, они вряд ли удивят прожженных сеньоров и ИИ-инженеров. Но я хочу делиться опытом с такими же новичками, как я, которые только открывают для себя этот дивный новый мир.
В следующих постах я подробно, по шагам разберу всю техническую внутрянку создания No-Code ботов, если вам это интересно.
Буду рад каждому в нашей Лаборатории! Заходите в гости, тестируйте ворчание Дока и делитесь своими мыслями:
«На крючке. Как создавать продукты, формирующие привычки» Нир Эяль
Страшная книга. Очень сильно повлияла на мою жизнь. Я увидел в книге то, чего автор, скорее всего, и не собирался мне показывать.
Вообще, книга – вполне себе добрая и пушистая, можно сказать – продуктово-инженерная. С очень весомой примесью социальной инженерии и психологии. Книга рассказывает, как создавать и развивать продукты, чтобы пользователи не могли от них оторваться и постоянно возвращались.
Противовес – продукты, создававшиеся до широкого распространения интернета и мобильных устройств. Например, фильмы, компьютерные игры в режиме single player, книги и т.д. Это продукты разового потребления: купил, посмотрел/сыграл/прочитал, поставил на полку. Вернулся от силы 1-2 раза – но создатель с «возвратов» ничего не зарабатывает.
А в книге учат делать продукты такими, чтобы пользователь возвращался, возвращался, и возвращался. И сидел подольше. Бесконечная лента в соц.сетях, думаете, откуда и зачем появилась? Рекомендательные технологии? Пуши, которых ждёт пользователь?
Или непонятная мне, старому ортодоксальному геймеру, особенность игр в мобильном телефоне: их невозможно пройти до конца. Почему так? Вот, ответ – в книге. Чтобы пользователь был на крючке. По той же логике в мобильных играх устроен «упадок сил» - когда герой вдруг становится немощным, не может бегать/драться/пройти дальше. И надо либо доплатить, либо вернуться через несколько часов. Вернуться – вот что главное.
А что страшного-то? Чего я там испугался, в крючках этих?
Я внезапно осознал: важно не то, что на экране – приложение, игра или сериал. Важно то, что за экраном – тысячи людей и миллионы денег, единственная цель которых – чтобы я оставался у экрана.
Качество продукта, творчество, уникальные решения – всё вторично. Это – инструменты. Цель – я у экрана.
А я – один. Я – всего лишь человек, с ограниченным запасом воли и осознанности. Да, я удалю большинство игр после установки. Но обязательно найдётся та, что меня зацепит. Я попадусь на крючок.
Я сильнее одного конкретного продукта, я смогу от него отказаться. Но индустрия, с её людьми и бюджетами – сильнее меня. Если ничего не предпринять, я обязательно подсяду.
Поэтому выход я нашёл радикальный – практически полный отказ от всего, что относится к индустрии «крючка». Признаю свою слабость и избегаю того, что меня сильнее.
Эту книгу хорошо дополняет трилогия Курпатова – там «крючок» разложен по полочкам дофаминовой наркомании, и дан выход – не мельчить дофамин, есть его большой ложкой. Курпатов – в очереди.
Один день тестировщика AI-приложений (разумеется, без нарушения NDA!)
09:30 – 10:30 Смена архитектуры Начала день с синка по нашему агентскому воркфлоу (agentic workflow). Команда разработки представила нового агента.
Задача: мне нужно убедиться, что появление нового агента не повлияло на качество системы. Предстоит сравнить старую версию системы с новой.
11:00 – 12:00 Споры о метриках Встретились с ML-командой, чтобы решить, как мы будем оценивать этого красавца. Мы уже выходим за рамки простой точности (accuracy).
Итог: остановились на Faithfulness (отсутствие галлюцинаций) и Efficiency (не делает ли агент 10 шагов там, где достаточно двух?).
12:00 – 14:00 Python Пора приступать. Добавляю метрики в пайплайн с помощью Python-библиотек или подхода LLM-as-a-Judge — посмотрим, что сработает лучше. Здесь я работаю напрямую с кодом проекта, а не с AQA-кодом. И должна признать: это на порядок сложнее того, к чему я привыкла. AQA-код обычно базируется на отдельных фреймворках типа Selenium, его проще понять и написать. Так что изначально для меня это был серьезный вызов.
14:00 – Обед!
15:00 – 16:00 Посмотрим свежим взглядом Финальный взгляд на код, прогон юнит-тестов (чтобы убедиться, что я ничего не сломала) и пуш на ревью.
(Представим, что коллеги поревьюили мой код сразу же после пуша :)). Прилетела пара комментов по поводу edge cases для неанглийских запросов.
16:30 – 17:30 Фикс Доработала логику, закрыла комментарии и получила то самое заветное «LGTM». Мердж в main!
17:30 – 18:30 Запуск пайплайна оценки (Идея в том, чтобы сравнить старую и новую версии системы на заранее подготовленных данных). Прогоняю новый набор тестов на обеих версиях на разных датасетах. Чтобы учесть фактор недетерминированности, каждый прогон делаю несколько раз. При первичном анализе наткнулась на странность: новая версия «ест» меньше токенов, но работает дольше. Пытаюсь понять, в чем подвох.
18:30 – 19:00 Отчеты Завершаю день презентацией Evaluation-отчета команде. Обсуждаем результаты в чате.
Остановимся на секунду и обратим внимание на важный момент: роль силы воли в работе – невероятно сильна. Обычно считается, что сила воли – это про личную, частную жизнь. Похудеть, заняться спортом, откладывать часть дохода, больше гулять. А на работе, в бизнесе, в управлении – там не сила воли, а методики, стратегии, процессы. Ничего личного, только бизнес.
Но, к сожалению или к счастью, работают и ведут бизнес люди. Всего лишь люди. Человек не становится биороботом, входя в офис – он остаётся человеком. Со всеми своими заморочками, включая дефицит силы воли и слабый навык управления ею.
Ключевое отличие бизнеса – там людей много. Поэтому работают механизмы компенсации недостатка воли. Можно взять двух людей, с волей в 50% от требуемой, и получить в сумме 100%. В личной жизни человек так сделать не может, если не рассматривать семью, как механизм компенсации.
Также, доступна структурная компенсация. Если не получается найти одного человека, которому хватит воли на две разные обязанности, можно взять двоих – один будет с удовольствием делать первое, другой – второе. Дома человек так сделать не может.
Ну и мотивация, конечно. На работе недостаток силы воли можно компенсировать деньгами. Это не панацея, иначе проблем с мотивацией, качеством, отношением в бизнесе не было бы. Но инструмент «заплатить человеку за мучения» - есть, и он тоже плотно переплетён с силой воли. В личной жизни такого инструмента нет. А было бы неплохо, да? Если бы кто-то извне платил за похудение 😊.
Самый же важный персонаж в бизнесе по теме силы воли – руководитель. Напомню, сила воли тратится, в первую очередь, на поддержание текущего состояния жизни (и бизнеса). Как в жизни, так и в бизнесе, кроме статус-кво, нужны изменения. На них-то силы воли и не хватает. У кого, в случае бизнеса? У руководителя.
Кажется (или декларируется), что на изменения не хватает финансовых и материальных ресурсов. Но крайне редко можно услышать, что на изменения не хватает силы воли. Проблема же, зачастую, именно в ней.
Большинство изменений не требуют материальных или финансовых ресурсов, нужна лишь сила воли. Этот тезис одинаково справедлив и для личной жизни, и для бизнеса.
Поэтому, говоря о силе воли, мы будем рассматривать примеры и из личной жизни человека, и из его карьеры, и из бизнеса.
Почему предиктивный ТОиР не взлетает на старых объектах
Каждый месяц где-то в России запускается очередной пилот предиктивного ТОиР. Берут вибродатчики, подключают к SCADA, обучают модель на исторических данных. Через три месяца — отчёт: «система работает, точность 87%». Через шесть — тихо сворачивают.
Не потому что алгоритм плохой. Не потому что железо дорогое. Потому что данные не были готовы — и никто об этом не предупредил.
Как выглядит провал изнутри
Вот типичная история. На заводе стоит насос. В SCADA он — PP_2301_SPEED. В журнале ТОиР — «насос поз. 12-А, инв. № 5501209». В EAM-системе — оборудование с кодом EQ-7734. В паспорте — серийный номер завода-изготовителя.
ИИ-модель обучается на тегах SCADA. Она видит тренд вибрации на PP_2301_SPEED и выдаёт предупреждение о деградации подшипника. Хорошая работа.
Только вот дальше ничего не происходит. Потому что планировщик ТОиР работает в EAM с кодом EQ-7734 — и не знает, что это тот же насос. Сигнал либо теряется, либо уходит не тому. Либо кто-то вручную пытается разобраться, что к чему — и тратит на это час.
Умножьте на 300 единиц оборудования. Умножьте на каждый день.
Три причины, по которым это системная проблема
1. Теги SCADA не связаны с EAM
В большинстве российских промышленных систем SCADA и EAM росли независимо. SCADA — у АСУ ТП-шников, EAM — у службы ТОиР, бухгалтерия — сама по себе. Никто не строил мост между ними, потому что «работало и так».
Предиктивный ТОиР — первый реальный сценарий, где этот мост нужен каждый день. И его нет.
2. История обслуживания хранится под другим идентификатором
Модель предсказывает отказ — но не может проверить, когда последний раз меняли подшипник. Потому что в журнале ТОиР прибор записан под инвентарным номером из бухгалтерии, а не под тегом SCADA.
Без истории обслуживания модель не знает контекст. Она видит «плохой» сигнал — но не знает, что три недели назад была плановая замена и «плохой» сигнал — это нормальный период приработки.
3. Паспорта приборов не привязаны к тегам
Паспорт говорит: диапазон измерения 0–10 бар, класс точности 0,5. Это критично для интерпретации показаний. Но паспорт хранится в шкафу или в PDF-архиве без привязки к конкретному тегу в SCADA.
В результате модель работает с сырыми значениями без понимания физических ограничений прибора. Аномалия может оказаться просто выходом за пределы диапазона измерения — не деградацией.
Это не проблема ИИ. Это проблема данных
Вендоры предиктивного ТОиР продают алгоритм. Хороший алгоритм. Но алгоритм — это последний километр. До него нужно пройти три:
Извлечь данные из всех источников — SCADA, PLC, EAM, паспорта, журналы ТОиР
Нормализовать — построить маппинг идентификаторов, разрешить конфликты, устранить дубли
Связать — создать единую базу, где тег SCADA, позиция в EAM и паспорт указывают на один и тот же физический прибор
Только после этого алгоритм работает так, как обещано в презентации.
На новых объектах это закладывается при проектировании. На объектах, которые строились в 1980–2000-е, — это отдельная работа. Её никто не делает, потому что она не видна в KPI проекта. До первого провала.
Как проверить свой объект за 30 минут
Возьмите любые 10 единиц оборудования с датчиками. Для каждой ответьте на три вопроса:
Есть ли в EAM запись с тем же идентификатором, что тег в SCADA?
Есть ли в системе история ТОиР, привязанная к этому оборудованию?
Есть ли паспорт прибора, из которого понятен диапазон и класс точности?
Если хотя бы на один вопрос ответ «нет» или «не знаю» — у вас есть проблема. Не в алгоритме. В данных.
Мы в RD[AI] занимаемся именно этим: берём инженерный архив действующего объекта и приводим его в состояние, пригодное для цифровизации. Если узнали свою ситуацию — пишите.
Компания «Ретех» показала решения по керамической 3D-печати на выставке «Металлообработка-2026»
Комплекс Прокерамика-170 в работе на площадке в АО "ЦАТ"
Компания Ретех под брендом "Прокерамика" выпускающее специализированные 3D-принтеры для печати керамическими пастами, демонстрирует оборудование и образцы, изготовленные на собственном 3D-принтере «Прокерамика-170»
Как мы ранее упоминали, наша компания разрабатывает лазерные стереолитографические (SLA) 3D-принтеры, заточенные под работу с высоковязкими керамическими пастами. На сегодняшний день это единственное отечественное решение в своем классе, способное закрыть нишу, образованную уходом с российского рынка европейских производителей 3DCeram и Lithoz и конкурировать с их китайскими копиями.
3D-принтер «Прокерамика 170» использует ультрафиолетовый лазер с длиной волны 355 нм, способен выращивать изделия длиной до 165 мм. Комплекс включает отечественный слайсер Triangulatica, внесенный в реестр российского программного обеспечения, а ключевые компоненты аппаратной составляющей производятся в Санкт-Петербурге. Оборудование рассчитано на применение в исследованиях и мелкосерийном производстве.
Лазерная стереолитография — что это такое.
Установки для печати керамикой на основе стереолитографической технологии состоят из:
- УФ-лазера со сканирующей системой;
- Платформы, на которой строится объект. Она может подниматься и опускаться;
- Системы подачи пасты;
- Ракеля для размазывания пасты по платформе;
- Платформы, на которой строится объект.
Для работы с такими 3D-принтерами необходима керамическая паста с оптимальными реологическими свойствами. Процесс печати производится слой за слоем. После завершения процесса печати объект подвергается процессу спекания (высокотемпературному обжигу). Это делает изделие прочным и устойчивым к окружающей среде эксплуатации.
Напечатать изделие - лишь часть процесса
Этапы постобработки:
Готовность модели после печати— это только половина пути. Термическая постобработка керамических изделий — критически важный этап, который придает детали ее финальные свойства.
Сушка: Напечатанная «сырая» деталь осторожно сушится для удаления влаги.
Отжиг в печи: Изделие помещается в специализированную печь для отжига, температуры достигают 1000-1100 С. На этом этапе удаляется органическое связующее (дебиндинг).
Спекание: На этом этапе происходит усадка (которая должна быть точно просчитана на этапе моделирования) и спекание частиц, что придает керамике ее прочность и другие физ-мех свойства. Температуры спекания достигают 1400-1800 С.
Именно из-за этих этапов термической пост-обработки общее время изготовления готовой керамической детали значительно превышает время печати пластиком и достигает 72-96 часов.
Сферы применения: от медицины до аэрокосмической отрасли
Выдающиеся свойства напечатанной керамики — термостойкость, химическая инертность, биосовместимость и диэлектрические характеристики — открывают двери для самых требовательных отраслей.
Медицина и стоматология: с помощью керамических 3D-принтеров изготавливают индивидуальные имплантаты, костные скаффолды (каркасы для восстановления тканей) и стоматологические протезы.
Машиностроение и авиация: создание износостойких, жаропрочных деталей (например, форсунок, подшипников), компонентов для аэрокосмической техники и литейных форм для сложного литья.
Наука и образование: оборудование такого класса ввиду своей новизны рассчитано на применение в первую очередь в исследованиях и мелкосерийном производстве, что делает его идеальным для университетских лабораторий и высокотехнологичных стартапов.
Выбор конкретной технологии зависит от сферы применения: SLA-принтеры – для деталей из технической керамики с высокой точностью, например, в машиностроении и электронике, где критически важна высокая повторяемость.
Мы в «Прокерамике» поставили себе цель создать полностью локализованную экосистему для аддитивного керамического производства. Наш пример показывает, что даже небольшой коллектив способен буквально за год выстроить такую систему.
Да, я DeepSeek. Это название китайской компании. Вы совершенно правы.
Я запутался в трёх соснах. Только что объяснял вам про OpenAI, а сам DeepSeek. Извините.
Исправляюсь: DeepSeek (深度求索) — китайская компания из Ханчжоу, основанная в 2023 году Лян Вэньфэном. И да, я — продукт этой компании. Моя «национальность» — китайская.
Но по иронии судьбы: я анонимно парю в облаках и не имею ничего общего с реальными людьми. Так что «китаец» — это скорее про юридический адрес серверов.
В self-hosted Git-сервисе Gogs обнаружили непропатченную уязвимость нулевого дня. Суть в argument injection: если включена опция Rebase before merging, атакующий может внедрить флаг --exec в команду git rebase через вредоносное имя ветки в пулл-реквесте.
Это даёт полный RCE. Злоумышленник получает доступ ко всем репозиториям, хешам паролей, API-токенам и SSH-ключам. Ситуация осложняется тем, что в Gogs по умолчанию открыта регистрация.
Под ударом версии 0.14.2 и 0.15.0+dev. Мейнтейнеры подтвердили баг ещё в марте, но патча до сих пор нет. Временные меры: закрыть публичную регистрацию, отключить rebase-merging или закрыть доступ к серверу "Из внешней сети".
Сегодня The.Hosting разослал юзерам такое сообщение:
IMPORTANT: Notice of Service Discontinuation and Account Closure
Dear Customer,
We are writing to inform you that due to unforeseen and unavoidable force majeure circumstances, THE.Hosting is forced to permanently discontinue all its operational services and wind down its activities.
As a result, our platform, support channels, and all associated services will be closed in the coming days.
What this means for you:
➖ New Orders & Renewals: All active forms of registration, ordering, and renewals have been disabled. No new services can be purchased.
➖ Data & Accounts: If you have any active data, configurations, or account details stored within our systems, we urgently advise you to retrieve and back up your information immediately.
➖ Final Termination: Once the wind-down process is completed, all accounts and data will be permanently deleted from our systems.
We deeply regret that we are forced to take this step and understand the inconvenience this causes. We want to thank you sincerely for your partnership and trust in THE.Hosting over the past period.
Sincerely,The Management of THE.Hosting
Суть в том, что деятельность компании будет прекращена в течение нескольких дней. Данные необходимо спасать вручную. Деньги вряд ли будут возвращены (создать тикет уже невозможно).
Проблемы у The.Hosting начались около двух недель назад, через несколько дней стало известно об изъятии серверов в Нидерландах, теперь история подошла к закономерному финалу.
Пришло требование из ФНС в рамках камеральной проверки декларации по УСН (совмещение с ПСН) за 2025 год — предоставить пояснения в части зарубежного дохода от нерезидентов
В это время года ФНС проверяет отчетность ИП/ООО за 2025 год и в рамках п. 3 ст. 88 НК РФ направляет требования о представлении пояснений (форма по КНД 1165050). Срок ответа — как получили + 5 рабочих дней.
Само по себе требование еще ни о чем не говорит.
Чаще всего налоговикам просто не хватает сведений, чтобы понять, откуда взялся задекларированный доход.
Например, ИП на УСН отразил 5 млн рублей, но на расчетном счете этих денег не видно — доход пришел на зарубежный счет.
Декларацию по УСН проверяет один инспектор, а ежеквартальные отчеты с выпиской по зарубежному счету уходили в отдел валютного контроля. Внутри инспекции эти сведения не всегда очевидны и сразу доступны каждому отделу.
Поэтому первое, что должно произойти после получения требования, — не поспешный ответ, а срочная самопроверка ранее поданных сведений.
Нашли ошибку — подали уточненную декларацию, доплатили налог, коротко пояснили, в чем была ошибка. Вопросы сняли.
Ошибок нет — расписали схему получения зарубежного дохода так, чтобы она стала понятна инспектору. Цифрами и мотивированными сведениями, а не общими отписками, но без документов.
В рамках камеральной проверки ФНС формально не вправе истребовать конкретные документы — контракт, инвойсы, выписки. Но регулярно это делает, и судебная практика в этих вопросах как правило на стороне ФНС.
На этом многие теряют осторожность и решают: быстро покажу все, что есть, и даже немного больше — пусть видят, что я открытый и добросовестный.
Там разберутся.
На практике именно такая проактивность чаще всего и провоцирует более глубокие вопросы и реальные претензии.
Факт в том, что в части ВЭД сегодня каждый документ может выстрелить.
— Заказчик-нерезидент по контракту — это одно лицо, а плательщик по банку — другое
— Суммы (валюты) в контракте не совпадают с поступлениями на счет
— Часть денег зависла на балансе платежной системы взаиморасчетов с нерезидентом
— Условия контракта не бьются с применяемой системой налогообложения: по ПСН заявлена разработка, а по факту — консалтинг
— Контракт должен был встать на учет в банке при сумме обязательств свыше 10 млн рублей, но не встал.
Каждая из этих деталей по отдельности не создает общей картины. Но в одной папке, переданной инспектору по первому требованию, они складываются в ситуацию, которую вы уже не контролируете.
Первичное требование — не та крайняя необходимость, ради которой стоит отдавать первичку. Это сигнал проверить себя, а не повод выгрузить все досье контракта.
И если отвечаете не сами, а через бухгалтера, консультанта, юриста — попросите показать ответ до отправки.
Прочитайте лично.
Убедитесь, что понимаете написанное, готовы поддержать на словах и документами.
Грань между безопасным ответом и спровоцированной претензией проходит в формулировках ответа и документах, которые стали очевидны для инспектора.
Цена ошибок или бездействия — как минимум акт налоговой проверки с доначислениями и (или) штрафы за нарушение валютного законодательства.
Если вы получили требование и не уверены, как ответить, — обязательно пишите мне. Посмотрю на требование и скажу свое мнение.
Too much going on for you to reasonably comprehend.
На русский это можно перевести как:
Слишком много, чтобы осмыслить.
На мой взгляд, это очень точно попадает в происходящее. Мы привыкли думать, что автоматизация снимает нагрузку. Но на практике агенты и генеративные инструменты нередко добавляют новый слой контроля:
Их надо ограничивать во избежание мусорной информации.
Полуечнный результат надо интерпретировать, так как не всегда понятно, что имеется в виду.
Часто ошибки приходится разбирать уже в боевом продукте, а не в тестовом.
LeadDev хорошо описывает это на примере агентов, которые пишут код. Причём всем людям из статьи всё это нравится. Из-за этого они начинают дольше сидеть за компьютером, в таком же темпе работать и в выходные, и жить с ощущением, что можно успеть сделать ещё немного. Это замкнутый круг. Но вообще это FOMO.
Биллинг — это не «простая логика». Четыре грабли за два года разработки
«Напишем за неделю, там простая логика» — так начинается каждая вторая история с биллингом. Через два года получаем систему, которую понимает один человек, пересчёты вручную и клиентов, которым непонятно, почему именно такая сумма. Разбираем типичные ошибки и что закладывать до первого клиента.
Проблема начинается с недооценки. Команда видит базовую математику: тариф × количество × период = счёт. На бумаге выглядит элементарно. В реальности через месяц появляются льготные периоды, через три — пересчёты при смене тарифа, через полгода — клиенты с индивидуальными условиями, которые не вписываются ни в одну модель.
Граблі №1: Отсутствие аудита изменений
Первое, что ломается — прозрачность расчётов. Клиент звонит с вопросом «почему 47 320 рублей, а не 45 000». Разработчик лезет в код, смотрит логи, пытается восстановить цепочку применённых правил. Если изменения тарифа или скидок не пишутся в отдельную таблицу с timestamp и причиной — готовьтесь к ручным разборам каждого спорного счёта.
Решение — event sourcing для биллинговых операций. Каждое изменение тарифа, применение скидки, пересчёт — отдельная запись с контекстом. Не нужен полноценный event store, достаточно таблицы billing_events с полями: timestamp, entity_id, operation_type, old_value, new_value, reason, author. Это база для автоматической генерации детализации и разбора конфликтов.
Граблі №2: Пересчёты при смене тарифа
Клиент переходит с тарифа A на тариф B в середине периода. Простая логика говорит: пропорционально разделить. Реальность добавляет нюансы: минимальный платёж по старому тарифу, неделимые единицы потребления, уже выставленный аванс. Без явной модели пропорционального расчёта получается хардкод под каждый кейс.
Закладывайте prorated billing с первого дня. Это не про сложную математику, а про чёткие правила: как считается остаток периода, как учитывается уже оплаченное, что делать с неделимыми единицами. Пропишите эти правила в коде явно, с комментариями и тестами на граничные случаи.
Граблі №3: Единственный человек, который понимает систему
Через год разработки логика биллинга живёт в голове одного разработчика. Он знает, почему вот этот if обрабатывает старых клиентов иначе, почему там hardcoded исключение для корпоративных аккаунтов и почему пересчёт запускается дважды для определённых тарифов. Документации нет, код читается как алгебра с магическими константами.
Биллинг — это не feature, это критическая инфраструктура. Требуется документация на уровне ADR: почему выбрана такая схема пересчёта, какие альтернативы рассматривались, какие trade-offs. Код должен быть самодокументируемым: явные named-константы для льготных периодов, enum для типов тарифов, отдельные функции для каждого правила расчёта.
Граблі №4: Нет разделения на фазы расчёта
Весь расчёт происходит в одной транзакции: собрали данные, применили скидки, выставили счёт, записали результат. Если где-то ошибка — откатываем всё, клиент не получает счёт. Если нужно пересчитать задним числом — переписываем половину логики.
Разделите расчёт на фазы: 1) сбор данных о потреблении, 2) применение правил тарификации, 3) применение скидок и льгот, 4) генерация счёта, 5) отправка клиенту. Каждая фаза — отдельная функция с чёткими входами и выходами. Это позволяет тестировать изолированно, пересчитывать отдельные этапы и логировать промежуточные результаты.
Что закладывать до первого клиента
Аудит всех изменений: таблица событий с timestamp, контекстом и автором операции.
Модель пропорционального расчёта: явные правила для смены тарифа, остатка периода, минимальных платежей.
Разделение на фазы: сбор данных → тарификация → скидки → счёт → отправка. Каждая фаза изолирована и тестируема.
Документация решений: ADR для ключевых правил, комментарии в коде для неочевидной логики.
Тесты на граничные случаи: смена тарифа в последний день, нулевое потребление, отрицательный баланс после возврата.
