HN user

GreenGames

245 karma
Posts20
Comments11
View on HN
www.lucebox.com 11d ago

Laguna XS 2.1 33B on a RTX 3090: 296 tok/s peak, 152 tok/s at 256K context

GreenGames
20pts1
github.com 1mo ago

256K context with 72MiB of KV cache on the GPU

GreenGames
3pts0
www.lucebox.com 1mo ago

A 35B MoE on a 16 GB GPU, without the offload tax

GreenGames
18pts0
github.com 2mo ago

PFlash: 10x prefill speedup over llama.cpp at 128K on a RTX 3090

GreenGames
3pts1
github.com 3mo ago

We got 207 tok/s with Qwen3.5-27B on an RTX 3090

GreenGames
165pts52
github.com 3mo ago

Show HN: OS Megakernel that match M5 Max Tok/w at 2x the Throughput on RTX 3090

GreenGames
6pts1
www.trycua.com 1y ago

App-Use, Control Individual Applications with CUA Agents

GreenGames
2pts1
github.com 1y ago

Show HN: Lumier – Run macOS VMs in a Docker

GreenGames
159pts52
techcrunch.com 1y ago

Microsoft is reportedly about to lay off 3% of its workforce

GreenGames
13pts2
www.polariscloud.ai 1y ago

Polaris is giving free GPUs/CPUs for everyone

GreenGames
3pts0
techcrunch.com 1y ago

Improvements in reasoning AI models may slow down soon, analysis finds

GreenGames
3pts0
techcrunch.com 1y ago

Microsoft and OpenAI are renegotiating their partnership

GreenGames
3pts0
techcrunch.com 1y ago

Apple developing new chips for smart glasses, Macs, and more

GreenGames
6pts0
github.com 1y ago

Show HN: Tlume – a CLI tool that converts Tart VM images for Lume

GreenGames
5pts2
github.com 1y ago

Show HN: Lume – OS lightweight CLI for MacOS and Linux VMs on Apple Silicon

GreenGames
309pts75
github.com 1y ago

Show HN: List of AI Agents

GreenGames
4pts1
github.com 1y ago

A curated list of AI agents for Computer Use

GreenGames
1pts1
github.com 1y ago

Show HN: OS List of AI Agents

GreenGames
1pts0
github.com 1y ago

ACU – Agents for Computer Use

GreenGames
2pts1
www.safurai.com 3y ago

An AI Code Assistant into Your IDE

GreenGames
2pts0

This reads like you didn’t read the post.

z-lab runs BF16 on B200 (54+ GB). There is no z-lab path that fits on a 24 GB 3090. That is literally the entire point of our work, and it is stated in the second paragraph. If you had checked the HF model card you linked before posting, you would see the same thing. Before this repo, there was no path to run this... SGLang's GGUF path for this model is broken. llama.cpp doesn't have DFlash speculative decoding at all. If you wanted to run this hybrid model fast on a 24 GB consumer card, there was nothing...

That took weeks of real engineering.

Calling that "vibecoded" because we used a bit of AI in the README is clean is the laziest possible critique. An LLM reading the DFlash paper does not catch verify_logits_buf being sized vocabq_len when DDTree reads vocab(budget+1). That is hours of debugging with nvidia-smi and memory sanitizers, not prompting.

The 207 and 129.5 numbers are both in the second sentence of the post and again in the TL;DR. 207.6 is peak tok/s in the linked demo video, 129.5 is the HumanEval 10-prompt mean at DDTree budget=22. We specify both just behind the title.

On the Q4 KV cache: the tradeoff is disclosed with actual numbers. AL 8.56 -> 8.33 at short context (3% drop), dramatically better at long context. It’s the only way 128K allocates on 24 GB. The binary is env-selectable, you can run BF16 KV if you don’t need 128K. Both are benchmarked.

We built a standalone C++/ggml speculative decoder for Qwen3.5-27B Q4_K_M with a DFlash block-diffusion draft.

207.6 tok/s peak (5.46x over AR); HE 10-prompt bench averages 129.5 tok/s at DDTree budget=22, single RTX 3090, 24 GB. 3.43x over autoregressive and 2.8x over the best public SGLang AWQ number.

