Runway Worlds 2 times prompts, DSpark triples VLM decode, Datasette ships OTel

TL;DR

• Runway Worlds 2 ships 24 fps / 720p video with a sliding KV-cache window that guarantees revisit drift.
• Liquid AI’s DSpark hits 3.13× decode speedup on M5 Max and 2.66× on H100.
• DSpark end-to-end gains land at 1.30–2.62× because prefill and vision encoding stay unaccelerated.
• Datasette 1.0a41 adds OpenTelemetry spans targeting SQL thread saturation and write queue depth.
• Gaussian Splatting variants of Runway’s sim converge 2× faster on 8 robot contact policies.

Three unrelated ships fill today’s tech beat. Runway’s Worlds 2 exposes its WorldPrompt format — a persistent genesis scene plus timestamped actions steering real-time 24 fps / 720p video, with a sliding KV-cache window that makes revisit drift structural rather than a bug. Liquid AI’s DSpark posts a 3.13× decode speedup on LFM2.5-VL-3B under M5 Max, with the same 280M drafter recipe already inside DeepSeek-V4. Datasette 1.0a41 skips features entirely and instead ships OpenTelemetry spans targeting SQL thread saturation, plus a Plugin Telemetry Kit for third-party spans.

Round-out is a pair of Simon Willison items: a commit-rewriter 0.2 release that finally handles non-default branches, and an SF agentic-engineering show-and-tell on October 14.

Runway’s Worlds 2 steers real-time video with timed prompts

Source: latent-space · published 2026-09-25

TL;DR

• Runway’s Worlds 2 ships a two-layer WorldPrompt: persistent genesis scene plus timestamped actions, running at 24 fps / 720p.
• Memory is a sliding KV-cache window, not a scene graph — the mechanism that guarantees revisit drift.
• 8 robot policies ran in-sim, with Gaussian Splatting variants converging 2× faster on contact tasks.
• The counterfactual gap is sharpest: successful outcomes dominate training data, so plausible failures render poorly.

What WorldPrompt actually is

Latent Space frames Worlds 2 around a clean split: a genesis prompt fixes the scene, then a stream of timed text and camera actions steers what happens next. An independent architecture note fills in the piece the post underplays — there’s a third tier, a sliding KV-cache window carrying temporal history, and the diffusion denoiser is distilled hard enough to hit 24 fps at 720p ¹. That’s the whole trick: persistence isn’t a world state, it’s cached attention.

flowchart LR
    A[Genesis prompt + reference frame] --> M{Distilled diffusion step}
    B[Per-frame camera + text actions] --> M
    C[Sliding KV-cache window] --> M
    M --> F[Frame t]
    F -->|append, evict oldest| C

The framing matters because it tells you exactly where the model will fail: anything older than the cache horizon is gone. iWorld-Bench, an ICML 2026 benchmark that scores interactive models on closed-loop “revisit” tasks via Memory Symmetry and Trajectory Alignment, finds most current systems degrade precisely at KV-cache truncation and attention decay ². Runway’s persistent-context pitch is real, but it’s bounded by a mechanism a scene graph would not have.

The robotics evidence is the load-bearing claim

The strongest thing going for Worlds 2 isn’t the demo reel — it’s a companion evaluation on manipulation. Runway Research ran eight robot policies inside GWM-Robotics; simulated rollouts correlated with real-hardware outcomes, and 3D variants using Gaussian Splatting converged up to 2× faster on contact-rich tasks than the video-only baseline ³. That’s the concrete number missing from Latent Space’s write-up and the most credible argument that this is a simulator, not just a generator.

Where it breaks, and who’s building the alternative

Two independent critiques land harder than the launch post admits.

First, a probability bias in training data. Futurepicker’s analysis points out that the model can render a soccer goal being scored but struggles to produce a realistic miss, because successful outcomes dominate video corpora ⁴. For a system pitched at robotics and simulation — domains that live and die on modeling failure — a counterfactual-reasoning hole is not cosmetic.

Second, Decart’s Mirage is quietly making a different bet: a “world transformation model” that restyles a live camera or game feed at 40–100 ms/frame rather than generating a world from scratch ⁵. It sidesteps drift by never owning the world state in the first place. Google’s Genie 3 is competing at 24 fps with longer visual memory. Worlds 2 is not alone in the category.

“Runway survives on hype.” — r/singularity thread on the launch ⁶

The community reaction to the preview is unusually sour, citing Runway’s “brutal credit economy,” aggressive Gen-3/4.5 safety filters, and a persistent gap between polished demos and what paying subscribers get ⁶. None of that is a critique of the science. It’s a critique of Runway’s track record turning research into product — and it’s the headwind Worlds 2 has to fight even if every technical claim holds.

The takeaway

