Readit News logoReadit News
nsomani commented on Show HN: Symbolic Circuit Distillation: prove program to LLM circuit equivalence   github.com/neelsomani/sym... · Posted by u/nsomani
nsomani · 7 days ago
Hi HN,

I have been working on a small interpretability project I call Symbolic Circuit Distillation. The goal is to take a tiny neuron-level circuit (like the ones in OpenAI's "Sparse Circuits" work) and automatically recover a concise Python program that implements the same algorithm, along with a bounded formal proof that the two are equivalent on a finite token domain.

Roughly, the pipeline is:

1. Start from a pruned circuit graph for a specific behavior (e.g. quote closing or bracket depth) extracted from a transformer. 2. Treat the circuit as an executable function and train a tiny ReLU network ("surrogate") that exactly matches the circuit on all inputs in a bounded domain (typically sequences of length 5–10 over a small token alphabet). 3. Search over a constrained DSL of common transformer motifs (counters, toggles, threshold detectors, small state machines) to synthesize candidate Python programs. 4. Use SMT-based bounded equivalence checking to either: - Prove that a candidate program and the surrogate agree on all inputs in the domain, or - Produce a counterexample input that rules the program out.

If the solver finds a proof, you get a small, human-readable Python function plus a machine-checkable guarantee that it matches the original circuit on that bounded domain.

Why I built this

Mechanistic interpretability has gotten pretty good at extracting "small crisp circuits" from large models, but turning those graphs into clean, human-readable algorithms is still very manual. My goal here is to automate that last step: go from "here is a sparse circuit" to "here is a verified algorithm that explains what it does", without hand-holding.

What works today

- Tasks: quote closing and bracket-depth detection from the OpenAI circuit_sparsity repo. - Exact surrogate fitting on a finite token domain. - DSL templates for simple counters, toggles, and small state machines. - SMT-based bounded equivalence between: sparse circuit -> ReLU surrogate -> Python program in the DSL.

Limitations and open questions

- The guarantees are bounded: equivalence is only proven on a finite token domain (short sequences and a small vocabulary). - Currently focused on very small circuits. Scaling to larger circuits and longer contexts is open engineering and research work. - The DSL is hand-designed around a few motifs. I am not yet learning the DSL itself or doing anything very clever in the search.

What I would love feedback on

- Are the problem framing and guarantees interesting to people working on mechanistic interpretability or formal methods? - Suggestions for next benchmarks: which circuits or behaviors would you want to see distilled next? - Feedback on the DSL design, search strategy, and SMT setup.

Happy to answer questions about implementation details, the SMT encoding, integration with OpenAI's Sparse Circuits repo, or anything else.

nsomani commented on Show HN: KV Marketplace – share LLM attention caches across GPUs like memcached   github.com/neelsomani/kv-... · Posted by u/nsomani
nsomani · a month ago
Hi all - this is a small research prototype I built to explore cross-GPU reuse of transformer attention states.

When inference engines like vLLM implement prefix/KV caching, it's local to each replica. LMCache recently generalized this idea to multi-tier storage.

KV Marketplace focuses narrowly on the GPU-to-GPU fast path: peer-to-peer prefix reuse over RDMA or NVLink. Each process exports completed prefix KV tensors (key/value attention states) into a registry keyed by a hash of the input tokens and model version. Other processes with the same prefix can import those tensors directly from a peer GPU, bypassing host memory and avoiding redundant prefill compute.

Under optimistic conditions (perfect prefix importing), the prototype shows about a 15% reduction in latency and throughput gains without heavy tuning. The code is intentionally minimal (no distributed registry, eviction, or CPU/disk tiers yet) but it's a prototype of "memcached for attention."

I thought others exploring distributed LLM inference, caching, or RDMA transports might find the repo useful or interesting.

nsomani commented on Show HN: Cuq – Formal Verification of Rust GPU Kernels   github.com/neelsomani/cuq... · Posted by u/nsomani
jroesch · 2 months ago
We also have a formal memory model and the program semantics are simpler so if anything reasoning about it should be easier.
nsomani · 2 months ago
Oh really? I can't find anything about the memory model online. I'm not sure what's the best way to do this, but if there's a way for us to get in contact, I'd be interested in adjusting the project so it's developed in the most ergonomic way possible. I'm chatting with a couple of universities and I might issue a research grant for this project to be further fleshed out, so would be keen to hear your insights prior to kicking this off. My email is neel[at]berkeley.edu.
nsomani commented on Show HN: Cuq – Formal Verification of Rust GPU Kernels   github.com/neelsomani/cuq... · Posted by u/nsomani
skrrtww · 2 months ago
If this was genuinely unintentional on your part, then bless your heart and I'm sorry for assuming the worst. You might be the least morally corrupted internet user alive today.
nsomani · 2 months ago
I think I've just spent too much time reading the word "CUDA" that I read "cu" as "koo", lol.
nsomani commented on Show HN: Cuq – Formal Verification of Rust GPU Kernels   github.com/neelsomani/cuq... · Posted by u/nsomani
gaogao · 2 months ago
Do you think it might be easier to target cuTile instead of PTX? (Probably not, since it has a less formalized model?)
nsomani · 2 months ago
That instinct is right. cuTile would be easier to parse but harder to reason about formally.
nsomani commented on Show HN: Cuq – Formal Verification of Rust GPU Kernels   github.com/neelsomani/cuq... · Posted by u/nsomani
skrrtww · 2 months ago
This might be the worst named project of all time. Not funny and demonstrates an absolutely terrible impulse on the part of the author. Probably the worst way possible to advertise your project.

edit: According to the author in a reply, the double entendre was in fact not intentional.

nsomani · 2 months ago
Oh wow, honestly this caught me off guard - I've been pronouncing it "kook" in my head the whole time.

u/nsomani

KarmaCake day432January 25, 2019
About
Neel Somani https://x.com/neelsomani
View Original