u/ai-lover

https://reddit.com/link/1uluc82/video/ml81ua82rvah1/player

Most browser agents drive the page from the outside. An external process, a headless browser, screenshots piped to a multimodal model. That's automation pointed at your app — not something living inside it. Alibaba's Page Agent flips the direction.

They shipped an open-source JavaScript GUI agent that runs client-side, inside the webpage itself. It reads the live DOM as text — a "dehydrated" FlatDomTree — then clicks, types, and scrolls as the real user. No screenshots, no multimodal model, no backend rewrite, and it inherits the user's existing session and auth.

Full analysis: https://www.marktechpost.com/2026/07/02/meet-alibabas-page-agent-a-javascript-in-page-gui-agent-that-controls-web-interfaces-with-natural-language-through-the-dom/

GitHub Repo: https://github.com/alibaba/page-agent

Using Lift to Turn Research PDFs into Structured JSON with Controlled, Schema-Guided Field-Level Evaluation

Most "PDF extraction" is a text dump with a regex bolted on top. That's not document mining — and it breaks the moment a paper puts its real number in a table three pages away from the abstract.

So we built a full tutorial around Lift, an open PDF-to-structured-data model, treating it as a controlled benchmark instead of a one-off demo.

The setup is synthetic multi-page research reports with deliberate traps: validation-vs-test metric ambiguity, baseline-vs-proposed comparisons, papers that release no code, and boolean state-of-the-art claims. A JSON Schema then tells Lift exactly which fields to recover — title, authors, datasets, metrics, hyperparameters, limitations, code URL.

Here's what's actually interesting:

→ 4-bit NF4 loading fits the ~10B model on a 16 GB T4/L4 — no A100 required

→ Schema descriptions do the disambiguation: test number vs. validation number, proposed method vs. baseline, released code vs. explicit null

→ Field-level scoring against ground truth, with numeric tolerance and abstention handling — not a vibe check

→ Extractions roll up into a queryable knowledge base, one row per mined paper

→ Datalab report Lift at ~90.2% field accuracy on their 225-doc benchmark

Full tutorial: https://www.marktechpost.com/2026/07/01/using-lift-to-turn-research-pdfs-into-structured-json-with-controlled-schema-guided-field-level-evaluation/

GitHub Repo: https://pxllnk.co/rc5yap

Most diffusion language models make one network do two jobs at once — represent the clean context and denoise the noisy tokens. Those two goals pull the same weights in different directions. NVIDIA just split them apart.

They released Nemotron-Labs-TwoTower — a block-wise autoregressive diffusion model built on the Nemotron-3-Nano-30B-A3B hybrid Mamba-2/attention/MoE backbone. It runs two towers: a frozen autoregressive context tower that processes clean tokens causally, and a trainable diffusion denoiser tower that refines noisy blocks via cross-attention to that context. Only the denoiser is trained — on ~2.1T tokens, a fraction of the backbone's 25T.

Here's what's actually interesting:

→ Two towers, not one: a frozen AR context tower and a trainable diffusion denoiser, connected layer-by-layer — denoiser layer i attends to context layer i, not just the last hidden state

→ 98.7% of the autoregressive baseline's quality at 2.42× generation throughput (γ=0.8, block size 16, 2×H100)

→ It commits multiple tokens per denoising step early in decoding — that's where the one-token-per-step AR bottleneck breaks

→ One checkpoint, three decoding modes: mask diffusion, mock-AR, and standard AR

→ Ablations: causal Mamba beats bidirectional Mamba, and tying the two towers under a joint loss is substantially worse

Full analysis: https://www.marktechpost.com/2026/07/01/nvidia-releases-nemotron-labs-twotower/

Paper: https://arxiv.org/pdf/2606.26493

Weights: https://huggingface.co/collections/nvidia/nemotron-labs-twotower

https://reddit.com/link/1ukfnsq/video/t43wdu4gukah1/player

Most tabular ML in production is still XGBoost plus hours of hyperparameter tuning and feature engineering. That's not a foundation-model workflow — and Google Research just brought the zero-shot idea to tables.

They introduced TabFM — a foundation model for tabular classification and regression that reads your entire dataset as a single prompt and predicts in one forward pass, with no per-dataset training, tuning, or feature engineering anywhere in the loop.

Here's what's actually interesting:

→ In-context learning, not fine-tuning: training rows and test rows go in as one context, and the model learns the task at inference time

