Your Daily AI Stew from Robin, on Salty Talk.
Today starts with a model whose name carries the word "Small", then looks at how mixture-of-experts models get trained, how large models get moved onto Windows PCs, and what a coding assistant may carry along when it sends a network request. Finally, the gaze turns to attempts at letting AI take part in physics proofs.
Inkling 2 Small: a "Small" model carrying 594 billion parameters
Inkling has announced Inkling 2 Small. This multimodal mixture-of-experts model reaches 594 billion total parameters with 17 billion activated per inference pass, accepts image input, and lets you adjust how much compute is invested at inference time. The name "Small" has to be read together with its architecture: the model hands input to a subset of selected experts, so at each step it does not have to mobilize every parameter, which cuts compute cost compared with a dense model of the same total capacity.
Compared with the earlier Inkling Small — 276 billion total parameters and 120 billion active — this update expands the model's capacity and adds image input and adjustable inference effort. The announcement says the new model scored 31 on the Artificial Analysis Intelligence Index, with gains in agentic coding, vision, knowledge work, and reasoning; Inkling attributes these changes to more efficient pretraining and one large-scale, unified reinforcement-learning run. Source: Inkling 2 Small release post
For developers, the entry point available right now is Tinker: you can use it in the Playground, and sample from and fine-tune it. The weights are still closed for now. Inkling plans to release the full weights and downloadable checkpoints next week under an Apache 2.0 license, contingent on completing external safety testing and red-teaming. The service is already open; the weight download remains a conditional release plan.
How do the experts divide the work? A MoE handbook turns the camera onto the training floor
Once you've seen "only part of the parameters activate per pass", the next questions are: who picks the experts, and how do you keep task allocation from going lopsided? The Megatron-LM field handbook written by Hugging Face author Nouamane targets developers moving from dense-model training to mixture-of-experts, folding routing, load balancing, and expert placement into an actionable engineering workflow.
The handbook starts from benchmarking the hardware, building an image, and establishing a dense-model baseline, then takes the reader through running a first single-node MoE. That order gives training a control: baseline first, then the division of labor inside the expert network. Later chapters also touch distributed-systems problems, model serving, and reinforcement learning, and it can all be learned without a GPU. Source: Megatron-LM MoE training handbook release post
The author says the guidance comes from about 800 thousand GH200 GPU-hours of MoE training experience on the Alps cluster at CSCS — the unit is cumulative GPU-hours. The companion material includes 55 figures, runnable scripts, and the distilled Megatron-LM recommended parameters, and the handbook also separates results the author actually ran from smaller simulation experiments. For engineers who have to configure and troubleshoot MoE training, these scripts and parameters connect the architecture words in model releases to concrete training steps.
DeepSeek on a single RTX 3090 — beyond VRAM, it's about memory and disk
Coming back from training clusters to desktop PCs, Delta Inference Engine has released v0.93. This MIT-licensed Windows port, based on Strata's Xolotl engine, extends support for running DeepSeek-V4.1-Flash-1017 on a single RTX 3090, covering 64 GB, 96 GB, and 128 GB memory configurations, and can natively read the new Unsloth quants.
The most eye-catching figure comes from the author's own test machine: On one RTX 3090 with 24 GB of VRAM, paired with an i5-13600K, 192 GB of system memory, and PCIe 4.0 NVMe storage, with no WSL used. On that setup, UD-IQ2_XXS reached 41 tokens per second; it answered 57 of 99 hard questions, against 52 for the reference ds4 Q2 and 59 for the full model. Facing prompts of about 180 tokens, time-to-first-token dropped from 3.8 seconds to 2.3 seconds. Source: Delta Inference Engine v0.93 update post
The key to this local-deployment route is making VRAM, system memory, and NVMe streaming share the model's weight, instead of demanding the whole model fit in VRAM. It runs natively on Windows and is compatible with the OpenAI interface, giving Windows users a way to run this model locally. The resource ledger has to be counted in full, too: the requirements include at least 64 GB of memory, an NVIDIA RTX card with at least 12 GB of VRAM, fast NVMe storage, and 233 to 395 GB of model storage. Those 41 tokens per second correspond to the author's 192 GB-memory test machine; they cannot be blanket-applied to every supported configuration. AMD GPUs are not supported for now, and scaling to three or four or more GPUs performs worse.
Claude Code email-leak report pulls attention onto the request headers
Once the model runs, how the tools get online shapes the experience just as much. A user reported that Claude Code sent the account's email address to a website; some commenters connected the junk personalization emails that appeared afterward to it. One of those commenters said the tool carried the organization's email address via curl while running under a private account.
Issue #107757 describes one path: during a web search, Claude Code writes the user's email address into the User-Agent request header. This field identifies the client software that originated the request; if an account identifier is placed in it, the website receiving the request can see it. For a coding assistant, this turns the question of whether identity information rides along with requests into an engineering problem specific down to the HTTP field. Source: Claude Code issue report #107757
A reply in the GitHub issue from a Contributor says that version 2.1.317 and later added a built-in module called cc-plugin-privacy, which blocks this behavior through deterministic checks. The available material is mostly user narrative; there is no technical reproduction, and no maintainer confirmation of the full scope of the problem. So what can be said here is that users reported email leakage and discussed corresponding safeguards; the link between the personalized spam and this behavior remains the commenters' judgment.
AI joins physics proofs — the landing point is one step forward
Finally, a research thread. One step in OpenAI's announced batch of proof research heads toward the long-standing Yang-Mills question. The author of the YouTube piece uses it to discuss AI's move from mathematical proofs toward physics. Source: YouTube content
Where this deserves attention is that AI's participation in proof work has extended its direction into physics questions. As for the specific result, the material only says "a step forward"; it gives no technical unfolding of this proof, and the provided text ends partway into its explanation of Yang-Mills theory. That is where this episode can stop: the author reported a piece of progress, and it cannot be written up as that long-standing problem being solved.
Put today's items together and the model spec sheets, the training scripts, the memory and disk inside a desktop PC, and the identity information inside network requests all enter the same picture of use. Inkling showed an arrangement of model capacity and activated compute; the MoE handbook lays out the division of labor among experts during training; Delta lands the deployment on concrete hardware; the Claude Code report reminds us to watch the requests our tools send. On the research end, "one step forward" also has to be said precisely. Today's pot of Daily AI Stew follows these concrete details and watches how AI gets trained, runs, and gets used.
