# Протокол: корпус прийнято до порівняння вартості

Версія 1 — 24 вересня 2026. Ця картка пропонує протокол для заповнення; вона не містить жодних виміряних результатів чи набору даних. Відповідний notebook використовує невеликий синтетичний MLP, щоб навчитися зчитувати пам'ять. Він не виконує наведений нижче робочий протокол.

## 1. Визначте корисну роботу до випробувань

Приклад роботи: класифікувати корпус із **1 000 текстів**. Складіть самостійно дозволений набір, репрезентативний для вашого використання, з унікальним ідентифікатором і перевіреною референсною відповіддю для кожного тексту. Зафіксуйте ревізію корпусу, моделі, tokenizer, коду та seed. Зберігайте окремо список очікуваних ID та індивідуальні виходи, щоб уможливити аудит.

Визначте до будь-якого вимірювання: класи, формат виходу, основну метрику (наприклад, macro-F1), її поріг прийняття та максимально допустиме погіршення щодо референсу. Виберіть допуск, доречний для вашого застосування; жодного універсального значення тут не наведено. Дані для навчання, налаштування та оцінювання мають залишатися розділеними.

Корпус приймається лише якщо всі 1 000 очікуваних ID присутні рівно один раз, у виходах немає жодної зайвої відповіді, формат валідний і заздалегідь встановлене правило якості виконано. Два файли, кожен з яких містить 1 000 рядків, самі по собі не доводять рівність ID. Заархівуйте перевірку множин і дублікатів.

## 2. Змінюйте лише анонсований варіант

Щоб дослідити batch, підготуйте, наприклад, варіанти 1, 4 і 8. Збережіть той самий корпус, порядок входів, модель, tokenizer, точність і ліміт контексту. Якщо ви далі досліджуєте точність, створіть окремий експеримент і повторіть контроль якості. Опишіть усічення: скорочення текстів змінює виконану роботу.

Зафіксуйте реальний GPU, кількість фактично використаних GPU, device, драйвер, Python, PyTorch і runtime CUDA або ROCm. Впишіть також версію вашого коду, можливі опції генерації та будь-яку конкуренцію за ресурси машини в `notes`. Комерційний пакет із двох GPU не означає, що програма використовує обидва.

## 3. Вимірюйте порівнювані проходи

Оголосіть, що охоплює секундомір: лише обробку чи повний ланцюжок із читанням, токенізацією та записом. Розділіть завантаження, перший прохід і прогріті проходи. Скрипт пам'яті вимірює лише свій MLP і не заміряє повний ланцюжок класифікації.

Виконайте анонсований прогрів, а потім п'ять виміряних проходів на варіант у чергуванні або заздалегідь випадковому порядку. Зберігайте кожну сиру тривалість. Наведення медіани та діапазону min–max дає змогу побачити розкид; п'ять спостережень не обґрунтовують надійну оцінку p95. Не відкидайте мовчки помилку чи повільний прохід: збережіть його рядок і поясніть інцидент. Перезапустіть у новому процесі, якщо хочете порівняти перші проходи за подібних умов.

Для вимірювань GPU PyTorch синхронізуйте вибраний device перед початковим відліком і після операції. Зніміть baseline `allocated` і `reserved`, скиньте статистику піку, а потім збережіть абсолютні піки фази. `allocated` входить до `reserved`: додавання їх порахувало б частину пам'яті двічі. Обидва максимуми можуть бути досягнуті в різні моменти: їхня різниця не є вимірюванням кешу в конкретний момент. Алокації інших процесів і ті, що поза алокатором PyTorch, не охоплюються.

## 4. Заповніть resultats-bruts.csv

Розповсюджуваний CSV містить лише заголовки. Записуйте один рядок на прохід, з десятковою крапкою та секундами для часів, байтами для пам'яті й центами USD для тарифу. Порожня клітинка означає «не заміряно»; нуль означає справді нуль. Коми, наявні в примітці, потрібно захистити звичайними правилами CSV.

| Поля | Значення та введення |
| --- | --- |
| `experiment_id`, `variant_id` | Стабільні ідентифікатори експерименту та варіанта. |
| `corpus_revision`, `model_revision`, `tokenizer_revision`, `seed` | Незмінні версії або відбитки, та оголошене зерно. |
| `gpu_model`, `gpu_count`, `device`, `driver_version`, `python_version`, `torch_version`, `runtime_version` | Фактично використане обладнання та спостережуване середовище; не переписуйте обіцянку з пропозиції. |
| `precision`, `batch`, `context` | Фактично застосована конфігурація. |
| `phase`, `run_index`, `warmup_iterations` | Окрема фаза (`cold` або `warm`, наприклад), номер проходу, кількість прогрівів. Не змішуйте тривалості. |
| `expected_ids`, `observed_ids` | Кількості очікуваних і спостережуваних ID; докладні списки зберігаються разом із виводами. |
| `ids_match`, `format_valid` | `true`/`false` після фактичної перевірки, включно з дублікатами та додатковими відповідями. |
| `quality_metric`, `quality_threshold`, `quality_tolerance`, `quality_value` | Заздалегідь визначені назва, поріг і допуск, а потім виміряне значення. Уточніть сенс допуску та еталон у `notes`. |
| `corpus_accepted` | `true` лише якщо всі умови валідації виконано; інакше `false`. |
| `elapsed_seconds` | Необроблена тривалість оголошеного обсягу, ніколи не очікуване значення. |
| `baseline_allocated_bytes`, `baseline_reserved_bytes`, `peak_allocated_bytes`, `peak_reserved_bytes` | Окремі показники лише для вимірюваного device. Залиште порожніми, якщо не вимірювалися. |
| `duration_days`, `lots`, `package_total_usd_minor` | Обраний повний пакет, оплачені лоти та загальна ціна в центах USD; одна витрата не повинна додаватися п'ять разів. |
| `accepted_unique_corpora` | Кількість різних корисних корпусів, прийнятих для економічного аналізу; це поле не потрібно підсумовувати між повтореннями. |
| `notes` | Обсяг, інциденти, рішення щодо якості, ревізія коду та посилання на збережені матеріали. |

## 5. Обчислювати, не вигадуючи обсяг виробництва

Ціна для порівняння — це повний пакет на 3, 7 або 30 днів, помножений на кількість лотів. Для B200 один лот містить два GPU, і тариф уже покриває цей лот. `calcul_forfaits.py` застосовує це правило до наданих тарифів.

Якщо обрана корисна робота — це повний прийнятий корпус, `--accepted-results` має отримати кількість різних корпусів, фактично валідованих за період. П'ять повторень того самого корпусу слугують для вимірювання варіативності: вони не створюють п'ять корисних результатів. Зафіксуйте одиницю виміру до порівняння та зберігайте її для всіх варіантів. Без виміряної та прийнятої кількості залиште цей параметр відсутнім: буде обчислено лише вартість пакета. Не проєктуйте автоматично темп роботи на 3, 7 або 30 днів.

Зберігайте разом заповнений протокол, індивідуальні виводи, перевірки якості, необроблений CSV та економічне обчислення. Швидша, але не прийнята конфігурація не виконує ту саму мету. Конфігурація, яка перевищує пам'ять, залишається спостереженням невдачі, а не часом, який слід замінити нулем.