При оптимизации кастомной ограниченной приоритетной очереди автор столкнулся с парадоксальным случаем, когда уровень оптимизации O3 работал на 123% медленнее, чем O2. Этот результат был подтверждён на процессорах Intel Haswell и AMD Zen 3, что указывает на системную проблему, а не на специфичную для архитектуры. Бенчмарки проводились с использованием criterion, а результаты демонстрировали устойчивую регрессию производительности при повышении уровня оптимизации.

Реализация использует отсортированный Vec с бинарным поиском вместо бинарной кучи, что эффективнее для данного случая из-за требования уникальности id элементов. Ключевую роль играет функция сравнения, работающая с числами с плавающей запятой, которые известны своей сложностью в сравнении. Для анализа производительности автор использовал flamegraph, чтобы выявить разницу в поведении между уровнями оптимизации.

Nice read. Last week I wrote a blog post about two noteworthy cases of O3 being slower than O2 in C++: https://barish.me/blog/cpp-o3-slower/ In the branchy function, id is only compared if distance is equal, and since distance is a random float, this almost never happens and the

SSA (Static Single Assignment) — это популярная форма промежуточного представления, используемая в большинстве современных компиляторов, включая LLVM, GCC, V8 и HotSpot. Её главная сила — в упрощении анализа и оптимизации программ. SSA преобразует императивный код с изменяемыми переменными в форму, где каждая переменная присваивается только один раз, что делает зависимости между значениями явными и легко отслеживаемыми.

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

• Обсуждение разошлось в сторону: от обсуждения SSA как формы IR и её влияния на оптимизации, к дискуссии о том, что такое SSA, как она соотносится с CPS и какие у неё есть trade-off'ы, а также к тому, что именно делает SSA «особенной» и как она влияет на компиляторы и языки.

SAT-солверы — это программы, решающие задачу выполнимости булевых формул (SAT), которая является NP-полной. Это означает, что любые NP-полные задачи, такие как задача коммивояжера, раскраска графа или Судоку, могут быть сведены к SAT и решены с помощью этих инструментов. SAT-солверы находят значения переменных, при которых булева формула становится истинной, предоставляя эффективный способ решения сложных задач, которые иначе требовали бы экспоненциального времени.

На примере Судоку автор демонстрирует, как преобразовать правила игры в систему булевых ограничений. Для каждой клетки (i,j) и цифры k вводится переменная x_{i,j,k}, где true означает, что клетка содержит цифру k. Правила игры переводятся в ограничения: каждая клетка должна содержать ровно одну цифку (x_{i,j,1} ∨ x_{i,j,2} ∨ ... ∨ x_{i,j,9} и ¬x_{i,j,k} ∨ ¬x_{i,j,l} для k≠l), каждая цифра должна встречаться ровно один раз в строке, столбце и под-сетке. SAT-солвер находит удовлетворяющее всем этим ограничениям присвоение значений переменным, решая головоломку.

• SAT и MILP-солверы недооценены: первые хорошо знакомы инженерам, вторые — нет, хотя MILP позволяет естественно выразить оптимизацию и ограничения.
• Исторически открытые MILP-солверы отставали от коммерческих, что сдерживало их использование.
• SAT-солверы и MILP-солверы дополняют друг друга: SAT хорошо для задач «есть/нет», MILP — для задач оптимизации.
• Практически любую задачу можно выразить как MILP, и SAT-солверы могут быть использованы для решения MILP.

После публикации результатов тестов, показывающих, что Cloudflare Workers значительно уступают по производительности Vercel, команда Cloudflare проанализировала тест и обнаружила ряд факторов, повлиявших на результат.

Во-первых, выяснилось, что в тесте использовалась более старая версия Cloudflare Workers, которая не была оптимизирована для этого конкретного типа нагрузки. Cloudflare немедленно выпустила обновление, улучшающее производительность.

Во-вторых, в тесте использовалась библиотека, которая вносила дополнительные накладные расходы на стороне Cloudflare, но не на стороне Vercel. После замены библиотеки на более оптимизированную, разница в производительности значительно сократилась.

