Groq молча выпилил модель, и парсер 6 дней не сохранял вакансии: уроки жизни на бесплатных LLM

Работа с LLM в разработке на бесплатных тарифах выглядит как халява ровно до того утра, когда модель, на которой всё держится, просто перестаёт существовать. У меня так и вышло: 18 июля 2026 Groq тихо убрал модель llama-4-scout из бесплатного доступа, и мой парсер вакансий 6 дней молча падал с ошибкой 404 model_not_found. Никто не орал, графики не краснели - вакансии просто перестали сохраняться. Разбираю, как так вышло, почему сторож всё проспал и что с этим делать, если вы тоже живёте на чужих бесплатных моделях.

Что произошло: Groq молча выпилил бесплатную модель

Groq снял модель llama-4-scout с бесплатного тарифа, и с 18 июля 2026, 07:51, каждый запрос на извлечение вакансии возвращал 404 model_not_found. Парсер честно ходил в API, честно получал отлуп и шёл дальше - без вакансий. Простой длился 6 дней, до 24 июля, и всё это время сервис снаружи был совершенно жив.

Чтобы было понятно, что вообще сломалось. У меня есть парсер вакансий из телеграм-каналов: он берёт посты из десятков каналов и через LLM вытаскивает из них структуру - должность, зарплатную вилку, стек, контакты. Groq тут стоял как бесплатный движок для этого извлечения. Красивая схема, пока движок на месте.

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

Почему сторож всё проспал: вотчер, который следил сам за собой

Watchdog - это отдельный процесс, который проверяет, что парсер жив, и должен был поймать шестидневную тишину. Не поймал по глупейшей причине: он искал живой процесс через pgrep -f, а pgrep находил сам себя - собственную командную строку с этим же паттерном внутри. Сторож видел "кто-то по этому шаблону есть" и спокойно шёл спать.

Это классические грабли pgrep -f: он матчит по всей командной строке, и строка самого pgrep (вместе с искомым паттерном) тоже попадает под совпадение. Получается self-match - процесс находит себя и радостно репортит, что цель жива. Лечится либо точным совпадением по имени через pgrep -x, либо якорем в регулярке вроде ^имя$, чтобы собственный аргумент не считался. У меня вотчер был написан наивно, поэтому он всю неделю честно сторожил пустое место и докладывал, что всё хорошо.

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

model_not_found - это не сбой, а похороны модели

model_not_found (404) - это не временный сетевой сбой, а сигнал, что модель убрали навсегда. Ретраи, бэкоффы и "подождём, само поднимется" тут не помогут: поднимать нечего. И в этом главная ловушка - код ошибки выглядит как обычная пятисотка-подруга, а на деле это некролог.

Самое обидное - предупреждение было. Groq официально анонсировал депрекейт llama-4-scout ещё 17 июня 2026, с датой отключения 17 июля 2026, и разослал письма всем затронутым (см. список депрекейтов Groq). То есть модель не "внезапно" умерла - у меня был почти месяц. Просто на бесплатном и developer-тарифе это так и устроено: письмо на почту, пара месяцев жизни, потом 404. Enterprise-клиентов с обязательствами по спенду эти отключения не касаются вовсе. А на халяве ты сам себе SRE: не прочитал рассылку вовремя - ловишь тишину на проде.

Фикс: ротация моделей вместо одной захардкоженной

Сам фикс занял меньше вечера. Выкинул мёртвые llama-4 из ротации, поднял приоритет llama-3.3-70b-versatile, прогнал тестовое извлечение - 0.66 секунды, вилка и требования распарсились корректно. Всё, парсер снова видит вакансии.

Но вот где меня отрезвило. У llama-3.3-70b-versatile, которой я только что заткнул дыру, своя дата отключения - 16 августа 2026. То есть модель, ставшая спасением, сама уже на смертном одре, и через месяц спектакль повторится. Groq рекомендует переезжать на openai/gpt-oss-120b или qwen/qwen3.6-27b, но суть не в том, какую именно модель вписать. Суть в том, что любой пункт этого списка смертен.

Поэтому вывод не "перееду на модель поновее", а "ротация моделей - это не разовый фикс, а постоянная гигиена". В конфиге лежит список приоритетов, воркер идёт по нему сверху вниз, а мёртвую модель я просто вычёркиваю, не трогая код. Один захардкоженный идентификатор модели - мина замедленного действия с таймером от провайдера.

Бэкфилл недели: 631 сообщение, 257 вакансий и один забытый сервис

За шесть дней тишины накопился завал - 631 сообщение из 37 каналов. Я прогнал бэкфилл на живой уже модели: 257 вакансий сохранено, 138 дублей обновлено, и ровно одна ошибка на всю пачку - AI перепутала местами зарплатную вилку, поставила нижнюю границу вверх, а верхнюю вниз. На фоне 257 корректных разборов - терпимо, но в проде такое ловится только глазами.

И бытовой грабль на сдачу. На время бэкфилла парсер останавливали, чтобы он не дрался с массовым прогоном за одни и те же посты. А дальше классика: остановленный сервис легко забыть включить обратно. Пришлось заводить отдельную задачу-напоминалку "не забудь поднять парсер", иначе я бы сам себе устроил второй тихий простой, уже руками. Звучит смешно, а по граблям - ровно тот же сценарий забытого сервиса, что и с моделью.

Что забрать, если вы живёте на бесплатных LLM

Первое - у бесплатных провайдеров модели смертны, и планировать надо ротацию в конфиге, а не хардкод одной модели. Список приоритетов + вычёркивание мёртвых стоит один вечер, а спасает от шестидневных простоев.

Второе, и это ключевое - алерт вешайте именно на model_not_found и 404 от воркера, а не на общий healthcheck в духе "сервис отвечает". Мой сервис всю неделю прекрасно отвечал, просто отвечал пустотой. Общая проверка живости такое не ловит по определению - нужен сигнал на конкретный код ошибки от того куска, который реально ходит в LLM.

Третье - следите за changelog и рассылками провайдера, но не полагайтесь на то, что письмо про депрекейт вы прочитаете вовремя. У меня письмо было, а простой всё равно случился. Алерт на 404 надёжнее вашей почтовой дисциплины.

И четвёртое, вечное - проверяйте сам мониторинг. Вотчер, который матчит себя через pgrep -f, опаснее, чем его отсутствие: он рисует зелёную галочку над мёртвым сервисом. Если у вас где-то стоит похожая самодельная сторожилка - сходите и убедитесь, что она сторожит не саму себя.

Кстати, это уже не первый раз, когда LLM подводит меня посреди пайплайна - до этого модель отказывала прямо в процессе, и приходилось падать на резервную. Разные симптомы, вывод один: у чужой модели в основе пайплайна всегда должен быть план Б.

Такие дела. Пойду проверю, что там ещё по-тихому не отвалилось :)