---
title: "Can GOOGL's 'Optical Net' take on NVDA's dominance?"
type: "Topics"
locale: "en"
url: "https://longbridge.com/en/dolphin/post/43994983.md"
description: "In the previous piece by Dolphin Research, we compared two third-party GPU vendors (3P GPUs) — $NVIDIA(NVDA.US) and $AMD(AMD.US) — on data center networking. NVDA's GB300 was a clear overmatch.AMD managed to scale up from 8 to 72 GPUs using Broadcom switches, delivering Helios. However, by the time it shipped, the competitor had already moved to Vera Rubin.AMD achieved parity in GPU interconnect bandwidth, but the cost economics were unfavorable and the engineering design lagged. AMD only just cleared the passing line..."
datetime: "2026-09-21T12:07:34.000Z"
locales:
  - [en](https://longbridge.com/en/dolphin/post/43994983.md)
  - [zh-CN](https://longbridge.com/zh-CN/dolphin/post/43994983.md)
  - [zh-HK](https://longbridge.com/zh-HK/dolphin/post/43994983.md)
author: "[Dolphin Research](https://longbridge.com/en/dolphin.md)"
generator: "portal-rs"
---

# Can GOOGL's 'Optical Net' take on NVDA's dominance?

In the [previous piece](https://longbridge.com/zh-CN/dolphin/post/43906382?channel=OWSN00110), Dolphin Research compared two 3P GPU vendors, $NVIDIA(NVDA.US) and $AMD(AMD.US), on data center interconnect architecture.

NVIDIA hard-launched GB300, while AMD finally leveraged Broadcom switches to scale up from 8 cards to 72 cards with Helios. By the time Helios shipped, the rival was Vera Rubin, which matched GPU link bandwidth but fell short on cost economics and lagged in engineering design.

AMD cleared the bar, but it feels like 'using an old sword to fight a new battle.' Dolphin Research believes the core issue is the lack of a self-developed full stack. **So what does pushing self-development to the extreme look like?**

**This piece turns to the 1P ASIC, self-developed-and-self-used networking leader — the CSP giant** $Alphabet(GOOGL.US) **. At a glance, its network reveals:**

**1\. A vast Scale-Up domain** approaching ten thousand chips, vs. Vera Rubin and Helios at only 72 cards.

**2\. A highly distinctive topology** that uses direct-connect instead of office area (compute trays) + scheduling room (switch trays) = office building (racks), adopting a unique OCS switch approach across the network.

**3\. Lower relative network cost**, thanks to the two points above.

Next, Dolphin Research drills down on these three traits to analyze Google:

1) How is the near-ten-thousand-chip Scale-Up domain achieved?

2) How did the direct-connect topology evolve from v7 to v8?

3) Does Google retain competitiveness after shifting to a TPU-aaS model?

4) Which names matter across the supply chain?

正文如下：

**1\. How is the near-ten-thousand-chip Scale-Up domain achieved?**

We use Ironwood v7, Google’s currently large-scale deployed generation, as the baseline.

**1) Interconnect protocol: ICI bears half the load**

**1) Scale-Up within a Pod: ICI over both optics and copper**

Google self-developed a proprietary TPU interconnect protocol, ICI (Inter-chip Interconnection; comparable to NVLink and UALink). v8 aggregates 2,400 GB/s bidirectional per TPU, doubling v7’s 1,200 GB/s (vs. NVIDIA at 3.6 TB/s).

Vera Rubin and Helios appear as ‘one protocol + one medium + in/out of rack,’ which can mislead readers that the three are tightly bound. The [first piece](https://longbridge.com/zh-CN/dolphin/post/43798848?channel=OWSN00110) clarified Scale-Up vs. Scale-Out is defined by communication semantics, not physical form. **Google aligns to this: within a Pod sized by TPUs, all TPU-to-TPU links use ICI regardless of in-rack/out-of-rack, optics or copper.** Only beyond that scale does it switch to conventional Ethernet-based DCN.

**2) Cross-Pod Scale-Out: Jupiter DCN plays a supporting role**

**Prior to v8, Google did not build a separate Scale-Out fabric.** Because the ICI domain is large enough, bandwidth-critical tensor and MoE parallel traffic stays inside ICI, suppressing cross-Pod demand, with relatively lenient bandwidth needs at **100 Gbps per chip**. Hence cross-Pod traffic piggybacks on Jupiter DCN, Google’s general-purpose Ethernet across all servers for search, ads, and storage. This means Jupiter DCN carries both front-end and back-end loads — front-end to storage/CPU/external networks with sparse traffic and tolerance for jitter; back-end between accelerators requiring synchronized parallelism.

