Я вот тоже подумал - если мышление, какое бы оно ни было, фундаментально ограничено стековой машиной и не очень большим размером контекста, сингулярности через год можно не бояться. Другая сторона, правда, не менее шокирующая - в скольких же видах даже “творческой” деятельности, как оказалось, даже такой болванчик с недомышлением справляется на все 146%.
“Здравый смысл llm” - это не “думать”, задавая правильные вопросы (опираясь на личный опыт), а выдавать правдоподобные ответы (опираясь на “насобаченность” весов).
Тут сложнее, как мне кажется. LLM базово выдаёт не ответ, а токен. Далее ей передают снова исходный вопрос с этим токеном, и она выдаёт следующий токен. И так далее, пока не выдаст токен со значением “ответ окончен”. Так вот, не напоминает ли это абстрактную вычислительную машину? Если эту схему можно формализовать как машину типа машины Тьюринга, то в процессе генерации ответа LLM может производить вычисления, т.е. “думать”. И в теории, если мы можем переводить текст на естественном языке в логические утверждения, то при надлежащей архитектуре машины можно добиться того, чтобы она делала логически непротиворечивые преобразования, в конце концов, давая-таки решение задачи, не опираясь только лишь на “насобаченность” весов. Мне кажется, что до какой-то степени оно сейчас уже так и есть, но на уровне местечковой, глючной, медленной и недокументированной реализации половины стандарта Common Lisp. В конце концов, не просто же так “режим размышлений” даёт объективный буст к качеству ответа.
С точки зрения абстрактной машины вообще выглядит так, что LLM работают как стековая машина, в которой к тому же для стека есть только операция push, а однажды положенные в стек значения нельзя менять. Можно ли на этом реализовать машину Тьюринга? Я тут недостаточно подкован в теории вычислений.
Ну вот к поверхности и будут приложены силы, стремящиеся всё разорвать. Как именно будет разрушение идти - отслаивание тонкого слоя с поверхности или распад на более крупные куски - мои знания о прочности не позволяют оценить.
Включать небезопасные оптимизации на уровне всей единицы компиляции - это тяжёлое наследие прошлого. По хорошему, они и должны настраиваться гранулярно на уровне хотя бы функций, а лучше отдельных выражений.
А еще, я может и не прав, но чтобы заменить собой питон, даже если язык справится с его требованиями на простоту использования и порог входа, то столкнется с тем, что мегатонны кода уже написаны на питон, и должны пройти многие годы нереального превосходства, чтобы люди перешли на другой язык.
С одной стороны да, поскольку так уже было с выходом Python 3 - что-то так до сих пор и работает на Python 2, потому что переписать дороже, чем поддерживать. С другой стороны, если вдруг весь FAANG начнёт от питона избавляться, остальные тоже, скорее всего, будут смотреть в ту же сторону.
В языке, кроме синтаксиса, есть и семантика. Язык определяет, что программа знает о данных, с которыми работает, и какие преобразования допустимо делать. В Python программа довольно мало знает о данных и мало что имеет право делать в плане “срезания углов”. Видя, например, запись a + b, компилятор C++ имеет право ругнуться, если обнаруживает, что для типов переменных a и b не определён operator+. Python же не знает, что там за типы. Не знает, определено для них суммирование как встроенная функция, или нужно будет вызвать a.__add__(b), или b.__radd__(a). Более того, в Python объекты одного и того же типа не обязаны иметь одинаковые атрибуты. По сути, объект - это словарь, из которого по имени достаются атрибуты. Поэтому на любой чих там поиск по хэш-таблице, несколько переходов по указателям и динамический диспатч. Сгенерировать эффективный машинный код заранее не представляется возможным. Если убрать такой беспредельный динамизм - получится что-то типа Julia, где, действительно, всё компилируется +/- в такой же код, что и в Си. Но, как заметил автор, там пока что не просматривается надежда на помощь крупных корпораций в создании ИИ-стека, поэтому там возможности очень неоднородные, может всё работать идеально и быстро, а можно оказаться перед необходимостью с нуля писать движок. Отдельно надо сказать, что когда появлялся Python, компиляторы не очень умели автоматически выводить типы, когда они явно не указаны. Поэтому вопрос пригодности скриптового языка для компиляции в принципе на повестке не стоял - всё, что без явной типизации, рассматривалось как неизбежно медленное.
Если удобно прототипировать на питоне, то можно солвер перенести на Julia. По опыту, пока не лезешь в совсем низкоуровневые оптимизации типа SIMD производительность будет на уровне 90% от плюсов.
На конкретной платформе и с определенным компилятором UB фактически невозможно - вы всегда можете проверить какое поведение будет у этого компилятора для любой кодовой конструкции.
Это не так. UB означает, что одна и та же конструкция, в том числе, может компилироваться в код с разным поведением в зависимости от оптимизации, инлайнинга и любых других внутренних соображений компилятора. Не говоря уже о том, что проверенное поведение может измениться при малейшем изменении компилятора без нарушения стандарта.
То, о чём вы говорите, - это в стандарте имеет отдельные названия неуточнённое поведение (unspecified behavior) и поведение, определяемое реализацией (implementation-defined behavior). К этим вещам обычно претензий не возникает.
С учётом UB при переполнении знаковых целых компилятор имеет полное право для операций с короткими целыми использовать полноширинные регистры, поэтому +32767 + 1 может быть по факту +32768, потому что под капотом операция выполнилась в 32 или 64 битах. И, если судить по вышеуказанной статье, такое поведение компиляторов можно на деле встретить.
На 24 ГБ RAM + VRAM? Если бы RAM хватало, то там можно было бы 15-35 ток/с ожидать. А тут модель в Q4 (18-20 ГБ) едва влазит, браузер запустил - и уже часть весов будет на диск сгружаться. Я так пробовал на 8 + 64 ГБ запустить 60 ГБ модель, очень медленно. На 16+64 ГБ уже остается запас RAM, 10 ток/с даёт стабильно.
Да ладно, у кадров интерес быстро остынет, как только поймут, что в этой парадигме для Макса с госуслугами в каждом кармане места не предусмотрено на ближайшие N десятилетий.
Ах да, ieee - это для педантов, а ФОРТРАН - ЭТО СКОРОСТЬ!!1 Если нужна правильная арифметика, так указывайте флагом компилятора, что нужно правильно, а не быстро.
На llama.cpp запустится, но нужно самостоятельно скомпилировать его. Но скорость будет низкая с 31b, т.к. плотная модель. 35b-a3b или 26b-a4b будет норм работать, около 20ток/с генерация у меня с rtx 4060, если тензоры экспертов сгружать на cpu.
У меня почти не прошёл, но в последнем предложении сделал ремарку.
Walk.
At 50 meters (about 164 feet), it will take you roughly 30–45 seconds on foot. Driving would actually take longer just to start the engine, maneuver out of parking, and park again at the car wash. It’s also unnecessary fuel consumption, added wear on your car, and overkill for such a short distance.
One quick clarification: If you need to bring the car to the wash, you’ll obviously have to drive it. But if you’re just heading over to check in, pay, grab supplies, or see if there’s a line, walking is the fastest, simplest choice.
Я вот тоже подумал - если мышление, какое бы оно ни было, фундаментально ограничено стековой машиной и не очень большим размером контекста, сингулярности через год можно не бояться. Другая сторона, правда, не менее шокирующая - в скольких же видах даже “творческой” деятельности, как оказалось, даже такой болванчик с недомышлением справляется на все 146%.
Тут сложнее, как мне кажется. LLM базово выдаёт не ответ, а токен. Далее ей передают снова исходный вопрос с этим токеном, и она выдаёт следующий токен. И так далее, пока не выдаст токен со значением “ответ окончен”. Так вот, не напоминает ли это абстрактную вычислительную машину? Если эту схему можно формализовать как машину типа машины Тьюринга, то в процессе генерации ответа LLM может производить вычисления, т.е. “думать”. И в теории, если мы можем переводить текст на естественном языке в логические утверждения, то при надлежащей архитектуре машины можно добиться того, чтобы она делала логически непротиворечивые преобразования, в конце концов, давая-таки решение задачи, не опираясь только лишь на “насобаченность” весов. Мне кажется, что до какой-то степени оно сейчас уже так и есть, но на уровне местечковой, глючной, медленной и недокументированной реализации половины стандарта Common Lisp. В конце концов, не просто же так “режим размышлений” даёт объективный буст к качеству ответа.
С точки зрения абстрактной машины вообще выглядит так, что LLM работают как стековая машина, в которой к тому же для стека есть только операция push, а однажды положенные в стек значения нельзя менять. Можно ли на этом реализовать машину Тьюринга? Я тут недостаточно подкован в теории вычислений.
Прикольно, но есть те же kOS и kRPC для KSP.
С точки зрения полезности лучше добавить что-то к ним или сделать мод для Kitten Space Agency.
Ну вот к поверхности и будут приложены силы, стремящиеся всё разорвать. Как именно будет разрушение идти - отслаивание тонкого слоя с поверхности или распад на более крупные куски - мои знания о прочности не позволяют оценить.
И правильно.
Включать небезопасные оптимизации на уровне всей единицы компиляции - это тяжёлое наследие прошлого. По хорошему, они и должны настраиваться гранулярно на уровне хотя бы функций, а лучше отдельных выражений.
С одной стороны да, поскольку так уже было с выходом Python 3 - что-то так до сих пор и работает на Python 2, потому что переписать дороже, чем поддерживать. С другой стороны, если вдруг весь FAANG начнёт от питона избавляться, остальные тоже, скорее всего, будут смотреть в ту же сторону.
В языке, кроме синтаксиса, есть и семантика. Язык определяет, что программа знает о данных, с которыми работает, и какие преобразования допустимо делать. В Python программа довольно мало знает о данных и мало что имеет право делать в плане “срезания углов”. Видя, например, запись
a + b, компилятор C++ имеет право ругнуться, если обнаруживает, что для типов переменныхaиbне определёнoperator+. Python же не знает, что там за типы. Не знает, определено для них суммирование как встроенная функция, или нужно будет вызватьa.__add__(b), илиb.__radd__(a). Более того, в Python объекты одного и того же типа не обязаны иметь одинаковые атрибуты. По сути, объект - это словарь, из которого по имени достаются атрибуты. Поэтому на любой чих там поиск по хэш-таблице, несколько переходов по указателям и динамический диспатч. Сгенерировать эффективный машинный код заранее не представляется возможным. Если убрать такой беспредельный динамизм - получится что-то типа Julia, где, действительно, всё компилируется +/- в такой же код, что и в Си. Но, как заметил автор, там пока что не просматривается надежда на помощь крупных корпораций в создании ИИ-стека, поэтому там возможности очень неоднородные, может всё работать идеально и быстро, а можно оказаться перед необходимостью с нуля писать движок. Отдельно надо сказать, что когда появлялся Python, компиляторы не очень умели автоматически выводить типы, когда они явно не указаны. Поэтому вопрос пригодности скриптового языка для компиляции в принципе на повестке не стоял - всё, что без явной типизации, рассматривалось как неизбежно медленное.Если удобно прототипировать на питоне, то можно солвер перенести на Julia. По опыту, пока не лезешь в совсем низкоуровневые оптимизации типа SIMD производительность будет на уровне 90% от плюсов.
А assert (и вообще выбрасывание исключений) не считается препятствием для разыменовывания, получается?
Это не так. UB означает, что одна и та же конструкция, в том числе, может компилироваться в код с разным поведением в зависимости от оптимизации, инлайнинга и любых других внутренних соображений компилятора. Не говоря уже о том, что проверенное поведение может измениться при малейшем изменении компилятора без нарушения стандарта.
То, о чём вы говорите, - это в стандарте имеет отдельные названия неуточнённое поведение (unspecified behavior) и поведение, определяемое реализацией (implementation-defined behavior). К этим вещам обычно претензий не возникает.
Предложение хорошее, но поезд компиляторостроения, похоже, слишком далеко уже ушёл.
Вот именно для случая с целыми, что вы описали, недавно была статья: https://habr.com/ru/companies/pvs-studio/articles/276657/
С учётом UB при переполнении знаковых целых компилятор имеет полное право для операций с короткими целыми использовать полноширинные регистры, поэтому +32767 + 1 может быть по факту +32768, потому что под капотом операция выполнилась в 32 или 64 битах. И, если судить по вышеуказанной статье, такое поведение компиляторов можно на деле встретить.
На 24 ГБ RAM + VRAM? Если бы RAM хватало, то там можно было бы 15-35 ток/с ожидать. А тут модель в Q4 (18-20 ГБ) едва влазит, браузер запустил - и уже часть весов будет на диск сгружаться. Я так пробовал на 8 + 64 ГБ запустить 60 ГБ модель, очень медленно. На 16+64 ГБ уже остается запас RAM, 10 ток/с даёт стабильно.
В теории, возможно, но скорость будет упираться в SSD. Скорее всего, 2-5 ток/с. Смотрите флаги -cmoe и --mmap.
Есть ещё синхронная параллельность в виде SIMD и ILP, например. Или стрельба через винт как механическая аналогия.
Да ладно, у кадров интерес быстро остынет, как только поймут, что в этой парадигме для Макса с госуслугами в каждом кармане места не предусмотрено на ближайшие N десятилетий.
Смешно. А что тогда в фортране 1e37 / 1e38 = 0?
https://fortran-lang.discourse.group/t/ifort-ifort-2021-8-0-1-0e-37-1-0e-38-0/4936?u=zaikunzhang
Ах да, ieee - это для педантов, а ФОРТРАН - ЭТО СКОРОСТЬ!!1 Если нужна правильная арифметика, так указывайте флагом компилятора, что нужно правильно, а не быстро.
Project Glasswing?
На llama.cpp запустится, но нужно самостоятельно скомпилировать его. Но скорость будет низкая с 31b, т.к. плотная модель. 35b-a3b или 26b-a4b будет норм работать, около 20ток/с генерация у меня с rtx 4060, если тензоры экспертов сгружать на cpu.
У меня почти не прошёл, но в последнем предложении сделал ремарку.
Walk.
At 50 meters (about 164 feet), it will take you roughly 30–45 seconds on foot. Driving would actually take longer just to start the engine, maneuver out of parking, and park again at the car wash. It’s also unnecessary fuel consumption, added wear on your car, and overkill for such a short distance.
One quick clarification: If you need to bring the car to the wash, you’ll obviously have to drive it. But if you’re just heading over to check in, pay, grab supplies, or see if there’s a line, walking is the fastest, simplest choice.
А 122b-a10b не работает с экспертами в RAM? Должна быть чуток поумнее с такой же примерно скоростью, если RAM хватает.