Чому ШІ відповідає по-різному на однакове запитання – Microsoft знайшла системну причину

Практично кожен, хто регулярно користується ChatGPT, Copilot, Gemini або іншими великими мовними моделями, стикався з дивною ситуацією. Можна двічі надіслати однакове запитання, нічого не змінити у формулюванні – й отримати дві трохи або навіть суттєво різні відповіді.

На перший погляд пояснення здається очевидним: штучний інтелект просто "випадковий". Частково це справді так, адже багато систем навмисно використовують випадковість під час вибору наступного слова, щоб відповіді не були абсолютно однаковими. Але дослідники Microsoft показали, що мінливість може виникати ще глибше – безпосередньо під час математичних обчислень на GPU, навіть якщо параметри генерації зафіксувати.

29 вересня 2026 року Microsoft Research опублікувала роботу LLM-42: Enabling Determinism in LLM Inference with Verified Speculation. Її автори Raja Gond, Aditya K Kamath, Ramachandran Ramjee та Ashish Panwar досліджують системну недетермінованість великих мовних моделей і пропонують спосіб отримувати відтворювані результати без необхідності відмовлятися від ефективного групування запитів.

Найдивніше відкриття для звичайного користувача звучить так: відповідь ШІ потенційно може залежати навіть від того, які чужі запити сервер обробляв поруч із вашим у той самий момент.

Що таке LLM-42 і чому це не нова модель Microsoft

Назва легко може ввести в оману. LLM-42 – це не конкурент GPT, Claude або Gemini і не новий чат-бот Microsoft. Це система для виконання вже наявних мовних моделей так, щоб однаковий запит міг гарантовано давати відтворюваний результат там, де така гарантія потрібна.

Дослідження представлено в межах SOSP 2026 – Symposium on Operating Systems Principles, який проходить у Празі з 29 вересня до 2 жовтня 2026 року. Microsoft відносить LLM-42 до напряму AI Infrastructure – тобто це робота не стільки про "інтелект" моделі, скільки про те, як її ефективно запускати на реальних серверах.

Проблема, яку намагається вирішити команда, називається determinism – детермінованість. У найпростішому вигляді вона означає: якщо вхідні дані та всі умови однакові, система повинна щоразу повертати однаковий результат.

Для звичайної програми це звучить природно. Якщо калькулятор сьогодні відповідає, що 25 × 4 = 100, завтра ми не очікуємо побачити 99 або 101. З великими мовними моделями все складніше.

Чому однаковий промпт взагалі може давати різні відповіді

Причин може бути кілька, і тут важливо їх не змішувати.

Перша – навмисна випадковість під час генерації тексту. Модель оцінює ймовірності наступних токенів і залежно від налаштувань може вибирати не завжди один і той самий варіант. Саме тому в одній відповіді вона може написати "важливо", а в іншій – "варто врахувати".

Але LLM-42 досліджує іншу проблему. Автори показують, що навіть коли sampling-параметри зафіксовані, різниця може з'явитися на системному рівні через floating-point арифметику, dynamic batching та спосіб, у який GPU виконує паралельні обчислення.

Це вже значно цікавіше, тому що користувач нічого не змінює, модель формально запускається в однакових умовах, але всередині сервера мікроскопічна математична різниця може поступово привести до іншого слова – а потім до зовсім іншого тексту.

Найпростіше пояснення: комп'ютер рахує не зовсім так, як шкільний калькулятор

Щоб зрозуміти LLM-42, потрібно спочатку розібратися з числами з плаваючою комою – floating point.

Комп'ютер не може зберігати абсолютно точне значення кожного можливого десяткового числа. Для багатьох значень використовується наближене представлення, приблизно так само, як людина замість нескінченного числа 1,333333333… може записати 1,33.

У більшості звичайних задач ця похибка настільки мала, що людина її ніколи не помітить. Але сучасна мовна модель за одну відповідь виконує величезну кількість математичних операцій, і дрібні відмінності можуть накопичуватися.

Найважливіше – для floating-point арифметики порядок додавання може змінити фінальний результат.

У звичайній математиці: (a + b) + c = a + (b + c).

