TMPDIR и политика повторов при сбоях.
Оглавление: узкие места · матрица · батч и буфер · исполняемые переменные · приёмка удалённого узла · шесть шагов · выводы · FAQ
Материал сознательно отделён от линии «текстовый LLM и маршрутизация» и от линии «векторный поиск». В мультимодельном роутинге вы балансируете политики батча, ключи моделей и долю трафика; в векторном индексе — размер батча эмбеддингов, потоки импорта и ANN-движок. Здесь же главный артефакт — дискретизированная волна и сквозная задержка аудиотракта: пик памяти на батче, p95 «хвоста» после окончания фразы, объём декодированного кэша и стабильность голосового I/O под нагрузкой. Текстовый контур на MLX-LM и Transformers полезен как сосед по unified memory, но метрики и runbook другие. Публичные покупка, тарифы и документация доступны без входа.
Три типичные поломки
Первая — в одной очереди смешаны интерактивный диалог и тяжёлый офлайн-батч без учёта длительности звучания и политики back-pressure: кольцевой буфер иссякает, появляются пропуски и переполнения. Вторая — TMPDIR по умолчанию указывает на медленный том или сетевой путь: декодирование и промежуточные волны упираются не в GPU, а в латентность диска. Третья — нет карантина для повреждённых входов: конечные повторы на битом файле многократно перезапускают один и тот же путь и «отравляют» статистику всего батча, пока оператор не отделит bad-артефакты от good.
Матрица решений (MLX Audio и внешняя цепочка)
Таблица не выбирает «победителя» в абстракции, а фиксирует оси компромисса: где выгодно держать вычисление в MLX, а где неизбежны внешние инструменты захвата и транскодирования. Используйте её на ревью архитектуры перед тем как подписать SLO по задержке и по машино-часам на удалённом Mac.
| Измерение | MLX Audio | Цепочка FFmpeg / захват | Практический вывод |
|---|---|---|---|
| Память | Пик по батчу и окну буфера накладывается | Часто лишние копии буфера, труднее читать профиль | Ступенчатый подбор батча в MLX, журнал пика на каждом шаге |
| Голосовой I/O | Выгодна фиксированная дискретизация в контракте модели | Внешний слой захвата и ресемплинга | Мерить сквозные перцентили, не «середину» пайплайна |
| Временные файлы | Чувствительна к быстрому тому | То же, плюс промежуточные контейнеры | Явно задать каталог и квоту; идемпотентная уборка между сессиями |
| Удалённый Mac | Ночные батчи и почасовая модель совместимы | SSH и туннели требуют отдельного чек-листа | Длинные батчи — без сна крышки ноутбука; стационарный арендный узел |
Батч-сессии и окно буфера
Внутри одной батч-сессии разумно разделять загрузку весов и общие гиперпараметры — в том числе целевую частоту дискретизации и схему каналов — чтобы не плодить скрытое ресемплирование между стендами. Размер батча наращивайте дискретно (например 1→2→4→8): на каждом уровне фиксируйте пик резидентной памяти, коэффициент реального времени относительно длины аудио и p95 задержки «хвоста» после конца последней реплики в минибатче. Когда кривая изламывается, остановитесь: дальнейший рост обычно покупается непропорциональным свопом или дрожащим интерактивом.
Окно буфера в кольцевой схеме задавайте от самого длинного ожидаемого сегмента плюс запас на джиттер устройства и планировщика — ориентир «длина максимума + 15–25%», затем уточняйте по логам. Голосовой I/O в реальном времени и офлайн-батч-обработка должны жить в разных очередях с разными лимитами глубины: иначе интерактив не удержит SLA, даже если средняя загрузка GPU выглядит комфортной. В мультимодальном сценарии, где рядом крутится текстовый декодер с крупным KV-кэшем, явно разведите пулы по процессам или по окнам времени и продолжайте измерять аудио от микрофона или файла до готового тензора/файла результата, а не только ядро MLX.
Исполняемые параметры: батч, дискретизация, диск, повторы
Имена переменных ниже — контракт для runbook: подставьте фактические ключи вашего раннера или обёртки, но сохраните семантику. Критично, чтобы один и тот же набор экспорта повторялся в CI, на ноутбуке инженера и на удалённом Mac при приёмке.
# Каталог временных и декодированных волн — быстрый локальный том
export TMPDIR="$HOME/Scratch/mlx-audio-wav"
mkdir -p "$TMPDIR"
# Частота дискретизации в герцах (под контракт модели; не повышать «на всякий случай»)
export MLX_AUDIO_SAMPLE_RATE_HZ=16000
# Стартовый размер батча; после профиля — только ступенчато
export MLX_AUDIO_BATCH_SIZE=4
# Конечные повторы только для восстанавливаемых ошибок (сеть, таймаут воркера)
export MLX_AUDIO_MAX_RETRIES=3
# Префикс карантина для битых входов и промежуточных артефактов
export MLX_AUDIO_QUARANTINE_DIR="$TMPDIR/quarantine"
mkdir -p "$MLX_AUDIO_QUARANTINE_DIR"После изменения размера батча или частоты дискретизации пересчитайте ожидаемый объём временных файлов: длинные сессии на высокой частоте и широком батче быстро съедают квоту тома, если уборка не идемпотентна. Повтор при сбое оформите с ограничением попыток и экспоненциальной задержкой; после исчерпания бюджета переносите объект в MLX_AUDIO_QUARANTINE_DIR и пишите ключ в структурированный журнал, чтобы батч не зависал на одном идентификаторе.
Чек-лист приёмки стоимости и качества на удалённом узле
- Машино-часы и биллинг. Выгрузите CSV ночного прогона: интервалы пиковой нагрузки, число параллельных воркеров, ключ тенанта. Сверьте с полями договора (почасовка, минимальный шаг списания) до масштабирования площадки.
- Диск и TMPDIR. Зафиксируйте путь быстрого тома, квоту и политику TTL для кэша волн. Проверьте, что уборка между прогонами не удаляет чужие сессии и что свободное место не уходит в отрицательную область из-за роста батча.
- Реальное время. Для интерактива — верхняя граница полной задержки контура (например целевой RT ниже одной секунды на согласованном перцентиле). Для офлайна — p95 времени обработки на минуту входного аудио и доля таймаутов.
- Отказоустойчивость. Доля успешных повторов в пределах бюджета, отсутствие бесконечных циклов на одном ID, полнота записей о карантине.
- Воспроизводимость. Одна строка «версия весов — частота — батч — TMPDIR — релиз раннера» в каждом отчёте приёмки; без неё сравнение недель бессмысленно.
Шесть оперативных шагов
- Заморозьте аудиобазовую линию: формат, каналы, целевая дискретизация, ревизия весов; запретите скрытое ресемплирование между стендами.
- Назначьте быстрый
TMPDIRи каталог карантина; права только у учётной записи сервиса. - Проведите ступенчатый подбор размера батча с логированием пика памяти и хвоста задержки.
- Зафиксируйте секунды окна буфера и раздельные очереди для диалога и офлайна.
- Подключите конечные повторы при сбое и маршрут в карантин для необрабатываемых входов.
- На выделенном удалённом Mac воспроизведите пиковый сценарий, приложите CSV к акту приёмки и только затем расширяйте пул узлов.
Короткие выводы:
- Произведение размера батча и частоты дискретизации задаёт пик памяти и объём временных файлов — это отдельный договор от текстового KV.
- Окно буфера заказывайте от максимальной длительности сегмента с запасом; уточняйте по продакшен-логам, а не по «дефолту драйвера».
- Удалённый узел ночного soak с машино-часами в том же формате, что биллинг, снимает споры между финансами и инженерией.
FAQ
Это вариация статьи про роутинг LLM? Нет. Роутинг про политики выбора модели и токен-метрики; здесь — волна, голосовой I/O и диск.
Как сочетать с векторным поиском? Держите квоты индекса и аудиокэша в разных бюджетах памяти и диска; см. матрицу движков для retrieval-контура.
Один Mac и текст, и речь. Разводите пулы процессов или окна по времени, иначе конкуренция за unified memory даст ложные регрессии в обоих контурах.
Резюме: ступенчатый батч, явное окно буфера, быстрый TMPDIR и конечные повторы с карантином оформите как контракт; приёмку закрепите на удалённом Mac с CSV машино-часов.