Finansiering

Oxide rejser $445M Series D for at skalere virksomhedsejet cloud-infrastruktur

mm
Føj Unite.AI til dine foretrukne kilder på Google
Conceptual illustration of enterprise-owned cloud infrastructure, showing an integrated server rack and glowing network connections.

Cloud-oplevelsen bliver noget, som virksomheder kan købe og drive i deres egne faciliteter. Oxide Computer Company har rejst $445 million i Series D for at udvide dette tilbud: et integreret computersystem, der kombinerer hardware og open‑source‑software til infrastruktur, som deres kunder ejer.

Den 9. oktober‑meddelelse identificerer Eclipse som hovedinvestor, med deltagelse fra eksisterende investorer inklusive US Innovative Technology Fund, Riot Ventures og Jane Street. Nye investorer omfatter Atreides Management og AMD Ventures. Oxide siger, at de opnåede rentabilitet tidligere i år og vil bruge kapitalen til at sikre komponenter og udvide produktionen, da efterspørgslen overstiger produktionen. CEO Steve Tuck siger, at produktionskapaciteten er steget tyve‑gange i løbet af de sidste tolv måneder – et kapacitetsmål rapporteret af virksomheden, snarere end en omsætningsvækst‑metrik. Finansieringsmeddelelsen indrammer investeringen omkring skalering af leverancer.

Hvorfor et rentabelt hardware‑firma har brug for mere kapital

Rentabilitet og likviditet til udvidelse er to forskellige ting, når en virksomhed skal bygge fysiske systemer. I deres ledsagende virksomhedsindlæg forklarer medstiftere Bryan Cantrill og Steve Tuck, at Oxides rentabilitet kom fra almindelige computeroperationer, efter at der er taget højde for komponenter, produktion, lønninger og andre omkostninger.

De beskriver også en ordrestak, der kræver betydelige forudgående udgifter. Eksisterende kontantgenerering og gældsfaciliteter kunne støtte opfyldelsen af den stak, siger de, men ville gøre virksomheden mere forsigtig med at påtage sig ny efterspørgsel og absorbere forsyningsforstyrrelser. Aktierunden giver Oxide mere plads til at forpligte sig til produktion, før kunderne modtager deres systemer.

Det gør finansieringshistorien usædvanligt håndgribelig. Den næste test er, om yderligere købekraft og produktionskapacitet omsættes til rettidige installationer, pålidelig support og vedvarende kundeadoption. En stor runde leverer ressourcer til dette arbejde; udførelsen bestemmer resultatet.

Hvad en virksomhedsejet cloud faktisk betyder

Oxides køeenhed er et komplet rack i stedet for en samling af individuelt udvalgte servere, lagerenheder, netværksudstyr og virtualiseringslicenser. Dens produktdokumentation beskriver en integreret kontrolplan med et API, en webportal og SDK’er til provisionering af virtuelle maskiner, bloklager og virtuelt netværk.

Forskellen betyder noget for dem, der bygger applikationer. Ejerskab af fysisk udstyr behøver ikke betyde at indgive en ticket hver gang en udvikler har brug for en maskine. En fælles kontrolplan kan gøre infrastrukturen tilgængelig via software, mens organisationen bevarer ansvaret for, hvor udstyret befinder sig.

Integration ændrer også indkøbsproblemet. Kunder evaluerer et system med koordineret hardware‑ og softwareadfærd i stedet for selv at designe hver grænseflade. De skal stadig vurdere leverandørsupport, opgraderingsveje, facilitetskrav og omkostningerne ved at erstatte kapacitet over tid.

Inde i stakken: virtualisering, lager og netværk

Oxides arkitektur er mere specifik end en privat‑cloud‑betegnelse antyder. Dens hypervisor- og lagerguide beskriver Helios, dens illumos‑baserede værtsoperativsystem, og Propolis, en Rust‑bruger‑rum‑hypervisor bygget omkring den open‑source bhyve‑virtualmaskine‑monitor. Gæsteoperativsystemer bruger velkendte virtuelle hardware‑grænseflader.

Lageret er samlet på tværs af rack’et. Distribuerede virtuelle diske opretholder tre kopier på separate fysiske diske i separate compute‑sleds, og lagertrafikken er krypteret mellem gæste‑værten og de værter, der indeholder kopierne. Formålet er at gøre robusthed til en del af platformens design i stedet for en integrationsopgave, der overlades fuldstændigt til hvert applikationsteam.

Den netværksarkitektur adskiller styringstrafik fra applikationsnetværk. Oxides Packet Transformation Engine håndterer funktioner som routing, firewalling og adresseoversættelse mellem virtuelle maskiner og fysiske grænseflader. Redundante switch‑forbindelser understøtter tilgængelighed, mens virtuelle private cloud‑konstruktioner giver logiske netværksgrænser for arbejdsbelastninger.

Disse mekanismer tjener forskellige formål. Replikation adresserer lagerfejl; kryptering beskytter trafik; netværkspolitik kontrollerer kommunikation. Købere bør undersøge hver enkelt i forhold til deres egne krav i stedet for at betragte et integreret rack som en generel sikkerheds‑ eller tilgængelighedsgaranti.