Кроме того, команда обнаружила, что тест не полностью изолировал переменные — часть замедления была вызвана сетевыми задержками, а не производительностью самого Workers. После настройки теста для измерения только времени выполнения кода, разница стала минимальной.

В конечном счете, Cloudflare удалось не только догнать, но и превзойти Vercel по некоторым показателям, просто устранив узкие места в своем стеке.

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

• Cloudflare и Vercel продолжают обмениваться тестами и оптимизациями, но вместо обвинений они фактически сотрудничают, чтобы улучшить свои продукты.
• Стороны соревнуются в прозрачности: Cloudflare публикует исходные данные теста, а Vercel делает тот же тест открытым исходным кодом.
• Сообщество отмечает, что обе платформы теперь демонстрируют лучшую производительность, чем раньше, и что конкуренция в конечном счете выгодна для пользователей.

Проект JIT-компилятора для PostgreSQL сталкивается со сложностями из-за особенностей современных процессоров. Автор объясняет, что даже хорошо написанный интерпретатор может проигрывать в производительности из-за непредсказуемости переходов в switch-based интерпретаторах.

Используя технику "computed gotos" (динамических переходов), можно значительно ускорить интерпретацию, сделав шаблоны переходов более предсказуемыми для предсказателя ветвления процессора. Это может дать до 15-20% прироста производительности.

Автор также упоминает, что его JIT-решение для PostgreSQL будет использовать этот подход, а также другие оптимизации, такие как векторизация и inlining, чтобы превзойти стандартный интерпретатор PostgreSQL.

Кроме того, автор отмечает, что оптимизация под современные процессоры (особенно с их out-of-order исполнением и предсказанием ветвлений) требует осторожного подхода. Например, код должен быть структурирован так, чтобы минимизировать зависимости по данным и максимизировать параллелизм на уровне инструкций.

В итоге, проект направлен не только на создание JIT-компилятора, но и на то, чтобы переосмыслить, как должен работать интерпретатор, чтобы эффективно использовать современные процессоры.

• Обсуждение затронуло ограничения JIT в iOS из-за политики Apple, что влияет на производительность и возможности использования JIT в этой системе.
• Участники обсудили, что JIT-компилятор может быть полезен для оптимизации, но его отсутствие в iOS ограничивает возможности приложений.
• Также обсуждались различные аспекты производительности интерпретатора и JIT, включая влияние на предсказание переходов и спекулятивное исполнение.
• Участники упомянули, что JIT может быть полезен для DSL или других специализированных языков, но ограничения iOS могут затруднить это.

Градиентный спуск в глубоком обучении работает вопреки классическим представлениям. Традиционный анализ предсказывает, что алгоритм должен оставаться в «стабильной области», где острота функции потерь (максимальное собственное значение гессиана) не превышает порога 2/η. Если острота становится выше, градиентный спуск на квадратичной аппроксимации начинает расходиться.

Однако на практике при обучении нейросетей острота часто растёт и достигает этого порога, но градиентный спуск не расходится, а продолжает сходиться. Это происходит потому, что реальная динамика оптимизации сложнее локальной квадратичной аппроксимации. Алгоритм стабилизируется за счёт нелинейных эффектов и взаимодействия параметров, что позволяет ему эффективно работать даже вне теоретически стабильной области.

• Обсуждение посвящено концепции "центрального потока" (central flow) — теоретической модели, объясняющей динамику градиентного спуска в глубоком обучении через проекцию градиента потерь на градиент "остроты" (sharpness).
• Участники отмечают, что модель предсказывает поведение функции потерь и объясняет, как нестабильность и осцилляции используются для самоисправления и обучения, а не просто избегаются.
• Поднимается вопрос о практической применимости модели: является ли она лишь теоретическим инструментом для понимания или может быть использована для ускорения сходимости на практике, например, через скользящее среднее.
• Обсуждается ограничение модели — её детерминистическая природа и необходимость проверки её работы со стохастическими градиентами (SGD), используемыми в реальных задачах.
• Упоминается, что авторы статьи видят центральный поток как инструмент для анализа, а не как готовый практический метод оптимизации.

