Привет

Чутка потерялся какой контент делать дальше, поэтому расскажу что есть на душе😘


Придавило работой, в середине мая деплоим банкоматы в прод. Уже были успешные операции пополнения и снятия. Беру на себя больше сырых задач - без аналитики. Дедлайн горит, появляются новые требования от "мексиканского цб". Как релизнем, скину фотку банкомата


В начале года хотели переезжать в Барсу по номаду, но нам отказали в шенгене и в аппелляции, поэтому переезжаем по рабочей визе.

Расскажите что нового у вас

По работе пишу outbox паттерн с поддержкой порядка доставки. Данный паттерн часто спрашивают на интервью. Недавно мой напарник снизил уровень кандидату с сильного мидла до джун+ за поверхностный рассказ этого паттерна 💀

Концепция паттерна - атомарно сохранить данные в бд и отправить их в кафку с помощью следующих двух пунктов

• Инсерт в бизнесовую и outbox таблицы происходит в одной транзакции
• Шедулер поллит outbox и пытается отправить в кафку

Как реализовать второй пункт конкурентно и поддержать порядок:

1) Простой вариант - select for update, для предотвращения race condition, внутри которого отправляем в кафку и пытаемся обновить статус на sent

Минус - держится бд транзакция на отправку в кафку

2) Вариант сложнее - Claim and finalize

Поле claimed_at с текущей датой - индикатор что ивент взят в работу - воркер пытается его отправить(финализировать) вне транзакции и рекавери джоба для сброса claimed_at в null для повторной отправки, работающая по таймауту.


Порядок

У ивентов есть монотонно возрастающий id, если пришел ивент с id=2, но событие с id=1 не отправилось, ивент сохраняется в отдельную таблицу - pending_event, затем джоба пытается перелить этот ивент в outbox.

Здесь есть race condition между консьюмером ивентов и джобой переливающей ивенты - ивент с id=2 может попасть раньше в pending_event и следовательно в outbox. Можно взять pg_advisory_lock по entity id с которым эти ивенты связаны


—————
Немного рефлексии🤔

Удивлен как ai агенты в разы ускоряют разработку такого паттерна, а главное повышают надежность. Агент помог сгенерить тесты на все возможные race condition.

От отрицания переходим к принятию - нейросети заменят меня, нейросети заменят тебя

В универе я учился на информационную безопасность

Мы с другом решили погрузиться в мир нейросетей через матлаб - запустили перцептрон, cкормили первую часть последовательности из 0 и 1 и пытались предсказать продолжение.
Хотели прогнозировать действия хакера при взломе автоматизированной системы. По итогам написали статью в журнале нашего универа.

Я скормил ее чат гпт и он выдал краткое описание статьи🤔

Статья выглядит как:
1) Мы скормили MATLAB бинарные нули и единицы
2) Нейросеть обучилась
3) Все злоумышленники вычислены

Если подумать, то в 2026 году примерно так и выглядит любой AI-стартап:
1) Мы скормили модели бинарные нули и единицы
2) Accuracy вырос после x10 нейронов
3) Ищем инвестиции

Еще в те времена - 2016, было все понятно про AI

P.S За опубликование статьи получили 13к стипендии в течении семестра🥂

Время порекомендовать хорошие каналы разработчиков


• Андрей(@programming_space) работал в майкрософт, устроился в Snowflake, разбирает литкод собесы/дейлики и систем дизайн

• Серега(@sergei_gorlov) работает в плате около двух лет, проводит моки, работали вместе в небезызвестном стартапе ioio 😁

• Ден(@nopanicengineer) недавно залетел в плату, сейчас вкатывается в матан через Khan Academy и Math Academy

На канале добавилось 100+ подписчиков, всех рад видеть❤️. Чутка о себе - работаю в Плате, делаю бэк для банкоматов, недавно заехали в прод. Олег тыкал тестовый банкомат, пополнение отвалилось, но пока не уволили🏆🏆

Летом планирую переезжать в Барселону. В прошлом году был interview loop в aws - ищется по #aws - то с чего начался мой канал

Здесь стараюсь писать интересно о технических вещах и о том как развиваюсь. На данный момент сижу в codecrafters.io, использую mathacademy чтобы прокачивать матан, также начал вкатываться в архитектуру LLM, щупаю этот домен в поисках интересного для себя

Главная цель это канала - общение с людьми и шаринг знаний, опыта и мотивации😘

Напишите в комментах о себе - все чем хотите поделиться

