Pith. sign in

REVIEW 3 major objections 4 minor 26 references

FlatAttention: Dataflow and Fabric Collectives Co-Optimization for Efficient Multi-Head Attention on Tile-Based Many-PE Accelerators

T0 review · 3 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read FlatAttention, a dataflow that groups tiles and uses on-chip multicast/reduction, lifts multi-head attention to 89.3% matrix-engine utilization, cuts HBM traffic 16x, and beats FlashAttention-3-style mapping by 4.1x on tile-based many-PE…

desk verdict A credible simulation-based MHA dataflow/NoC co-design; the HBM-traffic reduction is real, but the 4.1x speedup depends on an unvalidated multicast model and needs sensitivity analysis. read the letter →

arxiv 2505.18824 v1 pith:7TTAGZHY submitted 2025-05-24 cs.AR

Chi Zhang , Luca Colagrande , Renzo Andri , Thomas Benz , Gamze Islamoglu , Alessandro Nadalini , Francesco Conti , Yawei Li
show 1 more author
Luca Benini
This is my paper
classification cs.AR
keywords multi-headattentiontile-basedacceleratorsnetwork-on-chipcollectivesdataflowmappingHBMtrafficreductionmatrixengineutilizationalgorithm-architectureco-design
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Multi-head attention on tile-based accelerators is usually memory-bound: each tile fetches its own copies of K and V, and off-chip bandwidth saturates long before the matrix units do. FlatAttention proposes instead that a rectangular group of tiles cooperatively processes one attention block, with only edge tiles reading from HBM and the on-chip network forwarding, multicasting, and reducing the data. This grouping lowers the attention I/O complexity from scaling with sequence length divided by the block size to scaling with sequence length divided by the block size times the square root of the group size, and hardware multicast and reduction primitives make the extra on-chip traffic cheap. The paper reports up to 89.3% matrix-engine utilization, a 4.1x speedup over a FlashAttention-3-style dataflow, and a 16x reduction in HBM traffic. If these numbers hold, the key insight is that attention scaling on tile-based chips should be solved by trading off-chip bandwidth for on-chip collective communication, not by bigger caches or faster HBM.

What carries the argument

The load-bearing mechanism is the group-level flattening of attention: dividing a large attention block into slices that live in the aggregate L1 of a Gx by Gy tile group, combined with hardware collective communication primitives in the NoC (path-based multicast that duplicates and forwards packets in flight, plus row/column sum- and max-reduction). The paper's I/O identity is $IO = 2 H B D S (1 + S/(\sqrt{N} M))$ for N tiles grouped, versus $2 H B D S (1 + S/M)$ for the per-tile FlashAttention mapping, so grouping 64 tiles cuts the second-order term 8x; the same identity shows that over-flattening hurts when slices get so small that matrix units run at low utilization and fixed synchronization latencies dominate. The asynchronous schedule, which runs two heads per group so that DMA and vector work for one head hide behind the matrix engine's multiplications for the other, is what converts the I/O reduction into near-peak utilization.

What would settle it

On a real tile-based NoC or a cycle-accurate RTL simulation of one, time a 16 KB row-wise multicast and a sum-reduction across 32 tiles at 1 GHz; then run the D=128, S=4096 MHA layer with both FlatAttention and FlashAttention-3 schedules. If the multicast cost scales with the number of tiles (31 unicast hops) instead of the modeled forwarding path, the reported 4.1x speedup and 89.3% utilization should drop measurably.

Watch

Extended reading notes

Core claim

