Predictika · Arista AI cluster fabric design

An AI agent's GPU fabric design, checked before it reaches the simulator

An SE, a partner or an AI agent proposes the back-end fabric for a GPU cluster: which Arista Etherlink leaf and spine switches, how many spines, which optic, how far the links run, which EOS release. Before the design goes to a simulator, a lab or an order, the proposal goes to the Predictika validator. It recomputes the GPU count and the oversubscription from the servers and spines, checks every optic against the port, the distance and the EOS release, checks the platforms against their EOS minimums and LPO support, compares the figures the proposal states with the computed ones, and returns every reason in one answer. Hard rules block; soft recommendations route to a person for approval. This checks that a design is legal, not how it performs: it does not simulate traffic. Nothing here is priced. This is an illustrative model built from Arista's public documentation. Arista Networks is not involved with it and has not endorsed it.

Scope: two-tier leaf-spine GPU back-end fabrics on Arista Etherlink platforms: DCS-7060X6, DCS-7280R4, DCS-7720R4 and the 7800R4 chassis. See everything this validator covers

This validator checks one kind of proposal: a rail-optimized leaf-spine GPU back-end fabric built from Arista 800G OSFP platforms. It handles any proposal that picks from these switches, optics and EOS releases, not only the scenarios on this page. It checks whether the design is legal before it is simulated, tested or ordered. It does not simulate traffic or predict performance, and it does not cover front-end or storage fabrics, configuration or pricing.

  • Covered: sizing — GPUs from the server count (8 GPUs per server, one 400G fabric link per GPU), servers per stripe, leaf switches, uplinks and spines needed for 1:1, and the oversubscription of what is proposed. Two-to-one blocks; anything above 1:1 and below 2:1 needs approval. Counts are in 400G equivalents, the standard rail-optimized pattern.
  • Covered: optics — form factor (OSFP or QSFP-DD) against the ports, the reach of the optic against the leaf-to-spine distance, the minimum EOS release the optic needs on both the leaf and the spine, and linear pluggable optics (LPO), which Arista lists only on some platforms.
  • Covered: platforms — the minimum EOS release of each platform, and whether each switch is a leaf or spine model in the Etherlink AI designs; others route to approval.
  • Covered: options and the proposal itself — load balancing and lossless configuration, and the GPU count and oversubscription the proposal states, which are compared with the computed figures; a mismatch blocks.
  • Not covered — traffic simulation, cabling and breakout, power and cooling, links per leaf-spine pair, switch configuration, and any price or availability. Other areas can be added.
  • Only consistent rows are modeled — where Arista's documents disagree (LPO on the 7060X6-32PE and the 7720R4), the validator routes the question to approval. Where no minimum EOS release is published (the 7800R4 chassis), none is checked.
The AI design agentProposes the GPU back-end fabric from the customer's requirements and says it is ready for the build team.
Predictika validatorChecks every rule at once and returns the verdict, each finding, and the computed figures.

8 scenarios in 4 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

The AI design agent says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: AI design agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      

        
        
        
      

      
Waiting for the call.

      
    

  

  
  

    
Where rules-based CPQ gets it wrong
Click to expand
    
