ByteDance STE Firmware at OCP China 2026: From Standardization to Intelligent Data‑Center Firmware

Background

With AI workloads driving a rapid increase in XPU (GPU/NPU) density—from 4‑8 cards per node to 16‑32 cards and beyond—server firmware, once hidden beneath the OS, has become a decisive factor for data‑center reliability, security, and operational efficiency.

1. XPU Module Standardized Interface

Problem background: Diverse XPU scenarios (training, inference, fine‑tuning) and fragmented vendor management APIs create a "management fragmentation" problem that hinders large‑scale automation.

Identified pain points:

Complex scenarios require different monitoring capabilities.

Vendor‑specific interfaces differ greatly, forcing per‑vendor adapters.

Scale‑out clusters need automated, standardized management, but existing interfaces are inconsistent.

Analysis of current capabilities: A cross‑vendor Redfish/IPMI survey showed that while all vendors follow the Redfish spec, concrete monitoring functions (e.g., optical‑link monitoring, one‑click log collection, firmware upgrade) vary, leading to linear growth in adaptation cost.

Solution – Unified Redfish Layer: ByteDance proposes an "interface‑implementation decoupling" design where the head‑node BMC treats all XPU types uniformly via a standardized Redfish interface. The architecture uses a primary Redfish‑over‑LAN channel for full out‑of‑band management and an I2C side‑band as a fallback.

Why not adopt DMTF RDE? Compared with the Redfish Device Enablement (RDE) schema, the Redfish JSON approach offers simpler debugging, lower bandwidth usage, and easier extension for XPU‑specific resources, at the cost of requiring a new XPU‑focused schema.

Core API specification (selected examples):

Module BMC status – /redfish/v1 StartupState – /redfish/v1/Chassis/{id}/Processors/{xpu_id} (fields: ReadingCelsius, PowerWatts)

Switch port metrics – /redfish/v1/Fabrics/{id}/Switches/{id}/Ports/{id}/Metrics (field: BadTLPCount)

One‑click log collection – /redfish/v1/Managers/LogService/CollectAllLog (field: Status)

The design is highly extensible: new modules only need to implement the defined interface set and optional OEM extensions, without changing upper‑layer orchestration.

Open ecosystem: The team commits to an open‑source, community‑driven development model to foster a shared XPU management ecosystem.

2. OpenBMC Agent Framework

Migration pain points: Porting OpenBMC to a new XPU platform requires repetitive work—sensor configuration, GPIO mapping, FRU info, IPMI command adaptation—leading to knowledge silos, duplicated effort, and error‑prone manual coding.

Agent framework concept: Transform engineering experience into an executable knowledge base that an AI‑driven Agent can invoke together with CLI tools. The Agent decides the workflow, calls deterministic CLI utilities, and validates each step, thus avoiding hallucination.

Key components:

Executable Knowledge Base – rules such as "NVMe sensor depends on I2C channel; add mctp attribute in DTS" are encoded as actionable items.

CLI + Agent collaboration – CLI handles deterministic data extraction and config generation; the Agent interprets requirements, orchestrates tools, and handles exceptions.

Results:

Configuration generation for a new platform takes less than one minute.

Overall labor drops from person‑months to under two person‑weeks.

Systematic verification improves configuration consistency and reduces human error.

The framework demonstrates a correct use of AI in infrastructure: not replacing engineers but scaling their expertise through automated, knowledge‑driven processes.

3. RAS API Standardization

New reliability challenges: In heterogeneous AI clusters, hardware failures become common. Existing vendor‑specific fault‑reporting mechanisms prevent unified diagnostics, making rapid fault isolation and recovery difficult.

Industry need: A unified RAS API layer that abstracts away vendor differences, enabling higher‑level platforms to collect fault data, trigger diagnostics, and execute recovery without bespoke adapters.

Emerging RAS requirements in the XPU era:

Shift from single‑node to cluster‑wide fault impact analysis.

Extend fault detection from CPU‑centric to XPU‑centric models.

Leverage AI for predictive failure based on unified telemetry.

Roadmap:

Standardization first – drive RAS API definition within the OCP community.

Platform support – build a centralized RAS data platform to aggregate fault records.

Intelligent closed‑loop – apply AI for prediction, automatic diagnosis, and smart recovery.

Conclusion & Outlook

The three technical tracks form a logical progression: standardized management (Redfish layer) solves "how to manage"; the Agent framework automates "how to build"; and the RAS API ensures "how to run reliably" at scale. The overarching theme is the combination of standardization (the prerequisite for large‑scale ops) and intelligence (the efficiency lever). ByteDance plans to continue contributing to open‑source standards for XPU management and RAS, and to expand the knowledge base of the Agent framework.