<?xml version="1.0" encoding="UTF-8"?>
<rss  xmlns:atom="http://www.w3.org/2005/Atom" 
      xmlns:media="http://search.yahoo.com/mrss/" 
      xmlns:content="http://purl.org/rss/1.0/modules/content/" 
      xmlns:dc="http://purl.org/dc/elements/1.1/" 
      version="2.0">
<channel>
<title>the dimsum</title>
<link>https://chiragsehra.gitlab.io/thedimsumnews/issues/</link>
<atom:link href="https://chiragsehra.gitlab.io/thedimsumnews/issues/index.xml" rel="self" type="application/rss+xml"/>
<description>AI engineering intelligence from Chinese labs — read the sources, not the press release.</description>
<image>
<url>https://chiragsehra.gitlab.io/thedimsumnews/images/logo-wide.jpg</url>
<title>the dimsum</title>
<link>https://chiragsehra.gitlab.io/thedimsumnews/issues/</link>
</image>
<generator>quarto-1.10.18</generator>
<lastBuildDate>Sun, 30 Aug 2026 00:00:00 GMT</lastBuildDate>
<item>
  <title>Frontier model architecture is becoming a memory-systems problem</title>
  <dc:creator>the dimsum editorial</dc:creator>
  <link>https://chiragsehra.gitlab.io/thedimsumnews/issues/2026-08-30/</link>
  <description><![CDATA[ 





<p><strong>Week of August 24–30, 2026 · Issue 1.1 (corrected 2026-08-30 — see Corrections)</strong></p>
<hr>
<section id="the-week-in-one-sentence" class="level2">
<h2 class="anchored" data-anchor-id="the-week-in-one-sentence">The Week in One Sentence</h2>
<p>Three frontier-scale open-weight models shipped within five days — Tencent’s Hy4 preview, Alibaba’s Qwen3.8-Flash-Next, and Z.ai’s GLM-5.3-Flash (after a record-breaking week in disguise as “Ox Alpha”) — and all three bet on the same architectural hand: sparse or linear attention hybrids plus a native multi-token-prediction layer for speculative decoding.</p>
<hr>
</section>
<section id="the-big-story-tencent-open-sources-hy4-preview-770b-parameters-apache-2.0-and-sparse-attention-goes-mainstream" class="level2">
<h2 class="anchored" data-anchor-id="the-big-story-tencent-open-sources-hy4-preview-770b-parameters-apache-2.0-and-sparse-attention-goes-mainstream">The Big Story: Tencent open-sources Hy4 preview — 770B parameters, Apache 2.0, and sparse attention goes mainstream</h2>
<p><strong>What happened.</strong> On August 28, Tencent released and open-sourced <a href="https://www.tencent.com/tencent-releases-and-open-sources-tencent-hy4-preview/">Hy4 preview</a>, a 770B-total / 49B-active Mixture-of-Experts model with a 1M-token context window, under <strong>Apache 2.0</strong>, with both BF16 and FP8 checkpoints on <a href="https://huggingface.co/tencent/Hy4-preview">Hugging Face, ModelScope, GitCode, and CNB</a>. The full checkpoint is ~1.56 TB (779,960,992,733 parameters) across 78 layers (<a href="https://huggingface.co/tencent/Hy4-preview">model card</a>). This is Tencent’s flagship-class model going straight to open weights — the same week its two closest competitors shipped their own open previews (see Elsewhere).</p>
<p><strong>Under the hood.</strong> The <a href="https://huggingface.co/tencent/Hy4-preview">model card</a> is unusually specific, and the architecture reads like a synthesis of the last nine months of Chinese frontier research:</p>
<ul>
<li><strong>Attention:</strong> “Gated DeepSeek Sparse Attention (Gated DSA) with IndexCache for cross-layer sparse index reuse” — the model card explicitly cites DeepSeek’s DSA paper (arXiv:2512.02556) and a GLM paper (arXiv:2603.12201) as design references. Structural details: 64 heads, query compression to 2048 dims, KV compressed to 512 dims, a 32-head indexer (128-dim) with top-k 2048.</li>
<li><strong>MoE:</strong> 256 routed experts + 1 shared, top-8 routed per token, MoE on layers 2–78 with a dense layer 1.</li>
<li><strong>Residual:</strong> “identity Hyper-Connections” (iHC) with 4 residual streams — in the same family as Kimi K3’s Attention Residuals and GLM-5.3-Flash’s Manifold-Constrained Hyper-Connections.</li>
<li><strong>Native MTP:</strong> a built-in 10B/0.7B multi-token-prediction layer for speculative decoding, served by default in both vLLM and SGLang recipes (3 draft tokens).</li>
</ul>
<p><strong>What the evidence says.</strong> Two tiers, kept deliberately separate:</p>
<p><em>Vendor-reported (not independently verified):</em> an internal blind evaluation — 163 domain experts, 203 engineering tasks — scored Hy4 preview 2.99/4 versus Kimi K3 at 2.94 and GLM-5.3 at 2.92 (<a href="https://www.tencent.com/tencent-releases-and-open-sources-tencent-hy4-preview/">Tencent announcement</a>). Model-card benchmarks: GPQA Diamond 92.3, SWE-bench Multilingual 82.9, SWE-bench_Pro 65.7, Deep SWE 64.3. The announcement also claims the model “participated in its own training” via a recursive improvement loop and autonomously optimized its inference operators for a 31.8% end-to-end throughput gain — a striking claim with no external evidence; treat as marketing-grade until reproduced.</p>
<p><em>Independent and community evidence:</em> still thin, honestly. The <a href="https://www.reddit.com/r/LocalLLaMA/comments/1w0igxk/tencenthy4preview_770ba49b_weight_dropped/">r/LocalLLaMA weight-drop thread</a> largely amplifies Tencent’s own blind-eval numbers rather than re-running them. A <a href="https://www.reddit.com/r/LocalLLaMA/comments/1w1o324/tencent_compressed_hy4preview_from_15tb_to_about/">community GGUF quantization</a> reportedly compresses the ~1.56 TB checkpoint to ~200 GB with ~98% performance retained — unverified, but the official path exists via Tencent’s AngelSlim toolkit (see Repo Radar). <a href="https://benchlm.ai/models/hy4-preview">BenchLM ranks it #7 of 228 at 79.16</a>, but marks that score “Estimated.”</p>
<p>Worth crediting: Tencent self-flags real weaknesses in the model card — the model “spends longer than necessary reasoning” and over-verifies its own work, and both pre-training and post-training “have real headroom left.” That candor is a useful data point itself: this is a mid-training-cycle checkpoint, not a polished flagship.</p>
<p><strong>Engineer reaction and deployment surface.</strong> Same-day serving support is the real story for practitioners: prebuilt <a href="https://github.com/Tencent-Hunyuan/Hy4-preview">vLLM</a> image (<code>vllm/vllm-openai:hy4-preview</code>) with a custom <code>FLASHMLA_SPARSE</code> attention backend and <code>hy_v4</code> tool-call/reasoning parsers, plus a multi-arch (x86 + Arm) SGLang image with NEXTN speculation. Both recipes assume 8-way tensor parallelism minimum for the FP8 variant. API pricing: <strong>$0.834/M input, $2.501/M output, $0.042/M cache hits</strong> (<a href="https://www.tencent.com/tencent-releases-and-open-sources-tencent-hy4-preview/">Tencent</a>; the cache-hit line matters more than the headline price for agentic workloads — see My Read).</p>
<p><strong>Why this matters.</strong> DSA-style sparse attention and native MTP have graduated from “a DeepSeek paper” to “the default recipe copied by at least five major labs” (DeepSeek, Qwen, Tencent, Meituan, Z.ai — all documented in this issue). Hy4 is also strong evidence that Apache-2.0 frontier weights are now a competitive strategy, not a gesture: the only independent evaluation I found this month (Aikido’s, below) now treats Chinese models as defaults rather than add-ons.</p>
<p><strong>What I would test.</strong></p>
<ol type="1">
<li><strong>Speculative decoding economics:</strong> FP8 @ TP8, MTP on vs off — measure draft acceptance rate and tokens/sec at 1K/64K/512K context. The MTP layer is 0.7B active; if acceptance is near the ~3.1 mean length Meituan reports for LSA models, decode throughput should move materially.</li>
<li><strong>The overshoot tax:</strong> run a fixed coding-agent task battery at default (high) reasoning effort vs <code>reasoning_effort: "no_think"</code> and count tokens. If over-verification is real, the cost delta is the story.</li>
<li><strong>IndexCache at distance:</strong> needle-retrieval and re-ranking tasks at 256K–1M, watching for the cross-layer index reuse degrading (Meituan’s paper, below, found cross-layer reuse needs distillation to stay safe — N=4 without it collapsed their 128K needle score to 70%).</li>
</ol>
<blockquote class="blockquote">
<p><strong>A note on Anthropic model names in this issue.</strong> Three different vendors’ materials reference three different Claude generations: <strong>Opus 4.6 Max</strong> appears in Qwen’s benchmark table, <strong>Claude Opus 4.8</strong> in Z.ai’s positioning claim, and <strong>Opus 5</strong> in Aikido’s test pool. The spread reflects the sources’ vintage, not typos — and it means cross-section score comparisons are not apples-to-apples.</p>
</blockquote>
<hr>
</section>
<section id="elsewhere-in-ai-engineering" class="level2">
<h2 class="anchored" data-anchor-id="elsewhere-in-ai-engineering">Elsewhere in AI Engineering</h2>
<section id="glm-5.3-flash-the-model-that-spent-its-record-breaking-launch-week-anonymous-on-chinese-silicon-worth-testing" class="level3">
<h3 class="anchored" data-anchor-id="glm-5.3-flash-the-model-that-spent-its-record-breaking-launch-week-anonymous-on-chinese-silicon-worth-testing">GLM-5.3-Flash — the model that spent its record-breaking launch week anonymous, on Chinese silicon — <strong>Worth Testing</strong></h3>
<p><strong>What happened.</strong> On August 20, a free, unattributed model called <strong>“Ox Alpha”</strong> appeared on OpenRouter and OpenCode — no owner, no model card, 1M-token context, text/image/video input (<a href="https://linas.substack.com/p/glm-5-3-flash-guide">Linas’s Newsletter</a>). Six days later it was the most-used model on OpenRouter, having processed ~23 trillion tokens — the biggest launch in the platform’s history at roughly 2.3× the volume of the next model, and the end of DeepSeek’s 56-day run atop OpenCode (<a href="https://linas.substack.com/p/glm-5-3-flash-guide">Linas</a>). On August 26, Bloomberg’s confirmation surfaced what the community suspected: Ox Alpha was Z.ai’s GLM-5.3-Flash, and the weights landed on Hugging Face under <strong>MIT</strong> that same evening — the HF repository was created August 25 (<a href="https://linas.substack.com/p/glm-5-3-flash-guide">Linas</a>; <a href="https://huggingface.co/zai-org/GLM-5.3-Flash">HF metadata</a>). It’s 321B total / 18B active, natively FP8, ~328 GB (<a href="https://huggingface.co/zai-org/GLM-5.3-Flash">model card</a>), with 346K downloads in its first days.</p>
<p><strong>Technical signal.</strong> First natively multimodal GLM-5 (image/video/audio in), first GLM with a <strong>hybrid sparse + linear attention</strong> stack and “Manifold-Constrained Hyper-Connections,” trained on a 30T-token multimodal corpus; backing paper is <a href="https://arxiv.org/abs/2602.15763">arXiv:2602.15763</a> (per the model card). Z.ai’s launch materials describe an <strong>“IndexPool”</strong> that compresses groups of indexer key vectors to hold down latency and memory at million-token context — a fifth team attacking the indexer, though I have to flag it: the mechanism is <em>not</em> documented in the HF model card, and I could not verify it from a citable primary. The citable relayed claims are ~3× less attention compute and a <strong>4.4× smaller KV cache than GLM-5.3 at 1M context</strong> (<a href="https://linas.substack.com/p/glm-5-3-flash-guide">Linas, relaying Z.ai</a>). Vendor benchmarks: Terminal-Bench 2.1 at 84.3, DeepSWE 63.4 at 400K context.</p>
<p>The silicon detail is the part with the longest shadow: Zhipu claims the entire anonymous launch week was served on <strong>a cluster of roughly 100,000 Chinese-made AI chips, with no NVIDIA hardware involved</strong> (<a href="https://linas.substack.com/p/glm-5-3-flash-guide">Linas</a>; corroborated as reporting by <a href="https://www.scmp.com/tech/big-tech/article/3365433/zhipu-ai-shares-jump-viral-ox-alpha-model-revealed-glm-53-flash-chinese-chips">SCMP</a>). That is a vendor claim relayed through press, applying to inference “at production quality” — not training, and not independently audited. But it is the first same-week partial answer to the open question in the Ascend item below.</p>
<p><strong>Why it matters.</strong> The model card’s own benchmarks expose exactly where long-context claims should be stress-tested: ExtractBench collapses from 96.3 on short documents to <strong>27.83 on long ones</strong>, and layout parsing sits at 41.78. That’s the difference between a leaderboard context length and a usable one. The stated positioning — GLM-5.2 capability “at one-tenth the price” — is vendor framing; the MIT license and the OpenRouter usage data are the facts.</p>
<p><strong>Go deeper:</strong> <a href="https://huggingface.co/zai-org/GLM-5.3-Flash">HF model card</a> · <a href="https://linas.substack.com/p/glm-5-3-flash-guide">Linas’s Ox Alpha timeline</a> · <a href="https://www.scmp.com/tech/big-tech/article/3365433/zhipu-ai-shares-jump-viral-ox-alpha-model-revealed-glm-53-flash-chinese-chips">SCMP on the reveal</a></p>
</section>
<section id="qwen3.8-flash-next-alibaba-open-sources-a-live-preview-of-the-qwen4-architecture-worth-testing" class="level3">
<h3 class="anchored" data-anchor-id="qwen3.8-flash-next-alibaba-open-sources-a-live-preview-of-the-qwen4-architecture-worth-testing">Qwen3.8-Flash-Next — Alibaba open-sources a live preview of the Qwen4 architecture — <strong>Worth Testing</strong></h3>
<p><strong>What happened.</strong> Open weights landed August 24–26 (<a href="https://huggingface.co/Qwen/Qwen3.8-Flash-Next">HF metadata</a> says 2026-08-24; the <a href="https://qwen.ai/blog?id=qwen3.8-flash-next">Qwen blog</a> announced August 26, 23:00 Beijing). This follows the <a href="https://github.com/QwenLM/Qwen3.8">Qwen3.8-Max 2.4T-A95B weights on August 12 and the 27B on August 14</a> — the first time Qwen shipped a Max-tier model as open weights.</p>
<p><strong>Technical signal.</strong> The model card is a spec sheet for where frontier efficiency architecture is going. Total ~180B parameters in the repo, but the composition is the interesting part: a 125B/6B-active LM, plus a <strong>51B-parameter n-gram embedding table</strong> (20M bigram/trigram entries consulted at layer 2), plus a 4B MTP layer. Layer layout is 12 repeats of (3× Gated DeltaNet linear-attention blocks → 1× QSA block): “Qwen Sparse Attention” operates at the <strong>micro-block level, not individual tokens</strong>, with a selection budget the card states verbatim as <strong>“512 blocks or 2048 tokens”</strong> — the same budget in two units. Block size is not stated on the card; the arithmetic implies 4-token micro-blocks (2048 ÷ 512), which is my inference, not their text. An MQA indexer (4 query heads, 1 shared key head) drives selection. 512 experts, 10 routed + 1 shared. Training used <strong>Muon + AdamW split by weight category with no batch-size warmup</strong>, justified by refitted scaling laws — a notable optimizer confession. Context is 262K native, 1M via YaRN.</p>
<p><strong>Vendor benchmarks (self-reported):</strong> DeepSWE 1.1 at 58.7 with 6B active parameters — versus 54.4 for DeepSeek-V4-Flash-0731 — and SWE-bench Pro 62.5, ahead of Qwen3.8-27B (61.7), Qwen3.7-Plus (55.8), DeepSeek-V4-Flash (56.0), and Claude-Opus-4.6 Max (53.4) on their harness (<a href="https://huggingface.co/Qwen/Qwen3.8-Flash-Next">model card</a>). GPQA-D 91.7, AndroidWorld 84.5.</p>
<p><strong>Why it matters.</strong> A 6B-active model matching 50B-plus-class agentic performance would rewrite cost assumptions — if it holds off the vendor’s harness. Caveats worth flagging: the license is <strong>qwen-community-1.0, not Apache</strong> (read it before commercial deployment); the card admits static YaRN may hurt short-text quality, and low reasoning-effort settings can <em>increase</em> total agent tokens. One more sharp edge, flagged by a reader and <strong>unverified by me</strong> (the hosted model’s card isn’t publicly accessible): the hosted <code>Qwen3.8-Flash</code> and the downloadable <code>Flash-Next</code> weights are reportedly distinct artifacts diverging on license, default context, and built-in tools. Until Qwen documents the mapping, treat the open preview as an architecture demo, not a mirror of the hosted model. <strong>Worth Verifying.</strong> Community reception is running hot in the <a href="https://www.reddit.com/r/LocalLLaMA/comments/1vyq2v4/megathread_qwen38flashnext_release_day/">r/LocalLLaMA megathread</a>, with 135 community quantizations already published.</p>
<p><strong>Go deeper:</strong> <a href="https://huggingface.co/Qwen/Qwen3.8-Flash-Next">HF model card</a> · <a href="https://qwen.ai/blog?id=qwen3.8-flash-next">Qwen blog</a> · <a href="https://github.com/QwenLM/Qwen3.8">QwenLM/Qwen3.8 repo</a></p>
</section>
<section id="aikidos-independent-cve-benchmark-the-best-third-party-read-all-month-on-the-new-chinese-models-worth-reading" class="level3">
<h3 class="anchored" data-anchor-id="aikidos-independent-cve-benchmark-the-best-third-party-read-all-month-on-the-new-chinese-models-worth-reading">Aikido’s independent CVE benchmark — the best third-party read all month on the new Chinese models — <strong>Worth Reading</strong></h3>
<p><strong>What happened.</strong> Security firm Aikido ran 10 models against 32 recently-disclosed CVEs, 3 runs each (~11.7B tokens), 30-turn agents, no internet, frozen harness (<a href="https://www.aikido.dev/blog/ai-model-benchmarks-aug-21-2026">Aikido, Aug 21</a>). This is the only genuinely independent evaluation I found covering this month’s releases.</p>
<p><strong>Technical signal.</strong> Pooled recall: <strong>DeepSeek V4 Pro (0813) found 28/32 — best of all ten models — for ~$295 across three runs</strong>, versus $450–590 for a <em>single</em> pass of Opus 5 or Grok 4.6 (26/32 each) or Sol (25/32). DeepSeek V4 Flash hit 24/32 for $108 total — matching Grok 4.6’s best individual pass at under a quarter of the cost. Kimi K3: 25/32 with the best open-weight precision (92.3%). Qwen3.8-Max: 26/32, but “CVE déjà vu” — in 95 of 96 traces it burned turns re-finding already-patched CVEs from training data. GLM-5.3 final: 25/32 with the highest pass-at-1 consistency among open models (18/32 across runs).</p>
<p>The counter-evidence deserves equal billing, because it’s where the closed frontier still wins: <strong>Grok 4.6 found 21/32 in all three runs — the most consistent model tested</strong> — and Opus 5’s strongest single pass (25/32) beat every open model’s <em>first</em> run. Cheap open-weight coverage wins on recall-per-dollar; run-to-run stability is still a frontier moat.</p>
<p><strong>Why it matters.</strong> The caveats are the finding: DeepSeek models produce far more candidate findings (cheap recall, expensive triage), only 10 of V4 Pro’s 28 CVEs were found in every run (high variance), and Aikido’s own verdict on “can I swap my frontier model for an open Chinese one” is “Yesn’t” — the harness matters more than the model. This is the correct mental model for the whole open-weight surge: pooled cheap runs beat single expensive passes on coverage, and push cost downstream into filtering.</p>
<p><strong>Go deeper:</strong> <a href="https://www.aikido.dev/blog/ai-model-benchmarks-aug-21-2026">Aikido benchmark writeup</a>. Pricing context for the cost math — DeepSeek’s V4 lineup moved to peak/off-peak rates on August 16: V4-Pro lists at <strong>$1.32/M input (cache miss) and $3.96/M output at peak</strong>, half that off-peak, with cache hits at $0.044/M peak; “peak” means 01:00–04:00 and 06:00–10:00 UTC, weekdays (<a href="https://api-docs.deepseek.com/quick_start/pricing">rate card</a>, <a href="https://api-docs.deepseek.com/news/news260813/">GA notice</a>; <a href="https://www.reuters.com/world/china/deepseek-releases-official-v4-pro-model-it-steps-up-expansion-2026-08-13/">Reuters on the GA</a>).</p>
</section>
<section id="huaweis-ascend-950dt-pulls-its-cloud-debut-into-august-worth-watching" class="level3">
<h3 class="anchored" data-anchor-id="huaweis-ascend-950dt-pulls-its-cloud-debut-into-august-worth-watching">Huawei’s Ascend 950DT pulls its cloud debut into August — <strong>Worth Watching</strong></h3>
<p><strong>What happened.</strong> Huawei confirmed the Ascend 950DT will debut on Huawei Cloud in August, ahead of its original Q4 2026 roadmap slot (<a href="https://www.huaweicentral.com/huawei-confirms-ascend-950dt-ai-chip-to-debut-in-august/">HuaweiCentral</a>; VP Chen Lin via <a href="https://winbuzzer.com/2026/06/10/huawei-cloud-ties-agentic-infra-to-ascend-950dt-window-xcxwbn/">WinBuzzer</a>; pull-forward first reported by <a href="https://www.trendforce.com/news/2026/06/08/news-huawei-brings-forward-ascend-950dt-deployment-to-august-deepseek-v4-2-seen-as-potential-early-adopter/">TrendForce</a>).</p>
<p><strong>Technical signal (all vendor/analyst claims, none independently verified):</strong> H200-class performance with in-house-developed HBM (<a href="https://www.scmp.com/news/china/article/3356967/huawei-considering-deploying-ascend-ai-chips-latin-america-cloud-chief-says">SCMP</a>); the Atlas 950 SuperPoD architecture connects up to 8,192 950DT NPUs (<a href="https://www.huawei.com/en/news/2025/9/hc-xu-keynote-speech">Huawei Connect 2025 keynote</a>). TrendForce’s note that DeepSeek V4.2 might be an early adopter is a rumor, full stop.</p>
<p><strong>Why it matters.</strong> Sparse-attention, MTP-heavy architectures like this week’s three releases are memory-bandwidth machines — which is exactly the axis (self-developed HBM) Huawei claims as its differentiator. And the first partial evidence arrived the same week, from a competitor’s launch: Zhipu’s claim that GLM-5.3-Flash’s record OpenRouter week ran on ~100,000 domestic accelerators with no NVIDIA hardware (see the GLM item — vendor-claimed, unaudited). One vendor’s launch claim does not settle whether Chinese silicon can serve these architectures at production quality, but it moves the question from “can they?” to “who will verify it first?”</p>
<p><strong>Go deeper:</strong> <a href="https://www.huawei.com/en/news/2025/9/hc-xu-keynote-speech">Ascend roadmap keynote</a> · <a href="https://www.trendforce.com/news/2026/06/08/news-huawei-brings-forward-ascend-950dt-deployment-to-august-deepseek-v4-2-seen-as-potential-early-adopter/">TrendForce analysis</a></p>
<hr>
</section>
</section>
<section id="research-radar" class="level2">
<h2 class="anchored" data-anchor-id="research-radar">Research Radar</h2>
<section id="longcat-sparse-attention-taming-the-lightning-via-streaming-aware-hierarchical-cross-layer-indexing" class="level3">
<h3 class="anchored" data-anchor-id="longcat-sparse-attention-taming-the-lightning-via-streaming-aware-hierarchical-cross-layer-indexing">LongCat Sparse Attention: Taming the Lightning via Streaming-aware Hierarchical Cross-Layer Indexing</h3>
<p><strong><a href="https://arxiv.org/abs/2608.01662">arXiv:2608.01662</a></strong> — Meituan LongCat Team (14 authors; v2 Aug 4, 2026). Weights: <a href="https://huggingface.co/meituan-longcat/LongCat-Flash-Lite-Sparse">LongCat-Flash-Lite-Sparse 69B-A3B</a>.</p>
<ul>
<li><strong>Problem.</strong> DeepSeek Sparse Attention made long context affordable but introduced a new bottleneck: the Lightning Indexer costs O(L²) and its selections scatter memory access — the paper measures DSA’s scattered gathers at only <strong>~4.5% of peak HBM bandwidth</strong>, with the indexer consuming 90% of per-layer decode time at 1M context.</li>
<li><strong>Core idea.</strong> Three orthogonal fixes: <em>streaming-aware indexing</em> (re-lay KV entries into contiguous, coalesced blocks), <em>cross-layer indexing</em> (compute an index once, reuse across N consecutive layers, made safe by cross-layer distillation), and <em>hierarchical indexing</em> (coarse-to-fine candidate narrowing). This is implementation refinement, not a new attention theory — and the paper is honest that its novelty is hardware-algorithm co-design.</li>
<li><strong>Evidence (vendor-run, but unusually well-ablated).</strong> Training speed 1.53–1.61× over DSA per attention layer; end-to-end inference 1.42–3.60× prefill / 1.25–1.40× decode. Quality parity: RULER-style recall 98.63 (LSA) vs 98.83 (full attention) at 69B, validated again at 560B-A27B. LongCat-2.0 (1.6T-A48B) was trained on it. The ablations are the best part: hierarchical indexing is <em>slower</em> below 256K (0.79–0.82×); cross-layer reuse without distillation collapses 128K needle-in-a-haystack from 96% to 70%; MTP acceptance is unaffected (3.11 vs 3.15).</li>
<li><strong>Limitations.</strong> LSA cuts compute, <strong>not KV footprint</strong> — every token still stores a KV entry, so aggregate memory pressure is unchanged (authors point to CLA / DeepSeek-V4’s CSA as complements). Hierarchical indexing slightly hurts some agentic/code tasks (SWE-Bench Verified 68.20 → 65.20).</li>
<li><strong>Why I bookmarked it.</strong> It’s the first paper I’ve read that treats the <em>indexer</em> as the primary scaling enemy — the exact component Tencent’s IndexCache, Qwen’s QSA, and (per launch materials) GLM’s IndexPool are also optimizing. Read alongside those model cards, it explains where the next efficiency war is being fought.</li>
<li><strong>Read this if…</strong> you serve or train long-context models, or you want to understand why every architecture in this issue looks the way it does.</li>
</ul>
</section>
<section id="flashprefill-v2-block-sparse-prefill-attention-for-long-context-llm-serving" class="level3">
<h3 class="anchored" data-anchor-id="flashprefill-v2-block-sparse-prefill-attention-for-long-context-llm-serving">FlashPrefill V2: Block-Sparse Prefill Attention for Long-Context LLM Serving</h3>
<p><strong><a href="https://arxiv.org/abs/2608.19758">arXiv:2608.19758</a></strong> — Qihang Fan, Huaibo Huang, Zhiying Wu, Bingning Wang, Ran He (Tencent Hunyuan × CAS lineage, per <a href="https://arxiv.org/abs/2603.06199">V1’s author list</a>); Aug 20, 2026. V1 code: <a href="https://github.com/qhfan/FlashPrefill">github.com/qhfan/FlashPrefill</a>.</p>
<ul>
<li><strong>Problem.</strong> Prefill, not decode, is the wall for long-context serving — quadratic attention at a compute-bound stage.</li>
<li><strong>Core idea.</strong> A production-grade block-sparse prefill kernel: a <strong>mean-correction term</strong> that substitutes pooled statistics of pruned blocks into the softmax (recovering quality at aggressive sparsity), plus a Hopper-aligned kernel (PackGQA tiling, warp specialization, pingpong pipelines, FP8 with per-tensor scales) integrated into SGLang as a real attention backend with paged KV and continuous batching.</li>
<li><strong>Evidence (vendor-run).</strong> On <strong>H20 GPUs</strong> — the China-market NVIDIA part, bandwidth-rich and compute-poor, which makes this hardware choice itself a signal: up to <strong>47.26× (FP8) / 27.19× (BF16) over FlashAttention-2 at 128K</strong>, 30.49× over an FA3/4-aligned dense baseline, 2.1–4.8× end-to-end TTFT in SGLang. The mean correction keeps FP8 within ~1 point of full attention where naive sparsity loses 6.2 points.</li>
<li><strong>Limitations.</strong> Decode falls back to dense (single query token can’t exploit block sparsity); chunked prefill erodes gains (P50 speedup drops 1.9× → 1.6× at 8K chunks); at 4K contexts it’s merely at parity. V2 code does not appear to be released yet — only V1’s repo exists.</li>
<li><strong>Why I bookmarked it.</strong> The mean-correction trick is a genuinely reusable idea for anyone building approximate attention, and the H20 targeting tells you which hardware fleet this is actually for.</li>
<li><strong>Read this if…</strong> you build inference infrastructure or want one paper that connects sparsity research to real serving-stack engineering.</li>
</ul>
</section>
<section id="kimi-k3-open-frontier-intelligence-the-report-everyones-still-benchmarking-against" class="level3">
<h3 class="anchored" data-anchor-id="kimi-k3-open-frontier-intelligence-the-report-everyones-still-benchmarking-against">Kimi K3: Open Frontier Intelligence (the report everyone’s still benchmarking against)</h3>
<p><strong><a href="https://arxiv.org/abs/2607.24653">arXiv:2607.24653</a></strong> — Kimi Team; weights July 27, v2 Aug 7, 2026.</p>
<ul>
<li><strong>Problem.</strong> Frontier capability at open weights, at 2.8T scale.</li>
<li><strong>Core idea.</strong> Kimi Delta Attention (a gated-delta linear-attention variant) + Attention Residuals; “Stable LatentMoE” routing 16 of 896 experts; ~2.5× scaling efficiency over K2 (vendor claim); post-training centered on million-token agentic RL with persistent rollout/sandbox state.</li>
<li><strong>Evidence.</strong> Vendor evaluation suite shows frontier-level long-horizon coding/agentic results; the paper itself concedes it “still trails” the top proprietary models. The best independent corroboration this month is Aikido’s 25/32 recall at 92.3% precision — the highest-precision open model in their pool.</li>
<li><strong>Limitations.</strong> Self-reported margins. On licensing — corrected from v1.0, see Corrections — the weights carry a bespoke <strong>Kimi K3 License</strong> (tagged <code>license: other</code> on HF), <em>not</em> a Creative Commons term: it permits use, modification, distribution, sublicensing, and sale, with a separate Moonshot agreement required only for MaaS operators above <strong>$20M revenue over any consecutive 12 months</strong>, and on-screen “Kimi K3” credit required for commercial products above <strong>100M monthly active users or $20M monthly revenue</strong>; internal use and Moonshot’s own channels are exempt (<a href="https://huggingface.co/moonshotai/Kimi-K3/blob/main/LICENSE">LICENSE file</a>). That is a permissive-with-thresholds template that closely mirrors Qwen’s community-license structure — so the real licensing story across these releases is <strong>convergence on a common bespoke pattern</strong>, not divergence. The decision axis for readers is reading each model’s thresholds, not avoiding commercial use.</li>
<li><strong>Read this if…</strong> you need the reference architecture for the model that Hy4, Qwen, and half of August’s leaderboards are being compared against — and read the LICENSE before productizing, not this newsletter’s memory of it.</li>
</ul>
<hr>
</section>
</section>
<section id="repo-radar" class="level2">
<h2 class="anchored" data-anchor-id="repo-radar">Repo Radar</h2>
<section id="tencent-hunyuanhy4-preview" class="level3">
<h3 class="anchored" data-anchor-id="tencent-hunyuanhy4-preview"><a href="https://github.com/Tencent-Hunyuan/Hy4-preview">Tencent-Hunyuan/Hy4-preview</a></h3>
<ul>
<li><strong>What’s actually in it:</strong> almost nothing — and that’s worth knowing precisely. Five commits, two directories (<code>assets/</code>, <code>finetune/</code>), plus README and LICENSE. Benchmarks ship as JPGs. No eval harness, no training code, no requirements file.</li>
<li><strong>What you can run:</strong> the documented vLLM/SGLang Docker paths (FP8, TP≥8, MTP speculative decoding) and a finetuning pipeline referenced via <code>finetune/README.md</code> (I did not execute it; treat as documented-not-verified).</li>
<li><strong>What’s missing:</strong> any way to reproduce the 2.99 blind-eval score, a hardware requirements section, and anything beyond inference manifests. The gap between “frontier open weights” and “repo contents” is entirely bridged by upstream vLLM/SGLang support.</li>
<li><strong>Why open it:</strong> as the canonical deployment reference — the exact vLLM flags (<code>--attention-backend FLASHMLA_SPARSE</code>, <code>--tool-call-parser hy_v4</code>, MTP config) are the valuable contents.</li>
</ul>
</section>
<section id="qwenlmqwen3.8" class="level3">
<h3 class="anchored" data-anchor-id="qwenlmqwen3.8"><a href="https://github.com/QwenLM/Qwen3.8">QwenLM/Qwen3.8</a></h3>
<ul>
<li><strong>What’s actually in it:</strong> a docs-only landing repo — README and LICENSE, 11 commits, zero source files. Training is explicitly delegated to Unsloth/Swift/Llama-Factory; inference to transformers/vLLM/SGLang CLIs.</li>
<li><strong>What you can run:</strong> nothing from here directly; use it as the release ledger. Its News section is the authoritative weight-release timeline (Qwen3.8-2.4T-A95B on Aug 12, 27B on Aug 14) and corrects fuzzier secondary reporting on launch dates.</li>
<li><strong>What’s missing:</strong> code, releases/tags, and a license clarification — the repo is Apache-2.0, but the README defers weight licensing to the model card, where Flash-Next carries <code>qwen-community-1.0</code>. That split deserves attention before commercial use.</li>
<li><strong>Why open it:</strong> the fastest primary-source answer to “which Qwen weights exist, and since when.”</li>
</ul>
</section>
<section id="tencentangelslim" class="level3">
<h3 class="anchored" data-anchor-id="tencentangelslim"><a href="https://github.com/Tencent/AngelSlim">Tencent/AngelSlim</a></h3>
<ul>
<li><strong>What’s actually in it:</strong> a real, maintained compression toolkit (<a href="https://angelslim.readthedocs.io/">docs</a>) covering quantization, quantization-aware distillation (a Megatron-Core “MCoreQAD” backend for distributed QAD), speculative decoding, sparse attention, token compression, and even diffusion-model compression, with guides for Hunyuan, DeepSeek, and Qwen families. (Inspection depth: README and docs landing pages, not a full code audit.)</li>
<li><strong>What you can run:</strong> per-model quantization recipes — e.g., the documented Qwen3-Omni FP8 static/dynamic workflows — and it’s the officially referenced compression path for squeezing Hy4’s ~1.56 TB checkpoint onto fewer GPUs.</li>
<li><strong>What’s missing/incomplete:</strong> the Hy4-specific recipes postdate my inspection; Tencent Cloud’s headline claim (1.8B → 2-bit at ~4% accuracy loss) is vendor-reported without an independent reproduction I could find.</li>
<li><strong>Why open it:</strong> with three 300B–770B open models released this week, compression tooling is suddenly the practical bottleneck for actually deploying any of them, and this is the most complete first-party toolkit in the ecosystem.</li>
</ul>
<hr>
</section>
</section>
<section id="my-read-on-the-week" class="level2">
<h2 class="anchored" data-anchor-id="my-read-on-the-week">My Read on the Week</h2>
<p><em>(Synthesis and interpretation — not reported fact.)</em></p>
<p><strong>1. The indexer is the new bottleneck, and everyone now knows it.</strong> Five independently-developed systems — DeepSeek’s DSA, Qwen’s QSA, Tencent’s Gated DSA with IndexCache, Meituan’s LSA, and (per launch materials, not the model card) Z.ai’s IndexPool — converged on the same thesis: sparse attention won, so now optimize the thing that selects the sparsity. Meituan’s profiling (indexer eating 90% of decode time at 1M context, gathers at 4.5% of peak bandwidth) explains <em>why</em> Tencent ships cross-layer index reuse, Qwen moved selection up to micro-blocks, and Z.ai is compressing indexer keys. When this many teams attack the same sub-component in one month, that sub-component is where next year’s throughput gains live.</p>
<p><strong>2. Open-weight releases have become infrastructure events, and the “repo” is now a manifest.</strong> None of this week’s three flagship repos contains meaningful code — the engineering artifact is the <em>serving-stack support</em>: same-day vLLM/SGLang images, custom parsers, FP8 checkpoints, MTP recipes, compression tooling. The practical evaluation question for an open model has shifted from “is it open?” to “how fast did the serving frameworks land, and does the cache-hit price line work for my agent loop?” The pricing surface is converging on agentic economics: Hy4’s $0.042/M cache-hit rate, DeepSeek’s peak/off-peak card ($0.022/M off-peak cache hits on V4-Pro), and Qwen’s 6B-active bet all compete on cost per completed agent task, not cost per token. The OpenRouter numbers make the same point from the demand side — ~23T tokens in six days went to whichever model made agent loops cheapest. And the sharpest unresolved wrinkle for that argument is the Qwen split flagged above: if the hosted <code>Qwen3.8-Flash</code> and the open <code>Flash-Next</code> weights really are different artifacts, then “open preview” and “what you’re paying for” need to be compared separately, per vendor, every time.</p>
<p><strong>3. Verification is lagging capability — and this week, usage ran ahead of both.</strong> Every headline number this week is vendor-run: Tencent’s blind eval, Qwen’s benchmark table, Z.ai’s positioning claims, Zhipu’s 100K-domestic-chip serving claim. The only independent instrument I found (Aikido’s) says the open models are <em>better than expected on coverage, worse on precision, and inconsistent run-to-run</em> — not a reason to skip them, but a reason to budget for triage. The Ox Alpha launch is the phenomenon in its purest form: the market routed 23 trillion tokens to a model nobody had benchmarked, under a name nobody owned, and the identity reveal came after the usage record. Community threads also repeated vendor numbers as if they were independent confirmations; they aren’t. The reproduction layer for 300B–770B-class models is GPU-expensive, and it shows.</p>
<hr>
</section>
<section id="what-id-watch-next" class="level2">
<h2 class="anchored" data-anchor-id="what-id-watch-next">What I’d Watch Next</h2>
<ol type="1">
<li><strong>GLM-5.5.</strong> Media (CGTN, AIBase) have reported an August window for a 1T-plus “architecture leap,” but Z.ai has confirmed nothing (<a href="https://felloai.com/glm-5-5/">rumor roundup</a>). Given Z.ai shipped GLM-5.3-Flash this week under MIT, the license and sparse-attention details of a true GLM-5.5 would be a direct comparable to Hy4.</li>
<li><strong>Independent numbers on domestic silicon.</strong> The Ascend 950DT’s August Huawei Cloud debut was vendor-confirmed, and Zhipu’s ~100K-chip serving claim is the first (unaudited) production-scale data point. First third-party throughput measurement on sparse-attention + MTP workloads is the moment the bandwidth story gets tested — watch for OpenRouter-adjacent latency data and any Zhipu disclosure with verifiable detail.</li>
<li><strong>Hy4’s official release.</strong> Tencent says the next batch is coming soon; the specific thing to watch is whether the reasoning-overshoot/over-verification behavior survives post-training, and whether any reproducible eval harness ships with it.</li>
</ol>
<hr>
</section>
<section id="one-thing-id-experiment-with-this-week" class="level2">
<h2 class="anchored" data-anchor-id="one-thing-id-experiment-with-this-week">One Thing I’d Experiment With This Week</h2>
<p><strong>Replicate the “cheap coverage vs.&nbsp;expensive precision” tradeoff on your own bug-finding workload.</strong> Aikido’s data (<a href="https://www.aikido.dev/blog/ai-model-benchmarks-aug-21-2026">methodology</a>) supports a precise claim: <strong>three DeepSeek V4 Pro runs (~$295 total) reached 28/32 pooled recall, beating single $450–590 passes of Opus 5 and Grok 4.6 (26/32)</strong> — while <strong>three V4 Flash runs ($108) hit 24/32, matching Grok 4.6’s best individual pass at under a quarter of the cost</strong>. Note the asymmetry: the pooled-cheap-beats-single-expensive result belongs to Pro; Flash’s result is “equivalent coverage to a frontier pass, much cheaper,” not a win. Test whether the Pro result holds on code you own:</p>
<ul>
<li><strong>Setup:</strong> 20–30 bugs with known ground truth — recent CVEs in your dependency tree, or seeded defects in a frozen repo snapshot. Same harness, same turn budget (Aikido used 30), no internet, three runs per model.</li>
<li><strong>Conditions:</strong> one frontier closed model, single pass (the consistency baseline); three passes of DeepSeek V4 Pro (the coverage arm); three passes of V4 Flash (the budget arm); optionally one pass of Hy4 at low reasoning effort to probe the overshoot tax.</li>
<li><strong>Measure:</strong> pooled recall per dollar, precision (accepted findings / candidates raised — this is where Aikido says open models bleed), cross-run consistency (Jaccard overlap of found-bug sets — V4 Pro’s was only 10/32 stable, versus Grok’s 21/32), and median turns consumed. The decision output is a number: your triage cost per additional true positive over the frontier single-pass baseline. If Pro’s pooled recall clears the baseline at lower cost <em>after</em> triage labor, the open-model pool wins; if the false-positive load eats the savings, you’ve quantified exactly why not.</li>
</ul>
<hr>
</section>
<section id="corrections" class="level2">
<h2 class="anchored" data-anchor-id="corrections">Corrections</h2>
<p><strong>Issue 1.0 → 1.1, 2026-08-30.</strong> Reader feedback surfaced three material errors and several smaller ones; all load-bearing claims below were re-verified against primary sources before correcting.</p>
<ol type="1">
<li><strong>Kimi K3 license (Research Radar) — wrong, and the analysis built on it was inverted.</strong> v1.0 stated the weights ship under CC BY-NC-ND and argued this showed “license divergence” across Chinese labs. The <a href="https://huggingface.co/moonshotai/Kimi-K3/blob/main/LICENSE">LICENSE file in the weight repo</a> defines a bespoke <strong>Kimi K3 License</strong>: commercial use, modification, and sale are permitted, with thresholds (&gt;$20M/12-month MaaS revenue → separate agreement; &gt;100M MAU or &gt;$20M monthly revenue → on-screen credit). Corrected, and the takeaway rewritten as convergence on a permissive-with-thresholds template. Root cause: a carryover assumption from earlier Kimi releases, not re-checked against the license artifact.</li>
<li><strong>Closing experiment (One Thing I’d Experiment With) — model swapped in re-narration.</strong> v1.0 attributed the pooled-recall win (24/32 at $108) to V4 Flash and said it “beat” single frontier passes (25–26/32). 24 does not beat 25; Aikido’s actual finding is that Flash <em>matched</em> Grok 4.6’s best single pass at a quarter of the cost, while the beat-single-expensive result belongs to V4 Pro (28/32 at ~$295). Corrected throughout, experiment conditions updated. Root cause: numbers traveled two thousand words from their first correct use.</li>
<li><strong>Aikido results (Elsewhere) — Sol’s score miscounted, counter-evidence under-reported.</strong> v1.0 wrote “Opus 5 / Grok 4.6 / Sol, which found 26/32”; Sol found 25/32. Added the omitted counter-evidence: Grok 4.6’s 21/32 all-three-runs consistency (most consistent model tested) and Opus 5’s strongest single pass (25/32). (<a href="https://www.aikido.dev/blog/ai-model-benchmarks-aug-21-2026">Aikido</a>)</li>
<li><strong>QSA block size (Elsewhere) — unverified detail introduced.</strong> v1.0 described “512-token blocks,” which contradicts the card’s stated budget of “512 blocks or 2048 tokens.” The card never states a block size; the two budget figures imply 4-token micro-blocks (inference, now labeled as such). (<a href="https://huggingface.co/Qwen/Qwen3.8-Flash-Next">HF model card</a>)</li>
<li><strong>Internal consistency.</strong> Standardized checkpoint size to ~1.56 TB (was “1.5 TB”/“1.56 TB” in different sections); reconciled “every serious open-weight evaluation this month” with “the only independent instrument I found” (single formulation now); applied the weights-vs-announcement date distinction to GLM-5.3-Flash (weights Aug 25, reveal Aug 26), as v1.0 had done for Qwen but not GLM; defined DeepSeek’s peak/off-peak pricing at first use instead of referencing it undefined.</li>
<li><strong>Material omissions, added.</strong> The Ox Alpha stealth launch, OpenRouter usage record (~23T tokens), and Zhipu’s domestic-silicon serving claim — which connect the GLM item to the Ascend item and to this issue’s verification thesis. GLM’s “IndexPool” is included but explicitly flagged as launch-material-only (absent from the model card; no citable primary). The Qwen hosted-vs-weights divergence is included but explicitly flagged unverified.</li>
</ol>
<p><em>Found an error? Reply and it goes here, dated, with the correction. The working claims ledger behind this issue is maintained alongside it in the repository at <code>research/2026-08-30/claim-ledger.md</code>.</em></p>
<hr>
<p><em>All vendor-reported figures are labeled as such; if independent evidence doesn’t exist yet, that’s stated rather than papered over.</em></p>



</section>

<div id="quarto-appendix" class="default"><section class="quarto-appendix-contents" id="quarto-bibliography"><h2 class="anchored quarto-appendix-heading">References</h2><div id="refs" class="references csl-bib-body hanging-indent">
<div id="ref-flashprefill2026" class="csl-entry">
Fan, Qihang, Huaibo Huang, Zhiying Wu, Bingning Wang, and Ran He. 2026. <span>“FlashPrefill V2: Block-Sparse Prefill Attention for Long-Context LLM Serving.”</span> <em>arXiv</em>. <a href="https://arxiv.org/abs/2608.19758">https://arxiv.org/abs/2608.19758</a>.
</div>
<div id="ref-kimik32026" class="csl-entry">
Kimi Team, Moonshot AI. 2026. <span>“Kimi K3: Open Frontier Intelligence.”</span> <em>arXiv</em>. <a href="https://arxiv.org/abs/2607.24653">https://arxiv.org/abs/2607.24653</a>.
</div>
<div id="ref-longcat2026" class="csl-entry">
LongCat Team, Meituan. 2026. <span>“LongCat Sparse Attention: Taming the Lightning via Streaming-Aware Hierarchical Cross-Layer Indexing.”</span> <em>arXiv</em>. <a href="https://arxiv.org/abs/2608.01662">https://arxiv.org/abs/2608.01662</a>.
</div>
</div></section><section class="quarto-appendix-contents" id="quarto-citation"><h2 class="anchored quarto-appendix-heading">Citation</h2><div><div class="quarto-appendix-secondary-label">BibTeX citation:</div><pre class="sourceCode code-with-copy quarto-appendix-bibtex"><code class="sourceCode bibtex">@online{dimsum_editorial2026,
  author = {dimsum editorial, the},
  title = {Frontier Model Architecture Is Becoming a Memory-Systems
    Problem},
  date = {2026-08-30},
  url = {https://chiragsehra.gitlab.io/thedimsumnews/issues/2026-08-30/},
  langid = {en}
}
</code></pre><div class="quarto-appendix-secondary-label">For attribution, please cite this work as:</div><div id="ref-dimsum_editorial2026" class="csl-entry quarto-appendix-citeas">
<span class="nocase">dimsum editorial, the</span>. 2026. <span>“Frontier
Model Architecture Is Becoming a Memory-Systems Problem.”</span> August
30. <a href="https://chiragsehra.gitlab.io/thedimsumnews/issues/2026-08-30/">https://chiragsehra.gitlab.io/thedimsumnews/issues/2026-08-30/</a>.
</div></div></section></div> ]]></description>
  <category>AI Engineering</category>
  <category>Architecture</category>
  <category>Inference</category>
  <category>Agents</category>
  <guid>https://chiragsehra.gitlab.io/thedimsumnews/issues/2026-08-30/</guid>
  <pubDate>Sun, 30 Aug 2026 00:00:00 GMT</pubDate>
</item>
</channel>
</rss>
