Classify Image (TorchServe)

How it fits

Typical backends

Caveats

• I/O contractA single ranked list is built per frame and every output arm is a projection of it, so all arms agree class-for-class; the arm is fixed by which output type the downstream connection resolves, not by a parameter. The arms are Classification (top-1), [Classification] (ranked), String (top-1 label), ([String], [Double]) (parallel index-aligned label and score arrays), [DetectedClass] (ranked id/confidence), UInt64 (top-1 class id), and [Double] (ranked confidence scores, descending).
• Hard constraintInference runs against a TorchServe service that must be provisioned with the model archive; without the served archive the component cannot score frames.
• LatencyEach frame is JPEG-encoded and sent over the network to the service, so the encode quality trades image fidelity against payload size and per-frame round-trip cost.
• Parameter interactionThe confidence floor is applied before the top selection, so classes below it are dropped first and the kept-count then bounds the remaining ranked list. Both threshold and top_k are re-read every frame, so a mutable update takes effect on the next call.
• FallbackA frame the service cannot score — an undecodable input, a failed or non-2xx POST, or malformed JSON — is logged and degraded to an empty ranked result, so every arm still emits exactly one value (an empty list, an empty label, or a zero id) rather than throwing or dropping the frame.
• AccuracyThe label vocabulary and score calibration are defined entirely by the served model archive, not by this component.