Для комп'ютерних floating-point чисел через округлення ці два способи обчислення в окремих випадках можуть дати трохи різні значення. Саме цю властивість називають non-associativity – неасоціативністю.

Як одна крихітна математична похибка змінює ціле речення

Уявімо, що модель має вибрати наступне слово між двома дуже близькими варіантами.

Наприклад:

• "Так" – 49,9999%

• "Ні" – 50,0001%

Різниця практично мікроскопічна. Але модель усе одно повинна вибрати один токен.

Якщо через інший порядок floating-point операцій внутрішні значення трохи зміняться, результат умовно може стати таким:

• "Так" – 50,0002%

• "Ні" – 49,9998%

Тепер модель вибирає інший токен.

І тут починається ефект доміно. Велика мовна модель генерує текст авторегресивно: кожен новий токен стає частиною контексту для наступного. Якщо на десятому слові вибір змінився, одинадцяте слово вже обчислюється з іншою попередньою послідовністю.

Через кілька десятків токенів дві відповіді можуть виглядати так, ніби модель отримала зовсім різні запити, хоча початковий промпт був ідентичним.

До чого тут інші користувачі ШІ

Саме тут з'являється dynamic batching – одна з центральних тем дослідження Microsoft.

Великі AI-сервіси не виділяють окремий дорогий GPU кожній людині, яка написала запит. Це було б надзвичайно неефективно. Натомість система намагається одночасно обробляти кілька запитів різних користувачів.

Кілька незалежних запитів об'єднуються в batch – пакет – і GPU рахує їх паралельно.

Такий підхід різко підвищує продуктивність. Дорогий прискорювач використовується ефективніше, а AI-сервіс може одночасно обслуговувати значно більше людей.

Проблема полягає в тому, що склад batch постійно змінюється. Сьогодні ваш запит може оброблятися разом із дев'ятьма іншими, через секунду – з двадцятьма, а в наступному запуску – з зовсім іншою кількістю запитів.

І саме це може впливати на порядок математичних операцій усередині GPU.

Чому GPU рахує по-різному залежно від розміру batch

Сучасний GPU має величезну кількість паралельних обчислювальних блоків. Щоб отримати максимальну швидкість, програмне забезпечення постійно вирішує, як найефективніше розділити роботу між ними.

Коли batch великий, алгоритм може розкласти операцію одним способом. Коли малий – іншим. Для прискорення використовуються різні схеми розбиття матриць, паралельні reduction-операції та способи об'єднання часткових результатів.

Microsoft окремо описує, наприклад, оптимізацію split-K. Велике множення матриць розбивається між кількома блоками GPU, кожен рахує свою частину, а потім результати складаються разом. Кількість таких частин і порядок їхнього об'єднання можуть залежати від форми вхідних матриць, тобто й від розміру batch.

Математично всі блоки рахують те саме. Але через floating-point округлення інший порядок складання часткових результатів може дати крихітно інше число.

У більшості програм це не мало б жодного помітного значення. У LLM навіть мікроскопічна різниця іноді здатна змінити наступний токен.

Виходить, чужий промпт може вплинути на мою відповідь?

Тут важливо сформулювати дуже точно.

Чужий запит не передає свої слова, зміст або дані у вашу відповідь. Йдеться не про змішування контекстів різних користувачів.

Вплив відбувається на значно нижчому системному рівні. Через те, що ваш запит потрапляє в batch певного розміру, GPU може вибрати іншу схему паралельного виконання тієї самої математики. Через інший порядок floating-point операцій виникає мікроскопічна числова відмінність, яка теоретично може змінити вибір токена.

Тому правильніше сказати так: не зміст чужого запиту, а сам факт спільної обробки з іншою кількістю запитів може змінити обчислювальний шлях вашої відповіді.

Саме цю системну недетермінованість і намагається усунути LLM-42.

Що відбувається всередині LLM під час генерації відповіді

Microsoft ділить інференс мовної моделі на дві основні фази – prefill і decode.

Prefill – це момент, коли модель читає весь промпт. Якщо користувач надіслав кілька абзаців тексту, система паралельно обробляє багато початкових токенів та створює KV cache – внутрішній кеш інформації, який знадобиться під час подальшої генерації.

Decode починається після цього. Модель створює перший токен відповіді, додає його до контексту, потім створює другий, третій і так далі.