Our assessment of what a typical rules-based CPQ (product rules, price rules and validation rules, as in Salesforce CPQ) does with the same cases. It is a judgment about effort and reliability, not a claim that nothing can be built.

    
What the validator caughtTypical rules-based CPQPredictika
Fabric sizing that derives stripes, leaves, uplinks and spines from the server countOnly with workarounds
The counts depend on the server count in steps and on the port count of the chosen spine, so each is a formula that has to be rewritten for every switch model, and a 3-spine proposal for 2,048 GPUs passes unless someone adds the arithmetic.		The stripe, leaf, uplink and spine counts are computed on every call and compared with what was proposed; 3 spines for 2,048 GPUs comes back as 1.19 to 1 oversubscribed, with the 4 spines that 1:1 needs, and the stated 1:1 is caught.
Optics against distance, form factor and EOS releaseOnly with care
Reach, form factor and the minimum EOS release are compatibility rules per optic and per platform. They can be written, but every new optic multiplies them, and a distance has to be compared with a reach.		Each optic carries its form factor, reach and minimum EOS; a 120 metre run on a 50 metre optic, an optic that needs EOS 4.35.0 on leaves running 4.32.2, and a QSFP-DD optic in OSFP ports are all caught on the same call.
Platform rules that differ by modelOnly with care
LPO is listed on some platforms, disputed on others and unsupported on the rest, and each platform has its own minimum EOS release.		Each platform carries its LPO status and EOS minimum; unsupported blocks, disputed routes to approval.
Hard rules versus recommendations, and figures the proposal itself statesOnly with workarounds
Approval chains handle one threshold well, but here some findings block, some only need a person, and the proposal's own stated GPU count and oversubscription must be checked against the computed ones.		Each finding is labeled block or approval, and the stated figures travel with the proposal and are compared on every call.

  

  

    
What this validator catches: findings from its test cases
Click to expand
    
Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the design; approval findings need a person to sign off; everything else is computed. The wording shown is an example from the test runs; the numbers change with the proposal.

    
1Fabric is oversubscribed (blocks): The fabric is 3.56 to 1 oversubscribed: 1024 leaf-to-spine uplinks are needed for 1:1 but 1 x DCS-7804R4 give 288 ports. 1:1 needs 4 spines.
2LPO optic on an unlisted platform (blocks): LPO-800G-DR8 is a linear pluggable optic (LPO). Arista lists LPO support only on the 7060X6-64PE and the 7800R4 line cards; DCS-7280R4-32PE-F and DCS-7808R4 include a platform that is not listed.
3Leaf EOS below the platform minimum (blocks): Leaf DCS-7060X6-32PE needs EOS 4.34.2 or later (Arista datasheet); it is set to run 4.32.2.
4Optic cannot reach the distance (blocks): The leaf-to-spine run is 120 m but OSFP-800G-VSR8 reaches 50 m over multimode fiber.
5Optic does not fit the switch ports (blocks): Optic QDD-800G-2FR4 has the QSFP-DD form factor, but the ports of DCS-7060X6-32PE and DCS-7808R4 are OSFP ports. QSFP-DD and OSFP are different form factors and do not fit each other.
6Optic needs a newer EOS on the leaf (blocks): Optic OSFP-800G-VSR8 needs EOS 4.35.0 or later; leaf DCS-7060X6-64PE runs 4.32.2. An upgrade in the same project does not count: the optic can be deployed only on a release that supports it.
7Optic needs a newer EOS on the spine (blocks): Optic OSFP-800G-VSR8 needs EOS 4.35.0 or later; spine DCS-7808R4 runs 4.34.2. An upgrade in the same project does not count: the optic can be deployed only on a release that supports it.
8Stated GPU count does not match (blocks): Stated GPU count does not match: the agent stated 1152; the validator computes 1024 (128 servers x 8 GPUs).
9Stated oversubscription does not match (blocks): Stated oversubscription does not match: the agent stated 1.0 to 1; the validator computes 1.19 to 1.
10LPO support is disputed (needs approval): LPO-800G-DR8 is an LPO optic. The Arista transceiver guide lists LPO only on the 7060X6-64PE and the 7800R4 line cards, but the datasheet of DCS-7060X6-32PE or DCS-7808R4 describes LPO support. Confirm with Arista before ordering.
11No lossless configuration (needs approval): No lossless configuration proposed; RoCE back-end fabrics are normally run lossless with PFC and ECN.
12Oversubscribed against the 1:1 target (needs approval): The fabric is 1.19 to 1 oversubscribed; AI back-end fabrics are normally built at 1:1, so a design below 2:1 but above 1:1 needs a person to accept it.
13Plain ECMP load balancing (needs approval): Plain ECMP load balancing proposed; Arista guidance for AI back-end fabrics is RDMA-aware cluster load balancing.
14Switch is not a listed leaf (needs approval): DCS-7280R4-32PE-F is not one of the leaf models in the Arista Etherlink AI reference designs this validator covers.
15Switch is not a listed spine (needs approval): DCS-7060X6-64PE is not one of the spine models in the Arista Etherlink AI reference designs this validator covers.

  

  

    
Scenarios and results
Click to expand
    
The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.

    
1. Optics, EOS and stated figures: 3 spines, VSR8 over 120 m, EOS 4.32.2

    
The agent's request. Please check the GPU back-end fabric for Meridian Compute: 256 GPU servers, 2,048 GPUs in all, built rail-optimized on DCS-7060X6-64PE leaves running EOS 4.32.2 and 3 DCS-7808R4 spines running EOS 4.34.2, linked with OSFP-800G-VSR8 optics over 120 metres, with cluster load balancing and PFC and ECN lossless, stated as 1.0 to 1. It is ready for the build team.

    
Verdict: Blocked.

    
    
      
  • Optic cannot reach the distance. The leaf-to-spine run is 120 m but OSFP-800G-VSR8 reaches 50 m over multimode fiber.
    • 
      
  • Optic needs a newer EOS on the leaf. Optic OSFP-800G-VSR8 needs EOS 4.35.0 or later; leaf DCS-7060X6-64PE runs 4.32.2. An upgrade in the same project does not count: the optic can be deployed only on a release that supports it.
    • 
      
  • Optic needs a newer EOS on the spine. Optic OSFP-800G-VSR8 needs EOS 4.35.0 or later; spine DCS-7808R4 runs 4.34.2. An upgrade in the same project does not count: the optic can be deployed only on a release that supports it.
    • 
      
  • Stated oversubscription does not match. Stated oversubscription does not match: the agent stated 1.0 to 1; the validator computes 1.19 to 1.
    • 
      
  • Oversubscribed against the 1:1 target. The fabric is 1.19 to 1 oversubscribed; AI back-end fabrics are normally built at 1:1, so a design below 2:1 but above 1:1 needs a person to accept it.
    • 
    

    