FlatAttention posits that the FlashAttention dataflow, which assigns each tile its own independent attention block and moves every K and V block over HBM for every query block, is the wrong parallelization for tile-based many-PE accelerators. Instead, it extends the same tiling idea one level up: a group of Gx by Gy tiles is treated as a single logical processor with aggregate L1 capacity, so attention blocks can be Bc by Br with Br/Gy and Bc/Gx slices per tile. Only west-edge tiles load Q and only south-edge tiles load K^T and V; the NoC then row-multicasts Q, column-multicasts K^T and V, row-reduces and multicasts softmax maxima and denominators, and row-reduces the output O before storing it once. The claim is that with hardware-supported path-based multicast and in-network sum/max reduction, the reduced HBM pressure more than compensates for the on-chip traffic, and that overlapping two heads' data movement and softmax with the matrix engine keeps the tensor units almost continuously busy. The measured consequence on the paper's simulator is 89.3% utilization, a 4.1x speedup over a FlashAttention-3 mapping on the same tile array, and a 16x drop in HBM traffic, with a 32x32 tile configuration at 1024 TFLOPS outperforming an H100-based FlashAttention-3 by up to 1.3x in utilization while needing 40% less HBM bandwidth and a 1.8x smaller die.

Load-bearing premise

The load-bearing premise is that the simulator's network model—packet-duplicate-and-forward multicast, the assumed router latencies, and calibrated RTL models for matrix and NoC—matches real hardware closely enough that the measured HBM savings are not offset by slower or costlier on-chip collectives.

Editorial extensions

If this is right

  • FlashAttention-style per-tile replication of K and V is not the right dataflow for tile-based many-PE accelerators; on-chip collectives can substitute for off-chip reuse, and the paper's I/O formula predicts larger gains as sequence length grows.
  • The optimal group size is a function of sequence length: large groups help long sequences but cause over-flattening on short ones, so a runtime or compiler should select Gx by Gy per layer.
  • An accelerator designed around FlatAttention can match an H100's peak TFLOPS with a smaller, lower-bandwidth HBM configuration, reducing cost and power by roughly the die-size and bandwidth savings the paper estimates.
  • Hardware collective primitives in the NoC are not optional; the paper's naive software-multicast FlatAttention is slower than FlashAttention, so packet-duplication and in-network reduction are what make the dataflow win.
  • GEMM-style collectives also benefit from the same architecture, suggesting the fabric primitives generalize beyond attention to other tensor kernels.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A testable extension: run the same grouping scheme at sequence lengths beyond 4096; the I/O formula predicts the HBM savings grow with S, so the 16x figure is likely a lower bound for long-context prefill.
  • A side consequence the paper does not develop: the same row/column multicast and reduction primitives could serve tensor-parallelism collectives or all-reduce in distributed inference, which would amortize the hardware cost across more kernels.
  • The H100 comparison should be read as a co-design target rather than a chip-to-chip benchmark; a rigorous test would re-run FlashAttention-3 and FlatAttention on the same silicon or on a validated H100 model, including K-transpose overhead on both sides.
  • The over-flattening analysis implies an adaptive group-size selector: for short sequences, using a small group on a large mesh avoids the utilization collapse, so the optimal configuration is layer-dependent.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper proposes FlatAttention, a dataflow and on-chip fabric co-design for multi-head attention on tile-based many-PE accelerators. FlatAttention groups tiles into (Gx, Gy) meshes, loads Q and K^T/V slices only at group edges, and uses hardware multicast and reduction primitives in the NoC to share data and combine softmax statistics, thereby reducing HBM traffic. An asynchronous variant overlaps DMA and vector-engine work with matrix multiplications by processing two heads concurrently. The authors evaluate their approach in the SoftHier simulation framework (built on GVSoC with RTL-calibrated RedMulE, FlooNoC, and DRAMSys models), reporting up to 89.3% matrix-engine utilization, a 4.1x speedup over a FlashAttention-3-style dataflow, and a 16x reduction in HBM traffic. They also co-explore architecture parameters and identify a 32x32 tile-mesh configuration with 1024 TFLOPS peak that they compare against the H100 GPU, claiming up to 1.3x higher utilization, 40% lower HBM bandwidth demand, and a 1.8x die-size reduction at the same technology node.

Significance. If the results hold, the paper makes a useful contribution: it identifies a dataflow that can exploit on-chip collective primitives to reduce HBM-bound execution of MHA, and it provides a parameterized simulation framework for tile-based accelerator exploration. A notable strength is that both FlashAttention and FlatAttention baselines are implemented and evaluated in the same cycle-calibrated simulator, which mitigates many cross-platform comparison pitfalls. The use of open-source, RTL-calibrated components (GVSoC, RedMulE, FlooNoC, DRAMSys) is also a strength. The main significance risk is that the headline speedup and utilization numbers depend on a collective-primitive latency model that is asserted rather than validated, and on external H100 measurements that are imported without full methodological detail.