The engineering is real: timed actions, distilled denoisers, and rollouts that transfer to hardware are all defensible. But “persistent worlds” here means a bounded KV cache with known drift, and the counterfactual gap makes the safety-critical use cases the hardest sell. Watch the robotics numbers, not the game demos.

---

Liquid AI’s DSpark drafter triples VLM decode on M5 Max

Source: huggingface-blog · published 2026-09-24

TL;DR

• Liquid AI’s DSpark is a 280M drafter that hits 3.13× decode speedup on LFM2.5-VL-3B on M5 Max, 2.66× on H100.
• End-to-end gains land at 1.30–2.62× because prefill and vision encoding stay unaccelerated under Amdahl’s law.
• The same drafter recipe already ships in DeepSeek-V4, beating MTP baselines by 60–85% per-user generation.
• Vision-agnostic drafters like this one can lose to SpecVLM-style compressors on visually-grounded acceptance rates.

What DSpark actually is

DSpark is a speculative-decoding drafter for Liquid AI’s LFM2.5-VL-3B vision-language model: a 4-layer attention-only network with a low-rank Markov head, roughly 280M parameters, which adds 8.9% to the target’s memory footprint. It projects image patches and text tokens into a shared hidden-state space so the drafter runs modality-agnostically, and a block size of 8–9 draft tokens per verification step maximizes throughput on both Apple silicon and H100.

The reported wins on the MMSpec harness are real: up to 3.13× decode on M5 Max and 2.66× on H100, with end-to-end gains of 1.30–2.62× depending on chip and task. Day-one integrations cover SGLang, llama.cpp (via GGUF), and MLX-VLM.

Worth naming the target too: LFM2.5-VL-3B is a credible small VLM — 51.8 on MM-IFEval, 71.4 on RealWorldQA, and a jump from 57.1 to 87.9 on RefCOCO grounding versus the prior generation ⁷. This isn’t a drafter bolted onto a weak model to inflate a ratio.

DSpark is a family, not a VLM trick

The more interesting fact the blog post buries: the same drafter architecture — parallel backbone plus lightweight Markov head — is what powers DeepSeek’s DSpark release for DeepSeek-V4, where it reportedly delivers 60–85% per-user generation gains over multi-token-prediction baselines ⁸. That reframes the LFM2.5-VL number as one instantiation of a broader “semi-autoregressive drafter + confidence-scheduled verifier” pattern that generalizes across text and multimodal targets. The 280M/4-layer config is the small end of the design space.

The vision-agnostic bet

Liquid’s choice to let the drafter operate on unified hidden states, rather than model visual tokens separately, is a contested design axis. The MMSpec benchmark paper (600 samples, 10 algorithms across Qwen2.5-VL and LLaVA-1.5) finds vision-agnostic drafters can drop below autoregressive baselines as batch size grows, because acceptance rates collapse on visually-grounded tokens ⁹. SpecVLM takes the opposite bet — an elastic visual compressor that prunes image tokens before drafting — and reports 2.5–2.9× end-to-end on LLaVA/MMMU ¹⁰.

No public benchmark puts DSpark against SpecVLM, ViSkip, or EAGLE-3 on a common harness, so “state of the art” here rests on MMSpec’s internal grouping.

The caveats Liquid names — and one it doesn’t

Liquid concedes Amdahl’s law: nothing accelerates vision encoding or prefill, which dominate wall time on edge silicon. Their own numbers reportedly sag to ~1.29× on complex-reasoning tasks where drafter acceptance drops, and independent latency reproductions on public aggregators are still empty ¹¹.

The omission is security. Speculative decoding leaks: variable per-step acceptance counts are a documented network side channel, with published attacks recovering conversation topics and PII at >90% precision over encrypted traffic ¹². For anyone deploying DSpark in hosted or multi-tenant serving, that’s a threat model no LFM2.5 release note has yet addressed.

---

Datasette 1.0a41 adds OpenTelemetry for SQLite bottlenecks

Source: simon-willison · published 2026-09-24

TL;DR

• Datasette 1.0a41 ships OpenTelemetry spans and metrics targeting SQL thread saturation and write queue depth.
• A new Plugin Telemetry Kit lets third-party plugins register spans through a public registry API.
• All modal dialogs collapse into one documented Web Component plugins can reuse for focus trapping and ARIA.
• Following 1.0a39’s auth-leak patch and 1.0a40’s background tasks, this is 1.0 endgame hardening, not features.

The observability layer targets SQLite’s actual failure mode

Alec Garcia’s OpenTelemetry integration is the headline, and it’s more opinionated than a generic ASGI wrapper. Datasette now emits distinct spans for datasette.client and server work, plus dedicated spans for datasette.render_template, datasette.permission and each datasette.hook call ¹³. On the metrics side, it exposes SQL thread saturation, write queue depth and query latency ¹³.