→ Hybrid attention: alternating row/column attention (TabPFN-style) → row compression into a dense vector → in-context learning over compressed rows (TabICL-style)

→ Trained entirely on hundreds of millions of synthetic datasets generated by structural causal models — no proprietary tables required

→ TabArena (38 classification + 13 regression datasets, 700–150,000 samples): Google reports it consistently outperforms heavily tuned supervised baselines

Full analysis: https://www.marktechpost.com/2026/07/01/google-ai-introduces-tabfm-a-hybrid-attention-tabular-foundation-model-for-zero-shot-classification-and-regression/

Technical Details: https://research.google/blog/introducing-tabfm-a-zero-shot-foundation-model-for-tabular-data/

Repo: https://github.com/google-research/tabfm

https://preview.redd.it/eam5uqurqkah1.png?width=2026&format=png&auto=webp&s=aa79748af4ea0353ec930d645c5f91a2963c0939

OpenClaw Releases iOS and Android Companion Node Apps That Connect a Phone to a Self-Hosted AI Agent Gateway

Most "AI assistant" apps are a chatbot in a sandbox, calling someone else's API. OpenClaw's iOS and Android apps draw a very clear line away from that model.

They're companion nodes, not standalone apps. Each phone pairs to a self-hosted OpenClaw Gateway over a WebSocket (default port 18789) with role: "node". The Gateway — the single control plane for sessions, routing, channels, and events — runs on macOS, Linux, or Windows (WSL2). The phone gives the agent a body: camera, location, voice, notifications, and a live Canvas.

Here's what's actually interesting:

→ The assistant runs on your machine — chat messages land on the Gateway, never on the phone

→ Nodes expose a command surface (canvas., camera., device., notifications., system.*) through node.invoke

→ Privacy-heavy commands like camera.snap and screen.record stay off until you allowlist them via gateway.nodes.allowCommands

→ Camera and screen capture run foreground-only; pairing needs explicit approval (openclaw devices approve)

→ Both store listings declare no data collection; ws:// is LAN-only, remote needs a wss:// TLS endpoint via Tailscale

Full analysis: https://www.marktechpost.com/2026/06/29/openclaw-releases-ios-and-android-companion-node-apps-that-connect-a-phone-to-a-self-hosted-ai-agent-gateway/

Android app: https://play.google.com/store/apps/details?id=ai.openclaw.app

iOS App: https://apps.apple.com/us/app/openclaw-ai-that-does-things/id6780396132

https://reddit.com/link/1uj9096/video/x662yks27bah1/player

Most speculative decoding makes you pick one: a fast parallel drafter, or an accurate sequential one. is that a false choice? — and DeepSeek's DSpark just showed why.

They released DSpark — a speculative decoding framework, not a new model — that attaches a draft module to existing DeepSeek-V4 weights. It pairs a heavy parallel draft backbone with a tiny Markov head that nudges each token's logits using only t-1, then schedules how many tokens get verified based on real-time GPU load.

Here's what's actually interesting:

→ Semi-autoregressive drafting: parallel backbone for speed, lightweight sequential head to cut suffix decay — the rank-256 Markov head adds almost nothing to latency (0.2–1.3%)

→ Confidence-scheduled verification: a calibrated confidence head plus a hardware-aware scheduler verify more tokens when GPUs are idle, fewer when they're busy

→ Accepted length: +26–31% over Eagle3 and +16–18% over DFlash across Qwen3-4B / 8B / 14B

→ Production on DeepSeek-V4: 57–85% faster per-user generation over the MTP-1 baseline at matched throughput

→ Output stays lossless, and the training repo (DeepSpec) ships under MIT

Full analysis: 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/

Paper: https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf

GitHub Repo: https://github.com/deepseek-ai/DeepSpec

Model weights on HF: https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark

https://reddit.com/link/1uh83aw/video/h8e31q4dxu9h1/player

Most end-to-end OCR models slow down the longer they read. Every token they generate adds to the KV cache — so memory climbs and parsing dozens of pages becomes impractical. Baidu's Unlimited OCR attacks that at the attention layer, not with engineering workarounds.

They open-sourced Unlimited OCR — a 3B MoE model with 500M active parameters, built on DeepSeek OCR, that replaces every decoder attention layer with Reference Sliding Window Attention (R-SWA). Each token attends to all reference tokens (visual tokens + prompt) plus only the last 128 generated tokens. Everything older is evicted, so the KV cache stays constant instead of growing with output length. MIT-licensed, weights public.