Саме decode має особливо цікаву структуру: всередині однієї відповіді токени створюються послідовно, але запити різних користувачів можна рахувати паралельно. Це й робить dynamic batching настільки ефективним для великих AI-сервісів.

Чому не можна просто вимкнути dynamic batching

На перший погляд рішення здається очевидним. Якщо batch змінює порядок операцій – перестанемо об'єднувати запити.

Технічно це справді може прибрати одну з головних причин недетермінованості. Але для реального AI-сервісу ціна буде дуже високою.

GPU коштують дорого, споживають багато електроенергії й найбільш ефективні тоді, коли виконують великі паралельні обчислення. Якщо кожен запит обробляти практично окремо, значна частина можливостей обладнання простоюватиме.

Microsoft прямо пише, що відмова від dynamic batching суттєво погіршує throughput – кількість токенів, яку система здатна генерувати за секунду.

Для невеликого локального експерименту це може бути прийнятним. Для сервісу, який обслуговує мільйони користувачів, така ціна вже критична.

Другий варіант – змусити GPU завжди рахувати однаково

Існує ще один підхід – batch-invariant computation.

Його ідея полягає в тому, щоб GPU використовував однакову схему reduction незалежно від того, скільки запитів зараз знаходиться у batch. Якщо порядок операцій завжди однаковий, floating-point результати також стають відтворюваними.

Проблема в продуктивності та складності реалізації.

Високопродуктивні GPU-kernel спеціально змінюють свою поведінку залежно від форми даних, тому що різні задачі ефективніше рахувати різними способами. Якщо змусити їх завжди працювати за універсальною схемою, доводиться відмовлятися від частини оптимізацій.

Крім того, детермінованість фактично перетворюється на постійний податок на продуктивність – навіть для тих запитів, яким однаковий результат взагалі не потрібен. Microsoft зазначає, що в їхніх тестах deterministic-режим SGLang мав суттєвий штраф за throughput, а для окремих конфігурацій накладні витрати сягали 56%.

Ідея LLM-42: не робити все повільним заради кількох важливих запитів

Саме тут з'являється головна ідея LLM-42.

Дослідники поставили просте запитання: а що, якщо не змушувати всю генерацію бути детермінованою від самого початку, а дозволити системі працювати швидко й перевіряти результат після цього?

Модель спочатку використовує звичайний високопродуктивний шлях із dynamic batching. Тобто GPU продовжує виконувати всі оптимізації, які роблять сучасний inference швидким.

Після генерації певної кількості токенів спеціальний verifier перевіряє їх за фіксованою схемою обчислень. Якщо результат збігається – токени приймаються. Якщо ні – система відкочується до останньої гарантовано правильної точки й перераховує проблемну частину.

Microsoft називає цей механізм decode-verify-rollback.

Як decode-verify-rollback працює простими словами

Уявімо людину, яка швидко переписує сторінку документа.

Перший варіант – змусити її після кожного слова зупинятися й перевіряти написане. Помилок майже не буде, але робота стане дуже повільною.

LLM-42 використовує інший принцип. Людина швидко переписує, наприклад, цілий абзац. Потім перевіряє його. Якщо все правильно – рухається далі. Якщо помилка з'явилася в третьому реченні – перші два залишаються, а неправильну частину переписують заново.

Швидкий шлях у LLM-42 оптимістично припускає, що більшість токенів і так виявляться правильними. Перераховувати потрібно лише ті місця, де перевірка реально виявила розбіжність.

І результати експериментів показують, що це припущення часто працює: у тестах більше половини запитів завершувалися взагалі без rollback, а у багатьох конфігураціях відкоти траплялися рідко.

Що саме перевіряє verifier

Після швидкої генерації система повторно програє кандидатні токени, але вже за fixed-shape reduction schedule – фіксованою схемою reduction, яка не змінюється залежно від випадкового поточного batch.

Якщо повторне обчислення підтверджує токен, він вважається детермінованим і може бути остаточно прийнятий.

Якщо певний токен не збігається, LLM-42 зберігає правильну початкову частину послідовності, відкидає результат після точки розходження та перераховує цю частину.