**2) Topology: 3D building blocks + OCS**

Networking is about topology — how nodes connect across the fabric. The prior two pieces explained the 2D fat-tree used by most data centers. Google’s topology is 3D block-building. It scales from chip → tray → cube (i.e., rack) → Pod/Superpod. Compared with NVIDIA, chip and tray naming is similar, but the assembled trays look very different.

**1) Intra-Tray Scale-Up: physical 1×4 layout, logical 2×2 topology**

A tray hosts 4 TPUs (see below). TPU-to-TPU uses ICI; each TPU has 6 ICI ports with 1,200 GB/s aggregated bidirectional per chip. TPU-to-CPU communicates over PCIe (DAC).

The 6 ports make sense in the global layout: Google arranges TPUs in a 3D grid, with 6 ports linking to neighbors above/below, left/right, front/back (±x, ±y, ±z) — a 3D torus (below). Back to the tray, the 4 TPUs are in a row but not fully meshed. Four ports must be reserved for off-tray neighbors, leaving only two on-board, so each TPU can connect to only two same-board chips. Where the four off-tray ports go is addressed next.

**2) Tray-to-Tray Scale-Up: direct-connect topology provides connectivity**

The biggest difference vs. NVIDIA/AMD at tray-to-tray Scale-Up: **Google does not use switch ASICs, directly wiring TPUs in a 3D topology.** Sixteen trays form a Cube of 64 TPUs (i.e., a rack), interlinked as a 4×4×4 3D torus, each chip treated as a six-faced rectangular prism with cables pulled in six directions to its neighbors.

In the diagram below, some TPUs use optics in addition to copper. What’s going on?

**Copper vs. optics depends on a TPU’s position.** Within a single 64-chip Cube, the innermost 8 TPUs can fully connect to all six neighbors using copper (DAC+PCB). At the Cube boundary, a TPU without a physical neighbor on that face links optically to the TPU on the opposite side of the Cube (green line). Each boundary TPU is looped end-to-end, **with the link converted to optical by modules and aggregated into the OCS switch.** We summarize parts and parameters by TPU position (internal, surface, edge, corner) below.

**Going optical at the Scale-Up layer is Google-only.** Vera Rubin NVL72 and Helios use copper throughout Scale-Up: GPUs link via backplane copper to NVSwitch/Tomahawk; optics appear only at NICs and switches in Scale-Out, with GPUs themselves not on optics. By contrast, Google’s optical modules plug into OSFP cages on the TPU tray front panel, forming optical paths TPU → optical module → fiber → OCS → fiber → optical module → TPU, with no electrical switching in between.

**3) Cube-to-Cube Scale-Up: what is OCS?**

As noted, Cube boundary optical links are aggregated into OCS. In larger fabrics, **OCS also stitches multiple Cubes into bigger domains**: Pod (e.g., 4 Cubes, 256 TPUs) up to Superpod (max 144 Cubes, 9,216 TPUs). This is Google’s most unique hardware:

**a. OCS only redirects optical signals.** Boundary links enter OCS through optical modules, and OCS decides whether a port pair self-loops into a 64-chip torus or assembles into a larger torus. OCS simply guides light from one port to another.

**b. How does optics ‘switch’?** An OCS uses two 2D MEMS micro-mirror arrays; each mirror tilts bi-axially to direct any input beam to any output port (below). Unlike EPS (electronic packet switching, used by AMD/NVIDIA), **EPS makes real-time forwarding decisions per packet, while OCS establishes static optical paths between ports.** For example, if port 1 was connected to port 2 but now must talk to port 4, OCS must reconfigure the mirrors because it has no packet forwarding. A traditional EPS is fully interconnected at its ports and needs no reconfiguration.

A railroad switch is a useful analogy: many tracks exist, but only one is active at a time and changing routes requires flipping the switch (i.e., adjusting mirror angles). **Therefore, Google’s routing paths are pre-configured in software, since spending seconds to reconfigure under low-latency synchronous workloads is practically impossible.**

**c. OCS has no O–E–O conversion.** In conventional EPS, an out-of-rack path runs: chip outputs electrical signals, converted to optics in-rack (E→O), then fiber to the switch. The switch operates electrically, so optics are converted back (O→E), the switch ASIC makes a forwarding decision, then converts to optics (E→O); fiber to the remote rack, optics back to electrical (O→E), then into the chip.