That instrument list isn’t arbitrary. SQLite has a single writer; the classic Datasette-in-production failure is a concurrent-write pileup on Cloud Run or Fly, and Willison has previously advised capping production queries at 10,000 scanned rows to avoid CPU saturation ¹⁴. Write queue depth and thread saturation are exactly the signals an operator needs to see that wall coming before it hits.

The datasette-otel-prometheus plugin served as the pre-merge testbed, and the design ships with a Plugin Telemetry Kit: a public registry API plus test helpers so plugin authors can add their own spans without re-implementing OTel plumbing ¹⁵. That’s the interesting move — it’s an ecosystem-wide instrumentation contract rather than “we added tracing to core.”

One modal component, one accessibility floor

The frontend change is smaller in code but similar in spirit. Every modal dialog in Datasette now routes through a single Web Component, documented for plugins to consume. This is the pattern the wider community has converged on in 2026: centralise focus trapping, ARIA attributes and scroll locking in one primitive rather than letting each plugin roll its own and quietly ship accessibility bugs ¹⁶.

It’s also a live test of Willison’s server-rendered-plus-Web-Components approach. The trade-offs are known: recent adoption surveys still call Web Components a “sushi knife used to cut bread” — great for isolated widgets, awkward for app-wide state, with persistent friction at React boundaries ¹⁷. For a plugin ecosystem where each extension owns a small piece of UI, that’s the right side of the trade. For anyone imagining the same primitive scaling to full dashboards, the ceiling is lower.

Where this sits in the 1.0 sprint

Taken in isolation, 1.0a41 looks like housekeeping. In sequence it doesn’t: 1.0a39 patched authorization gaps that leaked table and database names to unauthenticated users, 1.0a40 added add_background_task(), and 1.0a41 layers telemetry and UI consolidation on top ¹⁸. The alphas are steadily closing the gaps enterprise deployments have been quietly flagging — security, async work, observability, plugin UI contracts — with the httpx2 migration cited as one of the last major architectural moves before beta ¹⁸.

The open question is adoption. Core now offers a telemetry contract and a modal contract; whether plugin authors take them up, or whether the long tail keeps rolling its own dialogs and ad-hoc logging, is what will decide whether 1.0 ships with a coherent ecosystem or just a coherent core.

Round-ups

commit-rewriter 0.2 adds non-default branch support

Source: simon-willison

Simon Willison’s commit-rewriter tool now runs against branches other than the repo default, invoked via uvx commit-rewriter —branch other. The 0.2 release closes issue #3 and extends the git history-rewriting utility beyond its previous single-branch limitation.

Willison and Vincent host SF agentic engineering show-and-tell Oct 14

Source: simon-willison

Simon Willison and Jesse Vincent are convening an evening Birds of a Feather session in San Francisco on October 14 for builders working on top of coding agents. The format is informal show-and-tell focused on odd experiments and unfinished work rather than product pitches.

Footnotes

1. acttwo.cv architecture write-up — https://acttwo.cv/gwm-worlds-2

   Three-tier conditioning per step: a genesis prompt + reference frame (global), per-frame camera translation/rotation and text actions (active inputs), and a sliding KV-cache window (temporal history) — with distillation compressing the diffusion denoiser for real-time latency.

   ↩

2. iWorld-Bench (ICML 2026 paper notes, GitHub) — https://github.com/zhaoyang97/Paper-Notes-en/blob/main/docs/ICML2026/others/iworld-bench_a_benchmark_for_interactive_world_models_with_a_unified_action_gene.md

   Interactive world models are scored on closed-loop revisit tasks using Memory Symmetry and Trajectory Alignment; many current models fail due to KV-cache truncation and attention decay when asked to return to a starting point.

   ↩

3. Medium — ‘Simulating Reality: Runway GWM-1’ — https://medium.com/mlworks/simulating-reality-the-dawn-of-runway-gwm-1-93bc11539f27

   Runway Research evaluated eight robot manipulation policies inside GWM-Robotics; world-model rollouts correlated strongly with real-hardware outcomes, and 3D variants using Gaussian Splatting converged up to 2× faster on contact-rich manipulation.

   ↩

4. Futurepicker analysis — https://futurepicker.com/en/runway-gwm-worlds-2-world-model-2026-en/

   A ‘probability bias’ in training data: the model convincingly simulates a football goal being scored but struggles to render a realistic ‘miss’ because successful outcomes dominate video datasets — a counterfactual-reasoning hole for high-stakes sim use.

   ↩

5. PixelSham (on Decart Mirage) — https://www.pixelsham.com/2025/07/25/decart-ai-mirage-the-first-ever-world-transformation-model-turning-any-video-game-or-camera-feed-into-a-new-digital-world-in-real-time/

   Decart Mirage… reports a processing delay of roughly 40–100ms per frame, sufficient for live-streaming and interactive video conferencing — a ‘World Transformation Model’ that restyles live feeds rather than generating worlds from scratch.

   ↩

