Xiaol.x
Adapting a 20-megabyte initial recurrent memory state delivers a 7.2-fold execution speedup without backbone retraining, though the compressed representation collapses on boolean and multi-step reasoning.
AI-assisted summary of Gut Feeling: RWKV + JEV — 7.2× Faster Decisions with State Tuning — original source. Check the original for full context.
Source published:
Key ideas
- By tuning only a learned initial WKV state (~20 MiB) and a lightweight decision head, a frozen G1k 3B RWKV backbone achieved a 7.2× within-request batching speedup on an A100 GPU. (0:00)
- In a separate public evaluation, the adapted recurrent model attained 64.5% accuracy (149/231 tasks) with 100% schema validity, though performance degraded sharply on complex reasoning queries. (0:00)
- At an 8k context length, the constant 20.31 MiB recurrent state offers a 14.18× memory reduction compared to a standard 3B Transformer's expanding KV cache. (6:29)
- Despite pristine schema formatting, severe blind spots emerged, including a near-total failure mode on boolean queries where the model defaulted to 'false' on 471 out of 472 inputs. (4:24)
Detailed notes
## Background Published on YouTube by Xiaol.x on September 25, 2026, this video examines how a pretrained 3B recurrent RWKV model can adapt to structured decision tasks without updating its core weights. According to the description, it demonstrates a 7.2× within-request batching speedup on an A100 GPU by training only an initial WKV state and a small decision head, alongside an empirical evaluation on public JevBench tasks.
## TL;DR The video demonstrates state tuning on a frozen G1k 3B RWKV backbone, adapting the model to structured decision tasks by optimizing only roughly 20 MiB of initial recurrent memory and a compact classification head via RLCD and policy gradients. Across 32 repeated queries on an A100 GPU, within-request batching achieved a 7.2× speedup compared to serial execution, while maintaining a fixed 20.3125 MiB live state per stream that avoids Transformer KV cache bloat. In a separate evaluation on 231 public tasks, the model scored 64.5% accuracy with 100% schema validity, though it exhibited severe blind spots such as near-total collapse on boolean questions and weak performance on multi-hop reasoning.
## Atmosphere & style The presentation carries a meticulous, engineering-first tone characterized by intellectual honesty and measured restraint. Rather than leaning into hyperbole around artificial intelligence breakthroughs, the presenter candidly dissects system limitations, walking viewers step-by-step through tensor math, memory matrices, and catastrophic edge-case failures like the near-uniform false predictions on boolean queries. It feels like an open-source technical post-mortem and lab walkthrough, pairing precise code mechanics with clear caveats distinguishing micro-benchmarks from production server concurrency.
## Bulletin - [00:00](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=0s) By tuning only a learned initial WKV state (~20 MiB) and a lightweight decision head, a frozen G1k 3B RWKV backbone achieved a 7.2× within-request batching speedup on an A100 GPU. - [00:00](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=0s) In a separate public evaluation, the adapted recurrent model attained 64.5% accuracy (149/231 tasks) with 100% schema validity, though performance degraded sharply on complex reasoning queries. - [06:29](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=389s) At an 8k context length, the constant 20.31 MiB recurrent state offers a 14.18× memory reduction compared to a standard 3B Transformer's expanding KV cache. - [04:24](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=264s) Despite pristine schema formatting, severe blind spots emerged, including a near-total failure mode on boolean queries where the model defaulted to 'false' on 471 out of 472 inputs.
## Key takeaways - [00:00](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=0s) The G1k 3B backbone remains completely frozen during adaptation, with updates restricted to ~20 MiB of initial recurrent memory state and a compact decision head. - [00:00](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=0s) The reported 7.2× speedup measures within-request batched execution (1.018 s vs. 7.330 s serial) for 32 repeated questions on an A100 GPU, rather than concurrent multi-client server throughput. - [00:00](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=0s) On public JevBench tasks, state tuning yielded 149 of 231 correct answers (64.5%) with zero schema violations, serving as a standalone evaluation rather than an official leaderboard rank. - [00:56](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=56s) The RWKV recurrent state spans 32 layers with 40 heads per layer, where each head maintains a 64×64 associative matrix memory alongside auxiliary token-shift history vectors. - [02:05](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=125s) Adaptation is achieved via RLCD and policy gradient updates applied directly to the learned starting state before prompt context enters the recurrent loop. - [02:05](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=125s) Policy gradient training optimizes 16 positive and negative perturbation pairs while reusing a single forward evaluation of the backbone per question. - [03:32](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=212s) Task accuracy proved highly sensitive to optimization hyperparameters; simply lowering the state learning rate raised task cohort accuracy from 38/72 to 56/72. - [04:24](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=264s) The adapter struggles with structured reasoning, recording 16.7% accuracy on trade-off questions, 20.0% on probability queries, and 27.8% on multi-hop composition. - [04:24](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=264s) A full regression occurred on boolean questions, with the system predicting 'false' on 471 of 472 inputs, demonstrating that schema compliance does not ensure logical calibration. - [05:15](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=315s) The recurrent state requires exactly 20.0 MiB in FP32 for head matrices plus 0.3125 MiB in FP16 for token history vectors, creating a constant 20.3125 MiB runtime footprint per stream. - [06:29](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=389s) In a 24 GiB VRAM budget at 8k context tokens, RWKV's fixed state allows theoretical room for 1,209 resident stream slots compared to 85 slots for a standard 3B Transformer. - [06:29](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=389s) Theoretical slot occupancy does not directly translate to multi-tenant concurrency due to prompt prefill overheads, candidate evaluation demands, and server scheduling bottlenecks. - [08:04](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=484s) State-tuned recurrent models provide a viable path toward low-latency, bounded decision APIs without post-training full multi-billion parameter backbones.
## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=0s) Results Overview and Frozen Backbone Adaptation
The core takeaway is delivered upfront: a 7.2× speedup achieved through within-request batching on an A100 GPU without any post-training of the G1k 3B recurrent backbone. The underlying model weights remain completely frozen; the only components updated during adaptation are the learned starting memory state and a lightweight decision head. In parallel, a separate supervised state-tuning evaluation on public JevBench tasks yields an accuracy of 64.5% (149 out of 231 tasks correct), with 100% of the model outputs maintaining schema validity. The presenter is careful to qualify these figures immediately: this is a standalone public evaluation rather than an official JevBench leaderboard submission, and the batching speedup measures within-request optimization rather than concurrent multi-client server throughput.
To demonstrate how the system works in practice, the video introduces a concrete customer service routing task: `"I was charged twice. Please refund the extra payment."` In an earlier 0.4B pilot experiment, this ticket was correctly categorized and routed to billing. The goal is to understand how this tokenized message flows through the recurrent memory structure and yields a structured decision without modifying the billions of weights inside the backbone.
- **Speedup:** 7.2× faster execution using batched evaluation on a warm A100 40GB GPU. - **Backbone State:** Pretrained G1k 3B backbone weights remain entirely frozen. - **Trainable Footprint:** ~20 MiB of initial recurrent memory state plus a compact decision head. - **Quality Metric:** 149/231 (64.5%) on public JevBench tasks, with every response schema-valid.
---
[00:56](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=56s) Deconstructing the Recurrent RWKV State
Peeling back the layers of a single RWKV block reveals how tokens interact with the recurrent architecture. As an incoming token enters a block, it first encounters TimeMix, which inspects and updates a persistent matrix memory before passing its output through a residual connection back into the token vector. From there, ChannelMix applies a feed-forward channel transformation, accompanied by a second residual addition. This sequence cascades across all 32 layers of the network.
```mermaid flowchart TD accTitle: RWKV Block State Flow accDescr: Diagram showing TimeMix and ChannelMix updates with residual connections and state memory in an RWKV block.
subgraph Block["RWKV Block (1 of 32)"] direction TB TokenIn["Token Vector In"] TM["TimeMix"] CM["ChannelMix"] TokenOut["Token Vector Out"]
TokenIn --> TM TokenIn -->|"Residual 1"| TM TM --> CM TM -->|"Residual 2"| CM CM --> TokenOut end
subgraph StateMem["Recurrent State Memory"] direction TB WKV["40 Heads x (64x64) Matrix"] Hist["Token History Vectors (TM & CM)"] end
TM <-->|"Read / Write"| WKV TM <-->|"Shift Context"| Hist CM <-->|"Shift Context"| Hist ```
The concept of "states inside a state" becomes tangible when inspecting the dimensional hierarchy: - **Depth:** 32 sequential layers. - **Attention/Mixing Heads:** 40 heads per layer. - **Head State:** Each individual head maintains a 64×64 state matrix. - **Token History Vectors:** Two smaller auxiliary vectors per layer capture the immediately preceding inputs to TimeMix and ChannelMix to facilitate token-to-token shift comparisons, distinct from the primary associative matrix memory.
Within each head matrix, past associations are retained, decayed over time, corrected, and overwritten with fresh associations as new tokens arrive. The video emphasizes that conceptual diagrams reflect the mathematical and structural mechanics of the code rather than empirical activation maps: the design provides an intuition for a compact situational representation, not a "verified world simulator."
---
[02:05](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=125s) State Tuning via RLCD and Policy Gradients
Rather than fine-tuning the 3-billion-parameter backbone, training is confined strictly to the initial WKV memory state and the decision head. This learned starting state enters the recurrent loop before any prompt context arrives; it acts as a learned prior rather than an additional adapter layer tacked onto the end of the model.
```mermaid flowchart LR accTitle: Training vs Inference Recurrent State Flow accDescr: Diagram contrasting policy and RLCD updates during training with static initial memory during inference.
subgraph Train["Training Phase (Backbone Frozen)"] direction TB InitStateTrain["Learned Initial WKV State"] PromptTrain["Prompt Tokens"] BBTrain["Frozen G1k 3B Backbone"] HeadTrain["Decision Head"] RewardGrad["Reward / Policy Updates\n(Pathwise or REINFORCE)"]
InitStateTrain --> BBTrain PromptTrain --> BBTrain BBTrain --> HeadTrain HeadTrain --> RewardGrad RewardGrad -.->|"Update State & Head"| InitStateTrain RewardGrad -.->|"Update State & Head"| HeadTrain end
subgraph Infer["Inference Phase"] direction TB InitStateInfer["Fixed Learned State"] BBInfer["Frozen G1k 3B Backbone"] Output["Typed Decision Output"]
InitStateInfer --> BBInfer BBInfer --> Output end ```
The optimization framework leverages Reinforcement Learning from Compiler/Diagnostic Feedback (RLCD) and policy gradient formulations: - **Legacy RLCD:** Adds perturbation noise directly to output logits and differentiates through a scoring reward function. - **Revised Policy Experiment:** Evaluates 32 noisy logit vectors derived from 16 positive and negative perturbation pairs. Crucially, these pairs reuse a single forward evaluation of the backbone per question rather than executing 32 separate autoregressive rollouts. - **Reward Signals:** Ground-truth target labels inform the reward, log-probabilities, and a spherical score metric, combined with an ordinal distance penalty applied specifically to score evaluations. - **Update Paths:** Both pathwise reward gradients (which differentiate directly through the scoring mechanism) and REINFORCE-style updates (which scale gradients by reward-weighted log probabilities) route parameter updates exclusively to the initial state and the decision head.
Once training concludes, exploratory noise, sampling perturbations, and optimizer updates are stripped away. During inference, while the live recurrent state continues to evolve dynamically with every ingested token, the learned starting state remains static.
---
[03:32](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=212s) Benchmark Accuracy and Failure Modes
On out-of-domain evaluation tasks where the adapter must produce structured, typed answers, performance proved highly sensitive to hyperparameter tuning: - **Early Public Baseline:** Initially achieved 38 out of 72 correct answers. - **Learning Rate Sensitivity:** Simply reducing the state learning rate boosted accuracy on the matched cohort to 56 of 72, edging out the pathwise reward branch by one task. - **Full Public Cohort:** On the broader 231-task public distribution, the lower learning rate cross-entropy run answered 149 of 231 tasks (64.5%), with 100% schema compliance. On a local A100 GPU, median serial request execution took approximately one-third of a second.
Despite strong schema validity, the model exhibits sharp blind spots, proving that a cleanly typed answer can still be "confidently wrong":
| Task Category | Accuracy / Metric | |:--- |:--- | | **Trade-off Questions** | 16.7% | | **Probability Questions** | 20.0% | | **Composition & Multi-hop Questions** | 27.8% | | **Boolean Questions (Full Regression)** | Predicts `false` on 471 / 472 inputs | | **Expected Calibration Error (ECE)** | 0.21 (lower LR run) | | **Ordinal Mean Absolute Error (MAE)** | 0.134 |
The near-complete failure on boolean queries—defaulting to `false` in all but one instance—highlights that the compressed state fails to carry complex multi-step reasoning dependencies, underscoring the absolute necessity of rigorous held-out calibration checks before deploying decisions into production.
---
[05:15](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=315s) Memory Footprint and Recurrent State Math
The exact parameter and memory math of the recurrent state illustrates why recurrent architectures provide an operational advantage for structured inference:
$$\text{Matrix Parameters} = 32 \text{ layers} \times 40 \text{ heads} \times (64 \times 64) = 5{,}242{,}880 \text{ elements}$$
Stored in 4-byte single-precision floating point (FP32), these matrix elements equate to exactly:
$$5{,}242{,}880 \times 4 \text{ bytes} = 20{,}971{,}520 \text{ bytes} = 20\text{ MiB}$$
The auxiliary input history vectors for TimeMix and ChannelMix store 2-byte values (FP16/BF16), contributing an additional 0.3125 MiB across the 32 layers. Consequently, a single active recurrent stream occupies exactly 20.3125 MiB, matching the repository's empirical memory allocation.
``` Total Live State Memory per Branch: • Head State Matrices (FP32): 20.0000 MiB • Token History Vectors (FP16): 0.3125 MiB ------------------------------------------- Total Recurrent State: 20.3125 MiB
Static Adapter Overhead: • Trainable Decision Head: ~1.2700 MiB ------------------------------------------- Total Adapter Tensors: ~21.2700 MiB ```
While the learned initial state is shared across requests, each concurrent branch or active user must maintain its own private 20.3125 MiB state. For example, a batch of 16 independent decision streams demands roughly 325 MiB of dedicated GPU memory for states alone, beyond backbone weights and workspace buffers.
---
[06:29](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=389s) Capacity Estimation vs. Transformers and Batched Speed
To evaluate memory capacity, the presenter contrasts RWKV against a standard Grouped-Query Attention (GQA) Transformer: Qwen 2.5 3B (36 layers, 2 key-value heads, head dimension of 128).
At 2 bytes per entry, the Transformer's KV cache expands continuously at 36 KiB per token:
$$\text{KV Cache at 8,192 tokens} = 8{,}192 \times 36\text{ KiB} = 294{,}912\text{ KiB} = 288\text{ MiB}$$
Comparing 288 MiB per stream to RWKV's constant 20.3125 MiB yields a memory footprint ratio of **14.18×** in favor of RWKV at long context lengths.
``` Resident Stream Slots in 24 GiB Free VRAM (at 8k Context): • Standard Transformer (Qwen 2.5 3B, 16-bit KV): 85 streams • Gated RWKV G1k 3B State: 1,209 streams ```
Quantizing the Transformer KV cache to 8-bit cuts that memory advantage roughly in half. Crucially, the presenter notes that theoretical slot occupancy does not equate to realized multi-tenant concurrency. Actual throughput depends heavily on prompt prefill speeds, candidate evaluation costs, custom CUDA kernels, and batch scheduling.
The empirical speedup measured in the repository—**7.2× faster execution** (reducing 7.330 seconds of serial execution to 1.018 seconds batched)—evaluates 32 repeated questions packed into a single shared-prefix request on an A100. Because the current test server serializes incoming clients, formal claims regarding multi-client server throughput and tail latency remain subject to future testing.
---
[08:04](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=484s) Bounded Decision APIs and Future Benchmarks
The overarching architecture distills into a clean pipeline: an incoming support ticket passes into the frozen G1k 3B backbone initialized with the learned recurrent state, terminating in branched output heads configured for structured choices, boolean outcomes, or continuous score predictions.
This creates a bounded, low-latency decision API that exploits recurrent state reuse without ballooning memory. However, critical research questions persist around improving data splits, modeling cross-candidate interactions, and remedying probability miscalibration on multi-hop questions. Gated RWKV illustrates a highly viable path toward turning a 3B recurrent model into a specialized Jev-style decision engine, but it does not claim to be an off-the-shelf general reasoner. The core breakthrough remains effective task adaptation achieved solely by tuning a 20 MiB starting memory and a tiny head, leaving the 3-billion-parameter backbone entirely untouched.
## Notable quotes > [00:00](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=0s) What if a 3B recurrent model could adapt to a structured decision task without updating its backbone?
> [00:00](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=0s) 7.2× faster within-request batching on one A100, while the pretrained G1k 3B backbone stays frozen.
> [00:00](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=0s) 149/231 = 64.5%, with every response schema-valid.
> [00:00](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=0s) this is not an official JevBench leaderboard rank and it is not a concurrent-client throughput claim.
> [00:00](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=0s) I was charged twice. Please refund the extra payment.
> [00:56](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=56s) states inside a state
> [03:24](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=204s) confidently wrong
> [03:24](https://www.youtube.com/watch?v=hRsQZ8Qb8vA&t=204s) predicts false on 471 / 472 inputs
## Mentioned RWKV, G1k 3B, JEV, JevBench, A100, A100 40GB, TimeMix, ChannelMix, RLCD, REINFORCE, Qwen 2.5 3B, GitHub
## Video description What if a 3B recurrent model could adapt to a structured decision task without updating its backbone?
In this video, we open with the measured result: **7.2× faster within-request batching** on one A100, while the pretrained G1k 3B backbone stays frozen. The trainable pieces are the learned initial WKV state and a small decision head. We then unpack the actual RWKV state, show how RLCD and reward-based state tuning update that memory, and follow one real decision from a customer message to a typed output.
The video also reports a separate public-task evaluation: **149/231 = 64.5%**, with every response schema-valid. That quality number and the batching number come from separate experiments; this is not an official JevBench leaderboard rank and it is not a concurrent-client throughput claim.
We visualize:
- the initial WKV state → 32 frozen RWKV blocks → decision head; - TimeMix, ChannelMix, residual paths, and the recurrent update; - nested state structure: 32 layers × 40 heads × 64×64 WKV matrices; - RLCD and REINFORCE-style reward updates to the state and head; - state memory, resident slots, and the measured batching path.
Project and research notes: https://github.com/xiaol/Gut-RWKV-Jev-laya
Chapters
00:00 The result first 00:56 Open the recurrent state 02:05 RL tunes the starting memory 03:32 Watch the decision happen 04:24 Where the story breaks 05:15 Twenty megabytes of learned starting memory 06:29 Estimate capacity, measure speed 08:04 What the result really says
Evidence notes
- The 7.2× result compares 7.330 s serial execution with 1.018 s batched execution for 32 repeated three-option questions, using a warm A100 40GB run and a shared prefix. - The 64.5% result is a separate cross-entropy state/head evaluation on 149 of 231 public tasks. - Backbone weights remain frozen. State/head adaptation is still training, but it does not post-train the G1k 3B backbone. - No claim is made that this is a top-ranked JevBench submission or that it measures multi-client server concurrency.
#RWKV #JevBench #StateTuning #ReinforcementLearning #RecurrentNeuralNetwork #MachineLearning
[Source](https://www.youtube.com/watch?v=hRsQZ8Qb8vA)