China's CXMT Moves New Memory Chip Platform into Mass Production
On September 20, Reuters reported that Chinese memory chip maker CXMT has moved a new memory chip platform into mass production. The details of the original report haven't been gathered at this point, and the breakdown of specifications and production scale needs to be confirmed in the article itself, but this is a development that points to a further expansion of China's memory mass-production capacity.
This supply-side move is not unrelated to LLMs. LLM inference, particularly token generation, tends to be memory-bandwidth bound, and memory is itself the supply constraint on AI infrastructure. In fact, on the same day, the LocalLLaMA community was buzzing about an experiment—covered below—that nearly doubled generation speed by overclocking memory bandwidth. The Reuters report was also quickly shared in the same community and drew attention, underscoring that memory is a real concern for running LLMs in practice.
ProgramAsWeights Compiles English Function Specs into the "Weights" of a Small Model
Researchers at the University of Waterloo shared an open-source project called "ProgramAsWeights" (PAW) that compiles English function descriptions into locally executable "neural programs." The idea is "separating compilation from inference." You describe what you want done in English, the compiler generates a task-specific LoRA adapter, and that adapter is loaded into a small "interpreter" model that runs locally, even on a CPU. A single line like `paw.compile_and_load("Classify urgent emails")` gives you a function, and calls after compilation need no external API.
The setup is clean. The standard compiler is a fine-tuned Qwen3-4B that generates a LoRA adapter from the task description together with a pseudo-program (a tidied task description and a handful of input-output examples), and applies it to a frozen Qwen3-0.6B interpreter. Training is done on (task description, input, output) triples, with gradients flowing through the frozen interpreter back to the compiler side. The adapter-generation mechanism is said to be close to text-to-LoRA (Charakorn et al., 2025). Compilation finishes in seconds, and no large model is needed for inference afterward. If you have a GPU, you can self-host the compiler, and the weights have been released.
The results are telling as well. On FuzzyBench, a homegrown benchmark with a spec-based train/test split, the 0.6B interpreter achieved 73.4% exact-match accuracy, beating direct prompting of Qwen3-32B (68.7%). A follow-up, "Compile by Training," reports that additionally training the generated adapter for 100 steps (about 1 minute in a deployment environment) on examples synthesized by a teacher model reaches 83.6% semantic accuracy on FuzzyBench-Hard, a set collecting only the specs that failed to achieve exact match in the original evaluation. It offers two compilers with different tradeoffs between compile time and accuracy in the same local execution format.
The poster said they shared it as attention to Jev keeps growing. The direction—big models build the tools (small programs), and small models run them repeatedly in the field—reads as the same current flowing around LLMs.
Overclocking the CMP 170HX to 1.89TB/s — Qwen 3.8 27B Goes from 110 to 202 T/S
On LocalLLaMA, an experimental report is drawing attention: overclocking the memory of a secondhand mining card, the CMP 170HX 40GB, pushed bandwidth from 1,386.2GB/s to 1,890.1GB/s (+36.4%). With nothing else in the settings changed, token generation speed on Qwen 3.8 27B nearly doubled from 110 T/S to 202 T/S. GPU power draw at the time was 300 watts, and the temperature actually dipped slightly.
Yesterday this blog also covered a report of "Qwen 3.8 27B at 30 tok/s on two $250 mining cards," and efforts to unlock the card's latent potential have continued since. The poster points out that the card's potential is heavily limited by its factory settings—a report that reflects how cheap, high-capacity cards are becoming an on-ramp to local LLMs.
The result—raising memory bandwidth by 36% alone stretched generation speed by 84%—is a clear-cut illustration that token generation is memory-bandwidth bound. Combined with the CXMT mass-production report at the top, it was a day when the theme "memory is the bottleneck of AI" was moving simultaneously on both ends, supply and demand.
Dynamically Generating Weights from a Hypersurface — How Close Can You Get with 16% of the Parameters?
In a research-flavored personal experiment, an architecture experiment called "LoopSLM" was shared: a single decoder layer is reused in a loop, with the weights themselves updated on each iteration. The idea is close to the Universal Transformer, but instead of reflecting loop depth in the input, it dynamically updates the weights. It generates weight deltas ΔWl from slices of a learned "hypersurface" and composes the weights for each iteration as Wl = W0 + ΔWl. A triangular wave gave the best results among periodic functions, and its amplitude, frequency, and phase are learned. Furthermore, Gated Linear Attention computes a state vector from the input and modulates the shape of the hypersurface, making the weight deltas depend on the content of the sequence.
In pretraining on a 10B-token sample from FineWeb-Edu (frozen GPT-2 embeddings, NoPE with no positional encoding, sequence length 1024, 10k steps), a configuration of three loop blocks with triangular waves plus contextual modulation—about 27 million parameters (~16%) versus a standard 24-layer decoder (~170 million parameters)—reached a loss clearly better than a baseline that simply unrolls the loop. In absolute loss, the full-parameter conventional configuration is still best, but with training currently bottlenecked by VRAM, the experiment offers one datapoint for the question of "how close can a drastically lighter configuration get?" As a next step, the poster says they plan to try again with a larger context vector and an expanded function basis.
Jev Gets an Explainer in Japanese Tech Media — Plus a Report on Using It for Memory Retrieval
Regarding "Jev" (announced by US-based TypeSafe AI on September 15, developed by a former OpenAI researcher), which has continued to draw attention in overseas communities since last week, Japan's ITmedia AI+ published an explainer. It sorts out why Jev is making waves as "the AI that doesn't write text" and how it differs from LLMs, and introduces the framing "think of it as a 'smart if statement.'" It's evidence that interest is spreading not just overseas but in Japan's AI community as well.
Practical-side moves continue too. In the MachineLearning community, an attempt called "jev-recall" that uses Jev for memory retrieval was shared as a "game changer." At this point it's only a shared GitHub repository with details to follow, but it suggests that Jev's applications are expanding from processing tasks like classification and extraction to personal memory search.
Claude Code's Session-Start Input: Why Does It Reach 90K Tokens?
On Qiita, an investigation breaking down the number of tokens input at the start of a Claude Code session drew attention. According to the author, a session already inputs 70–90K tokens by the time of the first response. The day after cutting their own documents (CLAUDE.md and auto memory) to bring it down to 79K, starting with the same request text yielded 86K, and the day after that it was back at 88K. The piece works out what brought the tokens back—decomposing the input into "what goes in every time" by repeatedly removing and restoring elements.
The structure in which tens of thousands of tokens are consumed right after a session starts underscores the importance of context design in agent development. What goes in every time, what can be removed, and what gets restored? Grasping the automatically injected elements is a prerequisite for using the limited context effectively.