Detect Objects (TorchServe)

How it fits

Typical backends

Caveats

• I/O contractThe served handler must return a JSON array whose elements carry a 4-element `[x1, y1, x2, y2]` box plus a score and class field; non-array responses or malformed boxes abort that message.
• I/O contractThe output is a oneof resolved at deploy time by the connected sink, and every shape is a projection of one per-detection record so the shapes agree detection-for-detection: [BoundingBox] is box geometry plus class, [Rectangle<Double>] is box geometry only, [DetectedClass] is class id plus confidence only, UInt64 is the detection count, and Image is the source frame with boxes drawn. This is a box-only detector, so no instance-mask shape is offered.
• Hard constraintBefore each request the component polls the server's health endpoint and blocks with no timeout until it is ready, so a down or still-loading sidecar makes the component wait indefinitely rather than erroring.
• Parameter interactionthreshold is the base confidence floor, class_thresholds overrides it per class id, and object_classes is an allow-list applied after inference (an empty list keeps every class).
• LatencyThe HTTP read and write timeouts are 60 seconds and the connect timeout is 2 seconds, so a long-running handler must complete within that window.
• State lifetimeAll configuration keys are captured once at startup; runtime changes have no effect and require a redeploy.
• CompatibilityA TorchServe sidecar hosting the packaged model archive is required; this component cannot run standalone.