GLM-5.2 NVIDIA free API цікавий з однієї причини: NVIDIA зробила важку модель від Z.ai легкою для тестування, але практичні обмеження ендпоінту не є тим самим, що й повні можливості моделі.
Коротка версія:
Я сприймаю це як корисне налаштування для оцінки (eval). 40 запитів на хвилину достатньо для прототипів, оцінки агентів та ручних порівнянь. Максимальна кількість токенів — це дратівлива частина, і саме її вам потрібно протестувати самостійно, оскільки специфікації моделі та обмеження ендпоінтів провайдерів можуть відрізнятися.
GLM-5.2 NVIDIA free API: що змінилося
GLM-5.2 — це нова флагманська модель від Z.ai. Документація моделі від NVIDIA описує її як модель типу Mixture-of-Experts з 753 млрд параметрів, створену для довгострокових завдань, агентів, написання коду та використання інструментів. Власна документація Z.ai виділяє контекст 1M та до 128K вихідних токенів.
Це позиціонування на рівні моделі.
Сторінка NVIDIA Build — це практичний рівень. Там GLM-5.2 перелічена з безкоштовним ендпоінтом, партнерським ендпоінтом та опцією завантаження. Приклад коду на Python викликає сумісний з OpenAI ендпоінт Integrate API від NVIDIA з моделлю `z-ai/glm-5.2`. У прикладі встановлено `max_tokens` на рівні 16,384.
Я б не писав «GLM-5.2 має лише 32k» як факт про модель. Натомість я б написав так: на безкоштовному ендпоінті NVIDIA простір максимальної кількості токенів, здається, обмежений провайдером порівняно з більшим вікном контексту моделі. Якщо на практиці ви бачите 32k, ставтеся до цього як до спостереження щодо ендпоінту, яке потребує перевірки стосовно вашого облікового запису, структури запиту та поточної конфігурації NVIDIA.
Це розрізнення має значення. Модель може підтримувати довгий контекст, тоді як безкоштовний ендпоінт надає нижчі ліміти виводу, менше можливостей та суворіші обмеження частоти запитів.
Бенчмарки: GLM-5.2 проти GLM-5.1
NVIDIA публікує цифри бенчмарків для GLM-5.2 у порівнянні з GLM-5.1 та кількома іншими передовими моделями. Найчіткіше порівняння починається з GLM-5.1, оскільки воно показує, куди Z.ai просунула модель.
| Benchmark | GLM-5.2 | GLM-5.1 | Різниця | Чому це важливо |
|---|---|---|---|---|
| --- | ---: | ---: | ---: | --- |
| HLE | 40.5 | 31.0 | +9.5 | Складні завдання на знання та міркування |
| HLE with tools | 54.7 | 52.3 | +2.4 | Розв'язання проблем з підтримкою інструментів |
| AIME 2026 | 99.2 | 95.3 | +3.9 | Олімпіадна математика та суворі міркування |
| GPQA-Diamond | 91.2 | 86.2 | +5.0 | Питання науки експертного рівня |
| SWE-bench Pro | 62.1 | 58.4 | +3.7 | Виправлення коду в середовищах, подібних до репозиторіїв |
| NL2Repo | 48.9 | 42.7 | +6.2 | Створення коду з природної мови в контексті репозиторію |
| Terminal Bench 2.1 | 81.0 | 63.5 | +17.5 | Інженерні завдання на основі терміналу |
| MCP-Atlas | 76.8 | 71.8 | +5.0 | Завдання для агентів, орієнтованих на MCP та інструменти |
| Tool-Decathlon | 48.2 | 40.7 | +7.5 | Широкі можливості використання інструментів |
Міркування та математика
AIME 2026 на рівні 99.2 та GPQA-Diamond на рівні 91.2 — це сильні показники. Вони демонструють, що GLM-5.2 позиціонується не лише як модель для написання коду. Вона також робить сильний акцент на суворих міркуваннях, експертних питаннях та завданнях, де модель не може обійтися розмитим зіставленням шаблонів.
Написання коду та робочі процеси агентів
Число, яке виділяється для мене, — це Terminal Bench 2.1: 81.0 проти 63.5. Це не косметичне покращення. Якщо цей результат підтвердиться в практичних тестах, GLM-5.2 стане цікавою для роботи з репозиторіями, робочих процесів CLI та інженерних завдань для агентів, де модель має перевіряти стан, виконувати кроки, інтерпретувати помилки та продовжувати роботу.
Саме звідси я б почав тестування. Жодних поетичних промптів. Жодних загальних чатів. Я б перевірив її проти реальних робочих процесів розробки: збої збірки, невеликі виправлення PR, налагодження, орієнтоване на репозиторій, та робота з MCP, де модель має узгоджувати кілька інструментів з метою.
40 запитів на хвилину — це краще, ніж здається
40 RPM звучить низько, якщо думати про продакшн-систему з багатьма одночасними користувачами. Для оцінки (evals) історія інша.
40 запитів на хвилину достатньо для:
Цього недостатньо для:
Для мене GLM-5.2 на безкоштовному ендпоінті NVIDIA — це поверхня для оцінки, а не для продакшну. Саме так я б використав її насамперед.
У мене є кілька ідей щодо додатків та агентів, які я хочу протестувати з такими моделями, але я не розголошую їх, доки не проведу реальні тести. 40 RPM достатньо, щоб з'ясувати, чи розуміє модель робочий процес. Цього недостатньо, щоб довести, що вона витримає навантаження у продакшні.
Максимальна кількість токенів: 32k — це ліміт для вимірювання
Якщо на практиці ендпоінт надає вам максимум 32k токенів, це не марно. Це все ще реальне обмеження.
Для звичайних промптів щодо написання коду 32k виводу — це багато. Для довгих потоків агентів, повного контексту репозиторію, довгих логів та згенерованих патчів це може швидко стати тісно. Це особливо вірно, коли ви хочете, щоб модель міркувала, планувала, повертала код та зберігала простежуваність.
Ось список тестів, які б я провів:
| Тест | Що б я вимірював |
|---|---|
| --- | --- |
| Довгий промпт репозиторію | Чи пропускає модель важливі файли або обмеження? |
| Великий лог плюс виправлення | Чи може вона знайти першопричину, не переписуючи неправильний модуль? |
| Вивід патчу | Чи є відповідь повною чи обрізаною? |
| Цикл використання інструментів | Чи зберігає вона стан протягом кількох кроків? |
| Навантаження 40 RPM | Коли починаються помилки 429 і наскільки стабільним є повторний запит/backoff? |
| Стеля токенів | Чи є ліміт 16k, 32k, чи він залежить від облікового запису/ендпоінту? |
| Модель для порівняння | Чи перевершує вона поточну модель у тому ж завданні, чи лише в опублікованих бенчмарках? |
Останній рядок має найбільше значення. Бенчмарки показують, де модель може бути сильною. Ваші власні завдання показують, чи є вона корисною.
Одна застереження від NVIDIA
Документація API від NVIDIA описує GLM-5.2 з підтримкою багатодіалогового чату, виклику інструментів, структурованого виводу та слідів міркувань. У той же час сторінка NVIDIA Build для безкоштовної моделі показує Function Calling, Structured Output та Reasoning як «Не підтримується» у бічній панелі.
Я б не припускав повної функціональності агента лише тому, що модель може підтримувати її десь. Я б спочатку протестував фактичний ендпоінт NVIDIA як сумісну з OpenAI поверхню chat/completions, а потім перевіряв кожну функцію окремо.
Це поширений поділ серед провайдерів: картка моделі описує саму модель, тоді як ендпоінт описує продукт, який ви можете використовувати.
Перевірка тверджень
Мій перший висновок
GLM-5.2 виглядає сильною на правильних бенчмарках. Найчіткіший сигнал для мене — це не число AIME, хоча 99.2 є екстремальним. Більш корисним сигналом є комбінація Terminal Bench 2.1, NL2Repo, SWE-bench Pro, MCP-Atlas та Tool-Decathlon.
Саме там модель починає мати значення для реальних робочих процесів розробників.
Безкоштовний ендпоінт NVIDIA знижує бар'єр. 40 RPM робить його корисним для серйозних тестів. Обмеження максимальної кількості токенів означає, що ви не повинні ставитися до нього як до повної продакшн-поверхні поки що.
Моя думка: GLM-5.2 варто бенчмаркити проти ваших власних робочих процесів агентів вже зараз. Логувайте кожен запит, вимірюйте обрізання виводу, запускайте ті ж самі кейси проти інших моделей і ставтеся до NVIDIA free API як до тестового стенду, доки ви не перевірите обмеження на практиці.
Робота полягає не в тому, щоб гнатися за хайпом. Робота полягає в тому, щоб з'ясувати, чи вирішує модель реальні завдання, не змушуючи вас будувати всю систему навколо її слабких місць.