Why a remote host was sending PaddleOCR requests: surya never ran. Every attempt
ended as

  [ocr] engine 'surya' could not serve (vLLM exited (code 1) before becoming
  ready) … falling back to paddle -> doctr

and the root cause, four frames down in the vLLM subprocess output:

  RuntimeError: Failed to find C compiler. Please specify via CC environment
  variable or set triton.knobs.build.impl.

Triton JIT-compiles its CUDA driver module at RUNTIME, on first engine start. The
image has no cc, gcc or clang — confirmed by looking inside it; the single dpkg
match is gcc-*-base, runtime libs, not a compiler. So gcc and libc6-dev are now
installed in the shipped stage, with the reason recorded beside them: a compiler
in a runtime image looks like an obvious thing to delete.

This affects EVERY vLLM engine, not just OCR.

What made it invisible: the OCR fallback chain worked. All 203 /v1/ocr requests in
the window returned 200 — on paddle, 218 times, after surya failed. Nothing in the
HTTP log said anything was wrong, and the only outward sign was a remote host
preferring an engine it should not have needed.

The RunPod vLLM capability profile has carried gcc from the start. The main image
never did. The test checks both so they cannot drift apart again.

Needs a rebuild to take effect — a compiler cannot be bind-mounted in like the
Python fixes.

4 tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY