Qwen模型连跑21天给显卡写推理引擎，性能只有llama.cpp一半

一个AI模型在一张RTX 3090上连续跑了约21天。任务很直白：给这块GPU自己写一个CUDA推理引擎。模型是Qwen 3.8 27B，量化到Q4，KV缓存用Q8，上下文拉到200k。跑起来用的是deepseek harness，外加一份书面规则手册。

规则手册写明了角色分工、交接方式、什么时候该通知人类。还有两条硬约束：不复制llama.cpp的代码，不宣布任务靠单人无法完成。作者本人不写CUDA，他的推动方式就是提示词：“llama.cpp在这张卡上prefill能做到约700 tps，你只有250，再试试。”

运行期间，模型经常连续几天没人盯着，到点就按规则升级。接近第6天时，它已经写了好几个内核，prefill速度还卡在250 tps左右。这个模式后来重复出现过。

最大的问题出在硬件共享上。同一张3090既要跑vLLM托管的代理，又要运行被测的引擎，两边都想占满GPU。错误地杀掉vLLM，所有代理会一起失联；留着它跑基准测试，又可能内存溢出。规则手册要求一套固定的交接脚本。顺序是：停vLLM、跑基准、重启vLLM、轮询健康直到恢复、写入STATE。但有一个子代理把这套流程当成可选项。它反复在窗口外杀vLLM，把编排器搞崩溃，然后再来一次。

还有一个工作线程干掉了托着自己运行的“大脑”。harness也在某个时刻硬崩溃过，作者手动重启。他判断这类问题可以用锁和更严格的协议级规则修，比如只有指定角色能碰vllm.sh。作者还说，这些中断大多是协议问题，不是模型跑偏。协议给的空间再大一点，这套东西也许能一直跑下去。

最终prefill速度大约只有llama.cpp在同一张卡上的一半，没有超过这个基准。不过模型在消费级硬件上连续数周保持了对目标的连贯追求，留下了能用的内核、基准测试、笔记，以及一条很长的git提交历史。Reddit上有人追问引擎发布了没有、是不是比现有方案更好。

代价不低。整个运行消耗了180个子代理、约2.3亿tokens的输入输出、17亿次缓存读取。上下文压缩做了699次，总共约83小时，接近日历时间的17%。典型的一次压缩约7分钟，要处理超过16万token的提示词。

对一个本地量化过的27B模型来说，能坚持这么久，作者觉得已经值了。他用的比喻是：不是优雅的芭蕾舞演员，但熊确实会跳舞。

作者把约15GB的运行转储和规则文件放上了Hugging Face，想复现的人可以直接下载。后端是HyperQwen，由u/iamMess开发。Reddit讨论里，高票评论把自杀循环形容为“可爱”，HyperQwen的作者回了一个爱心表情。

有评论者说，llama.cpp本来就是那张卡上跳了很多年的基准熊，单靠一个代理去击败它很难。但21天的运行值得尊重，压缩吃掉83小时是真的，学习过程可能比内核本身更有价值。也有人建议换一个专门为CUDA内核微调过的qwen3.6模型，那是后来的讨论，运行中没有用到。

还有一个留言的人说，自己的模型已经跑到第二天，正在写一个飞行模拟器加战斗机轰炸任务。验证方式是把输出帧再读回来检查。看测试帧，确实是在做跟飞机有关的事。