重温初代Steam Machine：硬件不是失败主因，软件才是

十二年前，Valve联手Alienware推出了首批Steam Machine，试图用一台小巧的客厅游戏主机撬动PC游戏市场。它们最终折戟沉沙。Craft Computing的Jeff近期同时拿到两台初代设备——Alienware Alpha R1与R2，并在2026年的今天重新审视这段历史。他的结论很明确：初代Steam Machine的失败从来不是硬件问题，而是软件生态与游戏库的缺失。

两代Alpha的硬件底细

Alienware Alpha R1于2014年12月上市，即便在当时也算不上发烧友的菜。它搭载第四代Haswell处理器，从双核i3-4310T到八线程i7-4765T不等，全部采用后缀为T的低功耗版本，峰值仅35W，远低于同期70-90W的常规水平。Valve从第一代产品就押注：CPU并非游戏PC性能的决定性因素，低功耗加上一块够用的GPU才是关键——这套逻辑与如今的新款Steam Machine如出一辙。

R1配备4或8GB DDR3内存（最高可扩展至16GB），显卡为带2GB GDDR5的英伟达GTX 860M，目标是在720p或1080p下以中高画质运行大多数游戏。存储方面，2014年SSD尚未普及，它出厂配的是一块500GB 7200转笔记本硬盘。

两年后的R2带来实质升级：跳到第六代Intel CPU（顶配为四核八线程的i7-6700T，睿频最高3.6GHz），内存升级到DDR4并提供出厂16GB选项，显卡换成带4GB显存的GTX 960M。R2还新增了M.2 NVMe插槽，让SteamOS明显更流畅，同时保留2.5英寸硬盘位——评测机内实际同时装有256GB M.2和1TB机械盘。

R2背后还有个用于外接显卡的接口，但别抱太大期望——它用的是Alienware专有的Graphics Amplifier接口，而非标准连接。两代机器都有一个贴心设计：后部有个下拉式隐藏USB口，专门用来插Steam Controller的接收器，作为客厅主机使用时非常实用。

失败的真正原因：SteamOS生的太早

既然R1和R2都提供了不错的性能、低功耗、小体积和好看的外观，完全能胜任客厅游戏主机的角色，为什么最终会失败？答案要回到2013年SteamOS诞生的背景。

当时微软威胁要让Windows 8的所有应用必须经过微软商店分发，把Windows变成一个封闭花园，封锁第三方应用商店。这直接威胁到Valve卖游戏的核心业务，于是Valve决定自己造操作系统，SteamOS由此而来。

但初代SteamOS与今天判若两物。它没有任何兼容层工具，没有Proton；即便你手动跑起Wine，也几乎只能勉强启动Windows纸牌。不能运行Windows就意味着当时Steam商店里几乎整个游戏库都无法使用。GTA5、巫师3、辐射4、毁灭战士、守望先锋、泰坦陨落——这些本可以在这套硬件上运行得很好的中期名作，没有一款真正在Linux或SteamOS上可玩。

Valve确实花了大力气把自家游戏（传送门、CS、求生之路等）从DirectX移植到OpenGL，让它们在Linux上原生运行。但没有第三方3A支持，SteamOS的游戏库根本不足以说服任何玩家跳进Linux或购买这套硬件。

Proton是Valve基于Wine和DXVK开发的兼容层工具，于2018年正式集成进Steam客户端，允许在Linux上直接运行绝大多数为Windows开发的游戏。其核心原理是将DirectX API调用实时翻译为Vulkan指令，再由Linux驱动执行，性能损耗通常在5%至15%之间，部分场景下甚至与原生Windows版本持平。Wine本身已有三十余年历史，但长期以来只能运行简单程序；DXVK的加入以及Valve大量工程投入才让复杂3A游戏也能正常运行。2018年之前的SteamOS完全没有这套机制，游戏是否可玩完全取决于开发商是否愿意专门移植Linux版本，而愿意这样做的主要是Valve自己和少数独立游戏工作室，这直接决定了初代Steam Machine注定面对一个几乎空洞的游戏库。

2026年的讽刺：SteamOS已装不进初代Steam Machine

如今的格局完全不同。2019年曝光Valve一直在暗中支持Wine和DXVK开发，随后推出集成在Steam内的Proton兼容工具。正是这些积累促成了Steam Deck的成功，也让Linux成为真正可日常使用的游戏平台。

讽刺的是，2022年随Steam Deck发布的SteamOS 3.0是彻底重建的系统，围绕AMD显卡设计，完全不支持英伟达GPU。即便最新beta加入了英伟达支持，也只针对现代显卡，而非这些十多年前的Maxwell移动芯片。

