gigastt-pro

Пилот

48 часов на вашем аудио внутри вашего контура

Вы даёте хост и 20–50 своих записей — или mini-suite из поставки. Бинарник и веса ставятся на этот хост, scripts/run_pilot.sh считает WER и RTF на ваших записях. Отчёты pilot-report.md и pilot-report.json остаются у вас: решение принимается по цифрам, не по презентации. Сайт в процедуре не участвует и файлов не принимает. Канон — docs/pilot.md движка.

Путь целиком

От письма до решения — пять шагов

  1. 01

    Письмо

    Организация, контур, ОС и задача — этого хватает для ответа. Формы и личного кабинета нет, письмо читает автор движка.

  2. 02

    Доступ

    Репозиторий открывается по SSH. Если контур без интернета — готовый пакет: tarball, .deb или .rpm плюс бандл весов.

  3. 03

    Установка на ваш хост

    Бинарник и веса на вашей машине, serve слушает 127.0.0.1:9876 и работает офлайн. Проверка — веб-интерфейс на 127.0.0.1:9876/app/ или CLI на своих файлах.

  4. 04

    Пилот 48 часов

    run_pilot.sh прогоняет ваши записи и считает WER и RTF. Отчёт остаётся в контуре — ход работ расписан ниже.

  5. 05

    Решение

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

Ход работ

Пять отметок за двое суток

  1. T0

    Доступ в контур и хост с запасом

    SSH или VPN, диск от 5 ГБ, CPU x86_64 или aarch64, RAM от 4 ГБ — минимальному профилю (pool=1) хватит 2 ГБ. Порт 9876 остаётся на loopback.

  2. 0–2 ч

    gigastt serve отвечает на /ready

    Ставится бинарник или образ Podman. Веса попадают в --model-dir: командой download на машине с сетью либо заранее перенесённым air-gap бандлом.

  3. 2–8 ч

    run_pilot.sh на ваших записях

    Mini-suite из pilot/mini.json или 20–50 файлов заказчика. На выходе первый pilot-report.md и pilot-report.json — оба остаются в контуре.

  4. 8–24 ч

    Доменный пакет и redact под сценарий

    Пакет со словарём домена, профиль telephony, маскирование PII, ключи API. Прогон повторяется, рядом появляется отчёт v2.

  5. 24–48 ч

    Разбор цифр и итоговое письмо

    Отчёт смотрят на месте и принимают решение. WER посчитан с той же нормализацией, что benchmark/common.py; mini-suite — smoke-прогон, цифры для решения берутся из ваших файлов.

Отчёт

Что считает run_pilot.sh

Markdown для чтения и JSON со schema_version 1.0 для CRM. Mini-suite проверяет, что контур живой; цифры для решения считаются на ваших записях.

  • Версия движка и энкодер

    Из /health и /v1/models: версия движка, модель, энкодер INT8 или FP32.

  • WER overall и worst-10

    Та же нормализация, что в benchmark/common.py движка. Эталон и гипотеза проходят её симметрично.

  • RTF и latency p50/p95

    Wall clock делится на длительность аудио. Поправок и усреднений в пользу движка нет.

  • Проверки защиты

    Пробы 401 на /v1/models, статус /ready, активность redact, пути к license и keys, пометка про bind на loopback.

  • Рекомендации

    Эвристики отчёта: доменный пакет, профиль telephony, auth, размер пула.

Доступ

Что нужно от заказчика

Хост на Linux — Astra, РЕД ОС, Альт, РОСА, Calculate или vanilla — или Windows x86_64/aarch64. RAM от 4 ГБ при pool=2; минимальный профиль (pool=1) обходится 2 ГБ. На диске ~300 МБ под product INT8 плюс отчёты и сами записи.

Порт 9876 свободен и слушает loopback. Веса приезжают через git и git-lfs или готовым бандлом в --model-dir, если контур без интернета. Для скрипта хватает python3 и curl из стандартной поставки ОС.

Записи — ваши: 20–50 файлов с эталонным текстом в manifest, sample без эталона пропускается. Своих под рукой нет — первый прогон идёт на mini-suite из поставки.

В письме укажите организацию, контур, ОС и задачу.

прогон, когда сервер уже стоит
./scripts/run_pilot.sh \
  --base-url http://127.0.0.1:9876 \
  --manifest pilot/mini.json \
  --out /tmp/pilot-report

Отчёт остаётся у вас, доступ открывается письмом

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