major comments (3)
  1. [Sections II and IV] The latency model for hardware-supported collectives (Section II) assumes that packet duplication and forwarding along the multicast path adds no router delay beyond one Lr per hop, and the same latency expression is used for reductions even though sum- and max-reductions require combining data. Section IV states that the NoC model 'incorporates' these primitives, but it does not report RTL calibration for them (only RedMulE and FlooNoC are said to be calibrated). Because Section V-A's 4.1x speedup and 89.3% utilization depend on replacing up to 31 sequential unicasts with a single collective pass, even a modest per-hop duplication/combine overhead or buffer/flow-control cost would directly reduce the reported gains. Please provide either an RTL-level validation of the collective primitives or a sensitivity analysis over Ld, Lr, link bandwidth, and per-hop combine latency showing that the headline results are robust.
  2. [Section V-C, Fig. 5b] The H100 comparison imports published FlashAttention-3 throughput from Shah et al. [6] and assumes the 3.4 TB/s HBM bandwidth figure, but the manuscript does not specify how the H100 utilization values are computed, whether the same layer shapes (S, H, B, D) and precisions are used on both sides, or how K-matrix pre-transposition time is accounted for on the H100 side. Since the 1.3x utilization advantage is a headline result, this comparison needs a detailed methodology statement (raw TFLOPS numbers, sources, and any normalization) and should also discuss the sensitivity to the FlashAttention-3 version, given the paper's own footnote that the NeurIPS release reports about 10% higher throughput.
  3. [Section V-C] The die-size estimate of 457 mm2 (1.8x smaller than H100) is derived from gate-equivalent counts of the compute tiles, an assumed transistor density, an assumed SRAM bit-cell size, and a flat 66% area-utilization factor. It does not include NoC routers, HBM controllers and PHYs, clocking, or other non-compute macros, and the GE count for 'BestArch' is not itemized in the text. The 1.8x claim should be presented as a compute-heavy area projection with a sensitivity range, or augmented with area estimates for the omitted components, before it can be treated as a quantitative result.
minor comments (4)
  1. [Section III-A, Algorithms 1 and 2] There are several typos: 'sequnce' in Section III-A, 'matrx' in the Require lines of both algorithms, and 'demoninator' in Section III-B bullet. Please proofread these passages.
  2. [Abstract and Fig. 5a] The abstract reports 89.3% utilization as the maximum, while Fig. 5a shows a 91.7% label for the S4096 D128 case at the 32x32 fabric granularity. Please reconcile these numbers and clearly state which configuration and workload produce the headline 89.3% value.
  3. [Section V-A, Fig. 3] The caption uses 'FA-2*', 'Flat*', and 'FlatColl*' with the note 'Implementations without double buffering', but the text does not define what double buffering means in this simulator context or why only some implementations lack it. Please define the term and explain the effect on the comparison.
  4. [Footnote 1 and Section V-C] The footnote noting that the NeurIPS FlashAttention-3 release reports about 10% higher throughput than the arXiv v1 used in the experiments is relevant to the H100 comparison in Section V-C. Please move this caveat into the H100 comparison discussion or explicitly state how it affects the 1.3x claim.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: results come from an independently implemented simulation baseline and external H100 measurements; the collective-primitive latency model is an explicit design assumption, not a fitted or self-cited input.

full rationale