Jeff尝试为R1下载归档的官方恢复镜像，但因系统默认关闭user namespaces而无法启动Steam客户端。由于SteamOS是不可变系统（immutable OS），且Steam客户端与Big Picture模式本身就是桌面环境，根本无从手动修改该设置。系统内Steam和Desktop两个默认用户都不在sudoer列表中，即便他最终拿到了root权限也无法启用该功能。原版SteamOS在这套老硬件上基本已经死亡。

所幸Bazite提供了支持传统英伟达GPU（包括Maxwell系列）的安装器，装上后R1和R2都能流畅运行接近现代SteamOS的体验。

不可变操作系统（Immutable OS）是一种系统分区在运行时处于只读状态的设计范式，用户无法直接修改系统文件，更新通过原子化的镜像替换完成，从而保证系统稳定性与可复现性。SteamOS 3.0、Fedora Silverblue、NixOS等均采用这一思路。其好处是几乎不可能因误操作或依赖冲突损坏系统，代价是传统Linux「sudo修改配置文件」的排错方式完全失效。Bazite是基于Fedora Atomic（不可变系列）构建的面向游戏的发行版，预装了Proton、驱动和Steam，并额外维护了对老旧英伟达Maxwell、Kepler等架构的驱动支持，成为让这类老设备重焕生机的主要民间方案。

性能实测：连N100路由器盒子都打不过

这两台机器今天的性能不会让人惊艳，但也并非毫无价值。Jeff用Cinebench R15做了对比，结果不太好看。

R1（四核i5-4590T）多线程仅360分，单线程106分。作为参照，一颗6W的Intel N100多线程能跑393分、单线程126分——也就是说，亚马逊上不到200美元的小型路由器盒子算力都超过初代Steam Machine。R2明显更强，i7-6700T多线程688分、单线程132分，至少还能在2010年代中期CPU的讨论里占一席之地。

真正拖后腿的是GPU。GTX 860M和960M都基于Maxwell架构的GM107核心——正是那颗名震一时的GTX 750Ti所用芯片。Unigine Heaven测试中R2平均64帧，R1只有43帧，快了近50%。《无主之地2》1080p高画质下，R1勉强触及平均60帧但低帧掉到十几，R2则稳在80帧左右、最低也有三十多帧。R2跑《GTA5》在1080p高画质下也能保持平均60帧，只是4GB显存在进入城市繁忙区域时偶尔爆显存导致卡顿，稍作调校应可解决。

Maxwell是英伟达于2014至2016年间使用的GPU微架构，以极高的能效比著称。桌面旗舰GTX 750 Ti与文中GTX 860M/960M均基于其入门核心GM107，该核心拥有512个CUDA核心。Maxwell在同瓦特性能上远超上一代Kepler，但在绝对算力上已大幅落后于后续的Pascal（GTX 10系）乃至Turing（RTX 20系）。英伟达对老旧移动Maxwell的驱动维护已于2019年前后进入「传统驱动」阶段，新功能与安全补丁不再跟进，这也是SteamOS 3.0官方放弃支持的重要原因之一——维护一个小众且老旧的驱动路径对Valve而言得不偿失。

走过的路，让Steam Deck得以奔跑

回看Valve第一次做专属游戏硬件的尝试，R1在2010年代下半段明显性能不足，R2则大约能提供四五年的良好游戏体验。但两者的致命伤从来不是硬件，而是软件支持和兼容游戏库的匮乏——这正是Valve十多年来通过Proton等工具持续解决的问题。

Jeff在2018年首次评测SteamOS时，那更像是一场追悼会：他当时约500款游戏中只有120款兼容Linux，且大多是独立游戏。他当年的结语颇具预见性——SteamOS命悬一线，但如果微软继续激进更新、糟糕的驱动管理、开始菜单塞广告和窃取数据，SteamOS或许还有一线生机。八年后，Windows的问题非但没变，还多了Copilot和Recall这类侵犯隐私的功能。而Linux在Steam客户端中的占比已从八年前的0.28%涨到今天的4%以上。

初代Steam Machine在多方面都是彻底的失败，但它们的存在让Steam Deck和今天的新Steam Machine得以诞生，更广义地推动了Linux游戏生态的繁荣。如果你手头还有一台老Alpha，它仍是不错的模拟器机器，适合玩2005至2020年间的游戏。但Jeff并不建议今天为二手市场上超过300美元的价格入手一台——想抛弃Windows，你几乎可以在任何现有PC上装Linux，他推荐Bazite或CachyOS，能获得SteamOS积累十年的全部兼容特性。