Флаппинг - когда состояние объекта хаотично меняется туда-сюда⌨️. Особенно применимо к банкоматам при мониторинге состояния девайсов. Если задача кинуть алерт на нестабильный девайс можно воспользоваться Prometheus.

Под каждый статус девайса - Error, UserError, FailedInit, Ok, Recovering - заводим временный бинарный ряд, затем через функцию changes смотрим сколько раз за интервал времени менялся статус

- device_status{state="error"} = 0 или 1
- device_status{state="recovering"} = 0 или 1
...

changes(device_status[2m]) > 4 // девайс нестабилен


Но если нам важна семантика перехода - этот переход критичный, а этот нет:

- Recovering → Ok → Recovering → Ok // девайс в петле, поломан, нужно вызывать инженера
- Ok -> Degraded // не критично, достаточно warning

Тут нам понадобится sliding window в виде кольцевого буфера и 2 хэшмапы: freqMap поддерживает переходы и их частоту, transitionToSeverity хранит переход и его критичность, псевдокод:

RingBuffer:
buf[]
index
freqMap
transitionToSeverity // Recovering->Error: Critical, Ok->Degraded: Warning

Append(status):
если буфер не полон:
prev = buf[len(buf) - 1]
buf.append(status)
freqMap[prev->status]++
иначе:
// убираем старый переход
removed = buf[index]
nextFromRemoved = buf[(index+1) % N]
freqMap[removed->nextFromRemoved]--

// добавляем новый
prev = buf[(index-1+N) % N]
freqMap[prev->status]++
buf[index] = status

index = (index+1) % N

IsFlapping(flapThreshold):
// для каждого перехода в freqMap
если переход критичный по transitionToSeverity → алерт
если count >= flapThreshold → алерт

// ищем петлю
loopCount = min(freqMap["error->recovering"], freqMap["recovering->error"])
если loopCount >= 2 → устройство в петле

LLM Inference 🤔
Вопрос в LLM -> ответ на выходе. Делится на два этапа - prefill, decode

Prefill - получение первого output токена и заполнение KV cache. Промпт превращается в токены, токены в эмбеддинг-векторы, затем attention обогащает каждый токен «важностью» относительно остальных. Все токены промпта обрабатываются за один проход, поэтому на каждый прочитанный байт весов приходится много вычислений - GPU загружен, этап compute-bound

Метрика измеряющая Prefill - TTFT (time to first token): время от начала запроса до первого токена

Decode - то как LLM печатает ответ по слову. LLM авторегрессивно(на основе предыдущего токена) генерит токен. На этом этапе активно читаются веса модели, мало вычислений на объем прочитанных данных - gpu простаивает, поэтому этот этап memory-bound.
KV cache - сохранённые векторы K и V каждого обработанного токена. Нужен чтобы на каждом шаге decode не пересчитывать предыдущие токены заново

Метрика для decode, TPOT - time per output token

———————————
Я запустил Naive(без оптимизаций) vs vLLM на RunPod для измерения TTFT, TPOT и GPU-метрик

Пропускная способность (64 запроса)
              tok/s
  Naive        420
  vLLM        2475   (6x)

Скорость ответа(p50)
              TTFT     TPOT
  Naive       158мс    148мс
  vLLM        206мс     20мс

GPU-метрики
          GPU%   Mem%   VRAM(MiB)
  Naive
           26     20      15028
           80     76      15030
           57     54      15106
  vLLM
          100    100      22274
          100    100      22274
          100    100      22274

Memory util - насколько занята шина, передающая данные VRAM -> SM

Как видно TPOT у vLLM ниже в 7 раз из-за continuous batching - новые output токены генерируются одновременно в рамках батча, что убирает ожидание, также данная оптимизация помогает держать arithmetic intensity на GPU при decode, что не дает GPU простаивать - загруженность 100%

TTFT стал хуже. Он и так растёт с числом запросов, но continuous batching усугубляет: decode забирает token budget (лимит токенов на шаг) первым, на prefill новых запросов остается мало - они ждут очереди, первый токен задерживается

С памятью работает PagedAttention - идея из виртуальной памяти ОС. KV cache делится на блоки фиксированного размера, таблица блоков сопоставляет логические физическим. Нет фрагментации, значит в ту же VRAM влезает больше запросов -> больше батч
Отсюда и константа 22274 MiB в метриках: резервация памяти просходит сразу на старте. У naive память ползёт вверх (15028 -> 15106) - аллокация по ходу запросов