cuda: restrict out_prod support to f32 inputs

[GuthL]

Summary

This narrows CUDA backend support for GGML_OP_OUT_PROD so the op is only offloaded when both sources are actually F32.

case GGML_OP_OUT_PROD:
    {
        const ggml_tensor * src0 = op->src[0];
        const ggml_tensor * src1 = op->src[1];
        return op->type == GGML_TYPE_F32 &&
            src0 != nullptr && src1 != nullptr &&
            src0->type == GGML_TYPE_F32 &&
            src1->type == GGML_TYPE_F32;
    } break;

Why

ggml_backend_cuda_device_supports_op() currently advertises CUDA support for GGML_OP_OUT_PROD whenever op->type == GGML_TYPE_F32.

That is broader than what the current CUDA out_prod path safely handles. In BitNet LoRA training, mixed-type out_prod nodes can be scheduled onto CUDA even though the CUDA implementation is not robust for those source types.

I hit this while training Bitnet_B1_58 Xl with llama-finetune-lora on an RTX A6000.

Reproduction / failure mode

With the current code, the run consistently reached:

• Training split: datapoints=32055, batches_per_epoch=30452
• Starting epoch 0 (step 0, lr=...)

and then died inside CUDA out_prod with:

** On entry to SGEMM parameter number 8 had an illegal value
CUDA error: an unsupported value or parameter was passed to the function
... ggml_cuda_out_prod ... out-prod.cu:113

Validation

After applying this support-guard fix locally, the same BitNet training path no longer crashed at the previous out_prod boundary.

A smoke run on the same machine got past:

• Loaded 5550 conversations
• Training split: datapoints=5550, batches_per_epoch=5272
• Starting epoch 0 (step 0, lr=...)
• Checkpointing enabled, saving every 500 steps

with llama-finetune-lora still alive after the old crash point.

Notes

• This aligns the support gate with what the CUDA backend is actually handling safely today.
• If mixed-type CUDA out_prod is intended longer term, I think the support check should stay narrow until that implementation is complete.
• I intended to open a matching issue first, but issues are disabled on this repository, so I’m putting the full report in the PR body.

[GuthL]

I pushed an updated fix on this branch.

The original change narrowed GGML_OP_OUT_PROD support to stop the immediate CUDA crash, but that was only a minimal guard. The current version keeps CUDA support for mixed input types and converts non-f32 inputs to temporary f32 buffers inside ggml_cuda_out_prod, which matches how the LoRA trainer probes and uses OUT_PROD (f16 x f32 -> f32).

So the branch now fixes the crash without dropping the mixed-input CUDA path that the trainer expects.