**OCS removes the two optical-electrical conversions inside the switch, the only ‘switch’ in this network, avoiding switch ASIC cost and power. Diagram below:**

**d. Flexible topology scale.** In practice, Google may not expand strictly by standard 64-TPU Cubes. TPU domains can be configured in common slices from 4 up to 2,048 chips, enabled by OCS pre-configuration.

**4) Superpod-to-Superpod Scale-Out: OCS aims to replace the Spine layer**

Beyond the ICI domain lies Scale-Out. The key component remains OCS. In the prior piece: NVIDIA and AMD use fat-tree (Leaf–Spine) with EPS at the core, suffering two pains — high power and a 2–3 year speed-doubling cycle that forces full Spine refresh and heavy capex.

Google keeps Ethernet switches at ToR (self-developed white-box; switch ASIC likely Broadcom), aiming to [replace the Spine layer](https://longbridge.com/zh-CN/dolphin/post/41423680) (typical ToR-to-Spine vs. Google’s ToR-to-OCS below). This offers two advantages:

**Cost savings via strong compatibility.** OCS only reflects light and is speed-agnostic, allowing different switch generations to share the same fabric (right), without the overall network rate dragged down by the slowest generation (left, conventional architecture). **Once OCS is deployed, switches and optical modules can be upgraded to much higher speeds without replacing the Spine layer, lengthening replacement cycles and saving money.**

**Lower latency and power.** Optical–electrical conversion adds latency, while OCS only reflects incident light from source to destination ports. This also reduces overall power draw. OCS is not perfect: aside from impractical reconfiguration under workloads, it sacrifices the flexibility of mixing with other EPS-based fabrics, since networks must be built around OCS. It also trails EPS on **reliability and insertion loss**.

**3) Summary**

**Google’s architecture fundamentally leverages its software stack advantage.** A direct torus removes switch ASICs, meaning no device makes runtime forwarding decisions. **The precondition is that topology and paths are fixed in software before jobs start** — whether a Cube self-loops or stitches, slice sizes, etc., are OCS configurations rather than physical rewiring. Using OCS to replace electrical Spine in Scale-Out follows the same logic. **In short, Google shifts ‘intelligence’ from switch ASICs into the configuration phase, while hardware provides fixed, low-cost direct links.**

**For customers, this swaps flexibility for determinism.** Paths are fixed upfront, avoiding runtime congestion rerouting, and performance is calculable before jobs run. The trade-off is no runtime remedies once launched. Further, only Google’s compiler understands how these chips are wired, keeping customers in Google’s compiler ecosystem, with CUDA migration a challenge.

**2\. How did the direct-connect topology evolve from v7 to v8?**

Google optimized the network for v8’s split of training and inference. Evolution boils down to two moves:

\- v8t (training) keeps the v7 topology, boosts bandwidth and scale, and builds a dedicated back-end network. - v8i (inference) changes topology to reduce hop count.

**1) v8t (training): bandwidth doubled, ICI domain expanded to 9,600 chips, new Virgo back-end**

**Bandwidth doubled, topology retained.** Per TPU bidirectional bandwidth doubled to 2,400 GB/s, trays and Cubes kept v7’s 3D torus. The ICI domain cap expanded from 9,216 to 9,600 chips. **Scale-Out no longer rides Jupiter.** Sharing front- and back-end on v8 became untenable as training clusters spill beyond one ICI domain, cross-Pod traffic becomes more than data-parallel gradient sync, per-chip bandwidth demand surges, and ms-level sync bursts plus inference’s latency consistency requirements conflict with a general-purpose network.

**Thus, Google built Virgo as a dedicated back-end network for v8t to carry cross-Pod Scale-Out traffic, lifting per-chip Scale-Out bandwidth to 4x v7 (i.e., 400 Gbps).** When training exceeds a single DC’s power/space, clusters must span DCs under a unified domain, Jupiter remains the front-end and Scale-Across egress, **scaling a single training cluster beyond 1 mn TPUs**.

**2) v8i (inference): full-mesh within tray, Boardfly lowers hop count**

