gekro
GitHub LinkedIn
Infrastructure

Linux 优势:为什么 AI 在内核里呼吸更顺畅

阅读约 8 分钟

本文是英文原文的机器翻译,部分细节可能有所损失,请以英文版本为准。 阅读英文原文

要点速览

为什么我不再与 Windows 注册表错误纠缠,并把整个 AI 工程实验室迁到了 WSL2 和 Ubuntu Server。
Windows 对人类来说是个很棒的操作系统,但对智能体而言是个令人窒息的环境。我把 Gekro 迁到了 WSL2/Ubuntu 内核上,因为 AI 库期待一颗符合 POSIX 的心脏。本文拆解 CUDA 直通的配置方式,以及为什么在 Linux 上运行 Docker 是管理日益增多的自主服务的唯一办法。

如果你在消费级操作系统上搭建 AI 实验室,你就是在两条战线上作战:你的代码和你的操作系统。在 AI 时代,Linux 是智能的母语。我花了六个月,试图让复杂的 Python 依赖与 Windows 路径和 DLL 和平共处,最后才接受了现实:既然模型权重是在 Linux 集群上训练出来的,推理也就该在 Linux 内核上进行。从我在 DFW 全面转向无界面的 Ubuntu 工作流的那一刻起,那些与操作系统而非代码有关的调试几乎完全消失了。

真正让我下定决心的,是看着 AI 生成的 PowerShell 失败、重试、再失败,并在这个过程中烧掉 token。不是一次,而是一种模式。这种事今天仍在发生,这也是我放弃用 PowerShell 做智能体工作,而不是想办法修好它的原因。

架构

我实验室里的“Edge”指的是对硬件的直接、无中间层的访问。Windows 会在你的代码和 GPU 之间添加一层“Desktop Window Manager”(DWM)的噪声。Linux 则提供硬件直通,感觉就像裸机一样。

特性Windows(原生)WSL2 (Ubuntu 22.04+)Ubuntu Server(裸机)
GPU 访问DirectX / CUDA(笨重)CUDA 直通(近乎原生)直接 CUDA(最快)
I/O 性能快 (NTFS)快(位于 VHDX 内)极致 (ext4/zfs)
Docker 引擎Hyper-V 虚拟机(慢)WSL2 后端(高效)原生 Cgroups(瞬时)
稳定性自动更新(有风险)由用户管理99.9% 在线率

在我的实验室里,我把 WSL2 当作“操作员控制台”,把 Raspberry Pi 集群上的 Ubuntu Server 当作“生产 Edge”。

搭建

搭建高速 AI 环境需要的不只是 apt install。你得在 Windows 硬件和 Linux 逻辑之间架起桥梁。

1. 在 WSL2 中启用 CUDA

基于 Windows 的实验室的“秘制酱料”是 NVIDIA 的 WSL 驱动。它能让 Linux 内核“看到”你 PC 上的 GPU,而无需完整虚拟机的开销。

# Verify GPU visibility inside WSL2
nvidia-smi

# If you see your GPU here, you're ready for local LLMs
# If not, you need to install the 'NVIDIA Game Ready' or 'Studio' driver on the Windows host.

2. Docker-AI 栈

我从不在宿主机上安装 pip 包。每个模型我都用 Docker 容器。这样能避免“依赖地狱”,比如一个智能体需要 Python 3.10,另一个需要 3.12。

本地 Gekro 节点的 docker-compose.yml:

services:
  ollama:
    image: ollama/ollama
    volumes:
      - ./ollama_data:/root/.ollama
    ports:
      - "11434:11434"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

  summarizer-agent:
    build: ./agents/summarizer
    environment:
      - OLLAMA_HOST=http://ollama:11434
    depends_on:
      - ollama

3. WSL2 说明:内存管理

默认情况下,WSL2 会试图吃光你所有的 Windows 内存。我把它限制在 16GB,这样我在 Windows 里的 Tesla 遥测脚本就不会崩溃。在你的用户文件夹里创建一个 .wslconfig:

[wsl2]
memory=16GB
processors=8

取舍

来谈谈痛点:符号链接和文件性能。如果你把代码放在 Windows 的 C: 盘,却想在 WSL2 里运行,由于 9P 协议的转换,它会慢 10 倍。我曾因为纳闷向量数据库为什么慢得像爬,白白损失了一周的生产力,后来才意识到必须把整个项目文件夹移到 Linux 文件系统内部(/home/rohit/gkro)。

我怀念的是互操作性。在 Windows 上,我可以让更新在屏幕的一侧慢慢跑,同时在另一侧工作,或者让一个生成任务一直运行,自己去做别的事。这在很大程度上已经没有了,而我还没找到一个干净的替代办法。

迁移本身比我预想的要平缓。我原本做好了新系统会把我摔懵的准备,结果大多数时候并没有。比其他任何事情都耗时得多的是文件同步:让 OneDrive 乖乖听话,以及把文件可靠地送到 Raspberry Pi 上。我至今仍怀念的是肌肉记忆。二十年的 Windows 命令没了,而在 Linux 里用得顺手并不能把它们换回来。

另外,VRAM 是有限的资源。如果我在 Windows 里开着 50 个标签页的 Chrome,它就在抢我 WSL2 里 Llama 3 实例的 VRAM。在混合环境里,你得学会做一个对内存毫不留情的拾荒者。

接下来

我正在向统一视图管理层迈进:用 Astro 做的定制仪表盘,实时监控我所有 Linux 节点(Pi 和 PC)的 CPU/GPU 温度和内存使用情况。目标是把我的家庭网络当作一个迷你 AWS 区域,操作系统只是个细节,智能体才是一等公民。

Rohit Burani

作者

Rohit Burani

AI 工程师,在实验室里构建本地优先系统、自托管基础设施和自主工具。

感谢阅读。

如果这篇文章对你有帮助,欢迎分享给你的圈子。

← 返回博客