Here's what's actually interesting:

→ The full decode runs on a constant KV cache (L_m + n) — memory and per-step latency stay flat the whole way

→ DeepEncoder compresses a 1024×1024 page to 256 visual tokens (16×), so the prefill stays small

→ Continue-trained from the DeepSeek OCR checkpoint for just 4,000 steps with the encoder frozen — the gains come from R-SWA, not scale

→ OmniDocBench v1.5: 93.23 vs. 87.01 for the DeepSeek OCR baseline (+6.22)

→ 40+ pages parsed in one forward pass, edit distance still under 0.11; 35% throughput lead at 6,000 output tokens

Full analysis: https://www.marktechpost.com/2026/06/24/baidu-releases-unlimited-ocr-a-3b-model-that-keeps-the-kv-cache-flat-for-long-document-parsing/

Paper: https://arxiv.org/pdf/2606.23050

Model weights on HF: https://huggingface.co/baidu/Unlimited-OCR

Repo: https://github.com/baidu/Unlimited-OCR

https://preview.redd.it/l99dpg19ad9h1.png?width=1814&format=png&auto=webp&s=e585f2a073d1b599eb13d957668e5b1880ddd062

Most speculative decoding still drafts tokens one at a time. That's not parallel generation — it just hides the serial loop behind a smaller model.

UC San Diego's z-lab just drew a clear line between the two. They released DFlash — a lightweight block diffusion model that drafts a whole block of tokens in a single forward pass, then lets the target model verify the block in parallel. Up to 15× higher throughput for gpt-oss-120b on NVIDIA Blackwell. No token-by-token drafting anywhere in the speculative path.

Here's what's actually interesting:

→ The drafter is conditioned on the target model's own hidden features, injected into the Key/Value cache of every draft layer — so acceptance length scales with draft depth instead of diluting away

→ A 5-layer drafter replaces the 7B diffusion drafters that capped earlier methods near 3–4×

→ MATH-500 speedup: 6.08× vs. 1.81× for EAGLE-3 (4.86× average vs. 1.76×, Qwen3-8B, greedy)

→ Up to 15× higher throughput for gpt-oss-120b on NVIDIA Blackwell — at the same interactivity target

→ Lossless: the target still verifies every token, so output quality is preserved

Full analysis: https://www.marktechpost.com/2026/06/24/dflash-speculative-decoding-drafts-whole-token-blocks-in-parallel-for-up-to-15x-higher-throughput-on-nvidia-blackwell/

Paper: https://arxiv.org/pdf/2602.06036

NVIDIA's metrics: https://developer.nvidia.com/blog/boost-inference-performance-up-to-15x-on-nvidia-blackwell-using-dflash-speculative-decoding/

Project: https://z-lab.ai/projects/dflash/

Model weights: https://huggingface.co/collections/z-lab/dflash

Repo: https://github.com/z-lab/dflash

https://reddit.com/link/1ue6r7w/video/cfkba395o69h1/player

Most "structured extraction" is a general LLM asked nicely to return JSON, with a retry loop bolted on. That's not a guarantee — and Datalab just drew a very clear line between the two.

They just released lift as open weights — a 9B vision model that decodes directly against your JSON schema, so the output is valid by construction. It reads whole multi-page documents in a single pass, including values that span pages. The structural guarantee lives in the decoder, so you don't need a parse-validate-retry loop to get well-formed JSON.

Here's what's actually interesting:

→ Schema-constrained decoding: your schema is compiled to a grammar, and tokens that would break it are masked at every step. Structure is enforced as it generates, not validated after the fact.

→ It guarantees shape, not meaning — a field typed "number" holds a number, just not necessarily the right one. Validity ≠ correctness.

→ Trained abstention: every field is made nullable, so it returns null instead of hallucinating a tax ID that isn't on the page.

→ The trap: hand it enum / ref / anyOf and the schema won't compile — lift silently drops the guarantee and free-generates. No hard error. Validate downstream.

→ 90.2% field accuracy on a 225-doc, ~11,000-field adversarial benchmark — the highest of any self-hostable model they tested.

→ 9.5s median/doc: ~3x faster than Gemini Flash 3.5, and within a point of it on field accuracy.

→ Built on Qwen 3.5 — the base scores 76.3%, lift hits 90.2%. Same size, so the gain is the training, not the parameters.

