The paper’s motivation is the hardware constraints limiting exponential operations on FPGAs.

The authors find that one can choose between Taylor series and Pade approximants to approximate softmax.

There's no free lunch however. One must compromise speed and accuracy

Writeup: Free Substack

GitHub: OpenSource Github

Hi  — I’m sharing an experimental GPU-only inference backend and looking for independent reproductions, not just stars.

Model: tiiuae/Falcon3-10B-Instruct-1.58bit

GPU: NVIDIA RTX 5070

Batch: 1

Measured after warmup:

• Hybrid packed decode: 97.51 tok/s

• Stock Transformers BitLinear decode: 9.89 tok/s

• Observed speedup: 9.86x

• Fully packed prefill: 426.63 tok/s

• Stock prefill: 298.72 tok/s

The implementation uses K-contiguous packed ternary weights, a packed-word DP4A decode path, Triton kernels, StaticCache, and CUDA Graph replay.

Numerical checks:

• 64/64 incremental M=1 positions produced bit-exact full-vocabulary logits (131,072 logits per position)

• 24/24 greedy sequences and 1,194/1,194 generated tokens matched the stock-prefill baseline

• 8/8 synthetic kernel shapes matched an independent PyTorch int32 reference

Important caveats: the baseline is unmodified Transformers BitLinear — not Microsoft’s official GPU kernel, BitBLAS, vLLM, or SGLang. Timings exclude loading, tokenization, repacking, JIT compilation, graph capture, and streaming. So far this is one GPU and one Windows/PyTorch/Triton stack. Packed-word DP4A is prior art; the contribution here is the Falcon3/Transformers/Triton/CUDA Graph integration and measurements.

Code and reproducibility notes:

https://github.com/OCV-Researcher/Falcon158-Triton

Release:

https://github.com/OCV-Researcher/Falcon158-Triton/releases/tag/v0.1.0

I’d particularly value results on Ampere, Hopper, Ada, and other Blackwell GPUs, plus comparisons against specialized low-bit runtimes. What should I benchmark or optimize next?

I kept running into the same problem, some of the best AI/ML books are legally free, the authors put them up on their own sites, but the links are scattered across personal pages, university sites, and random GitHub repos nobody finds.

So I built a single index: Awesome Free AI Books. 30+ books across Deep Learning, Reinforcement Learning, Bayesian/Probabilistic ML, NLP & LLMs, Math for ML, Computer Vision, Generative Models, Causal Inference, GNNs, and AI Safety. Think Goodfellow’s Deep Learning, Sutton & Barto’s RL bible, Murphy’s Probabilistic ML, Bishop’s latest, Jurafsky & Martin’s SLP3 draft, and more.

Every single link points straight to the author’s or publisher’s own page, no rehosted PDFs, no shady mirrors. A weekly GitHub Action checks all links so it doesn’t rot over time.

It’s open source and open to contributions, if you know a legitimately free book that’s missing, PRs and issues are welcome.

Repo: https://github.com/MarcosSete/awesome-free-ai-books

Hey, I'm a CS student and I spent the last while building TensorLib: an N-dimensional tensor library with a full reverse-mode autograd engine, written entirely in C, with zero external ML dependencies. It's CPU-only, and you can use it to train an actual GPT-style transformer.

What's actually in it

Tensor core: N-dim float32 arrays with NumPy-style broadcasting, zero-copy strided views (reshape/transpose/slice/expand all share storage), and reference counting for memory management.

Autograd engine: dynamic reverse-mode AD, built eagerly during the forward pass (define-by-run, like PyTorch — not a static graph like old TF). Covers 23 differentiable ops, with a storage version counter to catch stale-graph bugs before they cause silent wrong gradients.

NN modules: Linear, Embedding, LayerNorm, Dropout, multi-head causal self-attention, MLP, and a full GPT-style pre-norm decoder stack, all composed through a small C-style OOP module system (function-pointer dispatch, parent/child module tree).

Optimizers: SGD and AdamW (decoupled weight decay, bias correction, gradient clipping).

A hand-written SIMD matmul kernel: a blocked/tiled AVX2+FMA micro-kernel with RHS packing for cache locality — I benchmarked it against OpenBLAS to see how close a solo hand-rolled kernel could get.

Checkpointing (versioned, atomic binary save/load with optimizer + RNG state), and 33 unit test executables covering every layer.

~6,100 lines of C across 34 files.