Система фактично отримує швидкість недетермінованого inference, але накладає зверху контроль якості для тих запитів, де потрібна відтворюваність.

Чому Microsoft називає це verified speculation

Підхід частково натхнений speculative decoding – технікою, яка вже використовується для прискорення великих мовних моделей.

У класичному speculative decoding маленька або швидша модель намагається наперед вгадати кілька токенів, а велика модель потім одним проходом перевіряє ці припущення. Якщо вони правильні – система заощаджує час. Якщо ні – неправильна частина відкидається.

У LLM-42 логіка схожа, але мета інша. Система спекулятивно припускає, що швидко згенерований недетермінований результат збігатиметься з гарантовано відтворюваним, а потім це перевіряє.

Тому повна назва роботи – Enabling Determinism in LLM Inference with Verified Speculation.

Що таке grouped verification

У команди виникла ще одна проблема. Якщо перевіряти надто маленьку кількість токенів, GPU використовується неефективно й сама перевірка стає дорогою. Якщо накопичувати дуже великий блок токенів перед перевіркою, одна помилка може змусити систему відкинути й перерахувати значну частину роботи.

Microsoft виміряла цей компроміс. У тестах із великим verification window у 256 токенів близько 40% запитів мали високий rollback ratio, тоді як із вікном 32 токени таких запитів було приблизно 5%. Водночас маленькі verification-вікна мають вищу вартість перевірки на один токен.

Рішення отримало назву grouped verification. Замість того щоб перевіряти великий шматок однієї відповіді, система бере менші фрагменти одразу з кількох запитів і перевіряє їх разом.

Так GPU отримує достатньо великий batch для ефективної роботи, але якщо в одному запиті виникла помилка, доводиться відкотити лише невеликий шматок його відповіді.

Наскільки часто LLM-42 справді доводиться щось перераховувати

Результати виявилися доволі цікавими.

У частині експериментів rollback не виникав узагалі навіть тоді, коли певна частка запитів вимагала детермінованого результату. В інших випадках відкоти були, але залишалися відносно рідкісними.

У найгіршій конфігурації, яку автори описують для набору ArXiv при 100% deterministic traffic, система виконала 3351 rollback для 4096 запитів – тобто в середньому менше одного відкату на один запит. Частка повторно обчислених токенів у найгіршому протестованому випадку сягала 10,97%, а в середньому для інших конфігурацій була нижчою.

Це важливо, тому що весь підхід LLM-42 має сенс лише тоді, коли більшість швидко згенерованих токенів успішно проходять перевірку. Якщо доводилося б постійно перераховувати половину відповіді, перевага зникла б.

Чи справді LLM-42 працює швидше

За результатами Microsoft – так, особливо коли детермінованість потрібна лише частині трафіку.

В одному показовому тесті система обробляла 11 одночасних запитів, але тільки один із них вимагав гарантовано детермінованого результату. LLM-42 досягла 911 токенів за секунду – у 2,2 раза більше за повністю deterministic-режим SGLang і лише приблизно на 3% нижче за найшвидший недетермінований режим.

В інших offline-тестах перевага залежала від частки deterministic-запитів. На наборі ArXiv за 10–50% такого трафіку LLM-42 залишалася приблизно в межах 1–2% від найшвидшого недетермінованого режиму для частини конфігурацій, тоді як традиційний deterministic-підхід втрачав значно більше продуктивності.

Microsoft також повідомляє, що в окремих режимах LLM-42 була до 41% швидшою за SGLang-Deterministic, а при 10% deterministic traffic перевага залежно від workload становила приблизно від 33% до 48%.

Чому детермінованість взагалі потрібна – хіба різні відповіді не корисні

Для звичайної творчої розмови різноманітність часто є перевагою.

Якщо користувач просить придумати десять назв бренду або написати привітання, немає нічого поганого в тому, що другий запуск дасть інші варіанти. Навпаки, це може бути бажано.

Проблема починається там, де ШІ стає частиною програмної системи, яку потрібно тестувати, перевіряти й відтворювати.

Наприклад, команда розробників оновила одну частину AI-сервісу й запускає автоматичні тести. Якщо відповідь моделі щоразу трохи інша, незрозуміло, чи результат змінився через новий код, чи просто через системну недетермінованість.

