deepseek-ocr SAM ggml_conv_2d with the im2col kept in F32 - #26727
Conversation
github-actions
Bot
added
the
mtmd
| } | ||
|
|
||
| // ggml_conv_2d with the im2col kept in F32: the F16 im2col it emits since #23660 degrades OCR | ||
| static ggml_tensor * conv_2d_f32(ggml_context * ctx0, ggml_tensor * a, ggml_tensor * b, |
There was a problem hiding this comment.
if we simply cast the kernel to F32 and run ggml_conv_2d, does it work?
There was a problem hiding this comment.
No — the kernels are already F32, and ggml_conv_2d applies an F16 im2col on F32 kernels:
a->type == GGML_TYPE_BF16 ? GGML_TYPE_F32 : GGML_TYPE_F16
That F32-kernel + F16-im2col combination is exactly the regression this PR fixes.
Casting the kernels to BF16 would work; BF16 results in an F32 im2col, and for these weights the cast is lossless (HF ships them BF16; the converter upcasts to F32).
But it is a hack that would rely on the side-effect of a->type == GGML_TYPE_BF16 ? GGML_TYPE_F32 : GGML_TYPE_F16.
It will also cost either a cast node in the graph or a converter change.
But a converter change only helps newly converted GGUF files; every already-published mmproj keeps F32 kernels, so the model code has to handle them either way.
2 participants
Description
Since #23660, ggml_conv_2d emits an F16 im2col for all non-F16 conv kernels. The SAM convs in DeepSeek-OCR run F32 weights, and the F16 im2col measurably degrades their OCR quality on CUDA. This PR keeps the im2col of these convs in F32, in the model code. On Metal the output is unchanged.
DeepSeek-OCR eval on CUDA (DGX Spark), single-view scan, this branch vs master:
Requirements