**Tray-level full-mesh.** The 4 chips in a tray achieve full-mesh over internal ICI, reducing hops for diagonal pairs (e.g., a to c) from 2 to 1 (below). **Boardfly at the Cube layer.** Each tray exposes 16 external links; 8 trays fully mesh over copper using 11 to form a Group, with 5 links via optical modules into OCS. Thirty-six Groups OCS-direct form a Pod with 1,152 chips, of which 1,024 are active (below).

**The inference-side topology change directly improves network diameter.** In a 1,024-chip domain (8×8×16), a 3D torus needs up to 16 hops: each axis is a ring, the farthest distance is half a ring, and the axes add up to 4+4+8=16. Boardfly caps at 7 hops (paths below). Shrinking diameter by over 50% translates to lower tail latency, reducing user-perceived delay — critical for inference-heavy Agent workloads.

**3) With this, we wrap Google’s network design, evolution, pros/cons. Before discussing competitiveness, a brief summary:**

\- Scale-Up: proprietary ICI protocol with 3D torus direct-connect instead of switching, no switch ASICs inside the domain. Copper vs. optics per chip depends on its position in the Cube; OCS configures Cube-to-Cube optical paths to slice, add fault tolerance, and stitch near-ten-thousand-chip domains. v8i adopts Boardfly for inference to reduce max hops. - Scale-Out: pre-v8 piggybacked Jupiter DCN (OCS replaces electrical Spine, front- and back-end share the fabric); v8t built Virgo as a dedicated back-end, per-chip Scale-Out bandwidth up 4x, Jupiter returns to front-end and Scale-Across. - OCS is the key hardware across both layers, trading off some flexibility and performance for compatibility and cost-down.

**3\. Is Google’s approach competitive after shifting to TPU-aaS?**

**1) Trade-offs in path design**

Google vs. AMD/NVIDIA is not fully like-for-like; we highlight comparable items (green leads, red lags), while others are design trade-offs:

**Sacrificing per-chip bandwidth to expand the domain.** On protocol bandwidth, ICI’s 2,400 GB/s trails NVLink 6 and UALoE at 3,600 GB/s, but the Scale-Up domain is far larger (9,600 chips vs. 72 cards). Once clusters exceed a single rack (e.g., thousands of chips), NVIDIA/AMD must go to Scale-Out, incurring a bandwidth drop (per-chip Scale-Out slows to 200 Gbps) and protocol conversion overhead. Google remains in Scale-Up at that scale and is not necessarily at a disadvantage; lower Scale-Out bandwidth is a consequence of a large ICI domain. **Sacrificing hop count to eliminate switch ASICs.** In a switched fabric, any two GPUs are single-hop; in a torus, packets forward hop-by-hop along axes and diameter grows with scale. Without switch ASICs, expansion is no longer constrained by switch port counts or copper length.

**2) How do these trade-offs show up in network cost?**

We further estimate Google’s physical-layer cost per rack (external sourcing), as below.

On same compute capacity, per-chip network cost in v7 is highly cost-effective — comparable compute to GB300 with one-third the network cost. In v8, the split between the two chips reflects Google’s thinking: the training chip pays a network premium for a near-ten-thousand-chip domain, while the inference chip uses smaller domains to dilute network cost.

In real workloads, we cannot stop at per-chip cost, and OCS replacing Spine saves spend as noted above. Under v8t, every 9,600 chips form one ICI domain with 48 OCS per domain. Scaling the domain increases port utilization per OCS rather than unit count (below); cross-domain OCS scales linearly with domains.

For example, a 100,000-TPU training cluster requires roughly 1,000 OCS at Google. At equivalent compute, Vera Rubin’s fat-tree needs nearly 2,600 switches (144 ports). In large-cluster projects, this can indeed save capex.

**3) Summary**

Back to competitiveness: it’s not a simple stronger–weaker answer. **If AMD passed by copying answers, Google changed the way the problem is solved.** It avoids fighting under NVIDIA’s interconnect framework, where followers struggle to match NVIDIA on supply chain integration, iteration speed, and HW–SW co-design. **Google leverages its software stack advantage and trades network design choices for competitiveness.** It accepts one-third lower per-chip bandwidth and higher latency from multi-hop torus, in exchange for a near-ten-thousand-chip Scale-Up domain and roughly half the per-chip network cost. Per third-party InferenceX tests, Ironwood loses much of the raw performance curve to GB but wins on cost per chip-hour.

**This trade-off is gaining traction:** Anthropic signed for nearly 1 mn TPUs in Jul 2025, and over 75% of its recent $200 bn financing plan is tied to TPU. TPU is shifting from an internal-only solution to TPU-aaS for commercial use, becoming a scale option for leading labs, and is very likely to challenge NVIDIA.

