2026-11-04

A while back I posted V2 of my SPEED nodes for MiniMax-H3, which run the early, noisy part of diffusion at lower resolution and then step back up to full resolution as the detail starts to matter. Well I did a little (lot) more work on it and generalized the implementation. Allowing it to be (theoretically) used by any model running KSampler or SamplerCustomAdvanced (comprehensively tested and benchmarked with H3, MOSS, and Krea 2, works with FIBO 2 and Flux 3) Repo: https://github.com/StanLukuvka/ComfyUI-SPEED-Sampler Also, by popular demand, I added H3 videos as evidence, did a bunch of refactors and a bunch of improvements. And improved the documentation for it in every section. It's now essentially a 1:1 drop-in replacement for the default sampler nodes. What's new: Image models. MOSS Image and Krea 2 are tested, and other flow (CONST) image models should work too. KSampler nodes. Swap your KSampler for SPEED - KSampler and wire it exactly the same. There's also a Manual and a Sigma Harvest version. The H3 nodes stay wired like SamplerCustomAdvanced. Most samplers work now , not just the five from last time. The few that break (mostly on H3) are listed in the repo, along with why. Example workflows for H3, MOSS and Krea 2, already set to harvested values, so you can just load one of the workflows and queue. Tooltips on every input , so you don't have to come and read my README. Numbers (same seed and prompt, native vs SPEED): MiniMax-H3 , 5 s 0.5 MP clip, L40S: 288 s native, 182 s with SPEED (1.58×, 4 stages) MOSS Image , 1344×768, RTX 5070 Laptop: 22 s native, 18 s Automatic (1.26×), 14 s Manual (1.54×) Krea 2 , 1216×832, RTX 5070 Laptop: 283 s native, 215 s Automatic (1.31×), 183 s Manual (1.55×) Comparison GIFs and images for every run are in the repo's Evidence section. Heads-up if you used V2: Old workflows still load. The old node IDs are kept as deprecated nodes, so right-click and swap them for the new ones when you get to it. direct_coarse transition noise is now drawn on the CPU, so the same seed gives the same image on any GPU. As always, run Sigma Harvest once for your own model, sampler and schedule. edit: see evidence of it working with downloadable videos here submitted by /u/antipode_insights to r/StableDiffusion [link] [comments]

MIT CSAIL had GPT-6 Astra fix Qwen3.5-0.8B's reasoning loops by editing 0.016% of its weights (MATH-500 went from 7.9% to 48.1%). They released the diff, so the edit can be rebuilt exactly and run locally. I took it a step further and had Claude look at Qwen with Anthropic's Jacobian lens. At the token where the model decides to write "Wait" again, the lens reads "Wrong", "Nope" and "Hmm" from about 60% depth on, even though the answer is already written out. At real stopping points it reads "</think>", "Answer" and "Output". With the edit applied, the lens at the same token shows "Verification", "Completion" and "Result" in place of the doubt. The edit converts to GGUF cleanly (the base and edited bf16 files differ only in the two edited tensors) and still holds at Q4_K_M, with 1 loop in 40. I ran the evals in llama.cpp (Vulkan) on a Ryzen AI 9 HX 370 mini PC. Samples are small, but here's the code: https://github.com/alisorcorp/inside-a-reasoning-loop/tree/main/code And data: https://alisorcorp.github.io/inside-a-reasoning-loop/ submitted by /u/DeliciousGorilla to r/LocalLLaMA [link] [comments]

