Kurgan-Telecom Ru | Информационные технологии

Открываю экспериментальный цикл уменьшенного формата в личном блоге на Хабре.

Здесь не будет исторически-ностальгических прелюдий и рефлексии «кому и зачем это нужно». Просто небольшие истории спонтанно-рутинного решения той или иной практической задачи. Например, оживление ретро-техники, исследование её внутреннего устройства, а также создание самоделок. Одним словом, какая-то техническая возня («техновоз»), не особо приглядная, не имеющая глубокого смысла, но по своему увлекательная.

В свой первый рейс техновоз привёз мне китайскую портативную 16-битную Сегу с занимательной родословной. Даже две штуки, и обе потребовали некоторых приседаний перед их помещением в коллекцию.

Мы живем в эпоху, когда ИИ стал доступен каждому. Но за магией PyTorch скрывается колоссальная инженерная работа и сложные вычислительные процессы, которые для большинства остаются черным ящиком. 

Это четвертая статья из цикла От MNIST к Transformer, цель которого пошагово пройти путь от простого CUDA ядра до создания архитектуры Transformer - фундамента современных LLM моделей. Мы не будем использовать готовые высокоуровневые библиотеки. Мы будем разбирать, как все устроено под капотом, и пересобирать их ключевые механизмы своими руками на самом низком уровне. Только так можно по настоящему понять как работают LLM и что за этим стоит. В этой статье мы разберем как работает градиентный спуск, реализуем его и обучим нашу модель для распознования mnist датасета.

Приготовьтесь, будет много кода на C++ и CUDA, работы с памятью и погружения в архитектуру GPU. И конечно же математика что за этим стоит. Поехали!

Эта статья представляет собой дальнейшее развитие нашей предыдущей статьи, только здесь всё будет на 20 % круче. Мы полностью вынесем функциональность базовой станции на отдельный ПК, возьмём более мощное железо для ядра сети, а также развернём другой open source-стек для радиочасти. В общем, сделаем шаг вперёд и попробуем перейти от демонстратора идеи к тестовому стенду 5G. В этой статье вас ждут:

Установка ядра с низкой задержкой.

Установка DataPlane Development Kit (DPDK).

Установка драйвера UHD из исходных кодов.

Подключение USRP X310 к CU/DU с применением DPDK.

Развёртывание OpenAirInterface и подключение gNodeB к ядру сети.

Некоторое время назад я рассказывал, как у меня появилась гипотеза об устройстве мира, которую я оформил в качестве Теории Вибрационно-Энергетического Резонансного Континуума (ТВЭРК) https://habr.com/ru/articles/1013386/.

Сегодня я выпустил Второе издание монографии, в котором постарался максимально убрать все белые пятна и неточности предыдущей версии. И по моему мне это удалось.

Конечно вы наверняка найдёте в моей теории ошибки. Она не идеальна. Идеально может сделать только Бог, а я не он. Я просто независимый исследователь, который стремится объяснить устройство мира простым способом, без придумывания лишних сущностей. У меня нет никакого финансирования, я делаю всё это один.

Хочу также сказать огромное спасибо Хабру и его пользователям, за адекватную критику! Мне это действительно очень помогло!

Здравствуйте всем, я – менеджер продукта в компании «СИБИНТЕК». Если вы решите изучать Agile‑подходы самостоятельно или запишитесь на тренинг, то рано или поздно столкнетесь с фреймворком Кеневин (Cynefin). Он, как и фреймворк Scrum, прост в понимании и достаточно сложен для совершенного овладения. Но, возможно, это как закон тяготения Ньютона: вы его не применяете в повседневной жизни, а просто действуете соразмерно этому закону. Кстати, «cynefin» – валлийское слово, которое переводится как «среда обитания».

Уэльское происхождение названия фреймворка не удивительно. Его разработчик – шотландец. Кеневин создали для руководителей и специалистов: он помогает выбрать подходы к принятию решений для задач различного уровня сложности. Давайте заглянем в мир Кеневин, которому уже более 25 лет.