Нормализация тензоров в больших нейросетях — ключевой аспект их стабильного обучения. Она предотвращает проблемы численной нестабильности, такие как переполнение или исчезновение градиентов, и упрощает проектирование алгоритмов, обеспечивая предсказуемость размеров весов, активаций и обновлений. Хотя нормализация активаций (например, layer norm) и градиентов уже стала стандартом, нормализация весовых матриц применяется реже, несмотря на потенциальные преимущества.

Ограничение норм весов помогает контролировать относительный размер обновлений, избегать взрыва норм и улучшать condition number матриц, делая их поведение более предсказуемым. Это позволяет сосредоточить усилия по настройке гиперпараметров на наиболее значимых тензорах. Практические реализации, такие как в EDM2, показывают, что такие методы могут улучшать устойчивость и эффективность обучения больших моделей.

• Обсуждение возможности ограничения весов нейронных сетей на многообразиях и переосмысления оптимизации с такими ограничениями.
• Вопросы о новизне подхода, учитывая существующие работы и библиотеки (Pymanopt) по оптимизации на многообразиях.
• Критика и сомнения в представленных эмпирических результатах (низкая точность на CIFAR-10, малый масштаб модели).
• Обсуждение формата публикации (блогпост vs. научная статья) и мотивов авторов.
• Замечания о дизайне и UX сайта с блогпостом (положительные и отрицательные).

Системы эффектов в языках программирования, такие как в Flix, строго контролируют побочные действия вроде вывода в консоль, что мешает привычной отладке с помощью println. Ложь системе эффектов через unchecked_cast приводит к проблемам: компилятор удаляет «бесполезный» код без видимых эффектов или ломает семантику при оптимизациях.

Flix ищет прагматичный баланс между строгостью и удобством, предлагая временные решения для отладки без нарушения гарантий. Например, вводят функцию dprintln, которая обманывает систему эффектов, но рискует быть удалённой оптимизатором. Ключевой вывод: языки должны позволять гибкость там, где она нужна, без компромисса с безопасностью.

• Обсуждается подход Flix к типизации эффектов, включая системные (например, Debug) и возможность создания пользовательских эффектов.
• Рассматриваются целевые use-case языка: платформенная независимость, совместимость с JVM/Java, применение в бэкенде и академические цели.
• Поднимаются вопросы о практичности системы эффектов: необходимость для оптимизаций, потенциальная избыточность и сложность.
• Обсуждается проблема автоматической параллелизации и оптимизации, включая риски переупорядочивания или удаления операций ввода-вывода.
• Упоминаются аналогичные реализации в других языках (Haskell, Koka, Roc, Effekt) и их эволюция в моделировании эффектов.

Простое введение в z3

Изучение мира решателей ограничений на простых примерах.

Что такое решатели?

Решатели — это инструменты, которые принимают правила и ограничения, а затем находят решение. Они не всегда быстрее специальных алгоритмов, но гораздо гибче при изменении условий. Применяются для планирования, распределения ресурсов и других задач.

Терминология

В документации z3 много жаргона. Например, «Sort» означает тип, а «constants» — это переменные, которыми оперирует решатель. Solver работает со своим языком SMT-LIB2, а библиотеки переводят код в этот язык.

Простое уравнение

Решим уравнение x + 4 = 7. Вот код на Rust:

use z3::{Solver, ast::Int};
fn main() {
    let solver = Solver::new();
    let x = Int::new_const("x");
    solver.assert(&(x + 4).eq(&7));
    assert_eq!(solver.check(), SatResult::Sat);
    let model = solver.get_model().unwrap();
    println!("x = {}", model.eval(&x, true).unwrap());
}

Решатель находит x = 3. Это базовый пример, но он показывает принцип работы.

• Обсуждение причин некорректных ответов в задаче о сдаче (coin change) при использовании решателя Z3 без нижних границ, что приводит к минимизации до отрицательной бесконечности.
• Рекомендации ресурсов для изучения SAT/SMT-решателей, включая конкретные PDF-документы и статьи.
• Обсуждение практического применения решателей (Z3, OR-Tools, MiniZinc) для различных задач, включая игры и оптимизацию запросов.
• Сравнение и рекомендации по выбору решателей для начинающих на Python, с упоминанием Z3, OR-Tools и CPMpy.
• Трудности моделирования проблем для решателей и важность правильной постановки ограничений для избежания неинтуитивного поведения.
• Обсуждение технических особенностей интеграции решателей в языки программирования, таких как перегрузка операторов в Rust.
• Упоминание о применении решателей для доказательства теорем и поиска контрпримеров, например, к гипотезе Гольдбаха.

