🦉 从破损模型到活体系统：我在没有 GPU 的情况下构建 AI 的旅程

Source: Dev.to

介绍

简要回顾这段旅程，从早期的失误到持续的实验，以及一路上学到的经验教训。

Project #1: Lynqbit — My Favorite Failure

Lynqbit 是我的第一个真正的爱：一个 90 M 参数的模型，雄心勃勃、富有诗意且有点怪异。

• Failure points
  • 系统配置问题
  • 缺乏合适的训练基础设施
  • 没有 GPU 支持迭代

两个月的高强度工作化为乌有，项目崩溃了。虽然很痛，但它让我明白，失败是一个严苛却清晰的老师。

洞察 #1：训练应流畅，而非中断

Lynqbit的死亡引发了一个问题：

如果训练不依赖于单一脆弱的系统会怎样？
如果数据和学习可以流式传输会怎样？

项目 #2：Barn Owl AI — 短命，大教训

Barn Owl AI 探索了流式训练：

• 概念：云托管数据集、基于抽样的训练、持续学习。
• 现实：云数据集在几天后关闭，错误仍未修复，项目失败。

经验教训：损失很小，但洞察力巨大。

Project #3: Elf Owl AI — My First Real Win

Elf Owl AI was a small, chaotic, “alive” model:

• 25 M 参数
• 创造性、幻觉式、可选语法且情绪化的个性

Successes

• 完全训练并开源
• 公开发布（虽不完美，但它存在）

Existence matters.

项目 #4：Xenoglaux AI（Xeno AI）——持续的战斗

我现在正在构建 Xenoglaux AI，以真实的猫头鹰物种命名，并按体型和智力进行规模化。

• GitHub:
• 数据集：75 000+ 手工制作 + 开源条目，专为流式训练设计
• 模块化进化：猫头鹰系列第 2 部分

训练瓶颈

• 在 GPU 上约 15 小时（可接受）
• 在 CPU 上速度极慢
• 在线 TPU 几乎不配合

硬件限制，而非模型或数据，是当前的障碍。

副任务：一个了解你的游戏

在与 Xeno 斗争的过程中，我构建了一个拥有会从玩家学习的 AI 对手的游戏：

1. 第 1 场比赛 – AI 从一个字面块开始。
2. 数据收集 – 玩家移动、位置和决策以 JSON 形式存储。
3. 再训练循环 – 每场比赛结束后，AI 加载上一次检查点，使用新数据再训练，然后重复。

结果（内部测试）

• 20–30 场比赛 → 表现尚可的玩家
• 400–500 场比赛 → 无法击败

这是一种“后天智能”，而非脚本化行为。

我迄今为止的领悟

• 失败不是浪费的工作；它是压缩的知识。
• 小模型仍然可以充满活力。
• 流式 + 增量学习被低估了。
• 硬件对创造力的限制比想法本身更大。

如果你在资源有限的情况下进行构建，你并不孤单。

下一步（实话实说）

1. Xeno 的重命名策略

   • 保持 “Xenoglaux AI” 作为系列名称。
   • 使用模型专属标签，如 Xeno-25M、Xeno-40M、Xeno-Lite，以免混淆。

2. 停止完整重新训练 — 改为增量训练

   • 在小批量（2 k–5 k 样本）上训练。
   • 积极保存检查点。
   • 每天恢复训练，而不是进行 15 小时的马拉松。
   • 思考 “滴灌式学习”，而不是洪流。

3. 充分利用现有资源（CPU + 时间）

   • 使用低精度（如果可能，fp16/int8）。
   • 减少 epoch，增加迭代次数。
   • 使用更小的 batch size 并配合梯度累积。
   • 速度慢 ≠ 不可能；只需要更多自律。

4. 发布游戏 AI 的想法

   • 在线学习、自适应对手、个性化难度曲线。
   • 值得在 Dev.to 上单独写篇文章。

我 15 岁，没有 GPU、实验室或资金——只有一台容易过热的笔记本、源源不断的想法，以及经常“响亮”失败的项目。我学到的不是如何训练 AI，而是当心爱项目夭折时如何站稳脚步。失败是一次重定向，而不是止步标志。小模型也能有活力，未完成的作品依然有价值，每一个限制都能激发创造力。

如果一个没有 GPU 的 15 岁少年还能不断构建、失败、学习，也许我们真正训练的系统不是 AI……而是我们自己。 🦉✨