Автор фреймворка предполагает в своей модели, что реальный мир вокруг нас – это множество взаимосвязанных систем, в которых действуют различные агенты‑модуляторы: люди, компании, регламенты, процессы, события и др., которые постоянно взаимодействуют между собой. Количество и характер их взаимодействий определяет сложность каждой из систем. Все эти системы автор делит на четыре типа (домена): упорядоченные простые, упорядоченные сложные, комплексные и хаотические. В каждом из этих доменов предлагается своя модель принятия решений. Нужно сразу сказать, что Кеневин – это не столько категоризационная, сколько смыслообразующая модель. Это аналитический фреймворк.

Завершив в прошлой публикации обсуждение этапа развития разума на уровне индивидов, сегодня мы перейдём на следующую ступеньку - интеллект сообщества организмов как целого, то есть, коллективный разум. Мы пробежимся от муравейников и первых небольших коллективов наших далёких предков до ранних цивилизаций шумеров и египтян.

Привет. Делаю расширение для VS Code, которое даёт OpenCode CLI полноценный графический интерфейс. Называется PrimeCode.

Суть простая: OpenCode — мощный CLI-агент, но работать с ним в терминале на длинных сессиях не всегда удобно. Хотелось нормально видеть, что происходит — tool calls, изменения файлов, контекст, токены. Не форк, не отдельный продукт — именно UI-слой поверх OpenCode, который общается с ним через SDK и SSE-стриминг.

Если вы уже работаете с OpenCode и у вас есть существующие сессии — можно продолжить работу с ними прямо через расширение. Вся история, контекст, tool calls — всё подхватывается.

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

Недавно в дополнение к самому быстрому и оптимальному мы добавили ещё один вид маршрута — «лёгкий маршрут», наименее стрессовый для водителя. Минимум сложных перекрёстков, поворотов налево и перестроений. 

В статье рассказываем, как мы строим легкий маршрут и как он вписывается в текущую архитектуру маршрутизации.

Сразу сделаю чистосердечное признание: я ручной тестировщик. Я не умею писать код с закрытыми глазами, и да — эту статью мне тоже помог структурировать ИИ по моим промптам. Зато я умею декомпозировать задачи, выстраивать логику продукта и ломать то, что уже написано.

Меня бесила ситуация, когда я не могу подобрать себе фильм для просмотра. Обычно, у фильмов только скудное описание и рейтинг. Чтобы посмотреть трейлер нужно умудриться его найти. Да, можно прочитать отзывы, но там в основном рецензии на пару минут чтения

Я решил, что мне нужен инструмент, который превратит выбор фильма из рутины в развлечение. Бюджет — 0 рублей. Команда — я и нейросеть (Gemini 3.1 Pro).

В IT сейчас активно спорят про «вайбкодинг». Кто-то считает это абсолютным злом и костылестроением, кто-то — неизбежным будущим. Я решил проверить этот подход на практике и за выходные собрал MVP своего сервиса.

Меня зовут Дмитрий, я руковожу отделом ИТ-инфраструктуры и сервисов в Ви.Tech, IT-дочке ВсеИнструменты.ру. В предыдущих частях я рассказывал про P&L-центры, ценообразование, учет ресурсов и планирование бюджета, а теперь хочу перейти к самой чувствительной части всей этой истории - оптимизации потребления.

Здесь уже недостаточно просто собрать цифры в отчет. Нужно понять, где ресурсы реально тратятся неэффективно, что с этим можно сделать без вреда для сервисов и с какими организационными проблемами мы почти наверняка столкнемся по дороге.

Меня зовут Дмитрий, я руковожу отделом ИТ-инфраструктуры и сервисов в Ви.Tech, IT-дочке ВсеИнструменты.ру. В прошлой части я рассказывал, как мы собираем и считаем потребление вычислительных ресурсов, а теперь хочу перейти к следующему шагу - планированию ИТ-бюджета на базе этих данных.

Для этого я обычно использую два дополняющих друг друга подхода:

Меня зовут Дмитрий, я руковожу отделом ИТ-инфраструктуры и сервисов в Ви.Tech, IT-дочке ВсеИнструменты.ру. В прошлой части я подробно разбирал ценообразование вычислительных ресурсов, а теперь давайте соберем все это в единую модель учета и посмотрим, как она помогает не просто считать цифры, а принимать вполне прикладные решения.

Ниже пройдемся по основным блокам, из которых этот учет складывается.

1. Отдельно стоящее оборудование

Поскольку мы планируем учитывать расходы за месяц, то стоимость покупки оборудования нам также надо привести к месячным затратам. Для этого воспользуемся амортизацией, а именно определим ее срок и тип и посчитаем ежемесячную стоимость, исходя из этого. Для примера возьмем линейную амортизацию сроком на 5 лет (60 месяцев), тогда ежемесячная стоимость отдельно стоящего оборудования будет:

HW_month_price = HW_price / 60

При этом:

Сталкивались уже с EvaTeam (российский аналог Jira)? Чувствуете боль при работе с бизнес-процессами (workflow)? Думаю я могу вам немного помочь

или как уместить Вселенную в iPhone, не привлекая внимания санитаров

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

Автор проекта «ЭХО» взял и убрал всё лишнее. Без предупреждения, без RFC, без голосования в команде. Остался минимальный Linux, один бинарник на Go и файловая система — всё остальное полетело в мусор вместе с базами данных, фреймворками и «чёрными ящиками» с гарантией на три года. Получилась система на 250 миллионов анкет, которая работает на обычном пользовательском компьютере и не требует звонить в поддержку AWS в два часа ночи.

Но 250 миллионов — это как-то мелко, правда? Давайте замахнёмся на Вселенную. Ну или хотя бы на Млечный Путь для начала.

Проблема не в том, что инструментов мало. Проблема в том, что большинство из них построены вокруг браузера прошлого поколения, тогда как frontend уже давно живёт внутри runtime. Именно из этой практической боли появился собственный runtime-инспектор — сначала как консольный скрипт для одной конкретной задачи, а затем как полноценный инструмент, который неожиданно нашел отклик у QA и разработчиков.

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

И так как их много, а меня — мало, делать что-то предстояло мне. Teams и прочие платформы, конечно, имеют опции на такой случай, но не просить же включать запись каждый раз.

Получилась небольшая программа, которая берёт воспроизводимый звуковой поток, делит его на фразы, через whisper распознаёт в указанный язык (проверял русский, английский, французский) и переводит.

Мы разработали приложение, где пользователь может свайпать картинки, и с учетом лайков пользователя мы генерируем новые картинки. Ниже рассказ, с чем интересным мы столкнулись во время разработки этого приложения.

История такова. Бродил я на Хабре и увидел сей опус:

«Как я пытался трудоустроиться в Яндекс в 2026»

Где разраба с 20 летним опытом нагрели, как ребенка.

Ситуация типовая. И когда людей «едят», используют, эксплуатируют их ресурс/время/энергию/деньги/пэм ресурс и так далее. И они этого в упор не видят. Таких ситуаций множество. Да только разраб кажется умным. Есть ожидание, что он интеллектуален и может в математику. И так и есть скорее всего, но базовая, минимальная теория игр+ здравый смысл, к сожалению, обошли его стороной.

Потери могут быть небольшими, могут быть значительными. Это не главное, главное отличать одно от другого.

UseCase - как организовать своё приложение с точки зрения бизнес-процессов, чтобы не погрязнуть в хаосе сервисов, контроллеров и разрозненной логики.

Вы наверняка видели те самые видео: «Все секреты промптинга за 4 часа», «Идеальный промпт для Midjourney», «Как научиться разговаривать с нейросетями». Я тоже их смотрел. Сохранял в закладки, записывал советы, искал тот самый файл с рабочими формулировками, который куда‑то завалился.

А потом понял: вместо того чтобы учиться общаться с ИИ, можно просто сделать себе личного промпт‑инженера, который уже всё знает. И для этого даже не нужно настраивать сложные агенты или платить за API.