Сложные LeetCode-задачи — простые задачи на ограничения

Интервьюер спросил: «Минимальное количество монет для сдачи 37¢ при номиналах [10, 9, 1]».
Жадный алгоритм даёт 10 монет, оптимум — 4. Ручное ДП сложно, а в MiniZinc — три строки:

int: total; array[int] of int: values = [10,9,1];
array[index_set(values)] of var 0..: coins;
constraint sum(c in index_set(coins)) (coins[c]*values[c]) == total;
solve minimize sum(coins);

Запускаем онлайн, получаем ответы за секунды.

---

Другие «сложные» задачи

1. Максимальная прибыль на акциях
   Дано: цены за день.
   Решение: купить до продать, максимизировать prices[sell]-prices[buy].

   array[int] of int: prices;
   var int: buy; var int: sell;
   constraint sell > buy;
   solve maximize prices[sell]-prices[buy];
   

2. Три числа дают 0 в сумме
   Нужно ли среди списка выбрать 3 числа со знаками ±1, чтобы сумма была 0?

   array[int] of int: nums;
   array[index_set(nums)] of var {-1,0,1}: coef;
   constraint sum(i in index_set(nums)) (nums[i]*coef[i]) = 0;
   constraint sum(i in index_set(nums)) (abs(coef[i])) = 3;
   solve satisfy;
   

3. Самый большой прямоугольник в гистограмме
   Ширина столбцов = 1, высоты заданы.

   array[int] of int: h;
   var 1..length(h): x; var 1..length(h): dx; var 1..max(h): y;
   constraint x+dx <= length(h);
   constraint forall(i in x..x+dx) (y <= h[i]);
   solve maximize (dx+1)*y;
   

---

Плюсы и минусы солверов

• + Код в 3–5 строк, добавление новых ограничений бесплатно.
• – Сложность работы непредсказуема, медленнее «идеального» алгоритма.
• – На собеседовании спросят «а сложность?» — ответа нет.

Вывод: если нужен рабочий код быстро — бери солвер; если нужна гарантированная скорость — пиши алгоритм вручную.

• Кто-то предлагает решать «задачи на подбор монет» и прочие LeetCode-загадки не вручную, а вызывать готовый constraint-/SAT-/SMT-солвер — быстро и универсально.
• Интервьюеры возражают: «мы хотим увидеть, как ты сам пишешь алгоритм, а не вызываешь библиотеку; иначе как проверить сложность и масштабируемость?»
• Сторонники солверов отвечают: в продакшене важен рабочий результат, а не «олимпиадная остроумность»; к тому же солвер легко добавляет новые ограничения.
• Часть комментаторов считает, что LC-интервью вообще плохо предсказывают рабочие навыки и дискриминируют тех, кто не зубрит шаблоны.
• Итог: constraint-solvers — мощный инструмент, но на типовом собеседовании их использование чаще всего «вне правил», поэтому приходится писать ручное решение, даже если в реальной жизни ты бы просто вызвал OR-Tools.

Мешеры: геометрия невозможного

Кратко
Невозможные объекты — рисунки, которые мозг воспринимает, но в 3D не существуют. Раньше их «впихивали» в 3D: резали или гнули. Резка портит геометрию, гнутье мешает освещению и ломает алгоритмы (расстояния, диффузия и т.д.).

Мешер — новая сетка: у каждой вершины только 2D-координаты экрана, а у рёбер — разница глубин. Сумма этих разниц по циклу может быть ≠ 0; в этом вся «невозможность». Построено на дискретном внешнем исчислении.

Что умеет

• Сглаживание, диффузия тепла, геодезические расстояния.
• Инверсный рендеринг: из 2D-фото невозможного треугольника восстанавливаем мешер.
• Легко менять освещение, не портя форму.