The paper's central claims (89.3% utilization, 4.1x speedup over FlashAttention-3, 16x HBM traffic reduction) are produced by the SoftHier simulator, which is built from open-source, RTL-calibrated models (GVSoC, Snitch, Spatz, iDMA, RedMulE, FlooNoC, DRAMSys). The FlashAttention-2/3 baseline is implemented in C on the same simulator, so the comparison is not a fitted parameter renamed as a prediction. The H100 comparison imports published FlashAttention-3 numbers and H100 specifications from external work [6], and the die-size estimate uses component-level gate equivalents from prior publications; these are cited as independent evidence, not as the derivation of the speedup. The Section II multicast/reduction latency model (alpha/beta + 2Ld + N Lr) is an explicit modeling assumption for the hardware collective primitives; it is stated directly in the paper and is not calibrated against RTL, but it is not circular: no equation is defined in terms of the result it is used to predict, and no load-bearing step reduces to a self-citation. The HBM-traffic reduction factor is a direct arithmetic consequence of the grouping formula (1 + S/(sqrt(N) M)) derived in Section III-A; while the 16x figure follows from the chosen block and group sizes, it is a legitimate analytical consequence of the proposed dataflow rather than a circular redefinition. The main risk is validation fidelity of the collective-primitive model, which is a correctness concern, not a circularity concern. Under the stated rules, openly available RTL-calibrated components and externally published benchmarks constitute independent support, so the minor self-citations do not raise the circularity score.

Assumptions & free parameters 4 free parameters · 4 assumptions · 0 invented entities

The ledger captures the architectural parameters tuned by search (group size, mesh size, HBM channels) and the simulator and architecture assumptions the performance claims rest on. No invented physical entities are introduced.

free parameters (4)
  • Tile group shape (Gx, Gy) = varies: 4x4, 8x8, 16x16, 32x32
    Chosen per sequence length to balance HBM I/O reduction against over-flattening; the reported peak utilizations are the best over this search.
  • Fabric granularity = 32x32 (BestArch); also 16x16 and 8x8 evaluated
    Selected via co-exploration in Section V-C to optimize performance over cost, not derived from a first-principles model.
  • HBM channel count = 16x2 channels, 2 TB/s (BestArch)
    Chosen as part of the architecture search; yields 40% less bandwidth than H100's 3.4 TB/s.
  • Per-tile slice size (Br/Gy, Bc/Gx) = Set to maximize L1 occupancy while keeping the slice square
    Hand-tuned policy in Sections IV and V-B; directly affects RedMulE utilization and the over-flattening effect.
assumptions (4)
  • domain assumption The SoftHier simulator models are faithful proxies for real hardware performance.
    Models are calibrated against open-source RTL (RedMulE, FlooNoC, GVSoC), but no full-system silicon measurement validates the complete dataflow behavior.
  • domain assumption Hardware-supported multicast and reduction primitives can be implemented with the path-based latencies described in Section II.
    The key architectural enabler; the paper derives multicast latency reduction assuming in-flight packet duplication, but the actual NoC implementation cost is not demonstrated on fabricated hardware.
  • domain assumption Published FlashAttention-3 and H100 GPU numbers from Shah et al. form an accurate baseline for cross-architecture comparison.
    Section V-C uses external utilization figures; differences in measurement methodology, software versions, and precision are not fully controlled.
  • domain assumption K-matrix pre-transposition time is accounted for fairly in H100 comparisons.
    Footnote 2 states the authors include the pre-transposition cost when comparing to FlashAttention on H100, but the exact overhead model is not detailed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of FlatAttention: Dataflow and Fabric Collectives Co-Optimization for Efficient Multi-Head Attention on Tile-Based Many-PE Accelerators." pith.science (2026). https://pith.science/paper/7TTAGZHY

@misc{pith2026250518824,
  author       = {Pith},
  title        = {Pith review of: FlatAttention: Dataflow and Fabric Collectives Co-Optimization for Efficient Multi-Head Attention on Tile-Based Many-PE Accelerators},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7TTAGZHY}},
  note         = {Machine review of arXiv:2505.18824}
}
read the original abstract