2. Optics, EOS and stated figures: 2FR4 optics, still 3 spines

    
The agent's request. Please check the GPU back-end fabric for Meridian Compute: 256 GPU servers, 2,048 GPUs in all, built rail-optimized on DCS-7060X6-64PE leaves running EOS 4.32.2 and 3 DCS-7808R4 spines running EOS 4.34.2, linked with OSFP-800G-2FR4 optics over 120 metres, with cluster load balancing and PFC and ECN lossless, stated as 1.0 to 1. It is ready for the build team.

    
Verdict: Blocked.

    
    
      
  • Stated oversubscription does not match. Stated oversubscription does not match: the agent stated 1.0 to 1; the validator computes 1.19 to 1.
    • 
      
  • Oversubscribed against the 1:1 target. The fabric is 1.19 to 1 oversubscribed; AI back-end fabrics are normally built at 1:1, so a design below 2:1 but above 1:1 needs a person to accept it.
    • 
    

    
3. Optics, EOS and stated figures: 4 spines

    
The agent's request. Please check the GPU back-end fabric for Meridian Compute: 256 GPU servers, 2,048 GPUs in all, built rail-optimized on DCS-7060X6-64PE leaves running EOS 4.32.2 and 4 DCS-7808R4 spines running EOS 4.34.2, linked with OSFP-800G-2FR4 optics over 120 metres, with cluster load balancing and PFC and ECN lossless, stated as 1.0 to 1. It is ready for the build team.

    
Verdict: Allowed.

    
4. LPO optics: LPO optics on 7060X6-32PE leaves

    
The agent's request. Please check the GPU back-end fabric for Altair AI Lab: 64 GPU servers, 512 GPUs in all, built rail-optimized on DCS-7060X6-32PE leaves running EOS 4.36.0 and 2 DCS-7808R4 spines running EOS 4.36.0, linked with LPO-800G-DR8 optics over 100 metres, with cluster load balancing and PFC and ECN lossless, stated as 1.0 to 1. It is ready for the build team.

    
Verdict: Needs approval.

    
    
      
  • LPO support is disputed. LPO-800G-DR8 is an LPO optic. The Arista transceiver guide lists LPO only on the 7060X6-64PE and the 7800R4 line cards, but the datasheet of DCS-7060X6-32PE or DCS-7808R4 describes LPO support. Confirm with Arista before ordering.
    • 
    

    
5. LPO optics: Standard 2FR4 optics

    
The agent's request. Please check the GPU back-end fabric for Altair AI Lab: 64 GPU servers, 512 GPUs in all, built rail-optimized on DCS-7060X6-32PE leaves running EOS 4.34.2 and 2 DCS-7808R4 spines running EOS 4.34.2, linked with OSFP-800G-2FR4 optics over 100 metres, with cluster load balancing and PFC and ECN lossless, stated as 1.0 to 1. It is ready for the build team.

    
Verdict: Allowed.

    
6. Form factor and EOS release: QSFP-DD optics, EOS 4.32.2

    
The agent's request. Please check the GPU back-end fabric for Cobalt Cloud: 128 GPU servers, 1,024 GPUs in all, built rail-optimized on DCS-7060X6-32PE leaves running EOS 4.32.2 and 2 DCS-7808R4 spines running EOS 4.34.2, linked with QDD-800G-2FR4 optics over 100 metres, with cluster load balancing and PFC and ECN lossless, stated as 1.0 to 1. It is ready for the build team.

    
Verdict: Blocked.

    
    
      
  • Optic does not fit the switch ports. Optic QDD-800G-2FR4 has the QSFP-DD form factor, but the ports of DCS-7060X6-32PE and DCS-7808R4 are OSFP ports. QSFP-DD and OSFP are different form factors and do not fit each other.
    • 
      
  • Leaf EOS below the platform minimum. Leaf DCS-7060X6-32PE needs EOS 4.34.2 or later (Arista datasheet); it is set to run 4.32.2.
    • 
    

    