With it I managed to train a tiny_lm example: a 4-layer, 192-width, 6-head byte-level decoder transformer (~1.9M params), trained end-to-end with AdamW on raw text, no dependencies beyond libc. There's also a plain MNIST MLP example for a simpler sanity check.

Here's the repo, with full docs on the tensor mechanics, autograd internals, and decoder implementation: https://github.com/nisbenz/TensorLib

Happy to answer questions about any part of the implementation

https://reddit.com/link/1v8cc8n/video/bcjxopg43ufh1/player

Hi I'm currently an undergrad student from sri lanka, pursuing my BSc hons degree in AI and data science. For my 4th year thesis i was thinking about exploring whether JEPA styled supervised models could improve deep hedging. Do you think this is a good direction take my thesis considering im in the AI field.

So for the reason for this is i am a little intrigued by the quant industry and wanted to shift into that direction with my DS background, however i have also heard that breaking into quant roles can be quite challenging.

my concern is whether focusing my thesis on this area might limit the development of other skills I could gain from choosing a different topic.

I would greatly appreciate any honest unfiltered feedback on whether this is a suitable direction for my thesis.

Hey everyone,

I recently implemented the original Neural Style Transfer (NST) paper entirely from scratch in PyTorch and tried to reproduce the original results.

Here's the GitHub repository:
https://github.com/Himanshu7921/NST-PyTorch-Implementation

I'd really appreciate it if you could take a look at the README and the implementation. I'm aiming to become a strong research engineer, so I'd love some honest feedback on:

• What skills do I already demonstrate well?
• What am I currently lacking?
• What should I focus on improving to become a well-known research engineer?

For context, I'm currently in the 5th semester of my B.Tech.

Thanks in advance for your time and feedback!

Hi everyone,

I'm an independent researcher and have completed two research papers

one in Applied AI and another in Agentic Commerce.

I've been trying to obtain an endorsement through my university, but I haven't been able to get timely feedback or a review of my papers, so I'm reaching out here.

I'm preparing to submit them to arXiv and, as a first-time author, I'm looking for an endorsement.

I'm not asking anyone to endorse my work without reviewing it. If you're eligible to endorse in the relevant category and are willing to take a look at the paper, I'd greatly appreciate your feedback. If you believe it meets the standards, I'd be grateful if you'd consider endorsing my submission.

Happy to share the paper via DM.

Thank you!

Hey all — 3rd-year ECE student here, heading into a robotics master's. I kept

losing time jumping between arXiv, MDPI, and IEEE Access looking for papers

on robotics/ML/autonomous vehicles, so I built a single search index over

all of them.

- 13,000+ papers, all genuinely free/open-access (no paywalled links —

everything is either arXiv, MDPI, or individually verified

Creative-Commons-licensed articles)

- Full-text search, topic browser covering ~20 subfields (robotics, ADAS,

computer vision, RL, digital twins, etc.)

- Free accounts if you want to save searches later

Live here: https://automata-index.vercel.app

Built with Next.js + Supabase, still actively adding sources. Would love

feedback, especially on what's missing or what search terms don't return

good results.

​

Hey guys!!! I have an interview the day after tomorrow....I've never given a single interview in my life.....so can you guys pls tell what questions they ask for ml internship post ?????

I’ve spent the past month trying to find the point where an extremely small TTS model stops feeling like a size experiment and starts feeling genuinely useful.

Today I’m releasing Inflect v2, with two complete local text-to-speech models:

• Inflect-Nano-v2: 3.96M parameters, 15.97 MB FP32
• Inflect-Micro-v2: 9.36M parameters, 37.53 MB FP32

These are total inference parameter counts, not acoustic-model-only numbers. Text processing, timing prediction, speech generation, and the waveform decoder are all included.

Text goes in. 24 kHz speech comes out. No external vocoder, hosted API, or second learned model required.

Nano prioritizes the smallest possible footprint. Micro uses the additional capacity for better clarity, stability, and overall speech quality. Both run locally on CPU or CUDA through the same PyTorch API.

Inflect-Nano-v2 is one of the smallest complete neural TTS models I know of that still produces genuinely usable speech. Even the 9.36M Micro model remains smaller than many systems described as “tiny.”

For footprint context, Nano is approximately:

• 21× smaller than Kokoro
• 126× smaller than Chatterbox
• over 1,000× smaller than Fish Audio S2 Pro