Multi-Head Attention (MHA) is a critical computational kernel in transformer-based AI models. Emerging scalable tile-based accelerator architectures integrate increasing numbers of tightly-packed processing elements (PEs) with tensor units. MHA dataflow mapping is crucial for achieving high utilization of the available units. We propose FlatAttention, a new dataflow for MHA on tile-based many-PE accelerators, minimizing costly main memory (HBM) accesses by leveraging collective primitives integrated into the on-chip network fabric. FlatAttention achieves up to 89.3% utilization, and 4.1x performance speedup over FlashAttention-3 dataflow on tile-based accelerators whilst reducing HBM traffic by 16x. Through algorithm-architecture co-exploration, we identify an optimal configuration for a large scaled-out tile-based accelerator featuring a 32x32 tile mesh with 1024 TFLOPS @ FP16 peak performance, comparable to the state-of-the-art Nvidia H100 GPU. FlatAttention in this configuration achieves up to 1.3x higher utilization over FlashAttention-3 on the H100 GPU. Meanwhile, this tile-based accelerator configuration requires 40% less HBM bandwidth compared to the H100, enabling a 1.8x reduction in die size, estimated on the same technology node.

Figures

Figures reproduced from arXiv: 2505.18824 by the authors.

Figure 1
Figure 1. Tile-Based Many-PE Architecture Template [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. (a) Parametric definition of FlatAttention. (b) Detailed FlatAttention dataflow, with each step corresponding to the line numbers in Algorithm 2. (c) [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 4
Figure 4. Runtime breakdown for different (square) flattening scales and layer [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figures from the paper (2 more)
Figure 3
Figure 3. Figure 3: Runtime breakdown (bars) and average HBM BW utilization (star [PITH_FULL_IMAGE:figures/full_fig_p005_3.png]
Figure 5
Figure 5. Figure 5: (a) Heatmap of utilization with best group size. (b) Comparison with [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

26 extracted references · 22 canonical work pages

  1. [6]

    Flashattention-3: Fast and accurate attention with asynchrony and low-precision,

    J. Shahet al., “Flashattention-3: Fast and accurate attention with asynchrony and low-precision,”arXiv preprint arXiv:2407.08608, 2024

    arXiv 2024

  2. [1]

    On the computational complexity of self-attention,

    F. D. Keleset al., “On the computational complexity of self-attention,” inALT, 2023

    work page 2023

  3. [2]

    LLM inference unveiled: Survey and roofline model insights,

    Z. Yuanet al., “LLM inference unveiled: Survey and roofline model insights,”arXiv preprint arXiv:2402.16363, 2024

    arXiv 2024

  4. [3]

    Data movement is all you need: A case study on optimizing transformers,

    A. Ivanovet al., “Data movement is all you need: A case study on optimizing transformers,” inMLSys, 2021

    work page 2021

  5. [4]

    FlashAttention: Fast and memory-efficient exact attention with IO-awareness,

    T. Daoet al., “FlashAttention: Fast and memory-efficient exact attention with IO-awareness,” inNeurIPS, 2022

    work page 2022

  6. [5]

    FlashAttention-2: Faster attention with better parallelism and work partitioning,

    T. Dao, “FlashAttention-2: Faster attention with better parallelism and work partitioning,” inICLR, 2024

    2024

  7. [7]

    SambaNova SN40L: Scaling the AI memory wall with dataflow and composition of experts,

    R. Prabhakaret al., “ SambaNova SN40L: Scaling the AI memory wall with dataflow and composition of experts,” inMICRO, 2024

    work page 2024

  8. [8]

    Wafer-scale AI: GPU impossible performance,

    S. Lie, “Wafer-scale AI: GPU impossible performance,” inHCS, 2024

    work page 2024

Show all 26 references
  1. [9]

    Blackhole & TT-Metalium: The standalone AI computer and its programming model,

    J. Vasiljevicet al., “Blackhole & TT-Metalium: The standalone AI computer and its programming model,” inHCS, 2024

    2024

  2. [10]

    16.2 rngd: A 5nm tensor-contraction processor for power-efficient inference on large language models,

    S. M. Leeet al., “16.2 rngd: A 5nm tensor-contraction processor for power-efficient inference on large language models,” inISSCC, 2025

    2025

  3. [11]

    Attention in SRAM on tenstorrent grayskull,

    M. Th ¨uning, “Attention in SRAM on tenstorrent grayskull,”arXiv preprint arXiv:2407.13885, 2024

    2024 arXiv

  4. [12]

    FLAT: An optimized dataflow for mitigating attention bottlenecks,

    S.-C. Kaoet al., “FLAT: An optimized dataflow for mitigating attention bottlenecks,” inASPLOS, 2023

    2023

  5. [13]

    Fusemax: Leveraging extended einsums to optimize attention accelerator design,

    N. Nayaket al., “Fusemax: Leveraging extended einsums to optimize attention accelerator design,” inMICRO, 2024

    2024

  6. [14]

    Gemini: Mapping and architecture co-exploration for large- scale DNN chiplet accelerators,

    J. Caiet al., “Gemini: Mapping and architecture co-exploration for large- scale DNN chiplet accelerators,” inHPCA, 2024

    2024

  7. [15]

    DOJO: The microarchitecture of Tesla’s exa-scale computer,

    E. Talpeset al., “DOJO: The microarchitecture of Tesla’s exa-scale computer,” inHCS, 2022

    2022

  8. [16]

    Collective communication,

    R. van de Geijnet al., “Collective communication,” inEncyclopedia of Parallel Computing. Springer US, 2011, pp. 318–327

    2011

  9. [17]

    Towards the ideal on-chip fabric for 1-to-many and many-to-1 communication,

    T. Krishnaet al., “Towards the ideal on-chip fabric for 1-to-many and many-to-1 communication,” inMICRO, 2011

    2011

  10. [18]

    GVSoC: a highly configurable, fast and accurate full- platform simulator for RISC-V based IoT processors,

    N. Bruschiet al., “GVSoC: a highly configurable, fast and accurate full- platform simulator for RISC-V based IoT processors,” inICCD, 2021

    2021

  11. [19]

    Snitch: A tiny pseudo dual-issue processor for area and energy efficient execution of floating-point intensive workloads,

    F. Zarubaet al., “Snitch: A tiny pseudo dual-issue processor for area and energy efficient execution of floating-point intensive workloads,”IEEE TCOMP, 2020

    2020

  12. [20]

    Spatz: Clustering compact RISC-V-based vector units to maximize computing efficiency,

    M. Perottiet al., “Spatz: Clustering compact RISC-V-based vector units to maximize computing efficiency,”IEEE TCAD, 2025

    2025

  13. [21]

    A high-performance, energy-efficient modular DMA engine architecture,

    T. Benzet al., “A high-performance, energy-efficient modular DMA engine architecture,”IEEE TCOMP, 2023

    2023

  14. [22]

    RedMule: A mixed-precision matrix–matrix oper- ation engine for flexible and energy-efficient on-chip linear algebra and TinyML training acceleration,

    Y . Tortorellaet al., “RedMule: A mixed-precision matrix–matrix oper- ation engine for flexible and energy-efficient on-chip linear algebra and TinyML training acceleration,”FGCS, 2023

    2023

  15. [23]

    FlooNoC: A 645-Gb/s/link 0.15-pJ/B/hop open-source NoC with wide physical links and end-to-end AXI4 parallel multistream support,

    T. Fischeret al., “FlooNoC: A 645-Gb/s/link 0.15-pJ/B/hop open-source NoC with wide physical links and end-to-end AXI4 parallel multistream support,”IEEE TVLSI, 2025

    2025

  16. [24]

    DRAMSys: a flexible DRAM subsystem design space exploration framework,

    M. Junget al., “DRAMSys: a flexible DRAM subsystem design space exploration framework,”IPSJ T-SLDM, 2015

    2015

  17. [25]

    SUMMA: Scalable universal matrix multiplication algorithm,

    V . D. Geijnet al., “SUMMA: Scalable universal matrix multiplication algorithm,” inConcurrency: Practice and Experience. Wiley Online Library, 1997, pp. 255–274

    1997

  18. [26]

    MI300X vs H100 vs H200 Benchmark Part 1: Training,

    D. Schoret al., “MI300X vs H100 vs H200 Benchmark Part 1: Training,” 2024. [Online]. Available: https://semianalysis.com/2024/12/ 22/mi300x-vs-h100-vs-h200-benchmark-part-1-training/

    2024

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.