Для наукових експериментів це ще важливіше. Якщо дослідник запускає той самий тест вдруге, він повинен мати можливість відтворити попередній результат.

Де однакова відповідь ШІ може бути критично важливою

LLM-42 орієнтується насамперед на інфраструктурні сценарії, але сама проблема набагато ширша. Відтворюваність важлива там, де AI-рішення потрібно перевіряти або порівнювати.

Серед таких сценаріїв:

• автоматичне тестування AI-програм;

• оцінювання нових версій моделей;

• наукові експерименти;

• benchmark-тести;

• пошук регресій після оновлення;

• аудит AI-систем;

• debugging;

• повторне відтворення проблемної відповіді;

• критичні бізнес-процеси, де однаковий вхід має давати контрольований результат.

Якщо система одного разу зробила помилку, розробнику потрібно мати можливість запустити точно ті самі умови й отримати той самий збій. Інакше пошук причини перетворюється на значно складніше завдання.

Простий приклад: чому це проблема для тестувальника

Уявімо сервіс, який використовує LLM для перетворення листів клієнтів на структуровані заявки.

Під час тесту система правильно ставить "Гарантія". Через хвилину той самий текст запускають знову – модель вибирає "Повернення".

Якщо sampling вимкнений і всі налаштування однакові, команда очікує відтворюваність. Але якщо невелика floating-point різниця всередині GPU змінила один токен, результат уже інший.

Для користувача це просто дві трохи різні відповіді. Для інженера це означає, що систему значно складніше тестувати.

Чи означає це, що temperature = 0 не гарантує однакову відповідь

Один із найцікавіших практичних висновків цієї теми – вимкнення випадкового sampling саме по собі не обов'язково вирішує всі джерела недетермінованості.

Temperature, top-p та інші параметри керують тим, як модель вибирає наступний токен на основі отриманих ймовірностей. Але LLM-42 розглядає проблему, яка виникає ще до цього вибору: самі числові результати обчислень можуть трохи відрізнятися через порядок floating-point операцій.

Якщо два токени мають дуже близькі оцінки, навіть невеликий numerical drift здатний змінити те, який із них виявиться першим.

Тому greedy decoding і deterministic execution – не зовсім одне й те саме.

Чи пояснює LLM-42 усі випадки, коли ChatGPT відповідає по-різному

Ні, і це принципово важливо.

Коли звичайний користувач двічі ставить однакове запитання чат-боту, різниця може мати багато причин. Система може використовувати sampling, різний прихований системний контекст, маршрутизацію між моделями, оновлення моделі, пошукові результати, інструменти, персоналізацію або інші компоненти сервісу.

LLM-42 не доводить, що кожна різна відповідь ChatGPT чи Copilot виникла через GPU batching. Дослідники ізолюють конкретний системний механізм і показують, що він сам по собі достатній для появи недетермінованих результатів навіть за фіксованих параметрів генерації.

Саме тому робота важлива для інженерів: вона показує, що повна відтворюваність LLM – це не просто питання поставити temperature на нуль.

Чи бачить модель запити інших людей через dynamic batching

Ні. Dynamic batching не означає, що чужий промпт додається до вашого контексту.

Сервіс може паралельно виконувати кілька незалежних послідовностей на одному GPU, але їхні дані логічно залишаються окремими. Причина описаної Microsoft різниці – організація арифметичних операцій, а не передавання інформації між промптами.

Це важливе уточнення, оскільки фразу "інші користувачі можуть впливати на вашу відповідь" легко прочитати як проблему приватності. Дослідження LLM-42 говорить про інше: розмір і форма batch можуть змінити алгоритм паралельного reduction, а вже це – числовий результат.

Чому різницю не видно після кожного запиту

Якщо floating-point похибка виникає практично постійно, може виникнути логічне запитання: чому відповіді не змінюються щоразу?

Тому що маленька числова різниця далеко не завжди змінює токен.

Якщо модель оцінює один варіант у 90%, а найближчий конкурент має 5%, крихітне зміщення нічого не змінить. Перший токен залишиться переможцем.

Проблема виникає в місцях, де кілька варіантів мають дуже близькі внутрішні оцінки. Тоді невеликий numerical drift може змінити порядок.