6. r/singularity discussion of GWM Worlds 2 — https://www.reddit.com/r/singularity/comments/1w6exqw/introducing_gwm_worlds_2_a_playable_world_model/

   Runway ‘survives on hype’… a notable gap between the polished promotional demos and the inconsistent, sometimes ‘wonky’ results experienced by paying subscribers, alongside a ‘brutal credit economy’ and overzealous censorship on Gen-3/4.5.

   ↩ ↩²

7. Liquid AI blog — LFM2.5-VL-3B — https://www.liquid.ai/blog/lfm2-5-vl-3b

   LFM2.5-VL-3B scores 51.8% on MM-IFEval and 71.4% on RealWorldQA, and raised RefCOCO grounding precision from 57.1 to 87.9 versus the prior generation.

   ↩

8. MarkTechPost — DeepSeek DSpark framework coverage — https://www.marktechpost.com/2026/06/27/deepseek-releases-dspark-a-speculative-decoding-framework-that-accelerates-deepseek-v4-per-user-generation-60-85-over-mtp-1/

   DSpark accelerates DeepSeek-V4 per-user generation 60–85% over MTP baselines using a semi-autoregressive drafter with a lightweight Markov head.

   ↩

9. MMSpec benchmark paper (arXiv 2509.11815) — https://arxiv.org/html/2509.11815v1

   Vision-agnostic speculative decoding methods struggle to maintain acceptance rates on VLMs; without modeling visual information, speedups can drop below autoregressive baselines as batch size grows.

   ↩

10. SpecVLM paper (arXiv 2603.14989) — https://arxiv.org/html/2603.14989v1

    SpecVLM reports 2.5–2.9x end-to-end speedups on LLaVA/MMMU using an elastic visual compressor that adaptively prunes visual tokens to reduce drafter overhead.

    ↩

11. openai-hub summary of LFM2.5-VL-DSpark release — https://www.openai-hub.com/news/2168/

    Internal Liquid AI data show speedups drop to as low as 1.29x on complex reasoning tasks where drafter acceptance rates fall; independent third-party latency numbers for the DSpark variant remain unpopulated on public benchmark aggregators.

    ↩

12. Schneier on Security — Side-Channel Attacks Against LLMs — https://www.schneier.com/blog/archives/2026/02/side-channel-attacks-against-llms.html

    Because the number of tokens accepted per speculative step varies with draft correctness, attackers can monitor packet sizes and timing to infer conversation topics or recover PII with 90%+ precision, even over encrypted channels.

    ↩

13. g1ga.it (Alec Garcia) — OpenTelemetry implementation detail — https://www.g1ga.it/

    The integration emits datasette.client and SERVER spans plus dedicated spans for datasette.render_template, datasette.permission and datasette.hook, and exposes metrics for SQL thread saturation, write queue depth and query latency — signals aimed at SQLite’s single-writer bottleneck.

    ↩ ↩²

14. Simon Willison — production/observability context — https://simonwillison.net/

    Production Datasette instances should ideally be restricted to scanning no more than 10,000 rows per query to avoid CPU saturation; the new OTel metrics for write queue depth and thread saturation directly target the SQLite-in-serverless pain points operators have flagged.

    ↩

15. g1ga.it — ‘Plugin Telemetry Kit’ — https://www.g1ga.it/

    A public registry API and test helpers let plugin authors register their own spans and metrics without reinventing instrumentation; the datasette-otel-prometheus plugin served as the testbed before core adoption.

    ↩

16. Medium — ‘Stop Rebuilding Modals: A Deep Dive into the

    Element’ — https://medium.com/@beiselanja/stop-rebuilding-modals-a-deep-dive-into-the-dialog-element-4580cdbb7b20

    Centralising modal logic — focus trapping, ARIA attributes, scroll locking — into one component eliminates the inconsistency and accessibility bugs that plague ad-hoc per-plugin implementations.

    ↩

17. getdom.studio — Web Components adoption survey 2026 — https://getdom.studio/blog/can-i-use-web-components

    Web Components have ‘won’ the battle for cross-framework design systems but remain a ‘sushi knife used to cut bread’ — excellent for small reusable UI units, poorly suited for application-wide state; friction with React property binding and hydration persists.

    ↩

18. Simon Willison’s blog (context on 1.0 alpha cycle) — https://simonwillison.net/

    1.0a41 is part of an intensive triage effort to resolve remaining bugs and architectural inconsistencies before the final 1.0 stable launch, following 1.0a40’s add_background_task() and 1.0a39’s security patches for authorization gaps that leaked table and database names to unauthenticated users.

    ↩ ↩²