kernel-fun 0.2.0.dev1__py3-none-any.whl

kernel_fun-0.2.0.dev1.dist-info/METADATA

@@ -0,0 +1,347 @@
+Metadata-Version: 2.5
+Name: kernel-fun
+Version: 0.2.0.dev1
+Summary: CuTe/Triton kernels for linear-attention ops (KDA chunk kernel, KDA short conv), as drop-in replacements for flash-linear-attention, on Blackwell
+Project-URL: Source, https://github.com/allenai/kernel-fun
+Project-URL: Research ladder, https://github.com/allenai/kernel-fun-dev
+Author: Allen Institute for AI
+License-Expression: Apache-2.0
+License-File: LICENSE
+License-File: NOTICE
+License-File: THIRD_PARTY_NOTICES.md
+Keywords: blackwell,cuda,cute,cutlass,flash-linear-attention,kda,linear-attention,triton
+Classifier: Development Status :: 3 - Alpha
+Classifier: Environment :: GPU :: NVIDIA CUDA :: 13
+Classifier: Intended Audience :: Science/Research
+Classifier: Operating System :: POSIX :: Linux
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Topic :: Scientific/Engineering :: Artificial Intelligence
+Requires-Python: >=3.11
+Requires-Dist: fla-core<0.6,>=0.5.2
+Requires-Dist: torch>=2.7
+Requires-Dist: triton>=3.3
+Provides-Extra: cu12
+Requires-Dist: cuda-python<13,>=12.8; extra == 'cu12'
+Requires-Dist: nvidia-cutlass-dsl>=4.2.1; extra == 'cu12'
+Provides-Extra: cu13
+Requires-Dist: cuda-python>=13; extra == 'cu13'
+Requires-Dist: nvidia-cutlass-dsl[cu13]>=4.4; extra == 'cu13'
+Description-Content-Type: text/markdown
+
+# kernel-fun
+
+> **Experimental, in development.** These kernels have only been tested on B300 GPUs, for
+> the specific model configurations our training runs use. They exist to make those runs
+> faster and are not tested for general use — outside that hardware and those shapes, treat
+> both the correctness and the speed as unknown.
+
+Drop-in replacements for flash-linear-attention's linear-attention ops, on Blackwell.
+
+```python
+from kernel_fun.kda import chunk_kda          # instead of: from fla.ops.kda import chunk_kda
+from kernel_fun.cconv import causal_conv1d    # instead of: from fla.modules.convolution import causal_conv1d
+```
+
+Same signature, same returns. Any call this package does not implement — wrong
+architecture, wrong shape, a flag it has never seen, a CUDA graph capture of a shape that
+has not run eagerly yet — is forwarded to fla verbatim. Installing it can change how fast a
+model trains, not what it computes beyond kernel-level rounding.
+
+## Two repos — where to ship changes
+
+Split out of the research ladder on 2026-09-09. Two repos, one direction of flow:
+
+| | | |
+|---|---|---|
+| **`allenai/kernel-fun-dev`** | the research ladder | `loop/` + `kernels/<family>/ideas/*` — forks, falsifications, recorded bench rows and their `history/`. Nothing there is installable. |
+| **`allenai/kernel-fun`** | this repo | the release artifact: the winning chain only, knobs frozen, dead branches gone. The only thing that builds a wheel, and the only route into OLMo-core. |
+
+```
+kernels/kda/ideas/005-*/  --(tools/vendor.py)-->  src/kernel_fun/kda/_kernels/  --(INTEGRATION.md §1)-->  OLMo-core
+      ladder repo                                        this repo
+```
+
+- **A new kernel idea, or a change to one that is still being falsified:** the ladder. It
+  owns the bench, the oracle and the `code_sha` that makes `code_unchanged_since` mean
+  something.
+- **A change to what ships** — a released stage, the fallback gate, the call cache, the
+  public signatures, the tests, the version: **here**. Never by editing OLMo-core's copy.
+- **A won ladder row that should ship:** `python tools/vendor.py --family <f> --from-commit
+  <ladder sha>` here, then its checklist by hand, then a release ("Releasing" below).
+  `tools/vendor.py` and `tools/drift.py` need a ladder checkout: they default to
+  `../kernel-fun-dev` beside this repo, and take `--ladder PATH` or `$KERNEL_FUN_LADDER`.
+- Version tags (`v0.2.0`, …) live **here**. `_provenance.py`'s `SOURCE_COMMIT` is a sha in
+  the *ladder*; `VENDORED_FROM` in OLMo-core is a sha in *this* repo.
+
+**On the names — `allenai/kernel-fun` means THIS repo, and only since 2026-09-09.** Before
+that date it was the research ladder, which was renamed `kernel-fun-dev` to hand the name
+over. Three consequences worth knowing:
+
+- The pip/import name has been `kernel-fun` / `kernel_fun` throughout and did not change, so
+  nothing downstream — OLMo-core's extra, `caleb/cute-kda-vendored`, the wheel — moved
+  because of any of this.
+- **`kernel-fun` in anything written before 2026-09-09 means the ladder, not this repo.**
+  That includes commit messages, `git log` subjects, lockfiles, `VENDORED_FROM` shas and
+  image tags. Check the date before chasing a path or resolving a sha; a pre-split
+  `kernel-fun` sha will not exist in this repo's history, which starts at the split.
+- The old redirect is gone. `allenai/kernel-fun` used to redirect to the renamed ladder;
+  creating this repo under that name retired the redirect, which is exactly why it was done
+  this way. Anything still pointing at that URL for the *ladder* now silently reaches the
+  *package* — repoint it at `kernel-fun-dev`. A Beaker image named `kernel-fun-<date>` is
+  the ladder's image and deliberately keeps that name (its `scripts/image.sh` explains why).
+
+## Status and numbers
+
+| family | status | production shape, B300 |
+|---|---|---|
+| `kda` | shipping | fwd+bwd **23.74 ms vs fla 36.56 = 1.540x** (gate + q/k norm in-op; B16 T8192 H=HV16 K128 V256) |
+| `cconv` | shipping | isolated bwd **0.344 ms vs fla 1.597 = 4.65x**, fwd 0.190 vs 0.307 = 1.62x (B16 T8192 D2048 W4) |
+| `gdn`, `gnorm` | to follow | — |
+
+The kda numbers, measured 2026-09-02 on holmes-cs-aus-515 (the ladder's kda/005 record 001):
+
+| row | fla | kernel-fun | |
+|---|---|---|---|
+| fwd+bwd, gate and norm in-op (the production call) | 36.56 ms | 23.74 ms | **1.540x** |
+| fwd+bwd, pre-computed gate | 34.90 ms | 21.80 ms | 1.601x |
+| fwd only | 7.50 ms | 5.95 ms | 1.260x |
+| fwd+bwd at B=8 (the 1.4b ladder's real microbatch) | 17.80 ms | 11.30 ms | 1.575x |
+
+(The previous release quoted 1.545x on the production row from a different node and day;
+the fla baseline moved more than our chain did. Same-run, the transposed wy stage this
+release adds is worth +0.03x on every prod row over the previous chain.)
+
+The cconv numbers, measured 2026-09-01 on B300 (the ladder's cconv/001 record 002), one
+call, isolated with CUDA events — the number a training step feels, since the bench's
+fwd+bwd rows at this size are pinned by the harness's own per-iteration floor:
+
+| call (B=16, T=8192, W=4, bf16 x, fp32 weight) | fla | kernel-fun | |
+|---|---|---|---|
+| backward, D=2048 (q/k) — dx and dw, no forward re-run | 1.597 ms | 0.344 ms | **4.65x** |
+| forward, D=2048 (q/k) — silu fused | 0.307 ms | 0.190 ms | 1.62x |
+| D=1024 and D=4096 | | | same ratios |
+
+Both families re-measured from the installed package on 2026-09-02 (`tools/prodtime.py`,
+holmes-cs-aus-515, same B300 under a live session so absolute ms run higher than the
+records): kda **1.541x**, cconv fwd 1.62x / 1.63x and isolated bwd **4.25x** (D=2048) /
+**4.60x** (D=4096). The ratios are the records'; the package runs the ladder's kernels.
+
+At the 810m step (12 KDA layers, B=8) the trace put the three conv calls at ~50 ms of a
+~520 ms step; these ratios predict ~13 ms, i.e. roughly **7% of the step** — larger than
+the kda increment in this release. And 1.54x on kda at ~16% of step time predicts about
++6% tokens/sec. Confirm both on a real step before believing either; an op-level ratio is
+not a training result.
+
+## Install
+
+```
+pip install "kernel-fun @ git+ssh://git@github.com/allenai/kernel-fun.git@v0.2.0"
+```
+
+(Tags live in this repo; before the first one exists, pin a sha instead of `@v0.2.0`. The
+URL no longer carries `#subdirectory=packages/kernel-fun` — that was the path inside the
+ladder repo, before the 2026-09-09 split.)
+
+The base install declares torch, triton and `fla-core` only, with loose floors, so it never
+replaces the torch/triton a training image was built against. The CuTe DSL and cuda-python
+are **not** dependencies: they ride in with the training image, and when they are missing
+the kda family logs a reason and runs fla. An environment that needs them installed picks
+the extra for its CUDA major — the CuTe DSL ships separate CUDA 12 and CUDA 13 library
+wheels, and the bare `nvidia-cutlass-dsl` requirement is the CUDA 12 one:
+
+```
+pip install "kernel-fun[cu13] @ git+ssh://..."   # CUDA 13 torch (the production image)
+pip install "kernel-fun[cu12] @ git+ssh://..."   # a cu128 torch; untested since the image moved
+```
+
+**Tested against** — the only stack these kernels have run on. Everything else is where the
+version floors say it should work, not where anyone has checked:
+
+| | |
+|---|---|
+| GPU | B300 (sm_103; `arch_ok` admits any sm_10x, so B200 too) |
+| CUDA | 13.0 (torch `2.11.0+cu130`) |
+| torch / triton | 2.11.0 / 3.6.0 |
+| CuTe DSL | `nvidia-cutlass-dsl` 4.6.0.dev0, CUDA 13 libs |
+| flash-linear-attention | 0.5.2 (`fla-core`; `TESTED_FLA` in `_common/compat.py`, warns on anything else) |
+| Python | 3.12 |
+
+The cconv family is Triton-only and gated at sm90, so an H100 runs it — at a speed nobody
+has measured.
+
+Prefer that over `pip install -e`, which writes a `.pth` pointing back into a checkout and
+reintroduces "which copy am I running".
+
+**Inside the kernel-tuning image** the ladder is baked at `/work` but this repo is not, so
+clone it beside the ladder and put its `src/` on the path (`/work` is writable, and the
+image has `openssh-client`):
+
+```sh
+git clone git@github.com:allenai/kernel-fun.git /work/kernel-fun
+export PYTHONPATH=/work:/work/kernel-fun/src
+```
+
+In a session the ladder is `/work` itself — the tools' sibling default would look for
+`/work/kernel-fun-dev`, which does not exist — so `export KERNEL_FUN_LADDER=/work` (or pass
+`--ladder /work`) before running `tools/vendor.py` or `tools/drift.py` there.
+
+`torch`, `triton` and `fla-core` are required. The CuTe DSL (`nvidia-cutlass-dsl`) and
+`cuda-python` are deliberately **not** hard requirements: they arrive with the training
+base image, and letting pip resolve them risks swapping that build out. Without them the
+package still imports and still computes correctly — it just falls back to fla everywhere.
+Install the `cute` extra if you need them.
+
+## Using it
+
+```python
+import logging
+import kernel_fun
+from kernel_fun import kda, cconv
+
+logging.getLogger("kernel_fun").setLevel(logging.INFO)   # one line per process per family
+# `versions()` is logged for you the first time a family engages, from inside the
+# torch.compiler.disable'd entry point. Call it yourself only OUTSIDE a compiled region.
+
+kda.warmup(K=128, V=256, HV=16)                    # compile before step 1, not during it
+cconv.warmup(B=microbatch, T=seq_len, D=(2048, 4096))   # autotune at the REAL B, T, D
+
+q, _ = cconv.causal_conv1d(x=w_q(x), weight=conv_w, activation="silu")
+o, ht = kda.chunk_kda(q, k, v, g, beta, A_log=A_log, dt_bias=dt_bias,
+                      use_qk_l2norm_in_kernel=True, use_gate_in_kernel=True)
+```
+
+`warmup()` matters. Four `cute.compile` calls plus fla's Triton autotuning is tens of
+seconds; paid inside step 1 it looks exactly like a regression — which is what a previous
+port's reported "−3% tokens/sec" turned out to be. It also runs the fla compatibility probe,
+so a version mismatch raises before the run rather than at step 40,000.
+
+Both families have an `is_supported(...)` returning `(ok, reason)`. The reason string is
+meant for a training log: a silent fallback reads as a correct 1.00x, and "did the kernels
+actually run?" is the most expensive question a port can leave open. The package logs it
+once per process.
+
+### Supported — kda
+
+`chunk_size=64`, `T % 64 == 0`, `K ∈ {64, 128}`, `V % 64 == 0`, bf16/fp16, sm100
+(B200/B300), a grid of at least 256 CTAs (`B * HV * (V//64)`; `KERNEL_FUN_KDA_MIN_CTAS`
+moves that one number and nothing else — see Switches). Under CUDA graph capture the shape must already
+have run eagerly (fwd, and bwd if grads are needed): compile and autotune cannot be
+captured, but a warm shape captures and replays bit-identically, on any stream. Within that:
+`use_qk_l2norm_in_kernel`, `use_gate_in_kernel` (with `A_log`/`dt_bias`, fused into the
+cumsum), `use_beta_sigmoid_in_kernel`, `allow_neg_eigval`, GVA (`HV > H`),
+`initial_state=None`, `output_final_state=False`, fp32 `beta` (cast to q's dtype — the one
+numerics deviation, covered by a test).
+
+Stages also fall back individually below their own floors — most notably the MMA intra
+backward, which needs `B * (T/64) * HV >= 1024` and otherwise uses a Triton kernel that is
+faster at that size. `is_supported` reports the chain-level gate; the per-stage ones are
+performance choices, and the launch-witness test is what pins them down. They do not
+follow the chain-level gate down: at a configured 128 CTAs the b1 scan and dhu backwards
+are still fla's, and what the opt-in buys is the forward scan, the transposed WY backward
+and the intra backward.
+
+Everything else goes to fla: `cu_seqlens` and packed documents, context parallel,
+`safe_gate`, `state_v_first`, `disable_recompute`, `return_intermediate_states`,
+`chunk_size=32`, and any argument the package does not recognize — a new fla flag degrades
+to fla rather than being silently ignored.
+
+### Supported — cconv
+
+Exactly the KDA layer's mainline call: `activation` silu/swish, no bias, no residual, no
+initial/final state, no `cu_seqlens`, `backend="triton"`, `W <= 4`, bf16/fp16 `x` of shape
+`[B, T, D]` with any strides (production hands over a projection output and fla does not
+force it contiguous either), a `[D, W]` weight in any float dtype, `dw` back in the weight's
+dtype. Both kernels are Triton, so the arch floor is **sm90**, not sm100 — but they have
+only been *timed* on B300; an H100 computes the same numbers at an unmeasured speed.
+
+Everything else — bias, residual, conv state, packed documents, `activation=None`, an
+explicit `backend="cuda"`/`"mix"`, any unrecognized flag — goes to fla verbatim.
+
+### Switches
+
+| variable | effect |
+|---|---|
+| `KERNEL_FUN_DISABLE=1` | forward everything to fla. The 2am switch. |
+| `KERNEL_FUN_KDA_DISABLE=1`, `KERNEL_FUN_CCONV_DISABLE=1` | same, one family |
+| `KERNEL_FUN_DEBUG=1` | log the fallback reason |
+| `KERNEL_FUN_FALLBACK=1` | downgrade an fla-drift error to a warning + fallback |
+| `KERNEL_FUN_KDA_MIN_CTAS=<n>` | move the kda chain-level CTA floor off 256. Per workload, per measurement |
+
+All read per call, and a value that is not a positive integer is a warning and the default,
+not an exception — a launcher typo should cost throughput, not the run. There are
+deliberately no per-stage knobs: `MIN_CTAS` is the dispatch gate, not a stage, and bisecting
+a stage means reaching for the research ladder, which keeps all of them.
+
+`KERNEL_FUN_KDA_MIN_CTAS` is the one knob that can make things *slower*: 256 is where the
+CuTe scans stop underfilling the GPU on the shapes measured so far, and lowering it is a
+claim about one model on one box. The small OLMoE3 candidate (B4/T8192/HV8/K128/V256 — 128
+CTAs) is the shape it exists for. Time it against the default before believing it, and give
+`warmup()` the same environment the run will have: it warms one grid per floor in play.
+
+## How it relates to the research repo
+
+This package is a **release artifact**, not a mirror — see "Two repos" above for which
+change goes where. The ladder (`allenai/kernel-fun-dev`, `kernels/<family>/ideas/*`) stays free
+to fork and falsify; when an idea wins a recorded bench row, `tools/vendor.py` copies that
+commit's kernels here and prints a checklist of the edits it cannot do (freeze the env
+knobs, delete the branches they selected, unify the call cache). `_provenance.py` records
+which ladder commit each family came from — its paths are ladder-relative, which is why
+`tools/drift.py` needs a ladder checkout to report what has moved since. The real check that
+the two agree is the parity test, not a hash.
+
+For kda that is ~10 modules of the ladder's ~13k lines: the forward scan+readout and four of
+the backward's seven stages. The rest of the chain is fla's own kernels at fla's own stage
+boundaries — which is what makes a stage-by-stage comparison meaningful, and why the tests
+can hold to fla's own tolerances. For cconv it is one module: both directions, whole.
+
+## Releasing
+
+Published to PyPI as [`kernel-fun`](https://pypi.org/project/kernel-fun/) by
+`.github/workflows/release.yml`. Auth is **Trusted Publishing**: GitHub mints a short-lived
+OIDC token for the job, PyPI checks four claims against a publisher entry it holds, and
+trades it for an upload token good for minutes. No API token exists in this repo, in GitHub
+secrets, or on anyone's laptop. The four claims are owner `allenai`, repository
+`kernel-fun`, workflow filename `release.yml`, and the environment — so **renaming that
+workflow file, or an environment, breaks publishing** until the entry on PyPI is edited to
+match. That is the one non-obvious way this setup fails.
+
+| index | trigger | environment |
+|---|---|---|
+| TestPyPI | Actions → Release → Run workflow, target `testpypi` | `testpypi`, ungated |
+| PyPI | push a `v*` tag | `pypi`, manual approval, `v*` tags only |
+
+Cutting a release:
+
+```sh
+# 1. bump __version__ in src/kernel_fun/__init__.py  (the ONLY place it lives)
+# 2. rehearse on TestPyPI first -- it is the only way to exercise the real upload path
+gh workflow run Release -f target=testpypi
+# 3. tag; the build refuses a tag that disagrees with __version__, then waits for approval
+git tag v0.2.0 && git push origin v0.2.0
+```
+
+Two things here cannot be undone, which is what the approval gate and the tag check are
+for: **a version number is burnable once** — deleting `0.2.0` from PyPI does not let you
+re-upload it, so a bad release is fixed by shipping `0.2.1`, never by replacing it — and a
+release with a tag that disagrees with the metadata inside the wheel cannot be corrected in
+place. Installing from TestPyPI needs both indexes, since torch and `fla-core` are not
+mirrored there:
+
+```sh
+pip install --index-url https://test.pypi.org/simple/ \
+            --extra-index-url https://pypi.org/simple/ --pre kernel-fun
+```
+
+## Licensing
+
+Apache-2.0 (`LICENSE`), matching the research ladder and Ai2's default. Three of the Triton
+modules are derived from flash-linear-attention, which is MIT: `NOTICE` names them module by
+module and reproduces the MIT terms, which keep applying to those portions.
+`THIRD_PARTY_NOTICES.md` covers the rest of the dependency set — torch (BSD-3-Clause),
+triton (MIT), and the NVIDIA-licensed CuTe DSL and cuda-python that arrive with the base
+image — none of which are vendored here. All three files ship inside the wheel —
+`license-files` in `pyproject.toml` puts them there, which is what makes the attribution
+travel with an install rather than living only in this checkout.

kernel_fun-0.2.0.dev1.dist-info/RECORD

@@ -0,0 +1,30 @@
+kernel_fun/__init__.py,sha256=chmRNG1k-iGrS_YQbvr0fONBC4bQwcnQZSYmj7dQWtQ,2792
+kernel_fun/_common/__init__.py,sha256=S0FepNya2JLkmnrWJFAdgd01HycOXUFCRRRjblXR6qg,586
+kernel_fun/_common/cache.py,sha256=qeD1PTs7tV2QCT4fNzhG8-Ph90Zd8yo4MgYi9hbt730,4776
+kernel_fun/_common/compat.py,sha256=R1ejTGzOT2BmReDBv0DlGBV-sUekq0kdMLkxEl_Frz0,6651
+kernel_fun/_common/support.py,sha256=iMH590_5ye7eLgB4nQ0owsDvHj9GjAIw0KZ8QwgIGEM,11301
+kernel_fun/cconv/__init__.py,sha256=HLe5soJQ8gZOP8ABi6mGuJ8BazFdYBE5__ULrc0XWZc,1147
+kernel_fun/cconv/_provenance.py,sha256=UhQudpkvSYIdh_8u9LBTtq5V5v7w76K3m1JGZZJqiQI,443
+kernel_fun/cconv/ops.py,sha256=BDY7dXGhT31m2Zl62ZQt2SdFeyDwcPrHcoo0p9L68Vg,10914
+kernel_fun/cconv/_kernels/__init__.py,sha256=-i4zmoLZ2H_qTjSyRjws2AUzfymqbJIWn2YsYJcnR6w,323
+kernel_fun/cconv/_kernels/strip.py,sha256=_I06ovppBBb9o4XW5uJ7hjq7j9oFbhun6ZaFDShrZlY,18871
+kernel_fun/kda/__init__.py,sha256=Nb6c8xwEG23TInk8GHV7sSldEHSKTbsn01i-hA3oCSE,1020
+kernel_fun/kda/_provenance.py,sha256=P6oZJ2tCp098bbLC_gxJ-3xsTnyT6Ym1a-Qqmu1UVIs,1311
+kernel_fun/kda/autograd.py,sha256=tMYl9hI6ensTpOsHjruvv_Ue-UHmdJow4z-hfibVQVw,4515
+kernel_fun/kda/chain.py,sha256=UL92wkhnkr8mL9NqCETErYgY0WuLai54udT9PW5D4FI,6840
+kernel_fun/kda/ops.py,sha256=aE1XSLBoux90bQPlCqzgPQIA5vqHrUyxcAws08_3WWw,15132
+kernel_fun/kda/_kernels/__init__.py,sha256=PKTAudnL6NRxSockkdHxf__spLwTcjZz8ItuP28uWAU,406
+kernel_fun/kda/_kernels/bwd_dhu.py,sha256=7qaRWOREdGD4NUyZMxtUcMfKYj6XfRrrYp3baoR59MY,46809
+kernel_fun/kda/_kernels/bwd_intra.py,sha256=JGMUktLd-cnawMjsTQNiaUaftaFiIHrIbOYhCjGhtU8,51875
+kernel_fun/kda/_kernels/bwd_intra_triton.py,sha256=QXdxFOTgJIFa7N583G8B3vLN2m83WE0K1CAKjUevWrE,14431
+kernel_fun/kda/_kernels/bwd_scan.py,sha256=VCV0Fj5_RKDNptJzrHUMkqFRHgKPROiZLw1ZcnpEotI,53349
+kernel_fun/kda/_kernels/bwd_wy.py,sha256=1zqGMW6PMjRUbTRbd2g23VKjWX600OuowMOIQD4KgVg,11888
+kernel_fun/kda/_kernels/bwd_wy_t.py,sha256=NljLGhtrJqxuvYyyL33Rox3omiPrIROOajBuHFU5ndM,14917
+kernel_fun/kda/_kernels/fwd_intra_triton.py,sha256=0PfJXD1A91r9Z5TOzzNwJyWOuqDRMg30iPLK8-KbNFA,4075
+kernel_fun/kda/_kernels/fwd_state.py,sha256=DpWml05Di7SIDj0KbIct60jX9VyQfws2lTPbEnOHVX4,52002
+kernel_fun-0.2.0.dev1.dist-info/METADATA,sha256=DlRvgF9acQfoKiM37LmwOg4MpBgk5H8XCGf4HzFnIQI,19027
+kernel_fun-0.2.0.dev1.dist-info/WHEEL,sha256=zOwg4jB6zX2kU910N-cMawjivD6tO8NEWvE12je1bVk,87
+kernel_fun-0.2.0.dev1.dist-info/licenses/LICENSE,sha256=xx0jnfkXJvxRnG63LTGOxlggYnIysveWIZ6H3PNdCrQ,11357
+kernel_fun-0.2.0.dev1.dist-info/licenses/NOTICE,sha256=mcj7to1IuhpyCfb6vdaMwcvO4oanGE_GLYaBKC_dJ60,2907
+kernel_fun-0.2.0.dev1.dist-info/licenses/THIRD_PARTY_NOTICES.md,sha256=QnB8qE_gogmRda_d5KHZyh0ZFRj3BFeYti7iwoC8AM4,7992
+kernel_fun-0.2.0.dev1.dist-info/RECORD,,

kernel_fun-0.2.0.dev1.dist-info/WHEEL

@@ -0,0 +1,4 @@
+Wheel-Version: 1.0
+Generator: hatchling 1.32.0
+Root-Is-Purelib: true
+Tag: py3-none-any

kernel_fun-0.2.0.dev1.dist-info/licenses/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

kernel_fun-0.2.0.dev1.dist-info/licenses/NOTICE

@@ -0,0 +1,60 @@
+kernel-fun
+Copyright (c) 2026 The Allen Institute for Artificial Intelligence
+
+Licensed under the Apache License, Version 2.0 (see LICENSE).
+
+This product includes software derived from flash-linear-attention
+(https://github.com/fla-org/flash-linear-attention), Copyright (c) 2023-2026
+Songlin Yang, Yu Zhang, Zhiyuan Li, licensed under the MIT License. The MIT
+license text is reproduced at the end of this file and continues to apply to
+those portions.
+
+Specifically, the following modules are restructured ports of fla kernels and
+carry that lineage:
+
+  src/kernel_fun/kda/_kernels/bwd_wy.py
+      a full-K restructure of fla.ops.kda.chunk_bwd's fused wy_dqkg kernel
+  src/kernel_fun/kda/_kernels/bwd_intra_triton.py
+      a restructure of fla.ops.kda.chunk_intra's bwd_intra kernel
+  src/kernel_fun/kda/_kernels/fwd_intra_triton.py
+      a zero-fill companion to fla.ops.kda's forward intra/solve kernels,
+      written against their storage contract
+
+In addition, this package calls flash-linear-attention at runtime for the
+stages it does not replace, and delegates to it entirely for any call it does
+not support. It is not a fork: fla is a dependency.
+
+The CuTe kernels (fwd_state.py, bwd_scan.py, bwd_dhu.py, bwd_intra.py) are
+original work, though they implement fla's algorithms at fla's stage
+boundaries so that results remain comparable stage by stage.
+
+Attribution for the other projects this package depends on at runtime (torch,
+triton, and the optional NVIDIA CuTe DSL / cuda-python extras) is in
+THIRD_PARTY_NOTICES.md. None of them are vendored here; they are installed
+separately by pip.
+
+--------------------------------------------------------------------------------
+flash-linear-attention — MIT License
+--------------------------------------------------------------------------------
+
+MIT License
+
+Copyright (c) 2023-2026 Songlin Yang, Yu Zhang, Zhiyuan Li
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.