→ The honest catch: full-document accuracy is 20.9% — near the bottom of the table. Getting every field right across a 64-page doc is brutal; even the hosted leaders top out at 44.4% / 40.0%.

Full analysis: https://www.marktechpost.com/2026/06/23/datalab-releases-lift-a-9b-open-weights-vision-model-that-extracts-structured-json-from-pdfs-using-schemas/

Repo: https://pxllnk.co/nmpjxqn

Model weights on HF: https://pxllnk.co/t0x8a0r

Playground: https://pxllnk.co/mf4o7kl

https://preview.redd.it/gsr0tv46a39h1.png?width=1438&format=png&auto=webp&s=66ba3395cf90415900f7509c08c5620d81d1a57c

Most "structured extraction" is a general LLM asked nicely to return JSON, with a retry loop bolted on. That's not a guarantee — and Datalab just drew a very clear line between the two.

They just released lift as open weights — a 9B vision model that decodes directly against your JSON schema, so the output is valid by construction. It reads whole multi-page documents in a single pass, including values that span pages. The structural guarantee lives in the decoder, so you don't need a parse-validate-retry loop to get well-formed JSON.

Here's what's actually interesting:

→ Schema-constrained decoding: your schema is compiled to a grammar, and tokens that would break it are masked at every step. Structure is enforced as it generates, not validated after the fact.

→ It guarantees shape, not meaning — a field typed "number" holds a number, just not necessarily the right one. Validity ≠ correctness.

→ Trained abstention: every field is made nullable, so it returns null instead of hallucinating a tax ID that isn't on the page.

→ The trap: hand it enum / ref / anyOf and the schema won't compile — lift silently drops the guarantee and free-generates. No hard error. Validate downstream.

→ 90.2% field accuracy on a 225-doc, ~11,000-field adversarial benchmark — the highest of any self-hostable model they tested.

→ 9.5s median/doc: ~3x faster than Gemini Flash 3.5, and within a point of it on field accuracy.

→ Built on Qwen 3.5 — the base scores 76.3%, lift hits 90.2%. Same size, so the gain is the training, not the parameters.

→ The honest catch: full-document accuracy is 20.9% — near the bottom of the table. Getting every field right across a 64-page doc is brutal; even the hosted leaders top out at 44.4% / 40.0%.

Full analysis: https://www.marktechpost.com/2026/06/23/datalab-releases-lift-a-9b-open-weights-vision-model-that-extracts-structured-json-from-pdfs-using-schemas/

Repo: https://pxllnk.co/nmpjxqn

Model weights on HF: https://pxllnk.co/t0x8a0r

Playground: https://pxllnk.co/mf4o7kl

https://preview.redd.it/gsr0tv46a39h1.png?width=1438&format=png&auto=webp&s=66ba3395cf90415900f7509c08c5620d81d1a57c

Most fast attention kernels on AMD get there by hand-writing GCN assembly. That's a maintenance tax most teams can't pay — and MoonMath.ai just showed you don't have to.

They open-sourced a bf16 forward attention kernel for AMD MI300X (CDNA3, gfx942), written entirely in HIP, not assembly. It beats AITER v3 — AMD's own assembly-tuned kernel — on every shape and every rounding mode across an 8K–128K token sweep.

Here's what's actually interesting:

→ One-instruction asm wrappers: you pick the exact opcode, the compiler still allocates the registers — instruction-level control without the assembly tax

→ Eight waves in two groups, two barriers per iteration — one group saturates the matrix core while the other runs softmax and prefetches the next loads

→ Most of the win is memory placement, not a clever instruction — K in LDS, V kept hot in L1, Q and accumulators in registers

→ Geomean 1.18× / 1.15× / 1.08× vs AITER (RTNE/RTNA/RTZ), up to 1.26×; 1.37–1.59× vs Modular MAX

→ Already merged into SGLang diffusion: 1.23× faster Wan2.1 video generation on MI300X, with no visible quality regression

The core bet: give the compiler a hand-built framework, then let it do what it's good at — optimize locally inside it.

Full analysis: https://www.marktechpost.com/2026/06/22/moonmath-ai-open-sources-a-hip-attention-kernel-for-amd-mi300x-that-beats-aiter-v3-on-every-shape-and-rounding-mode/

Technical details: https://moonmath.ai/cdna3attention/

https://reddit.com/link/1ucdr77/video/ecq2xvgkcs8h1/player