Саме ця властивість і дозволяє LLM-42 працювати ефективно. Автори виходять із припущення, що більшість токенів навіть на швидкому недетермінованому шляху все одно виявляться такими самими, тому дорогий rollback потрібен лише для невеликої частини генерації.

Чому одна помилка може змінити всю відповідь

LLM генерує текст послідовно, тому наслідок одного іншого токена може бути набагато більшим, ніж здається.

Уявімо початок:

"Основна причина полягає в..."

Модель А наступним токеном вибирає "тому".

Модель Б – "однак".

Від цього моменту граматична й логічна структура продовження вже різна. Наступні токени генеруються з урахуванням "тому" або "однак", тому траєкторії починають розходитися.

Через 100 слів відповіді можуть мати різні аргументи, приклади й навіть висновки.

Тому мікроскопічна різниця у floating-point числі здатна зрештою перетворитися на цілком помітну різницю у тексті.

Чому Microsoft не робить усі AI-запити детермінованими

Тому що це не завжди потрібно.

Якщо людина просить модель написати казку, придумати заголовки або провести brainstorming, мінливість корисна. Немає сенсу витрачати додаткові ресурси заради абсолютно однакового результату.

LLM-42 спеціально підтримує selective determinism – вибіркову детермінованість. Система може гарантувати відтворюваність лише тим запитам, яким вона справді потрібна, а решта продовжують виконуватися максимально швидким способом.

Це одна з ключових переваг підходу над batch-invariant kernels. Там витрати на deterministic execution фактично несуть усі запити. У LLM-42 overhead приблизно масштабується разом із часткою трафіку, для якого потрібна гарантія.

Що показали онлайн-тести

Microsoft тестувала систему не лише у режимі, коли великий набір запитів просто проганяється один за одним, а й у сценарії, схожому на реальний онлайн-сервіс.

При 12 запитах на секунду недетермінований SGLang мав медіанну end-to-end latency 2,15 секунди. Повністю deterministic-режим – 4,64 секунди. Для LLM-42, коли лише 2% трафіку вимагали детермінованості, медіана становила 2,21 секунди – приблизно на 3% більше за найшвидший baseline.

При вищому навантаженні різниця між традиційним deterministic-режимом і звичайним inference ставала ще помітнішою. Автори зазначають, що LLM-42 здебільшого трималася ближче до швидкого недетермінованого режиму, хоча зі збільшенням частки deterministic traffic затримка поступово зростала.

Це саме той компроміс, якого й намагалася досягти команда: не робити весь сервіс повільним через те, що невеликій частині запитів потрібна сувора відтворюваність.

У LLM-42 уже є обмеження

Microsoft не подає роботу як завершене універсальне рішення для всіх AI-систем.

У поточному прототипі verification може створювати latency overhead навіть для запитів, які самі не потребують детермінованості. Причина в тому, що під час перевірки можуть тимчасово затримуватися інші запити на GPU. Автори вважають, що це можна покращити, наприклад виділивши для verifier окрему частину GPU-ресурсів.

Є й інші інженерні нюанси, пов'язані з різними reduction-стратегіями для prefill і decode. Це важливе нагадування: LLM-42 – дослідницька система, а не оголошена функція ChatGPT або Microsoft Copilot, яку користувач уже може ввімкнути перемикачем.

Її значення зараз радше в тому, що дослідники показали практичний спосіб зробити детермінований inference значно дешевшим.

Чому назва LLM-42

Назва майже напевно викликає асоціацію з числом 42 із "Путівника по Галактиці для космотуристів" Дугласа Адамса – знаменитою "відповіддю на головне питання життя, Всесвіту і всього такого".

У самій публікації Microsoft основна увага приділена технічному механізму, а не поясненню маркетингового походження назви. Тому трактувати 42 як офіційно підтверджене посилання без прямої заяви авторів не варто.

Але сама назва дуже вдало пасує до дослідження, яке намагається зробити так, щоб на одне й те саме питання машина нарешті могла гарантовано дати ту саму відповідь.

Що LLM-42 змінює для звичайного користувача

Сьогодні – практично нічого. Користувач не отримає у Copilot нову кнопку "відповідай завжди однаково" лише через публікацію цієї роботи.

