熊也能跳舞：在单个3090上运行Qwen 3.8 27B三周

太长不读：本地代理循环，约21天，一个RTX 3090。任务基本上是“为自己在此GPU架构上构建优化的CUDA推理引擎”。得到了可用的内核和基准测试，但没有超越llama.cpp。约12条人类消息。压缩耗时约83小时。老笑话：你不会批评熊跳舞跳得多好，你会惊讶它竟然会跳舞。设置：Qwen 3.8 27B Q4，Q8 KV，200k上下文，deepseek工具，书面规则书：角色、交接、何时联系我、不要复制llama.cpp、不要单独宣布任务不可能。我不写CUDA。提示基本上是“llama.cpp在此卡上做约700预填充，你在约250，更努力些。”运行：连续几天不受监督，然后根据规则升级。接近第6天时，它有几个内核，预填充卡在约250令牌/秒；后来模式相同。停止主要是协议问题，不是模型偏离。一个更强大的协议可能能无限期地持续下去。自杀循环：同一个3090必须托管代理（vLLM）并运行测试中的引擎。两者都想占用整个GPU。错误杀死vLLM会导致所有代理消失，在基准测试期间保留它会导致内存溢出。规则书要求一个固定的交接脚本：停止vLLM，基准测试，启动vLLM，轮询健康状态直到恢复，写入STATE。一个子工作者将其视为可选，在窗口外杀死vLLM，崩溃了编排器，然后又做了一次。一个工作者关闭了运行它的大脑。工具也曾硬崩溃一次；我手动重启了它。可以通过锁和“只有此角色可以接触vllm.sh”的协议级改进来修复。本地成本：180个子代理，约2.3亿令牌输入输出，约17亿缓存读取。699次压缩，约83小时在其中（约占日历时间的17%）。典型压缩在约160k+令牌提示上约7分钟。预填充达到同一张卡上llama.cpp的一半左右。尽管如此：在消费级硬件上进行数周的连贯目标跟踪，留下了可用的内核、基准测试、笔记和长长的git历史。对于一个本地（量化！）的27B能保持真实的工程目标这么长时间，我接受它。不是优雅的芭蕾舞者，但该死，这只熊能跳舞！转储+规则（约15 GB）：https://huggingface.co/datasets/skeole/qwen-cpp-agent-0-protocol 后端：https://github.com/syv-ai/HyperQwen（由u/iamMess完成的惊人工作）