TL;DR - Peak 207.6 tok/s DFlash vs 38.0 tok/s AR (5.46x). HE bench: 129.5 tok/s mean at DDTree budget=22. - 3.43x over autoregressive Q4_K_M baseline (37.78 tok/s). - 2.8x vs SGLang AWQ reference (46.6 tok/s) on the same RTX 3090. - 128K context fits on 24 GB. Q4_0 KV + rolling 4096-slot target feature buffer. 134.78 tok/s at ctx=131072. - Only ggml. Never link libllama. ~2000 LOC C++/CUDA in libdflash27b.a around ggml_gated_delta_net.

Why the experiment exists Qwen3.5-27B is a hybrid model: every 4th layer is full softmax attention, the rest (48 of 64) are Gated DeltaNet. SSM state cache alongside the KV cache. That combo doesn't have a good single-3090 decode path today: llama.cpp has the GGUF loader and ggml_gated_delta_net, but no DFlash speculative decoding. vLLM / SGLang ship z-lab's DFlash integration, but only on BF16 (54 GB, doesn't fit on 24 GB). AWQ target on SGLang runs plain AR at 46.6 tok/s but can't host a BF16 draft + DDTree state in 24 GB. z-lab's reference benchmarks run BF16 on B200, 54+ GB class. We wanted the fastest single-3090 decode on a 24 GB card. The answer: port only the graph glue to ggml, keep the existing DeltaNet kernel, run DFlash block-diffusion draft with a DDTree verifier, compress KV to Q4_0 for long context.

From autoregressive to DDTree Same 10-prompt HE bench, n_gen=256, Q4_K_M target, BF16 draft. AL = average accept length. DDTree paper reports +35-42% over chain DFlash on pure-attention Qwen3 variants. On our hybrid Q4_K_M/RTX 3090 combo we see +15% over chain. The gap comes from Q4 quantization flattening the draft softmax, partially patched with a chain pre-seed in build_ddtree. Draft-ceiling bound, not verify-memory bound: a bigger tree won't help, only a better draft will.

Key wins - f16 intermediate cache: half the bandwidth, +5% at the same tree budget. Bit-identical to AR at 40 tokens. - Persist-write kernel (ggml_gated_delta_net_tree_persist): skips a 9 ms ggml_cpy per step, +11%. - target_feat compaction after sibling accept: unlocked real tree rescue on 9/10 prompts. - extract_draft_topk reverse bug: sort_heap + cmp_greater already produces descending order; an extra std::reverse was sending the worst candidate to the tree root. One-line fix. - verify_logits_buf overflow: sized vocabq_len but DDTree reads vocab(budget+1) past budget 15. Silent memory corruption. One-line size fix.

128K context on 24 GB Flash-attention in ggml-cuda supports Q4_0 K+V natively, so KV compression is just ggml_cpy with the F32->Q4_0 quantizer on write. 8x over f16. Combined with a rolling 4096-slot target_feat ring, target_feat shrinks from 6.6 GB to 0.2 GB at 128K. Tradeoffs: Q4_0 KV costs ~3% quality on HE (AL 8.56 -> 8.33) at short context, dramatically better at long ones. Only thing that lets 128K fit on 24 GB.

Prefill Short prompts (<=2048 tok): PREFILL_UBATCH=16. Matches DFlash block size. Long prompts (>2048 tok): auto-bump to PREFILL_UBATCH=192. 13K prefill: 40.9 s -> 15.07 s (2.7x, ~913 tok/s).

What comes next - Daemon mode: keep the model resident, first-token latency 10 s -> ms. - Temperature / top-k sampling in verify. Currently greedy-only. - Q5_K_M / Q6_K: better quants should recover most of the ~30-point accept gap vs BF16. - Full llama.cpp integration: qwen35 arch, llama-speculative-dflash.cpp wiring. - Metal/Vulkan: not planned. CUDA only, anyone who wants Metal can fork.

As soon as Qwen3.6-27B comes out, we'll do the same for it. Repo in the first comment (open source, MIT).

Hi there, Alessandro and Francesco here. We just launched an experimental feature in C/ua called App-Use. It lets you create virtual desktops scoped to specific apps (e.g., "Safari and Notes only") to give your agents focused, lightweight control without full-screen access.

Use cases:

- Run multiple agents in parallel with isolated app views

- Automate your iPhone using the iPhone Mirroring app

- Improve agent task precision and reduce VLM distractions

Works only on macOS (Sequoia+) and requires experiments=["app-use"]. No extra processes, just clever compositing.

More details: https://www.trycua.com/blog/app-use

Feedback and experiments welcome!

[dead] 1 year ago

Sundar just started following cursor on twitter lol