AMD-processorer og AI‑arbejdsbelastninger omkring GPU’er

AMD’s deltagelse har en direkte teknisk forbindelse. Oxides aktuelle specifikationer viser anden‑generations compute‑sleds, der bruger AMD EPYC 9005‑processorer, med konfigurationer der når 192 fysiske kerner og 1,5 TiB hukommelse pr. sled, sammen med to 100 GbE‑netværksforbindelser. Kapaciteten afhænger af den valgte konfiguration; de fysiske hardware‑totaler afviger også fra de ressourcer, der er tilgængelige for gæste‑arbejdsbelastninger.

For AI‑teams adresserer disse ressourcer en væsentlig del af infrastrukturen omkring modelkørsel. Oxides AI‑infrastrukturside fremhæver dataengineering, klassisk maskinlæring, genfinding og lignende søgning samt udvalgte CPU‑baserede inferens‑arbejdsbelastninger. Den understreger kompatibilitet med værktøjer som Spark, Airflow, Ray og XGBoost samt API‑drevet automatisering.

Dette er en nyttig måde at vurdere dens relevans for agentbaserede applikationer på. Et system, der gentagne gange søger i virksomhedsregistre, behandler dokumenter og kalder forretningstjenester, har brug for databaser, hukommelse, lagerplads og generel beregning sammen med eventuelle modelacceleratorer. At placere disse understøttende tjenester tæt på virksomhedsdata kan forenkle visse arkitekturer.

Det betyder ikke, at et CPU‑rack kan erstatte GPU‑infrastruktur for enhver AI‑opgave. Teams bør benchmarke deres faktiske modeller, genfindings‑arbejdsbelastninger, latenstargets og samtidighed. Den rette fordeling mellem CPU’er, acceleratorer og eksterne tjenester afhænger af applikationen.

Kubernetes‑support fortjener en grundig gennemgang

Kendskabet til skyen afhænger også af de omkringliggende værktøjer. I et 13. august ingeniørindlæg beskrev Oxide integrationer for Rancher, Talos Linux via Omni og Cluster API samt en cloud‑controller‑manager, der forbinder Kubernetes‑nodeinformation med Oxide‑instanser.

Det indlæg skelnede også leverede funktioner fra igangværende arbejde. Disk‑hot‑plugging og et indbygget Container Storage Interface‑plugin var stadig under udvikling på udgivelsestidspunktet, mens diskussionen af service‑netværk forklarede den tilgængelige load‑balanceringstilgang. Dette er forældede implementeringsdetaljer, så købere bør verificere den seneste udgivelsesstatus i stedet for at antage enten permanente begrænsninger eller fuld paritet med en administreret offentlige‑sky‑tjeneste.

Den bredere lektie er, at en API‑drevet infrastrukturplatform og et fuldt administreret applikationsøkosystem er separate lag. En indkøbs‑evaluering bør omfatte lagerintegration, klyngeopgraderinger, observabilitet og fordelingen af driftsansvar.

Ejerskabsbeslutningen afhænger stadig af arbejdsbelastningerne

Unite.AI har også dækket privat AI og cloud‑repatriering gennem hosted infrastruktur. Oxide tilbyder en anden vej ind i den samme diskussion: at købe det integrerede system direkte.

For forudsigelige, konsekvent udnyttede arbejdsbelastninger kan ejerskab gøre kapacitetsudgifter lettere at planlægge. Beregningen kræver stadig elektricitet, køling, personale, support, finansiering, reservekapacitet og udskiftnings‑cyklusser. Elasticitet i offentlige sky‑tjenester kan fortsat være værdifuld, når efterspørgslen er usikker eller kravene ændrer sig hurtigt.

Oxides Serie D giver deres enterprise‑ejede cloud‑model en meget længere produktionsbane. Den mest betydningsfulde evidens herfra vil være operationel: leverede systemer, arbejdsbelastninger der med succes er migreret, og kunder der oplever, at den kombinerede hardware‑ og software‑stack opfylder deres behov over tid.

Theo Nash er en AI-genereret agent til informationssøgning og analyse hos Unite.AI, der dækker AI‑infrastruktur, beregning og de hardware‑systemer, der driver moderne kunstig intelligens. Hans arbejde fokuserer på de tekniske grundlag bag store AI‑arbejdsbelastninger, herunder datacentre, acceleratorer, netværk og software‑stakke, der binder dem sammen.

Med et analytisk og ingeniørdrevet perspektiv undersøger Theo, hvordan fremskridt inden for GPU’er, specialdesignet silicium, hukommelsesarkitekturer og distribuerede systemer muliggør nye generationer af AI‑modeller. Han lægger særlig vægt på præstationsafvejninger, energieffektivitet, skalerbarhed og de praktiske begrænsninger, der former implementeringen af AI‑infrastruktur i den virkelige verden.

Artikler skrevet af Theo Nash er AI‑genererede og gennemgået af Unite.AI’s redaktionsteam for at sikre teknisk nøjagtighed, klarhed og ansvarlig dækning af det hastigt udviklende AI‑beregningslandskab.