Дошли руки почитать статью годовой давности, Cut Your Losses in Large-Vocabulary Language Models. Разбирать мы её не будем, так как она очень тяжела на математику и почти наверняка не интересна вам, но если вдруг вы MLE и будете готовиться к собеседованиям — это почти мастхэв. В статье описан очень интересный трюк с фильтрацией части элементов в наборе вероятностей слов, основанный на том, что очень маленькие вероятности ниже какого-то значения не будут оказывать влияния на подсчёт, если используется 16 бит для записи чисел (bfloat16). В целом это достаточно широко известный факт: если складывать очень большое число и очень маленькое, то сумма будет равна первому числу — второе на его фоне потеряется. При этом даже если работать с просто очень маленькими числами, то в какой-то момент их сумма может стать большой и начать «съедать» второе слагаемое в сумме, приравнивая его вклад к нулю. Простой пример: ``` import torch dtype = torch.bfloat16 large_tensor = torch.tensor([1.0], dtype=dtype) tiny_val = 2-8 tiny_tensor = torch.tensor([tiny_val], dtype=dtype) steps = 28 naive_sum = large_tensor.clone() for _ in range(steps): naive_sum += tiny_tensor block = torch.full((steps,), tiny_val, dtype=dtype) block_sum = torch.sum(block, dtype=dtype) smart_sum = large_tensor + block_sum print(naive_sum, smart_sum) ``` — прибавляем `2-8` к единице много-много раз, чтобы получить двойку. Как-то я задумывался, а почему так происходит и где границы, при которых сложение не работает, но забил. А теперь вот вернулся к этому — и делюсь с вами. Причина в том, как именно компьютер делает сложение. Чтобы это понять, нужно вспомнить, как хранятся числа. С битами и двоичной системой возиться неинтересно, поэтому давайте представим, что всё работает в привычной десятичной. Будем складывать `100_000` и `50`. В памяти компьютера `100_000` будет храниться так: `1.00 x 10^5`, то есть как некоторое число, называемое мантиссой, умноженное на десять в какой-то степени (сохраняем только первый множитель + степень десятки). Тогда `50` будет записано так: `5.00 x 10^1`. Степень десятки называется экспонентой, и компьютер не умеет складывать числа с разными экспонентами — поэтому их нужно привести к одной, большей (`10^5`). Но тогда и мантиссу нужно соответственным образом разделить (в реальности — сдвинуть биты, ведь каждый сдвиг это деление на 2): `0.0005 x 10^5 = 50`. То есть пятёрку разделили на десять тысяч (потому что разница экспонент `10^4`). После этого при одинаковой экспоненте нужно просто сложить мантиссы и получится результат операции. Но под хранение мантиссы выделено определённое количество бит, и поэтому очень-очень маленькие значения (из-за деления на `10^4 = 10_000`) там сливаются с нулём. Если в нашем примере оставлять лишь 3 значащих цифры, то получится что `0.0005` превратится в `0.00`. Итого `100_000 + 50 = (1.00 x 10^5) + (0.00×10^5) = 100_000 + 0 = 100_000` В реальности же под мантиссу в bfloat16 выделяется 7 бит (и плюс у нас есть единица, `1.xxxxxxxx` — 8 значащих бит). Если разность экспонент двух слагаемых больше `28`, то одно из слагаемых будет равно нулю из-за сдвига при выравнивании экспонент. `1.0101010` превратится в `0.0000000`. Но на самом деле всё ещё чуть сложнее, так как по стандарту нужно хранить отдельно 3 разных флага при выравнивании экспонент, включая — возможно вы слышали — sticky bit (показывает, есть ли в отрезанном хвосте хотя бы одна единица в битах). И плюс есть правила округления. Но при разности экспонент `9` и больше (числа отличаются по масштабу в `x256` и более раз) вас уже ничего не спасёт. Ниже — реакция подписчика, который пришёл на канал читать понятные объяснения про ИИ 💳