Демо
Слева — сглаживание 2D-координат, в центре — сглаживание глубин, справа — всё вместе.
Из обычного тора оптимизацией получаем настоящий невозможный Penrose-треугольник.

Код и статья — на сайте проекта.

• Авторы фактически оцифровали «трюки Эшера»: в 3D-модели хранят только x, y и разность z между концами рёбер, вместо полных z-координат.
• Это превращает невозможные геометрии в «возможные» для нашего зрения, обманывая 2.5-D «прошивку» мозга.
• Комментаторы спорят: обман ли это или топологическая, неевклидова интеграция, которую приматье зрение легко переваривает.

Типы — это небеса

В CL тип — это множество, и каждый объект принадлежит хотя бы одному.
(type-of 37) → (INTEGER 0 …)
(type-of "漣") → (SIMPLE-ARRAY CHARACTER (1))

(typep 37 'integer) → T, аналогично 'real, 'number, t.
Типы не образуют строгую иерархию: строка всегда string, но не обязательно simple-array.

Типы для корректности

(defun f (n) (+ n "漣")) — компилятор жалуется: "漣" не NUMBER.
(defstruct sky (molecules 0 :type integer))
(make-sky :molecules 1.1) — ошибка типа.
То же для длины массива: (simple-array character (17)) отвергнет строку из 18 символов.

Типы для оптимизации

Подсказки помогают компилятору.
(defun add (n) (+ n 37)) без аннотаций → общий код.
Добавим (declare (type fixnum n)) — генерируется короткая машинная инструкция LEA.

Классы — это земля

Классы реальны: (defclass point () ((x :initarg :x) (y :initarg :y))).
Наследование и множественный диспатч generic-функций работают как в CLOS.

Сердце машины

• «Абстрактные» классы — просто не создают экземпляров.
• fixnum — самый быстрый целый, в SBCL 61 бит (63 на 64-битных).
  (type-of 4611686018427387904) → (INTEGER 4611686018427387904) — уже bignum.

Итог

CL даёт строгие типы без потери гибкости: проверки на этапе компиляции и выполнения, оптимизация, но возможность менять код в REPL.

• Участники согласились, что статья преувеличивает гарантии статической проверки типов в Common Lisp: SBCL даёт лишь «вежливые» предупреждения, а стандарт вообще не требует обязательной проверки.
• Обсуждали «квирки» иерархии типов: отношения между string, simple-array и vector уточняли через subtypep и typep; выяснилось, что они связаны отношениями подтипов.
• Отметили особенность «апгрейда» типов элементов массивов: итоговый тип всегда супертип заявленного, причём сохраняются отношения подтипов.
• Вспомнили специальную форму the, которая служит как для оптимизации, так и для runtime-assert’ов, но не даёт жёстких гарантий.
• Пошутили о том, что массив с элементами типа NIL формально считается строкой, поскольку NIL — подтип любого типа, включая CHARACTER.

Байес

$$P(A|B)=\frac{P(B|A)P(A)}{P(B)}$$ Обновляем вероятность гипотезы при новых данных.

def bayes(p_d, p_t_d, p_t_nd):
    p_t = p_t_d*p_d + p_t_nd*(1-p_d)
    return p_t_d*p_d / p_t

Энтропия

$$H(X)=-\sum_x P(x)\log P(x)$$ Измеряем неопределённость распределения.

import numpy as np
H = lambda p: -np.sum(p*np.log(p, where=p>0))

KL-дивергенция

$$D_{\text{KL}}(P|Q)=\sum_x P(x)\log\frac{P(x)}{Q(x)}$$ Сколько бит «лишних» нужно, если вместо истинного распределения $P$ использовать $Q$.

Кросс-энтропия

$$H(P,Q)=-\sum_x P(x)\log Q(x)$$ Используется как лосс в классификации.

Линейная алгебра

Линейное преобразование

$$\mathbf{y}=A\mathbf{x}$$ Матрица $A$ переводит вектор $\mathbf{x}$ в пространство признаков.

Собственные значения и векторы

$$A\mathbf{v}=\lambda\mathbf{v}$$ Направления, вдоль которых преобразование лишь растягивает/сжимает.

SVD

$$A=U\Sigma V^\top$$ Разложение на ортогональные и диагональные матрицы; основа PCA и рекомендательных систем.

Оптимизация

Градиентный спуск

$$\theta_{t+1}=\theta_t-\eta\nabla_\theta J(\theta)$$ Шагаем против градиента, чтобы минимизировать функцию потерь $J$.

Backprop

$$\frac{\partial L}{\partial W^{(l)}}=\delta^{(l)}(a^{(l-1)})^\top$$ Цепное правило для обучения нейросетей.

Функции потерь

MSE

$$\text{MSE}=\frac{1}{n}\sum_i (y_i-\hat y_i)^2$$ Классика регрессии.

Кросс-энтропия

$$L=-\sum_i y_i\log \hat y_i$$ Стандарт для классификации.

Продвинутые темы

Диффузия

$$q(x_t|x_{t-1})=\mathcal N(x_t;\sqrt{1-\beta_t}x_{t-1},\beta_t I)$$ Постепенное добавление шума и обратное восстановление.

Свертка

$$(f*g)[n]=\sum_m f[m]g[n-m]$$ Извлечение локальных паттернов в CNN.

Softmax

$$\text{softmax}(z_i)=\frac{e^{z_i}}{\sum_j e^{z_j}}$$ Превращает логиты в вероятности.

Attention

$$\text{Attention}(Q,K,V)=\text{softmax}\left(\frac{QK^\top}{\sqrt d_k}\right)V$$ Взвешенная сумма значений по релевантности запроса и ключей.

---

Краткий конспект ключевых уравнений ML: от вероятностей до трансформеров, с кодом и интуицией.

• @dkislyuk и @morleytj критикуют формат «списка формул» без связного объяснения и советуют читать оригинальную теорию Шеннона.
• @cl3misch нашёл баг в коде энтропии из-за неинициализированных значений и несоответствие формулы кросс-энтропии.
• @dawnofdusk и @cgadski хвалят полноту материала как удобную шпаргалку для быстрого погружения.
• @bee_rider и @calebkaiser обсуждают применение сингулярных чисел и собственных значений в LLM и LoRA.

• Зачем замедлять программу?
  Искать race-conditions, «виртуально» оценить выгоду оптимизации (как в Coz) и проверять точность профилировщиков. Для этого меняют расписание потоков или вставляют задержки.

• Как замедляют сейчас?
  Грубо: Thread.sleep, остановка потоков, вставка лишнего байт-кода. Это снижает точность.

• Наша идея
  Вставлять задержки внутри basic block на уровне x86. Нужны инструкции, которые:
  – надёжно тратят циклы;
  – не искажают семантику;
  – не оптимизируются CPU за счёт out-of-order.

• Проблема
  Современные процессоры выполняют независимые mov параллельно, поэтому просто добавить «тяжёлые» команды недостаточно — нужно учитывать зависимости и микроархитектуру.

• Используются разные способы замедления: от NOP-циклов и RDTSC до AVX-нагрузок и «тормозных» устройств вроде C64 Snail или Turbo-кнопки.
• Замедление помогает выявлять N+1-запросы, неработающие кеши и другие узкие места, которые на быстрых машинах незаметны.
• Современные CPU оптимизируют NOP/MOV на стадии переименования, поэтому они плохо подходят для точного контроля времени.
• Causal-profiling (Coz) и специальные прокси (Toxiproxy, dummynet) позволяют «ускорять» выбранный код, оставляя остальное медленным, чтобы заранее оценить выгоду оптимизации.

Идея: вместо одного огромного LLM использовать роутер, который для каждого запроса выбирает наиболее подходящую по размеру и качеству модель из набора.
Проблема: GPT-4/5 дороги и не всегда нужны; мелкие модели дешевле, но хуже.
Решение: обучить роутер-LLM прогнозировать, какая модель справится с задачей с минимальными затратами и заданным порогом качества.

Методика:

• Собрали 30 задач NLP (перевод, суммаризация, код и т.д.).
• Для каждой задачи подготовили набор моделей разных размеров (от 1.3 B до 70 B параметров).
• Обучили роутер на 100k примеров, где вход — запрос, выход — выбор модели + оценка качества.
• Использовали Pareto-оптимизацию: минимизировать стоимость при фиксированном качестве.

Результаты:

• При том же качестве, что у GPT-4, роутер сокращает стоимость в 4–6 раз.
• На 50 % запросов достаточно модели 7 B вместо 70 B.
• Роутер добавляет <1 мс задержки (незаметно).

Вывод: дешевле и быстрее держать «зоопарк» моделей + роутер, чем один сверхбольшой LLM.

• Обсуждают «роутинг» запросов между разными LLM вместо одной большой модели: берут 70 % примеров, смотрят, какая модель лучше справляется с каждым кластером, и на оставшиеся 30 % уже маршрутизируют.
• Идея пока простая (эмбеддинг + выбор лучшей по истории), но сообщество считает её неизбежным следующим шагом после CoT и способом дешевле масштабироваться.
• Критика: не учитывают латентность роутера, могут промахнуться со «сложными» запросами, выглядящими простыми; GPT-5 редко включает reasoning-модель.
• Некоторые сравнивают с NotDiamond и другими стартапами, а также с «облачной» эволюцией: сначала дорого, потом дешевеет.
• Видение будущего — AGI как ансамбль специализированных модулей, которые можно миксовать под задачу пользователя.

Производная показывает, как меняется функция.
Для y = x² – 6x + 13 производная y' = 2x – 6.
Знак y' подсказывает, куда идти вниз по графику; ноль означает минимум.
Решив 2x – 6 = 0, сразу получаем x = 3, y = 4.
Итеративный спуск (градиентный) полезен, когда аналитическое решение сложно.

Градиент — вектор частных производных по каждому аргументу.
Для w = f(x, y, z)
∇f = [∂w/∂x, ∂w/∂y, ∂w/∂z].
Каждая компонента показывает, насколько w изменится при приращении соответствующей переменной на 1.

• Градиенты удобно представлять как «карты стрелок», а Якобиан — как набор таких карт для каждой выходной координаты.
• Хесс-матрица — это вторые производные скалярной функции, и её форма (n×n) возникает только при одномерном выходе.
• Визуальные подходы помогают интуитивно понимать устойчивые/неустойчивые точки и алгоритмы оптимизации.
• Современные инструменты (Julia, Enzyme) позволяют эффективно вычислять Якобианы и Хессианы автоматическим дифференцированием.
• Человеческое зрение быстро «находит минимум» лишь в низких размерностях; в высших размерностях без вычислений не обойтись.

Сильнейшая модель за 5 минут на ноутбуке
Победитель: 1.8-млн-параметровный GPT-подобный трансформер, обученный на ~20 млн токенов TinyStories и показавший 9.6 перплексии. Пример:

Once upon a time, there was a little boy named Tim…

Ограничение времени

5 минут — это ~300 млн токен-шагов. Большие модели не успевают, мелкие (10 k) быстро выходят на плато. Оптимум — 1-2 млн параметров.

Скорость

На M1 Pro (MPS) достигал 3000 ток/с.

• torch.compile, float16, MLX — без выгоды.
• Градиентное накопление тормозит.
• Главное: минимальный размер модели и MPS.

Датасет

Simple Wikipedia давала факты без смысла («Paris, France is a city in North Carolina»).
TinyStories (рассказы уровня 4-летнего) — простые паттерны, мало имён, быстрая сходимость.

• Обсуждение вращается вокруг тренировки маленьких языковых моделей на ноутбуке: почему это важно для науки и практики.
• Участники сравнивают ограничения по времени, энергии (джоулям) и железу; предлагают «AI-олимпиаду» за лучший результат на данный бюджет.
• Приводятся конкретные приёмы: Muon-оптимизатор, улучшенная инициализация, «cramming» за день на лэптопе, идея специализированных моделей «под задачу».
• Задаются вопросы о данных, переобучении, диффузных архитектурах и о том, когда марковская цепь окажется достаточной.
• В целом тон оптимистичен: даже на обычном ноутбуке можно быстро экспериментировать и учиться, не дожидаясь супер-кластеров.