Oxide 完成 $445M D 轮融资，以扩大企业自有云基础设施

云体验正逐渐成为企业可以在自有设施中购买和运营的产品。Oxide Computer Company 完成了 $445 million D 轮融资，以扩展这一方案：一种将硬件与开源软件相结合的集成计算系统，构成客户拥有的基础设施。

10月9日的公告指出 Eclipse 为领投方，其他已有投资者包括 US Innovative Technology Fund、Riot Ventures 和 Jane Street。新投资者包括 Atreides Management 和 AMD Ventures。Oxide 表示公司在今年早些时候实现了盈利，并将利用这笔资金来确保元件供应并扩大制造规模，因为需求已超出产能。首席执行官 Steve Tuck 说，过去十二个月制造能力增长了二十倍——这是公司报告的产能数据，而非收入增长指标。融资公告 将此项投资定位于扩大交付规模。

为何一家盈利的硬件公司仍需更多资本

当企业必须构建实体系统时，盈利能力与可用于扩张的现金是不同的概念。在 他们的公司配套帖子 中，联合创始人 Bryan Cantrill 和 Steve Tuck 解释说，Oxide 的盈利来源于普通的计算业务，在扣除元件、制造、工资及其他成本后实现。

他们还描述了一个需要大量前期支出的订单积压。他们表示，现有的现金产生和债务融资可以支持完成该积压，但这会使公司在接受新需求和应对供应中断时更加谨慎。此轮股权融资为 Oxide 提供了更多空间，在客户收到系统之前投入制造。

这使得融资故事格外具体。下一个考验是额外的采购能力和生产产能是否能够转化为及时的部署、可靠的支持以及持续的客户采纳。大额融资为此提供了资源，执行情况决定最终结果。

企业自有云的实际含义

Oxide 的购买单位是完整的机架，而非单独挑选的服务器、存储设备、网络设备和虚拟化许可证的集合。其 产品文档 描述了一个集成的控制平面，提供 API、网页门户和用于配置虚拟机、块存储以及虚拟网络的 SDK。

这一区别对构建应用的人员至关重要。拥有实体设备并不意味着每当开发者需要机器时都要提交工单。统一的控制平面可以通过软件提供基础设施，同时组织仍然负责设备的放置位置。

集成同样改变了采购难题。客户评估的是硬件与软件协同运行的系统，而不是自行设计每个接口。他们仍需评估供应商支持、升级路径、设施需求以及随时间更换容量的成本。

深入技术栈：虚拟化、存储与网络

Oxide 的架构比“私有云”标签所暗示的更为具体。其 hypervisor 与存储指南 介绍了 Helios（基于 illumos 的宿主操作系统）和 Propolis（围绕开源 bhyve 虚拟机监视器构建的 Rust 用户态 hypervisor）。客户操作系统使用熟悉的虚拟硬件接口。

存储在整个机架内实现池化。分布式虚拟磁盘在不同计算 sled 的独立物理磁盘上保持三份副本，且存储流量在客户主机与保存副本的主机之间进行加密。其目的在于将弹性设计为平台本身的一部分，而非完全交由各应用团队自行集成的任务。

网络架构 将管理流量与应用网络分离。Oxide 的数据包转换引擎处理路由、防火墙和虚拟机与物理接口之间的地址转换等功能。冗余交换机连接提升可用性，而虚拟私有云结构为工作负载提供逻辑网络边界。

这些机制各有用途。复制用于应对存储故障；加密用于保护流量；网络策略用于控制通信。买家应根据自身需求审视每项功能，而不是把集成机架视为全方位的安全或可用性保证。

AMD 处理器与围绕 GPU 的 AI 工作负载

AMD 的参与具有直接的技术关联。Oxide 的 当前规格 列出了使用 AMD EPYC 9005 处理器的第二代计算 sled，配置可达每 sled 192 个物理核心和 1.5 TiB 内存，并配备两条 100 GbE 网络连接。容量取决于所选配置；物理硬件总量也与客户工作负载可用的资源不同。

对于 AI 团队而言，这些资源解决了模型执行周边基础设施的相当大一部分。Oxide 的 AI 基础设施页面 强调了数据工程、传统机器学习、检索与相似性搜索，以及选定的基于 CPU 的推理工作负载。它还突出显示了与 Spark、Airflow、Ray 和 XGBoost 等工具的兼容性，以及 API 驱动的自动化。

这是一种评估其对代理应用相关性的重要方法。一个不断搜索企业记录、处理文档并调用业务服务的系统，需要数据库、内存、存储以及通用计算资源，同时还可能需要模型加速器。将这些支撑服务靠近企业数据放置，可能会简化某些架构。

这并不意味着 CPU 机架可以取代 GPU 基础设施来完成所有 AI 任务。团队应对其实际模型、检索工作负载、延迟目标和并发度进行基准测试。CPU、加速器和外部服务之间的适当分配取决于具体应用。

Kubernetes 支持值得深入审视

云的熟悉度也取决于周边工具。在一篇 8 月 13 日工程帖子 中，Oxide 介绍了与 Rancher、通过 Omni 的 Talos Linux 以及 Cluster API 的集成，并描述了将 Kubernetes 节点信息与 Oxide 实例连接的云控制器管理器。

该帖子还区分了已交付的功能与正在进行的工作。磁盘热插拔和原生容器存储接口插件在发布时仍在开发中，而其对服务网络的讨论则阐释了可用的负载均衡方案。这些都是已过时的实现细节，买家应核实最新的发布状态，而不是假设存在永久性限制或与托管公共云服务完全等同。

更广泛的教训是，API 驱动的基础设施平台与完全托管的应用生态系统是不同的层级。采购评估应包括存储集成、集群升级、可观测性以及运营责任的划分。

所有权决策仍取决于工作负载

Unite.AI 也报道了 通过托管基础设施实现私有 AI 和云回流。Oxide 提供了一条通往同一讨论的不同路径：直接购买集成系统本身。

对于可预测且持续利用的工作负载，拥有权可以使容量支出更易于规划。计算仍需考虑电力、制冷、人员、支持、融资、备用容量以及更新周期。当需求不确定或需求快速变化时，公共云的弹性仍然具有价值。

Oxide 的 D 轮融资为其企业自有云模型提供了更大的制造跑道。此后最具意义的证据将是运营层面的：交付的系统、成功迁移的工作负载，以及客户发现硬件与软件堆栈随时间满足其需求的情况。