Але дослідження дуже добре пояснює, чому поведінка сучасних AI-систем іноді здається менш стабільною, ніж поведінка звичайних програм.

Мовна модель – це не просто набір правил типу "на запит X повернути Y". Мільярди числових параметрів проходять через величезну кількість паралельних операцій на GPU, а фінальна відповідь складається токен за токеном.

Навіть якщо логіка моделі не змінилася, фізичний спосіб виконання цих обчислень у дата-центрі може мати значення.

Головний парадокс: ШІ може бути логічно однаковим, але математично трохи іншим

Саме це, мабуть, найцікавіший висновок роботи для людини, яка не займається AI-інфраструктурою.

Ми звикли вважати комп'ютерну програму абсолютно точною. Один і той самий код плюс одні й ті самі дані нібито повинні означати однаковий результат.

На масштабі сучасних GPU це правило має нюанси. Математично еквівалентні способи паралельного виконання можуть створювати трохи різні floating-point числа, а для авторегресивної моделі іноді достатньо однієї такої відмінності, щоб почалася зовсім інша текстова траєкторія.

LLM-42 намагається не ліквідувати всю цю високопродуктивну складність, а працювати поверх неї. GPU дозволяють працювати максимально швидко, а система окремо перевіряє, чи отриманий результат відповідає детермінованому еталону.

Якщо так – нічого не потрібно перераховувати.

Якщо ні – система повертається назад і виправляє лише проблемну частину.

Чому робота Microsoft важлива для майбутніх AI-агентів

Сьогодні різниця в одному слові чат-бота може здатися дрібницею. Але AI дедалі частіше переходить від розмови до виконання дій.

Агент може:

• створювати код;

• запускати інструменти;

• обробляти документи;

• працювати з базами даних;

• планувати багатокрокові завдання;

• приймати проміжні рішення.

У такій системі один інший токен іноді означає вже не інше формулювання, а іншу дію.

Якщо на одному кроці агент вибрав інший інструмент або параметр, усі наступні кроки можуть змінитися. Тому можливість відтворити конкретний запуск стає важливою не лише для красивих benchmark-графіків, а й для debugging реальних AI-продуктів.

Чим більше ШІ переходить від "говорити" до "робити", тим дорожчою стає недетермінованість.

LLM-42 показує проблему, якої користувач зазвичай не бачить

Коли людина пише питання у чаті, вона бачить дуже просту картину: текст пішов на сервер, за кілька секунд прийшла відповідь.

Насправді між цими двома моментами відбувається величезна кількість операцій. Запит токенізується, потрапляє в scheduler, об'єднується з іншими у batch, проходить через десятки шарів Transformer, GPU розподіляє матричні операції між тисячами обчислювальних блоків, результати складаються, обирається наступний токен – і все повторюється знову.

LLM-42 показує, що навіть порядок роботи цієї невидимої інфраструктури здатний впливати на фінальний текст.

Саме тому проблема відтворюваності великих мовних моделей виявилася значно складнішою, ніж просто "вимкнути випадковість".

Головне про LLM-42 за 30 секунд

Microsoft Research показала, що однакові запити до LLM можуть давати різні результати на системному рівні через поєднання трьох речей: floating-point неасоціативності, dynamic batching та GPU-kernel, які змінюють порядок reduction залежно від розміру batch.

Звичайний спосіб вирішити проблему – змусити всі GPU-операції виконуватися в однаковому порядку – знижує продуктивність і вимагає спеціалізованих kernels.

LLM-42 використовує іншу схему:

1. Швидко генерує токени звичайним недетермінованим шляхом.

2. Перевіряє їх за фіксованою схемою.

3. Підтверджені токени залишає.

4. Якщо знаходить розбіжність – робить rollback.

5. Перераховує лише проблемну частину.

Головна перевага – детермінованість можна вмикати вибірково, не змушуючи весь AI-сервіс постійно платити штраф продуктивністю.

У тесті, де лише один із 11 запитів потребував детермінованості, LLM-42 працювала у 2,2 раза швидше за deterministic SGLang і залишалася лише приблизно на 3% нижче від найшвидшого недетермінованого режиму.