**4\. Which names matter across the supply chain?**

**1) Supply chains with similar logic**

We have mapped the [supply chain logic](https://longbridge.com/zh-CN/dolphin/post/43906382?channel=OWNN00030) behind NVIDIA and AMD’s networks; most core names overlap with Google’s suppliers. Google’s unique OCS and its component chain are detailed below.

**a. From Google’s network iteration, implications for the supply chain:**

\- Compute trays: The most critical next-gen TPU ASIC supplier will introduce MediaTek; we have tracked and commented — please [cf.](https://longbridge.com/zh-CN/dolphin/post/43726753?channel=OWSN00110). - v8t: As v7’s topology is retained, we expect limited changes across the supply chain. - v8i: Topology is optimized for inference. Hardware upgrades lift unit value, but Boardfly uses fewer interconnect parts than a 3D torus.

Overall, v8t is not the cost-performance pick in our estimates: on a per-compute basis, its network cost exceeds Vera Rubin’s and only regains some ground by eliminating Spine gear in large clusters. Per Google at Cloud Next 2026, inference accounts for 70%+ of accelerator cycles; as TPU splits training vs. inference, weak v8t shipments would be a negative for Google’s chain.

**b. By value contribution, optics dominates Google’s network, followed by PCB > switching > copper.**

**\- Optical modules see the largest incremental lift.** Unlike OCS counts fixed at 48 per domain, our estimate of optical module/TPU ratio is as high as 1.5, implying each added TPU needs 1.5 optical modules. Speed upgrades (800G to 1.6T) plus tech shifts (pluggable to NPO/CPO) raise ASPs, and entries by giants like NVIDIA and Broadcom **largely cement a volume-and-price upcycle.** For details, cf. [tech evolution](https://longbridge.com/zh-CN/dolphin/post/41423680) and [supply chain mapping](https://longbridge.com/zh-CN/dolphin/post/42139974). **\- PCB ranks second by value.** As with NVIDIA’s approach, scale and speed demand larger area, higher-grade materials, and more layers; although Ironwood’s direct-connect relaxes PCB signaling demands somewhat, v8t is broadly expected to use M9 (Panasonic spec; low Dk/Df, strength rising M2→M9), lifting ASPs. Volumes are driven by large-scale builds, **making this a relatively high-certainty segment.**

**\- Switch ASIC here refers to chips inside Scale-Out switches, primarily supplied by** $Broadcom(AVGO.US). We cannot rule out future collaboration with $Marvell Tech(MRVL.US) and $Astera Labs(ALAB.US), similar to Google’s diversified TPU sourcing. This incremental only exists beyond the ICI domain. **\- Copper** is largely peripheral under Google’s approach, and topology continuity suggests no DAC upgrade (e.g., AEC) next; we will discuss this under AWS in the next piece.

**Please cf.** [**the prior piece**](https://longbridge.com/zh-CN/dolphin/post/43906382?channel=OWSN00110) **for the above chain.**

**2) The key differentiator is the OCS supply chain**

OCS covers both layers of Google’s networks. Four common OCS technologies exist today (below); among them, MEMS has the broadest, most mature adoption and simpler optical paths, with Google and $Lumentum(LITE.US) as key names. The industry is evolving from ‘Google-unique’ to ‘industry-standard,’ and MEMS-OCS penetration should rise.

As noted earlier, mirror tilt angles in MEMS determine optical paths — **but how much tilt is ‘aligned’?** A beam must fall from port 1 precisely into the fiber core at port 4, thinner than a hair, requiring high precision across components. Along the optical path:

**\- Fiber collimator array:** input/output for light. Light exits fiber divergent, collimators straighten it into a parallel beam; at the output, they refocus it back into fiber. **\- Lens array:** focusing. Ensures beams land centered on the mirrors and fiber cores.

**\- MEMS micro-mirror arrays (two sets):** each mirror tilts bi-axially, and tilt angle changes the path, like a row of rotatable railway switches. **\- Dichroic beam splitters:** think wavelength-selective ‘one-way glass’; transmit one band, reflect another. Used to combine or separate two lights.

**\- Injection module:** emits probe light. **\- Camera module:** monitors the probe light’s landing spot.

**Google pairs the signal with a ‘guide light’:** OCS carries two co-propagating lights — 1310 nm signal for data and 850 nm probe for MEMS alignment monitoring. The probe must traverse the exact same path as the signal to reflect signal deviation, while a dichroic splitter at the output port separates wavelengths to keep only the 1310 nm signal.

Google self-develops the system architecture and the control modules (injection and camera). **Upstream passive optics — MEMS mirror arrays, dichroics, fiber collimator arrays, lens arrays — are externally sourced and account for 60%–70% of unit cost.** We suggest focusing on upstream suppliers in Google’s MEMS chain, as below:

**Upstream component supply:**

**1) MEMS mirror arrays:** By value, the MEMS mirror array chip is most critical, at ~30%–40% of OCS BOM. **Saiv Microelectronics** (through Silex in Sweden) is Google’s exclusive foundry for MEMS-OCS chips, the core of Google’s TPU optical switch system. In China, **Ingdan Holdings**’s 6-inch MEMS fab (vs. Saiv’s 8-inch) can produce MEMS chip arrays.

**2) Dichroic beam splitters: Tengjing Tech** supplies prisms and filters for OCS switches, qualified on Google’s whitelist and tied to Google’s optical module suppliers. Customers include **Lumentum, Coherent, and Accelink**.

Domestic names **Eastoptics, Hengtai New Materials, Crystal-Optech, and Fuchin Tech** are entering via the same coating platforms (filters/dichroics/splitters), often in sampling or pilot stages.

**3) Fiber collimator arrays: Corning** is the global primary supplier; **T&S Communications and O-Net** are secondary suppliers. **Tengjing Tech** is a third-party source for Coherent on collimator arrays.