What one generated image costs in electricity on each GPU we've measured, at one dated price: 18.31 cents per kWh, the US residential average for July 2026. Power is the board's own reading from each card's driver. The page has two bar charts (cents per 1,000 images and seconds per image) and shows the arithmetic once, so you can redo it at your own rate. FLUX.2 [klein] 4B, 1024x1024, 8 steps, one pinned ComfyUI stack, images drawn back to back for ten minutes. Cents of board electricity per 1,000 images: - RTX 5090 Laptop GPU 24 GB, Dynamic Boost: 3.37 cents (4.48 s per image) - RTX PRO 6000 Blackwell Workstation Edition 96 GB at 300 W: 3.39 cents (2.30 s) - ZOTAC RTX 5080 Solid CORE OC 16 GB at 360 W: 5.04 cents (3.61 s) - EVGA RTX 3090 Ti FTW3 Ultra 24 GB at 350 W: 8.47 cents (4.97 s) - EVGA RTX 3090 XC3 Ultra 24 GB at 350 W: 9.13 cents (5.29 s) - RTX 3080 Ti Founders Edition 12 GB at 350 W: 9.71 cents (5.81 s) Capping the RTX 3090 Ti and the RTX 3090 at 300 W cut the energy per image by about 9 percent, for about 4.5 percent more time per image. What moves the bill: 8 to 32 steps costs 3.5 to 3.9 times as much; 512x512 to 1024x1024 costs 3.0 to 3.3 times; 1024x1024 to 2048x1280 costs 2.7 to 2.9 times. Z-Image-Turbo costs 1.5 to 1.6 times klein, and FLUX.1 [dev] fp8 costs 2.1 to 2.5 times. Cheapest picture we've measured: 0.79 cents per 1,000 (klein, 512x512, 8 steps, the laptop GPU held to 95 W, one image's share of a batch of three). Dearest: about 150 cents per 1,000 (Z-Image-Turbo, 2048x1280, 32 steps, on an RTX 3080 Ti Founders Edition 12 GB with part of the model streamed over PCIe each step). Board vs wall, the one reading we have both ways: a batch of three klein images on an RTX 3090 at 250 W read 1.27 Wh at the card and 1.87 Wh at the wall meter, 1.47 times as much. Caveats: board power, not the wall (except that one reading); cross-card comparisons are "same software, different computer"; every run had ComfyUI's debug log on, so a normal setup should match or beat these figures; no idle cost is billed; and the price is a national average, not anyone's bill. https://research.strata2signal.com/electricity-per-image/ submitted by /u/strata2signal to r/StableDiffusion [link] [comments]

TL;DR We find that frontier LLMs are surprisingly good at natively reading and writing neural network weights , well past what we’d expect from humans or conventional algorithms. This might be a big deal for both optimization and interpretability. Just by looking at the raw weights, GPT-6 Astra can tell what a network was trained to do . And without any environment feedback, it has no trouble writing, from scratch, small game-playing networks that outplay networks trained with PPO for 100 million steps. Likewise, asked to make Qwen3.5-0.8B better at math without gradients, Astra identifies an issue in its weights causing reasoning loops that Qwen’s own model card warns about, and fixes this by natively editing 0.016% of the weights . With the same sampling settings, this weight correction raises MATH-500 from 7.9% to 48.1% and generalizes out of the box to instruction following, raising IFEval by 3x . All of this is possible without allowing Astra to write training loops. It uses its reasoning to figure out what each part of a neural network computes, or should compute, and changes the weights accordingly. We call this Weight-Space Programming . Throughout the history of deep learning, we encoded our simplistic inductive biases into tiny symbolic optimizers like Adam or Muon. This is changing: our neural network weights will soon be natively optimized by LLMs that deliberately reason about their weights . Blog Post : https://rikiyat.github.io/blog/weight-space-programming/ GitHub : https://github.com/rikiyat/lm_understand-logs HuggingFace : https://huggingface.co/RikiyaT/Qwen3.5-0.8B-weight-space-programming Demo : https://huggingface.co/spaces/ML-Intern-lab/weight-space-programming-demo What Comes Next? In this blog, we demonstrated the rising capability of LLMs to read and write neural network weights (i.e., the rising concept of Weight-Space Programming). Our current results do show that capabilities are exciting but still limited, specifically due to inefficiencies in context length and harnesses. However, the current signs do show strong potential for a future involving Weight-Space Programming. We believe this marks the beginning of a dramatic shift in fields like mechanistic interpretability and neural network optimization. This opens up radical new possibilities for LLMs to function as a translator between human language and the weight space. Here are some examples: Auditing without evaluation: This may allow us to uncover hidden problems or capabilities without ever running inference or benchmarks. Currently, capabilities and vulnerabilities can only be detected if we have test sets designed for them, or worse, after deployment in the real world. If LLMs can interpret weight space accurately, we could identify such issues directly from the weights (e.g., backdoors). Dramatically reducing optimization cost: Weight-space editing could save immense time and compute. For instance, one-shot model initialization would be far faster and more efficient than curating datasets and running full training loops. Zero-data capability steering and unlearning: Adding or unlearning a capability currently requires extensive data collection and fine-tuning. In the future, we may just prompt “Can you add Capability X to the model?” and the LLM can directly tweak some weights. Because such an edit touches only a few weights (0.016% in Experiment 8), it can leave the rest of the model intact and avoid the catastrophic forgetting that fine-tuning often causes. Recursive self-improvement: Today, recursive self-improvement is often operationalized as a model writing code that launches training jobs. An LLM that can inspect, debug, and improve its own weights, or those of a newer model, offers a richer, more native path to it. True architectural and model merging: Today, merging models relies on averaging weights, which only works for models with identical architectures. An LLM that understands the weight space could instead graft a circuit, such as a reasoning module, from one model into a completely different one, without retraining. We are currently building a benchmark and a harness for LLMs’ capability on Weight-Space Programming. We believe this will provide a standardized evaluation to measure and accelerate progress in Weight-Space Programming, turning what currently seems like black magic into a rigorous, reproducible engineering discipline. submitted by /u/pmttyji to r/LocalLLaMA [link] [comments]

Yesterday MIT CSAIL showed GPT-6 Astra editing the weights of a small model by hand. It changed a few neurons of Qwen3.5-0.8B, the model stopped looping on math problems, and its scores jumped. No training at all. I wanted to try the same thing on something closer to what I actually do with local models, which is translating into Italian. Gemma 4 has a habit I don't love. For sentences like He had been hiding in the attic for months when the soldiers found him. it writes «Si era nascosto in soffitta per mesi…». That's correct, but I prefer «Si nascondeva in soffitta da mesi…», which says he was still hiding when they came. The catch is that when the period was already over ( he had lived in Paris for ten years, but by 1990 he had moved back ), the original tense has to stay. So it's not "always use tense X", it's "use it only when the meaning calls for it". So I gave Claude Opus 5.5 the same kind of setup MIT used: a Python kernel over Gemma's weights; 50 forward passes to test its ideas on practice sentences; no gradients, no training. It first checked whether Gemma already "knows" the difference between still-going-on and already-over. It does: a linear probe in the middle layers separates them almost perfectly. It just doesn't use that when choosing the verb. Then Claude rewrote 8 MLP neurons into a small switch that fires only in that context and nudges the verb toward the form I prefer. That's 92k out of 11.9B parameters, roughly a 100 KB diff. Results on sentences it never saw The table shows the share still in the old form, then how many control sentences got pushed into a wrong reading, then how many of 200 unrelated translations stayed identical. Method test 1 test 2 (independent) controls broken unrelated unchanged Gemma 4 12B 26 % 32 % — 200 Preference in the system prompt 4 % 2 % 49 82 Classic "difference of means" ablation 49 % 75 % 53 43 LoRA fine-tune on the same data 12 % 23 % 0 120 Claude's hand edit 5 % 16 % 2 182 The prompt applies the preference everywhere, even where it changes the meaning. The ablation recipe breaks the past tenses. The LoRA shifts fewer sentences and touches far more unrelated ones (it's better inside paragraphs, though). The hand edit moves just the verb and leaves almost everything else identical. Fair warning: it's one construction and one model. Two of my three runs succeeded (the third crashed because of my own harness), and the two that worked landed on the same "switch neuron" design independently. Repo with the edits, the code, the agent logs and all baselines: https://github.com/ValerioDolci/frontier-weight-edit submitted by /u/FeydRowan to r/LocalLLaMA [link] [comments]

Hey guys - made this a few weeks back and just shipped a big update. You take a video of a person, it builds a 4D capture, you fly a new camera through it inside ComfyUI, and you get the same moment back from the new angle. Everything runs locally. Capture: turns a video of one person into a 4D capture: their motion in 3D, the background around them, and where the original camera was and how it moved. Quick mode for fast previews, or a full 4D Gaussian splat if you want a closer look while you direct Virtual Camera: a 4D camera editor that opens right inside the node, so no separate app. Keyframe the camera anywhere on the timeline, look through it or step outside to see the whole scene. Blender-style view gizmo, J/K/L shuttle, frame stepping, multi-select to move or retime keys together Retake: ReDirector re-shoots the whole video along your new path Photoreal Pass: LTX 2.3 renders every final frame, guided by the real footage warped to the new view (Cseti's CrossView-Warp IC-LoRA) Camera settings on every key: aperture, focus (in metres or locked to the subject), vignette, grain. Rack focus and aperture pulls between keys, Alt+click in the viewport to focus on whatever you click. Change those later without re-rendering. The render gets reused, so a focus tweak takes a few minutes instead of the whole pipeline again Zoom through the lens: zoom keys change the lens after the render, which makes dolly zooms work Bring your own camera: import an animated camera from .fbx, .abc or .usd (tested with Blender exports), and it starts on the original camera at roughly real scale, lens and focus included. Files with several cameras work too, and you can export your moves back out Lens looks per shot: distortion, chromatic aberration, bloom, halation, anamorphic bokeh. Depth and subject matte passes if you want to comp afterwards. Finish node: 24 to 60 fps with RIFE, real motion blur from a shutter angle, upscale up to 4K, keeps the original audio A Settings panel at the top of the workflow for the stuff you change between runs (quality, frame rate, upscale) Try the editor in your browser, no install: itsmetamike.github.io/reshoot-4d/demo/ For those enquiring about specs: Tested on one RTX 3090 (24 GB), roughly 30 minutes per shot Stays good within about 30 to 40 degrees of the original camera but am looking to improve this next Fast spins can still smear a face for a few frames Code (AGPL-3.0) and the workflow: github.com/itsmetamike/reshoot-4d Hope it's useful to some of you. Built for the #OpenSourceHiggsfield competition. submitted by /u/itsmetamike to r/StableDiffusion [link] [comments]

submitted by /u/141_1337 to r/singularity [link] [comments]

Article URL: https://webkit.org/blog/18541/introducing-adaptive-dark-mode/ Comments URL: https://news.ycombinator.com/item?id=50358562 Points: 411 # Comments: 219

common : fix -hf tag matching inside longer quant names ( #31620 ) common : fix -hf tag matching inside longer quant names ":F16" picked a BF16 file when the repo had both, since "BF16" contains "F16". The same applied to ":Q4_XS" vs "IQ4_XS". The tag now has to start at a token boundary in the path. Assisted-by: dsh:llama.cpp/ggml-org/GLM-5.3-Flash-GGUF (Mac Studio, M5 Ultra, 256GB) common : accept underscore as -hf tag boundary Some repos separate the quant with an underscore, e.g. stepfun-ai/Step-3.5-Flash-GGUF-Q4_K_S ships step3p5_flash_Q4_K_S-00001-of-00012.gguf, which :Q4_K_S no longer matched. Add _ to the token boundary and pin the tag and default lookup cases. Co-authored-by: Pascal admin@serveurperso.com Website: https://llama.app Attestations: https://github.com/ggml-org/llama.cpp/attestations/63478879 macOS/iOS: macOS Apple Silicon (arm64) macOS Apple Silicon (arm64, KleidiAI enabled) DISABLED macOS Intel (x64) iOS XCFramework Linux: Ubuntu x64 (CPU) Ubuntu arm64 (CPU) Ubuntu s390x (CPU) Ubuntu 26.04 s390x (CPU) Ubuntu 26.04 s390x (zDNN) Ubuntu x64 (Vulkan) Ubuntu arm64 (Vulkan) Ubuntu x64 (CUDA 12) - CUDA 12.8 libraries Ubuntu x64 (CUDA 13) - CUDA 13.4 libraries Ubuntu arm64 (CUDA 13) - CUDA 13.4 libraries Ubuntu x64 (ROCm 10.0) Ubuntu x64 (OpenVINO) Ubuntu x64 (SYCL FP32) Ubuntu x64 (SYCL FP16) Linux arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Android: Android arm64 (CPU) Android arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Windows: Windows x64 (CPU) Windows arm64 (CPU) Windows arm64 (OpenCL Adreno) Windows x64 (CUDA 12) - CUDA 12.4 DLLs Windows x64 (CUDA 13) - CUDA 13.4 DLLs Windows arm64 (CUDA 13) - CUDA 13.4 DLLs Windows x64 (Vulkan) Windows arm64 (Vulkan) Windows x64 (OpenVINO) Windows x64 (SYCL) Windows x64 (ROCm 10.0) openEuler: DISABLED openEuler x86 (310p) openEuler x86 (910b, ACL Graph) openEuler aarch64 (310p) openEuler aarch64 (910b, ACL Graph) UI: UI