引用Sudo su@sudoingX
我现在正在一台 dgx spark 上运行 stepfun 新的 step 3.7 flash。
198b 的视觉模型,跑在一台就摆在桌上的机器上。以下是如何帮你省下大约 3 小时抓耳挠腮的加载时间,因为我已经替你抓过了。
官方 README 告诉你需要 stepfun 自己的 llama.cpp fork。你不需要,主线 ggml-org 就能跑得好好的,视觉功能什么的都行,64k。别花一个小时去构建一个 fork,结果发现不用它模型也能加载。
下面这个才是真正会吃掉你一整晚的:模型占了你约 121gb 统一内存池中的 104gb,而 spark 没有 swap。请求的上下文太大,它不会干净地崩溃,而是会静默地颠簸,内核把模型页换出、再从磁盘反复读回,循环往复,而你只能盯着“loading”发呆。
判断的信号是 read_bytes。如果它涨过 104gb 的模型大小还继续涨,同时进程内存钉在 99% 且日志毫无进展,那就是卡死了。杀掉它,它不会自己恢复。
在 q8 kv cache 上加载视觉投影器时,64k 就是 128gb 机器上的上限,超过它就会在 clip loader 里颠簸,模型加上 KV 加上视觉缓冲区全都在争抢你剩下的那约 17gb。
想要完整的 256k 上下文?去掉视觉,换成 q4 kv cache,这样就能装下,121gb 里用 114gb。这就是他们 README 没有明说的取舍:大上下文是真的,只不过得用 q4 cache,而且仅限文本。
而且它是个推理模型。问它点东西,如果你得到空白回复,不是你把它弄坏了,是你把 max_tokens 设得太低,它把整个预算都花在思考上了。答案就在 reasoning_content 里。给它留点空间。
这就是那 3 小时。确切可用的参数和权重在回复里。