Présentation

Le script 01_attention.py montre comment le moteur d'optimisation einfold transforme une requête SQL décrivant l’attention d’un transformeur en un algorithme équivalent à FlashAttention. Le modèle utilise D=64 caractéristiques par tête, ce qui implique un facteur d’échelle de 1/√64 = 1/8. La requête SQL décrit les scores comme la somme SUM(q.x * k.x) / 8.0 puis applique un softmax pondéré pour obtenir la sortie.

Mécanisme d'optimisation

Einfold analyse le plan naïf qui stockerait N×N scores et applique une règle générique : toute moyenne pondérée par un softmax dont les scores proviennent d’une jointure est fusionnée. Cette règle détecte le motif présent dans les deux variantes SQL fournies (ATTENTION_WINDOW et ATTENTION_GROUP_BY) et génère un pipeline où les blocs de clés sont parcourus en flux, exactement comme le décrit l’article FlashAttention (Dao et al., 2022). Aucun code spécifique à l’attention n’est requis ; la même règle accélère également le contrôle de Nadaraya–Watson, démontrant la généralité du mécanisme.

CREATE OR REPLACE VIEW attention AS
WITH scores AS (
  SELECT q.t AS i, k.t AS j, SUM(q.x * k.x) / 8.0 AS s
  FROM q JOIN k ON q.d = k.d
  WHERE q.t >= k.t
  GROUP BY q.t, k.t),
weights AS (
  SELECT i, j, exp(s - MAX(s) OVER (PARTITION BY i)) AS w
  FROM scores),
norm AS (
  SELECT i, SUM(w) AS z FROM weights GROUP BY i)
SELECT w.i AS t, v.d, SUM(w.w / n.z * v.x) AS x
FROM weights w
JOIN v ON w.j = v.t
JOIN norm n ON w.i = n.i
GROUP BY w.i, v.d

Évaluation des performances et gradients

Le script exécute trois hôtes : DataFusion, DataFusion avec einfold et DuckDB. Chaque hôte calcule le passage avant via la requête SELECT t, d, x FROM attention ORDER BY t, d et compare le résultat à une implémentation JAX identique. La perte, définie comme la moitié de la norme au carré de la sortie, est différenciée en une seule instruction SQL grâce à ddx. Le gradient de chaque tenseur (Q, K, V) est obtenu avec grad(loss, q.x) etc., puis validé par jax.grad(loss, argnums=(0,1,2)). Cette approche montre que le plan optimisé conserve la différentiabilité exacte, même lorsque les masques sont implémentés comme lignes absentes.

Limites et perspectives

Le démonstrateur repose sur des jeux de données modestes et ne mesure pas explicitement le gain en temps d’exécution ou l’utilisation mémoire. L’absence de métriques chiffrées empêche d’évaluer l’impact réel de la suppression du tableau N×N. De plus, la règle de fusion actuelle ne couvre que les moyennes pondérées par un softmax ; d’autres motifs de calculs matriciels pourraient nécessiter des extensions. Enfin, la compatibilité dépend de la capacité des moteurs SQL sous-jacents à supporter les fonctions d’agrégation window et les sous‑requêtes, ce qui peut varier entre implémentations.