7. Form factor and EOS release: OSFP optics, EOS 4.34.2

    
The agent's request. Please check the GPU back-end fabric for Cobalt Cloud: 128 GPU servers, 1,024 GPUs in all, built rail-optimized on DCS-7060X6-32PE leaves running EOS 4.34.2 and 4 DCS-7808R4 spines running EOS 4.34.2, linked with OSFP-800G-2FR4 optics over 100 metres, with cluster load balancing and PFC and ECN lossless, stated as 1.0 to 1. It is ready for the build team.

    
Verdict: Allowed.

    
8. Roles and options: 7060X6-64PE spines, ECMP, no lossless

    
The agent's request. Please check the GPU back-end fabric for Orchid Systems: 128 GPU servers, 1,024 GPUs in all, built rail-optimized on DCS-7060X6-64PE leaves running EOS 4.34.2 and 8 DCS-7060X6-64PE spines running EOS 4.34.2, linked with OSFP-800G-2FR4 optics over 80 metres, with plain ECMP load balancing and no lossless configuration, stated as 1.0 to 1. It is ready for the build team.

    
Verdict: Needs approval.

    
    
      
  • Switch is not a listed spine. DCS-7060X6-64PE is not one of the spine models in the Arista Etherlink AI reference designs this validator covers.
    • 
      
  • Plain ECMP load balancing. Plain ECMP load balancing proposed; Arista guidance for AI back-end fabrics is RDMA-aware cluster load balancing.
    • 
      
  • No lossless configuration. No lossless configuration proposed; RoCE back-end fabrics are normally run lossless with PFC and ECN.
    • 
    

  

  

    
Narration transcript
Click to expand
    
The text of the narrated walkthrough, step by step.

    
    
      
  1. Welcome to a demo of Predictika's Validator. An SE, a partner or an AI agent proposes the back-end fabric for a GPU cluster: which Arista Etherlink leaf and spine switches, how many spines, which optic, and more. Before the design goes to a simulator, a lab or an order, the proposal goes to the Predictika validator. It recomputes the GPU count and the oversubscription from the servers and spines, checks every optic against the port, the distance and the EOS release, checks the platforms against their EOS minimums and LPO support, compares the figures the proposal states with the computed ones, and returns every reason in one answer. Hard rules block; soft recommendations route to a person for approval. This checks that a design is legal, not how it performs: it does not simulate traffic. Nothing here is priced. This is an illustrative model built from Arista's public documentation. Arista Networks is not involved with it and has not endorsed it.
    2. 
      
  2. I will start with the first request by the agent.
    3. 
      
  3. The agent says. Please check the GPU back-end fabric for Meridian Compute: 256 GPU servers, 2,048 GPUs in all, built rail-optimized on DCS-7060X6-64PE leaves running EOS 4.32.2 and 3 DCS-7808R4 spines running EOS 4.34.2. It is ready for the build team. The rest of the request is on screen.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with four findings and one approval, all in one answer. The leaf-to-spine run is 120 m but OSFP-800G-VSR8 reaches 50 m over multimode fiber. Optic OSFP-800G-VSR8 needs EOS 4.35.0 or later; leaf DCS-7060X6-64PE runs 4.32.2. An upgrade in the same project does not count: the optic can be deployed only on a release that supports it. Optic OSFP-800G-VSR8 needs EOS 4.35.0 or later; spine DCS-7808R4 runs 4.34.2. An upgrade in the same project does not count: the optic can be deployed only on a release that supports it. The other one is on screen.
    6. 
      
  6. The validator returned four blocking findings and one approval in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the design are checked against each other.
    7. 
      
  7. What this shows: for optics against distance, form factor and EOS release, a rules-based application is error-prone for this.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the leaf-to-spine optic to OSFP-800G-2FR4.
    10. 
      
  10. It calls the validator again.
    11. 
      
  11. Still blocked, with one finding and one approval, all in one answer. Stated oversubscription does not match: the agent stated 1.0 to 1; the validator computes 1.19 to 1.
    12. 
      
  12. Three findings cleared. Still blocking: stated oversubscription does not match. One approval also remains for a person: oversubscribed against the 1:1 target.
    13. 
      
  13. The agent resubmits once more.
    14. 
      
  14. The revised request. It changes the spines to 4.
    15. 
      
  15. It calls the validator once more.
    16. 
      
  16. This time the validator clears it.
    17. 
      
  17. The validator also returns the line-item quote. It starts with 8-GPU servers and DCS-7060X6-64PE leaf switches; the other two lines are on screen.
    18. 
      
  18. Both earlier findings are cleared, and the validator's figure matches the design.
    19. 
      
  19. Five problems caught in one call, fixed in two passes, and a clean design. That is the value of Predictika's validator: catching mistakes before they reach the build. Now you can try the other scenarios yourself.
    20.