WorldTUI 360M模型训练以模拟终端

摘要

WorldTUI对360M参数的Qwen2.5-Coder模型进行微调，使其充当终端模拟器：每次按键输入模型，模型预测屏幕网格更新。生成的演示完全在浏览器中运行（208MB int4模型），可以创建文件、运行vim、tmux，甚至玩贪吃蛇，同时跨命令记住简单状态。

模型如何表示终端

结论： 终端被编码为字符网格，模型预测逐行增量操作，而不是线性令牌流。

输入以快照令牌块开始，描述屏幕大小、内容和光标位置（例如，BOS SCREEN_START 32 96 …）。
每次按键作为原始字节发送（'l'、\r、ESC [ D等），包裹在INPUT_START/INPUT_END令牌中。
模型在OUTPUT_START/OUTPUT_END内输出一组操作，如ROW_0 17 'l'和CURSOR 0 18 1，指示要覆盖的单元格和最终光标状态。
特殊的WAIT令牌编码经过的时间，实现如贪吃蛇游戏中的自主更新。
词汇表被缩减为333个令牌：256个字节值令牌、64个行标识符和少量控制令牌（例如，COPY、WAIT）。这种紧凑的词汇表使模型能够适应浏览器友好的大小。

使用行复制操作实现高效屏幕更新

结论： 引入COPY操作将滚动和行操作的成本从每行数千个令牌减少到几个令牌。

当终端滚动时，模型不是发出新屏幕的每个字符，而是发出ROW_i COPY j命令，将前一行复制到新位置。
这将典型的3,000令牌全屏重绘减少到每个受影响行大约3个令牌。
相同的机制处理清屏、在vim中插入/删除行以及更新手册页。

训练数据生成

结论： 作者通过记录具有随机环境的真实Docker shell生成了336k个合成终端会话（约2B令牌），确保按键到屏幕的完美对齐。

随机用户名、主机名、提示符和终端尺寸。
反映人物角色（开发人员、系统管理员等）的随机文件系统布局。
加权活动选择（vim编辑、python REPL、tmux等）。
状态跟踪以保持命令真实（例如，打开现有文件）。
类似人类的打字，错误率为1.2%。
35%的会话从应用程序中间开始，以教导模型从任意状态继续。

最终数据集涵盖32×96、24×80和40×120屏幕尺寸。

微调和自我纠正

结论： 添加DAgger风格的自我纠正示例显著提高了内存一致性，将PresetBench得分从24/47提高到38/47（int4）。

在初始监督微调后，模型在记录的会话上运行以收集自己的错误。
对于每个错误，构建一个纠正增量，将模型的屏幕恢复到真实状态，并用作训练示例。
纠正只允许使用已经出现在真实屏幕上的令牌，防止幻觉。
大约三分之一的采样会话产生了有用的纠正；执行了三轮此过程。

训练（包括纠正轮次）在RTX 4090上消耗了约75个GPU小时。

基准测试

结论： WorldTUI在命令输出准确性和简单文件记忆任务上均优于提示基础模型。

模型	ShellBench（106个命令）	文件回读（13个）
Qwen2.5-Coder-0.5B（提示）	52	2
Qwen3-0.6B（提示）	60	3
WorldTUI	80	9

最大的提升在记忆测试中，WorldTUI正确重现了9/13的回读场景，而基础模型为2-3个。

速度优化

结论： 并行行解码和推测性验证将RTX 4090上的大帧延迟从6.7秒降低到0.87秒。

并行行： 每行在批次中独立解码，共享KV缓存，因此解码成本等于最长行（约100步），而不是所有行的总和（约3,000步）。
推测性解码： 并行传递为所有行生成草稿；第二次验证传递使用相同模型检查草稿并纠正第一个不一致，保持一致性（例如，正确的vim窗口放置）。
在Mac M4上，单字符延迟约为60毫秒；完整的man页面顺序需要2.5秒，而并行草稿为0.9秒。

浏览器模型大小缩减

结论： 将嵌入表缩减到333令牌词汇表并进行int4量化，将模型缩小到208MB，实现WebGPU推理。

原始Qwen2.5-Coder-0.5B：494M参数，990MB。
移除未使用的令牌嵌入后：约360M参数，716MB。
Int4量化：208MB下载大小。
推理完全通过自定义WGSL着色器在客户端运行；激活保持32位浮点数。

蒸馏实验

结论： 即使下一个令牌准确性保持较高，移除层也会损害内存一致性，表明内存依赖于特定的深层表示。

仅丢弃第7层几乎不影响令牌准确性（99.3% → 98.9%），但将精确内存回读从64/64减少到0/64。
保留第1、7、15、22层的16层学生模型在内存上匹配教师（64/64），但失去了ShellBench性能（65 vs. 78个正确命令）。
由于这种权衡，进一步的蒸馏尝试被放弃。

展示的能力

结论： WorldTUI可以运行交互式全屏应用程序（vim、tmux、贪吃蛇），并在会话之间保留简单状态，尽管在复杂的文件系统操作上仍会产生幻觉。

内存： 在单独的tmux窗格中创建、编辑和回读的文件大多数时候正确持久化。
Vim： 支持模式切换（Esc）、插入、保存和退出。
Tmux： 处理窗格创建、导航和环境变量扩展。
Python REPL： 接受简单表达式；容忍轻微拼写错误（pythoon启动Python）。
贪吃蛇： 尽管计算密集，但运行流畅。

局限性

结论： 模型缺乏真实的文件系统或外部工具，导致幻觉和偶尔的路径跟踪错误。

Docker容器内没有互联网访问；像lynx这样的工具无法使用。
复杂的文件操作（例如，追加到现有文件）经常产生错误输出。
嵌套目录导航可能丢失当前路径。
Firefox WebGPU性能比Chrome慢约20倍；原因未知。

社区反应（精选评论）

“WorldTUI是探索这个问题的绝佳方式：预测智能输出的模型与智能本身有什么区别？” – OtherShrezzing

“非常酷。有趣的项目。我觉得一旦你理解了对好的现有模型进行微调，就有广阔的领域可以探索” – oilkillsbirds

“我试过了，它不像演示gif那样工作。它告诉我一个文件夹已经存在，但实际上不存在，然后ls之后文件夹不见了。” – donperignon

“下一步是训练一个模型假装成互联网。（你可以在那个终端中运行lynx来训练/测试它，无需图像）” – amelius

“我想知道如果一个小模型有一个用于文件系统的工具调用API、一个嵌入式busybox，以及一个输出令牌用于‘发出busybox在这里会做什么’，它能做多少事情” – Lerc

要点

WorldTUI证明了一个适度的360M参数模型可以在完美对齐的按键-屏幕数据上学习一个连贯、交互式的终端世界。
通过DAgger风格示例进行自我纠正是提高持久内存的关键。
并行行解码和推测性验证对于在消费级GPU和浏览器中实现接近实时延迟至关重要。
未来的工作可以探索更丰富的状态表示（真实文件系统API、工具调用、基于扩散的屏幕更新），以减少幻觉并扩大适用性。

尝试一下： 演示可在https://simedw.com/projects/worldtui获得（208MB下载，推荐Chrome/Edge）。