发布

  • fix(llama-cpp): cap single-pass embedding batch to fit VRAM (#10695)

    frostbyte_neo 发布于 2026-07-06 10:56:09 +00:00 | 991 次提交 在此版本后已推送到 master

    • fix(llama-cpp): cap single-pass embedding batch to fit VRAM

    Embedding/score/rerank all decode or pool the whole input in one physical
    batch, so EffectiveBatchSize sized the batch to the full context window. For
    a large context that makes n_ubatch huge, and the per-device CUDA compute
    buffer (forward-graph scratch, ~n_ubatch * n_ctx, NOT split across GPUs)
    balloons into multi-GiB: a large-context embedding model then aborts on load
    (exitCode=-1) even with plenty of free VRAM. Reproduced with qwen3-embedding-4b
    (context 40960 -> n_batch 40960 -> abort) and qwen3-embedding-0.6b
    (n_batch 8192); pinning batch:512 avoided it.

    This is the same root cause as issue #10485 (a large context turns the batch
    into multi-GiB of scratch that must fit on a SINGLE card), but the single-pass
    path bypassed the VRAM headroom guard the config layer already had — it
    returned the unbounded context as the batch with no GPU awareness.

    Make the single-pass batch VRAM-aware: cap it to the largest batch whose
    compute buffer fits the per-device VRAM headroom, clamped to
    [DefaultPhysicalBatch, ctx], reusing the existing computeBufferBytesPerCell and
    headroom-divisor math (no duplication). Unknown per-device VRAM (0) stays
    conservative (DefaultPhysicalBatch, not the context) so a detection gap can't
    OOM. The GPU is resolved through an injectable package var (config.LocalGPU,
    backed by sync.Once-cached xsysinfo detection) so the per-request router call
    stays cheap and tests inject a deterministic device. Explicit batch: still
    wins. An input longer than the cap can no longer be pooled in one pass — the
    accepted tradeoff, since a batch that OOMs the device processes nothing.

    Assisted-by: Claude:claude-opus-4-8 golangci-lint go-test
    Signed-off-by: Ettore Di Giacinto mudler@localai.io

    • fix(config): single-pass batch follows context on unknown VRAM

    The single-pass (embedding/score/rerank) batch cap must only shrink the batch
    when the per-device VRAM ceiling is KNOWN. On unknown VRAM (CPU-only or a GPU
    detection gap) SinglePassBatchForContext returned DefaultPhysicalBatch, which
    under-sized the batch below the context — over-trimming score/embed/rerank
    inputs (the modelTokenTrim middleware regression) with no OOM benefit on CPU
    where the compute buffer lives in system RAM. Return the full context instead,
    preserving the original single-pass behavior; the VRAM cap stays a downward
    safety that only engages when VRAM is known.

    Assisted-by: Claude:claude-opus-4-8 [go-test go-vet]
    Signed-off-by: Ettore Di Giacinto mudler@localai.io


    Signed-off-by: Ettore Di Giacinto mudler@localai.io
    Co-authored-by: Ettore Di Giacinto mudler@localai.io

    下载附件