Xsight Labs makes AI networking programmable in silicon

The network around an AI workload does more than move model weights. It carries storage requests, control messages, tenant traffic and bursts of communication between compute nodes. Xsight Labs supplies programmable switching silicon and data processing units that let infrastructure teams move some of this work into dedicated devices. Its attraction is control over packet handling and infrastructure services. The tradeoff is that control becomes an engineering responsibility, involving software, host integration and system-level validation.

01 / ProductSwitching and offload are related but different jobs

The X-Series page describes X2 switching silicon with an advertised 12.8 Tbps capacity and programmable packet processing. A switch decides how traffic moves between ports. Programmability lets the system designer adapt selected network behavior to a workload, subject to the device's actual resources. It does not turn an Ethernet switch into a general-purpose AI accelerator or guarantee that every custom feature runs without a throughput cost.

The E-Series portfolio addresses a different layer. E1 combines Arm compute with networking and storage functions, with advertised 800 Gbps throughput. Its development model includes Linux, XDP, DPDK and SPDK. A DPU can run infrastructure services separately from the host processor, allowing a system to isolate or offload work. Whether this helps depends on the service, memory traffic and host connection, rather than on the network rate alone.

Xsight's XISA overview describes separate instruction sets for parsing packets and the programmable match-action pipeline. This is the specification boundary exposed to switch developers. Public visibility into that boundary can improve understanding and tooling, but an open instruction set is not the same as unrestricted access to every SDK, reference design or support service needed for a commercial product.

02 / AudienceA fit for teams that can own networking behavior

One suitable reader builds a network appliance and needs packet handling beyond a fixed feature set. Another operates an AI platform where storage or security services consume host CPU resources. A third develops a control plane and wants more visibility into the switch underneath it. Each should begin with a named function to change: telemetry collection, traffic steering, storage processing or tenant isolation. A broad wish for faster AI is too imprecise.

Equipment buyers with no intention of maintaining a data plane may prefer an integrated networking system. Arista provides a useful comparison at the system and operations layer. NVIDIA is an adjacent reference for integrated accelerated-computing and networking platforms. The decision is partly about where responsibility should sit: within an established system stack or within the buyer's own hardware and software integration team.

Availability needs careful separation. The E1L announcement dated 8 October 2026 schedules sampling for the second quarter of 2027. Its lower-power edge positioning is therefore a roadmap option today. A near-term evaluation should not be designed around immediate E1L deliveries simply because the product appears alongside E1 on the current website.

03 / WorkflowProposed workflow for storage traffic beside an AI host

Consider a proposed inference platform whose hosts spend substantial CPU time on storage and networking while accelerators intermittently wait for input. First separate the delay sources. Measure data preparation, filesystem work, network transfer, queueing and accelerator execution under representative request mixes. If preprocessing dominates, a DPU may leave the bottleneck untouched. If the host is busy moving and protecting data, offload becomes a more specific hypothesis.

Choose one service to prototype on an E1-based system and retain a host-based control path. Map the complete flow: where requests arrive, which component owns buffers, where encryption or access checks occur, and how results reach the accelerator. Include NUMA placement and the host interface in the design review. Moving code away from the CPU can add crossings that offset an apparent saving if the data path is poorly arranged.

Implement the minimum useful function using the documented software model, then measure at the application boundary. The outcome should be completed requests within the latency target, accompanied by host CPU use, DPU resource use and error counts. Avoid combining a vendor's maximum network throughput with a separate benchmark and presenting the result as measured end-to-end capacity. This workflow is illustrative; Sequenced has not run it on Xsight hardware.

For a switch evaluation, construct traffic that resembles the actual AI fabric. Include bursts toward one destination, simultaneous storage activity, control traffic and partial link failures. Test the chosen telemetry or load-balancing logic under those conditions. A quiet network can make an elegant algorithm look effective while hiding queue contention. Record whether the custom program changes resource consumption, forwarding behavior or observability under load.

Finally, rehearse operational changes. Update the offload application, roll back the switch program and restart the host independently. Establish which combinations are supported and which require coordinated maintenance. A separate processing domain is useful only if its lifecycle is understood. Otherwise a routine host update can leave the network or storage service on an incompatible version with difficult failure symptoms.

04 / PricingQuoted silicon, software terms and system costs

Xsight's sales terms describe written purchase orders subject to acceptance and prices supplied through quotations or an applicable price list. No current numeric public tariff was verified. The terms distinguish software licensing from sale of chips. The practical purchasing unit may also be a partner board or complete system, whose support and pricing should not be inferred from the silicon supplier's description.

The public X-Series and E-Series pages identify detailed design resources that require NDA access. A buyer should establish the scope of those resources before estimating integration effort. A published ISA or support for familiar Linux frameworks reduces some uncertainty; it does not prove that all hardware documentation, SDK samples and commercial assistance are freely downloadable. Confirm the precise software rights and deliverables for the chosen configuration.

Cost comparisons should include the server resources displaced and the engineering work added. Count board power and cooling, host slots, memory, software maintenance and failure handling. An ASIC power figure covers a narrower boundary than a finished card or appliance. A useful business case shows both the infrastructure saving and the resources needed to keep the offloaded service reliable over its intended life.

05 / DistinctionsProgrammability exposes choices that fixed appliances hide

XISA offers a way to reason about packet processing below the usual network operating-system abstraction. That can matter when a team needs a new parser or traffic behavior, rather than only a different configuration of existing features. The advantage is strongest for builders with the ability to test those changes thoroughly. More control expands the space of possible mistakes as well as useful designs.

The E-Series' familiar software frameworks offer a different kind of continuity. Existing Linux networking or storage expertise may transfer to a DPU project, but the hardware still has its own CPU, memory and I/O limits. A successful port should account for those constraints explicitly. Source compatibility is an encouraging starting point; it is not proof that an application retains its performance or operational behavior without adjustment.

Combining switch telemetry with host-side service measurements could make an AI platform easier to diagnose. For example, a burst seen at the switch may explain a long storage tail at the application. That is a proposed observability pattern, not a built-in guarantee. The team needs consistent identifiers and clocks, plus a way to collect data without overwhelming the control system during the very events it is trying to investigate.

06 / QuestionsSeparate open specifications from a supported deployment

First, identify the exact supported system. X2 silicon, an E1 add-in card, a partner appliance and a future E1L module are different products with different integration boundaries. Ask which party owns firmware, the network operating system, board qualification and support. A component-level specification cannot establish the behavior of a system assembled from independently chosen parts.

Second, examine isolation and recovery. A DPU may run services outside the host, but the security benefit depends on its boot chain, management permissions and access to host resources. Determine how a failed or compromised service is contained and how administrators regain control. Do this at the actual system level rather than treating physical separation alone as a complete security design.

Third, distinguish product claims from evidence matching the workload. Port speed, connections per second and packet latency describe different tests. Request packet sizes, enabled functions, memory conditions and measurement boundaries before comparing them. For E1L, retain the published future sampling date in the plan and avoid turning a roadmap specification into a promise of near-term deployment capacity.

07 / DecisionStart with one network function worth owning