**4) Lens arrays: Focuslight** is Lumentum’s key supplier; it is also sampling LC 2D collimators to Coherent.

**Midstream system and manufacturing:**

Google’s 2026 OCS plan is to in-house 12,000–14,000 units and externally procure 6,000 units, likely split between **Lumentum** and another vendor (probably $Coherent Corp.(COHR.US)). As actual shipments fell short, Google placed orders with **Polatis**, which uses piezo-ceramic DLBS technology. In China, **Accelink** is progressing fast with full-stack in-house MEMS mirror chips, fiber arrays, and precision coupling packaging.

Google’s contract manufacturer is mainly China’s **Gigalight**, widely viewed as Google’s largest MEMS-OCS supplier with over 70% of Google’s purchases.

Dolphin Research’s summary of core assets in Google’s chain is below:

The next piece will map AWS and Huawei’s network designs. Stay tuned.

\<End>

Risk disclosure and statement: [Dolphin Research Disclaimer and General Disclosure](https://support.longbridge.global/topics/misc/dolphin-disclaimer)

**Dolphin Research AI DC Interconnect Series:**

‘[The Era of AI Hyper-Interconnect: AI Runs to Light?](https://longbridge.cn/zh-CN/dolphin/post/41423680?channel=OWNN00110)’

‘[‘Copper’ Won’t Leave! CPO: Real Opportunity or Mirage?](https://longbridge.cn/zh-CN/dolphin/post/42139974?channel=OWNN00110)’

‘[AI-Era DC Interconnect: Teaming Above Single Chips — Is There a ‘China’ Opportunity?](https://longbridge.com/zh-CN/dolphin/post/43798848?channel=OWSN00110)’

‘[AMD Arm-Wrestles NVIDIA — Is Helios Qualified?](https://longbridge.com/zh-CN/dolphin/post/43906382?channel=OWSN00110)’

### Related Stocks

- [AMD.US](https://longbridge.com/en/quote/AMD.US.md)
- [NVDA.US](https://longbridge.com/en/quote/NVDA.US.md)
- [XXX.US](https://longbridge.com/en/quote/XXX.US.md)
- [AVGO.US](https://longbridge.com/en/quote/AVGO.US.md)
- [GOOGL.US](https://longbridge.com/en/quote/GOOGL.US.md)
- [GOOG.US](https://longbridge.com/en/quote/GOOG.US.md)
- [GOOGN.US](https://longbridge.com/en/quote/GOOGN.US.md)
- [MRVL.US](https://longbridge.com/en/quote/MRVL.US.md)
- [ALAB.US](https://longbridge.com/en/quote/ALAB.US.md)
- [LITE.US](https://longbridge.com/en/quote/LITE.US.md)

---
> **Disclaimer: This article is for reference only and does not constitute any investment advice.**