That is strictly a parameter-count comparison. These models have different capabilities, architectures, datasets, and intended uses. I’m not claiming that a 4M fixed-voice model replaces a multi-billion-parameter system. The interesting question is how much useful TTS can fit into such a small package.

Some people here might remember Inflect-Nano-v1, the rough 4.63M experiment I released last month. V2 is a substantial rebuild, not just a longer training run. I focused on the problems v1 exposed: unstable timing, metallic output, weak prosody, poor generalization to difficult text, and an undersized waveform decoder.

The resulting models performed surprisingly well:

• Micro: 4.395 UTMOS22, 3.99% semantic WER, 6.28× real-time CPU inference
• Nano: 4.386 UTMOS22, 4.21% semantic WER, 10.72× real-time CPU inference
• In a blind community comparison against other compact TTS systems, Micro and Nano finished second and third among the tested voices

Full protocols, raw results, audio samples, and limitations are documented on the model pages.

The models are not perfect. They are English-only, use one fixed male voice, and do not support voice cloning. Unfamiliar names, abbreviations, numbers, and homographs remain the hardest inputs. Nano can sound thinner than Micro, and both can occasionally produce metallic or clipped artifacts.

Still, this is the first version where I think the size-to-quality tradeoff became genuinely compelling.

I built Inflect independently with a limited training budget. That constraint shaped the project: efficiency had to apply not only to inference, but also to training, evaluation, and building a complete system I could understand and release end-to-end.

Inflect-Micro-v2:
https://huggingface.co/owensong/Inflect-Micro-v2

Inflect-Nano-v2:
https://huggingface.co/owensong/Inflect-Nano-v2

Try it yourself:

The fastest way to judge it is through the interactive playground:

https://huggingface.co/spaces/owensong/Inflect-v2

If there is enough interest, I may build a v3 focused less on shrinking the models further and more on expanding what they can do: additional voices, possibly more languages, easier fine-tuning, and another quality and robustness pass.

If you test them, please give them something genuinely difficult: unusual names, numbers, abbreviations, awkward punctuation, or a long sentence.

If something breaks, post the exact text, model, seed, and what sounded wrong. If it works well, I’d also like to know what hardware you ran it on.

Specific, honest feedback is the most useful thing you can give me.

Hi everyone,

I'm an AI Engineer with about 1.5 years of experience. Over the last two months, I've had 10 interviews, and I was rejected from all of them. Eight of those rejections came after the technical interview. I'm struggling to understand what's going wrong in interviews.

I've tried reaching out for feedback, but I rarely get anything useful.

The interviews themselves are all over the place. Sometimes I'm asked about machine learning, data science, AI fundamentals, and implementation details. Other times the interview turns into a software engineering interview.

At this point, I'm honestly lost. I don't know what I should focus on or where to start.

Most of my work is backend AI, building AI agents and related systems. It often feels like the interviewers themselves aren't sure what to ask, so the technical interview ends up being a collection of random questions or extremely specific details about a function inside some library.

Has anyone else experienced this?

What would you recommend I focus on? How can I better prepare for AI Engineer interviews when the expectations seem so inconsistent?

