runpod: a proxy that edits the request decides for the server
Three silent drops on the way to a rented pod, all found while wiring Surya to
the model layer, all of the same shape: coderai accepted a field, forwarded a
reduced version of it, and the pod answered something plausible.
* Images. The front flattens multipart content to the literal text
"[image_url content]" unless the backend claims vision, and only the llama.cpp
backend ever did. So every page sent to a VLM served on RunPod — olmOCR in
"model" mode, or Surya through a coderai-vllm pod — arrived as that
placeholder, and the model answered fluently about nothing. A proxy is the
wrong place to judge: forwarded, a text-only server returns a plain 400 and a
VLM server reads the page.
* Structured output. Only {"type":"json_object"} survived, so a json_schema —
the strict form current clients send, Surya's guided decoding among them — was
dropped and the reply came back as free text the caller could not parse. The
streamed path ignored the field entirely, json_object included.
* extra_args. Whitelisted per engine on a model's runpod block since pods
shipped, parsed, stored, and never put on a command line. Setting it looked
like tuning and did nothing, which is worse than refusing it: the pod boots,
serves, and ignores the decision. A page-reading model wants prefix caching
and the Qwen-VL pixel bounds, and until now the only way in was docker_args,
which replaces the whole generated line.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PxYHWbCAjjjD7A1rhFKtaW
Showing
Please
register
or
sign in
to comment