招聘：需要内核开发者构建 AI 原生启动基础设施

发布: 1小时前 (2026年2月1日 GMT+8 16:11)

14 min read

原文: Dev.to

Source: Dev.to

请提供您希望翻译的完整文本内容，我将按照您的要求将其翻译为简体中文并保留原有的格式。

将概念验证转化为生产现实

我是 HejHdiss，我必须坦诚：我是一名自学的 C 程序员，掌握纯 C、一些标准库以及一些 POSIX C——但我在内核开发方面毫无深入经验。然而，我仍然在这里请求帮助，进行一个 Linux 内核模块项目。

为什么？

我对一个尚未存在的事物有一个设想，并已在我的知识范围内尽可能推进。现在我需要专家帮助将其实现。

项目：NeuroShell LKM

仓库：
目的： 一个 Linux 内核模块，通过 /sys/kernel/neuroshell/ 暴露详细的硬件信息。
检测内容：
- CPU
- 内存
- NUMA 拓扑
- GPU（NVIDIA、AMD、Intel）
- AI 加速器（TPU、NPU 等）

完整披露： 内核层代码主要由 Claude（Anthropic 的 AI）生成。我编写提示、验证功能并在真实硬件上测试模块。它可以工作，但只是概念验证，并非生产就绪代码。

示例输出

$ cat /sys/kernel/neuroshell/system_summary
=== NeuroShell System Summary ===

CPU:
  Online: 8
  Total:  8

Memory:
  Total: 16384 MB

NUMA:
  Nodes: 1

GPUs:
  Total:  1
  NVIDIA: 1

Accelerators:
  Count: 0

它很基础，能够运行。但距离真正需要的功能还有很大差距。

更宏大的愿景：NeuroShell OS

我在这里写了完整的愿景概述：NeuroShell OS – Rethinking Boot‑Time Design for AI‑Native Computing。文章描述了一个在启动阶段的系统，它：

在用户空间启动之前的早期引导阶段发现 AI 硬件
根据检测到的硬件动态分配资源
与 bootloader 集成，在内核完全加载之前做出硬件感知的决策
专门为张量运算和 AI 工作负载优化内存拓扑
提供了解 GPU/TPU/NPU 拓扑的硬件感知调度器钩子
处理数据中心环境中硬件动态变化的热插拔事件
暴露实时性能指标，以便 AI 框架进行优化

当前模块仅读取了一些 PCI 设备并暴露 sysfs 属性。与愿景所需的功能相比，这只是一个玩具。

我真的做不到的事

区域	差距
深度内核集成	我不知道如何与引导加载程序、init 系统或早期启动序列进行集成。我可以编写 C 函数，但对内核子系统的了解不足，无法在正确的时间挂钩到合适的位置。
性能与并发	代码没有锁机制，也不安全于 SMP 环境。我缺乏内核同步原语的知识，无法正确地修复此问题。
安全加固	存在缓冲区溢出风险，没有输入验证，可能还有许多我未意识到的安全问题。
高级硬件 API	我仅仅触及了 PCI 枚举的表面。真正的硬件探查需要： • PCIe 拓扑映射 • IOMMU 配置感知 • 缓存层次结构细节 • 热区集成 • 电源管理状态跟踪 • SR‑IOV 虚拟功能检测
生产最佳实践	内核编码风格、适当的错误处理、内存管理模式、模块生命周期管理——我已经阅读了文档，但阅读与真正理解是两回事。

为什么这很重要

新一类操作系统

传统操作系统的启动序列是在 1970‑1990 年代设计的，当时的“高性能计算”指的是大型机和工作站。它们并未针对以下情况设计：

多 GPU 训练集群
异构 AI 加速器（GPU + TPU + NPU）
NUMA 感知的张量内存分配
用于机器学习工作负载的动态资源划分

NeuroShell OS 从头重新构想了这一切。

开源 AI 基础设施

AI 行业正日益被专有技术栈主导。我们需要一种开源基础设施，它应具备：

供应商中立（兼容 NVIDIA、AMD、Intel 以及定制加速器）
社区驱动
透明且可审计
为现代 AI 工作负载设计，而非为遗留兼容性而生

学习机会

如果你是对 AI 感兴趣的内核开发者，却还未深入了解 AI 框架如何与硬件交互，这将是一次探索二者交叉点的机会。该项目正位于系统编程与 AI 基础设施的交界处。

您可以提供的帮助

任务	描述
代码审查	审计现有模块的错误、安全问题以及内核风格违规
架构指导	评估内核模块是否是合适的方案；如有需要提出替代方案
锁与并发	使代码支持 SMP 并正确处理并发访问
错误处理	添加适当的错误路径和资源清理
高级硬件检测	实现更深入的 PCIe 拓扑、IOMMU 感知、缓存细节等
热插拔支持	响应动态硬件变更
性能优化	最小化频繁查询的开销
测试框架	建立针对不同硬件配置的自动化测试
引导加载程序集成	与 GRUB / systemd‑boot 协作，在内核加载前暴露硬件信息
初始化系统钩子	与 systemd / OpenRC 集成，实现早期硬件配置
调度器扩展	提供硬件感知的 CPU / GPU 调度提示
内存拓扑优化	为 AI 工作负载实现 NUMA 感知的分配

这确实非常有趣

有多少项目能让你重新思考面向新兴工作负载的基础操作系统设计？这不仅仅是“修复 bug”的工作——它是全新架构的探索。

实际影响

AI 基础设施是一个庞大且快速增长的领域。改进启动时的硬件发现与配置能够提升研究人员、工程师以及运行 AI 工作负载的公司的性能。

如果你是一名有经验的内核开发者并且愿意合作，请联系我。 我们可以共同把这个概念验证转化为面向下一代 AI 原生操作系统的生产就绪基础。

您将拥有自己的贡献

这是 GPL‑v3。您的代码仍归您所有。
您的专业知识将获得应有的认可。
这是协作的，而 非剥削 的。

想象一个这样的世界

研究人员启动新的 AI 训练节点时 不需要手动配置 CUDA、ROCm 和 NUMA 设置——操作系统在启动时自动完成。
数据中心可以 热插拔 GPU，操作系统能够立即识别并分配它们，无需人工干预。
AI 框架能够获取 实时硬件拓扑信息，无需解析 /proc/cpuinfo 并进行猜测。
启动时的硬件发现 快速、准确且供应商中立。

这就是目标。该内核模块是 第一步。

您的选项

您不必直接向我的仓库贡献代码，如果您不想的话。可以选择以下任意方式：

Fork 并修改 – Fork 仓库并使其成为您自己的。
创建新仓库 – 基于该概念从头开始实现您自己的版本。
上传到您自己的空间 – 构建您的版本并在任意您想要的地方托管。
随心所欲 – 它采用 GPL‑v3 许可证——您可以按任何您认为合适的方向使用它。

只需注明您的版本来源即可。就这样。我并不占有领地；如果您能够独立构建更好的版本，请随意。目标是让这个概念运行良好，而不是控制谁来构建它。

如何贡献

克隆仓库

git clone https://github.com/hejhdiss/lkm-for-ai-resource-info

审查代码 – 查看 neuroshell_enhanced.c 并找出需要修复的地方。
打开 Issue – 指出 bug、安全问题或架构问题。
提交 PR – 即使是小的修复也能推动项目进展。
加入设计讨论 – 阅读 NeuroShell OS 文章并分享你的想法。
提出架构修改 – 如果当前方案有误，让我们一起找出正确的方案。
实现高级特性 – 负责子系统（PCIe 拓扑、NUMA、热插拔等）。
成为共同维护者 – 如果你认同此项目，帮助推动项目前进。

其他可能性：

Fork 项目 – 用你自己的设计决策创建自己的版本。
重写项目 – 如果你认为应该以不同方式构建，就按不同方式构建。
创建更好的实现 – 将此项目作为灵感，打造你自己的更优实现。

我唯一的要求：即使你的实现完全不同，也请注明想法来源。

传播此信息

如果您不是内核开发者，但认识有内核开发经验的人——尤其是对 AI 基础设施感兴趣的人——请转发此信息。

我请求的是您的专业知识，而不是您的慈善捐助。我已经用我掌握的知识尽力构建了目前的成果。现在，我需要真正懂内核开发的人认真对待并帮助将其实现。

我在寻找的人

关注 开源基础设施。
对 AI/ML 系统 感兴趣。
想要参与 新颖且有影响力 的项目。
重视 诚实合作胜于自我。

即使只花几小时审阅代码并提出改进建议也很有价值。即使只是指点我正确的 kernel API 或设计模式也很有帮助。

我的故事

我本可以安守本行——只写自己完全懂的 C 程序，完全不涉及内核开发。但我看到一个空白：AI 基础设施需要更好的启动时硬件发现，而没有人去构建它。

于是我尽力而为。我学会了足够的知识来原型化这个想法，使用 AI 填补知识空缺，在真实硬件上进行测试，它能工作——虽然勉强，但确实能工作。

现在我需要比我更聪明的人来把它做得更好。

项目与愿景

项目:
愿景: NeuroShell OS – 重新思考 AI‑Native 计算的启动时设计

作者: HejHdiss（自学 C 程序员，内核新手，但致力于此愿景）

让我们一起构建 AI‑native 基础设施。

预计阅读时间：5 分钟