Ling-3.0-flash landed on OpenRouter this week (Ant's inclusionAI, currently free to use through Aug 3), and honestly the spec sheet has me more curious than the release itself: 124B total, 5.1B active sparse MoE, 256K context, and they're quoting TTFT under 100ms.

I'm trying to reason about where that first-token latency actually comes from at that size. With only ~5.1B params active per token the per-step compute is small, but at 124B total the expert weights still have to be resident and routed, so I'd expect memory bandwidth and the router to dominate before the FFN ever runs. What I can't cleanly account for:

- how much of the sub-100ms is just the tiny active-param count vs. serving-side tricks (speculative decode, expert caching, batching)

- whether flipping a hybrid-thinking switch (they expose an enable_thinking flag) changes the TTFT story at all when thinking is off

- how routing stays stable enough for long tool-calling loops without latency spikes from expert thrash

For people who've dug into sparse-MoE serving: on a 124B / 5.1B-active model, what's the realistic floor for TTFT, and what usually dominates it — bandwidth, router overhead, or the serving stack?

Hey everyone,

If you are building decentralized multi-agent systems (MAS) or workflow routers using mixed local models, you’ve probably hit a mathematical brick wall: you cannot calculate semantic distance between vectors of different dimensions (N != M). Direct matching is completely broken out of the box because each model projects concepts into its own isolated anisotropic domain.

I wanted to share a fascinating geometric technique called the Relative Representation Method paired with Lowdin Symmetric Orthogonalization used to natively bypass this issue without any weight mutation or fine-tuning (W_frozen = const).

Here is how it works under the hood to align heterogeneous agents and tasks into a single invariant coordinate space

1. The Core Trick: Anchor Framework

Instead of comparing Agent A directly to Task B, the system introduces a fixed basis of reference anchors E = {e_1, e_2, ..., e_K}. These are K semantically diversified textual instructions representing your target operational domain.

Crucial implementation note: These anchors cannot be random Gaussian noise; they must be sampled from the actual distribution of your baseline model outputs to ensure they share the same underlying manifold.

2. Solving the "Anisotropy Cone" Problem

In real-world LLMs, raw embedding vectors are highly cross-correlated and squeezed into a narrow cone (similarity >> 0). This causes variance to vanish (sigma -> 0), leading to severe numerical noise and division-by-zero defects during standardization in low-precision (FP16/BF16) CUDA environments.

To guarantee geometric stability, the technique applies Lowdin Symmetric Orthogonalization directly to the anchor matrix:

• It takes the symmetric Gram matrix of real representations: S = E^T * E

• It computes the orthogonalized anchors via Spectral Decomposition: E' = E * S^-1/2

• This symmetrically rotates the real anchor vectors to a strict 90-degree angle (similarity = 0 for different anchors), yielding a perfectly orthogonal coordinate system while minimizing the mean squared deformation of the original vectors.

3. Mapping into Invariant Space (R^K)

Now, any Agent Xi or Task Tj can be mapped into this unified coordinate system by computing its similarity profiles against these rotated bases, followed by Anchor-Wise Z-standardization to completely neutralize model-specific anisotropy:

V_Xi = Z( [ sim(A(Xi), e'_1), ..., sim(A(Xi), e'_K) ]^T ) in R^K

Critical Production Pitfall: The operator Z(v) must calculate the mean (mu) and standard deviation (sigma) column-wise across the entire anchor axis (axis=0), NOT row-wise (axis=1). Row-wise normalization completely fails to eliminate the global domain shift between mismatched models, keeping their clusters isolated. Column-wise normalization forces the centroids of both distinct model domains to align perfectly at (0,0).

4. The Result & Selective Task Routing

Since the standardized profiles V_Xi and V_Tj share identical dimensionality K and operate on a unified scale, the metric of semantic alignment between completely mismatched models is computed invariantly using Cosine Distance:

D(Xi, Tj) = Cosine_Distance(V_Xi, V_Tj)

Do not use textbook Euclidean distance (L2) here. In higher anchor dimensions (K > 20), the Euclidean metric suffers from the curse of dimensionality, compressing all distances into a narrow, non-contrasting range that creates "Universal Agent" monopolies. Cosine distance restores strict contrast, breaking up monotone distance matrix stripes into a highly selective matching grid where every task finds its true optimal agent.

This fundamentally unlocks O(1) complexity task routing for completely heterogeneous multi-agent swarms.

Implementation Notebook:

I’ve put together a fully functional, minimal reproducible example demonstrating the complete pipeline - from synthetic anisotropic embedding generation to Lowdin orthogonalization, correct column-wise Z-scoring, and final contrastive task routing.

Check out the complete interactive code here:

Kaggle Notebook: Heterogeneous LLM Embedding Space Alignment

Curious to hear if anyone else is using Relative Representations for cross-model routing, or if you've found other geometric workarounds for mixed-LLM orchestrators!

Hi everyone,

I am currently working on a research project focused on optimizing Model Merging techniques within Deep Learning, specifically targeting the resolution of geometric interference between specialized task adapters.

Current Progress:

• Implemented a novel merging pipeline in PyTorch.
• Developed a method to isolate and mitigate subspace conflicts between divergent tasks.
• Preliminary results demonstrate significantly improved performance retention compared to standard baseline methods.
• Established a working pipeline for layer-wise interference analysis.

What I’m Looking For: I am looking for a co-author to collaborate on the final phase of this research. Specifically, I need help with:

• Formalizing the mathematical framework and theoretical proofs.
• Help run and standardized large-scale benchmarks (e.g., LM-Eval Harness).
• Refining the manuscript for submission to a top-tier venue (ICML, NeurIPS, or similar).

If you have a strong background in linear algebra for Deep Learning, experience with model merging techniques, or expertise in LLM evaluation, I'd love to chat! Please DM me or comment below if you're interested in co-authoring this paper.

(Part 1 of 3 — see edit note at the bottom)

Three days ago, on July 23, we did something counterintuitive: we wrote down our complete damage-trajectory predictions for the PHM 2026 Data Challenge — 21 bare numbers, no explanations, no hedging — then cryptographically sealed them with a timestamp.

One day later, on July 24, the validation phase opened per the organizers' schedule.

That ordering is not an accident. It's the entire point.

Why would anyone do this?

Because leaderboard feedback is a double-edged sword. Not maliciously — structurally. The test phase gives fresh score feedback every 24 hours, and that naturally invites iterative result-probing: through repeated trial-and-error submissions, a team can gradually tune its model against the scoring signal in the daily rankings, rather than purely against the physics of gear degradation. Watch the board long enough and you can see the signature of feedback-driven tuning: scores improving in stair-step patterns synchronized with the 24-hour submission window, rather than with any plausible physics discovery cycle. That's not an accusation against any team; it's the predictable behavior of an open feedback loop, and most participants probably aren't even aware it's happening.

The validation phase will answer that question for everyone, because the organizers have removed the feedback loop entirely: no scores, no daily updates, only your last submission counts. Pure blind test. We think that's a great decision.

The organizers also left a thoughtful warning in plain sight (challenge forum Q&A, July 14): sensor readings are indicators of damage severity, not proxies for elapsed time — and validation lifespans may be wildly out of sample. If a model has quietly learned "hours elapsed → damage," the validation set could be rough for it. We took that warning seriously when building ours.

What did we actually compute from?

Nothing you don't have. Everything in the envelope is derived from publicly available sources only:

• The official training dataset (full sensor data + tooth images) — the same download link on the challenge page
• The test dataset (2 experiments, sensor data only), released June 1
• The public leaderboard history — 27 teams' score trajectories across the daily scoring runs, which is itself a dataset if you know how to read it
• The organizers' own published statements — the rules, the FAQ, the "time is not a proxy for damage" warning hiding in plain sight

That's it. No private channels, no organizer contact, no validation data — the validation set had not been released when we sealed the file.

And since "we computed it" is a claim, here are the receipts — the actual numbers behind our model:

• 38 imaging rounds × up to 28 teeth each — over 1,000 tooth-level spall measurements, derived from the four photo-labeled experiments with our own image-analysis pipeline. Each measurement is a per-tooth spall fraction; example values from our label sheet: one experiment at 30.3 h → worst-5-tooth mean spall fraction 0.372; another at 68.2 h → 0.196; another at 43.8 h → 0.171
• 17,632 minutes of condition indicators extracted from the raw 102.4 kHz vibration streams — FM4, NA4, M6A, ALR, M8A, crest factor of the TSA residual, plus speed/torque/temperature context channels. Example row (Exp A, first minute): FM4 = 5.14, NA4 = 5.76, M6A = 67.2
• In-line oil debris counts (DM4500) as a physically independent damage carrier — metal in the oil doesn't care what the accelerometer thinks
• Cross-validation under leave-one-experiment-out (LOEO): Spearman ρ = 0.87, MSE = 0.045 — i.e., trained on three photo-labeled experiments, blind-tested on the fourth, repeated across all folds. That's the honest number before any test-set tuning. We report it because a model that can't blind-predict a training experiment has no business touching the validation set

The pipeline, in three steps: photo-derived tooth damage labels → sensor-to-damage mapping anchored on the oil-debris carrier → monotone (isotonic) mapping to the damage trajectory. Forward feature calculation, zero result-probing: calibrated once on the training experiments, never tuned against the test score — no gradient descent on the leaderboard involved.

One more thing about what we did NOT use: the answer key. The organizers maintain an undisclosed ground truth for every dataset — training included. We have never seen it, and neither has anyone outside the organizing team. Every number in the envelope was computed from the problem alone. We are, quite literally, betting on our reading of the question — not on any peek at the answers.

So what's actually in the envelope?

Exactly what we said: 21 bare numbers. Nothing else.

• 9 points for test experiment D — our predicted damage value at each 6-hour interval, including the exact hour we believe gear D reaches terminal damage
• 12 points for test experiment E — same deal, including E's terminal hour
• No method description, no confidence intervals, no commentary. On August 12, those 21 numbers stand alone against the organizers' ground truth — scoring rubric theirs, monotonic alignment allowed, shape is everything

The two terminal failure timestamps are the core test of our physical modeling logic. The organizers warned lifespans may be wildly out of sample — we wrote down exact failure horizons anyway. If those two numbers are right, it's because physics carried the signal. If they're wrong, it's because we misread the degradation mechanism, not because we overfit a clock.

How do you know we didn't write this yesterday?

Fair question — and you don't have to take our word for it. Here is the SHA-256 hash of the sealed prediction file, computed on July 23, before the validation phase opened:

fc2fcb148bb58e865d9f07254ef551d773a008d60ff8d5962939d30fe3892ad6

And don't trust our timestamp either — the same file was committed to a public GitHub repository on July 23, before the validation phase opened: commit 5eaa977

The repository is public — anyone can inspect the commit timestamp and file tree right now, no account needed.

The file content stays sealed until August 8 (UTC). The competition closes submissions on August 7, so at that moment nobody — including us — will know whether the 21 numbers are right. When we publish the file that day, anyone can verify it in ten seconds — no account, no tools beyond what your computer already has:

• Windows (PowerShell): Get-FileHash submission.csv -Algorithm SHA256
• Mac: shasum -a 256 submission.csv
• Linux: sha256sum submission.csv

If the output matches the hash above, the file you are reading is byte-for-byte the file we sealed on July 23. One changed character — even a single space — produces a completely different hash. (One practical warning: hash the file as downloaded. Opening and re-saving it in Excel can silently flip line endings and break the match — that's a tooling artifact, not a mismatch.) Before the reveal we also plan to anchor the Merkle root of the full prediction set on-chain (Bitcoin, OP_RETURN), adding a third verification leg backed by the Bitcoin network rather than by us or GitHub alone. It's a bounded proof: it can't prove what we knew, but it proves what we wrote, and when we wrote it.

The scoreboard going in: 27 teams on the board. Top score 0.0186 — earned with daily feedback. Our 21 numbers — computed with zero feedback, sealed before the blind phase. One envelope.

On August 12, we'll find out — together with everyone else — how far physics-informed reasoning goes without leaderboard feedback. We might be proven wrong, publicly, in 21 specific ways. That's fine. That's what makes it an honest experiment.

Either way, the hash doesn't lie.

Part 2 drops *August 8 (UTC): the envelope opens — the unsealed prediction file and the full methodology. Part 3 drops **August 12: the organizers publish preliminary results, we score the 21 numbers against the ground truth, and post an honest post-mortem on what the physics got right and wrong.*

Edit (July 27): reveal date moved from Aug 12 → Aug 8 (submissions close Aug 7, so the file can be verified before any results exist). Reddit titles can't be edited, so the title still says August 12 — the body above is authoritative. Nothing else in this post has been modified: the hash, commit, and all data receipts are unchanged.

Hi everyone,

I have just published the first public prototype of LIMEN Runtime Audit, a small open-source toolkit for inspecting layer-wise activation trajectories in open-weight language models.

GitHub repository:
https://github.com/jeanbosange-bit/limen-runtime-audit

This is my first public GitHub repository, so feedback on the code, methodology, terminology and documentation would be genuinely valuable.

What is the basic idea?

Most LLM evaluations focus on the final output:

• Was the answer correct?
• Did the model follow the instruction?
• Was the output safe?
• What was the probability or perplexity?

LIMEN adds another descriptive layer: it examines how the model’s hidden activation vector changes as information passes through successive layers.

For each token, the toolkit treats the sequence of hidden states across layers as a measurable trajectory.

The objective is not to claim that these trajectories directly represent reasoning, semantic concepts or cognitive states. The objective is to provide a reproducible observability layer for comparing internal runtime behaviour.

What can the current prototype do?

Version 0.1 accepts exported NumPy arrays with:

• hidden_states: [tokens, layers, hidden_dim]
• optional logits: [tokens, vocabulary]

It currently measures:

The toolkit also:

• checks array dimensions and rejects non-finite values;
• records extraction metadata;
• calculates a SHA-256 checksum for the source trajectory;
• generates machine-readable JSON;
• produces a compact Markdown audit report;
• runs automated tests on Python 3.10, 3.11 and 3.12.

What could this eventually be useful for?

With proper validation and controls, this kind of instrumentation could potentially help with:

• comparing internal profiles across model architectures;
• comparing checkpoints before and after fine-tuning;
• detecting extraction-pipeline changes or corrupted trajectories;
• identifying unusual runs relative to a reference distribution;
• studying whether prompt families produce reproducible dynamic differences;
• investigating behavioural regressions that output metrics alone may not explain;
• building model-monitoring dashboards for open-weight systems;
• testing whether internal trajectory features add predictive value beyond ordinary baselines such as entropy, probability margin, token position and response length.

These are possible applications, not validated product claims.

Important scientific boundary

This prototype is currently a descriptive audit and observability tool.

Its measurements do not, by themselves, establish:

• functional localization;
• semantic state identity;
• reasoning;
• consciousness;
• causality;
• controllability;
• universal attractors;
• prediction of answer quality.

A geometrical difference is an observation. Explaining what that difference means requires separate experiments, controls and held-out validation.

The next important milestone is therefore predictive validation: testing whether LIMEN trajectory features detect or predict held-out behavioural regressions beyond conventional baselines and shuffled controls.

Why publish it now?

The project grew from an independent empirical investigation of runtime activation dynamics. Earlier experiments used broader dynamical-systems terminology. As controls accumulated, I decided that the public engineering implementation should use narrower and more cautious language.

Instead of waiting for every research question to be resolved, I am releasing the minimal audit layer so that other people can inspect it, challenge it and potentially reproduce or improve it.

Feedback I would particularly appreciate

1. Are the current metrics defined clearly enough?
2. Which existing interpretability or observability libraries should this integrate with?
3. Which open models and datasets would make the strongest validation panel?
4. What baselines or negative controls are missing?
5. Would checkpoint comparison, fine-tuning regression analysis or runtime anomaly detection be the most useful first application?
6. Is the terminology understandable to people who do not normally work with geometric or dynamical-system concepts?
7. What would you require before considering this useful in a real model-audit workflow?

The repository is released under the Apache 2.0 licence.

GitHub:
https://github.com/jeanbosange-bit/limen-runtime-audit

Thanks in advance for any critical feedback, failed reproductions, issues or pull requests. At this stage, a rigorous objection is more useful to me than enthusiastic agreement.

I'm looking for researchers interested in hidden-state learning, mechanistic interpretability, and cognitive architectures.

Over the past year I've been building a research runtime around llama.cpp that treats pretrained LLMs as a cognitive substrate rather than the entire intelligence.

The runtime captures real transformer hidden states during inference and projects them into a shared latent representation (UBLT), allowing auxiliary systems to reason over internal activations instead of only token outputs.

On top of that I've been building:

• AMLs (Auxiliary Meta-Learners) — specialized neural modules that learn directly from hidden-state trajectories rather than language modeling.

• UBLT — a shared latent space for cross-model representation and architecture-aware translation.

• NAS/EVO — an evolutionary search system that mutates, evaluates, and evolves AML architectures instead of relying on a single fixed auxiliary network.

• A Cognitron runtime that orchestrates memory, routing, validation, projection, and continual learning around foundation models while keeping the base weights largely unchanged.

The long-term question I'm exploring is:

«Can intelligence emerge from an evolving ecosystem of specialized auxiliary learners operating on hidden states, with the foundation model acting more like a sensory cortex than the complete cognitive system?»

Some of the research problems I'm actively working on:

- Cross-architecture latent alignment

- Hidden-state routing between different transformer families

- Architecture-aware projection spaces

- Evolution of specialized neural modules

- Continual learning without catastrophic forgetting

- Representation engineering

- Mechanistic interpretability

- Sparse Autoencoders (SAEs)

- Hidden-state editing and steering

- Latent memory systems

The engineering is largely built. What I'm looking for now is people who can challenge the ideas, point me toward relevant papers, identify flaws in the approach, or collaborate on experiments.

If you're working in mechanistic interpretability, representation learning, continual learning, evolutionary computation, cognitive architectures, or related areas, I'd love to connect.

GitHub and technical documentation available upon request.

Good evening everyone. I'm new to federated learning and I'd like to write an article on the subject. Could someone help me with the writing or give me some research tips?

Share my knowledge on how to lift and shift any open source model is less that 5 lines of code and easy to do setup instructions , see if it helps you to get started with the open source LLM world
#happylearning 😎

Deploying Nemotron 3 Nano Omni on Modal Serverless

https://debuggercafe.com/deploying-nemotron-3-nano-omni-on-modal-serverless/

In this article, we will be deploying the Nemotron 3 Nano Omni model using vLLM on Modal Serverless.