Implementation:Pytorch Serve ArgParser For Worker

Overview

Pytorch_Serve_ArgParser_For_Worker documents the worker-specific argument parsing API within ArgParser. While the same class also provides server-level argument parsing (linked to Server Lifecycle), the model_service_worker_args() method defines a distinct set of CLI arguments consumed by the backend worker process (TorchModelServiceWorker).

Source

Property	Value
File	ts/arg_parser.py
Lines	162 (method at lines 102–157)
Language	Python
Key Method	ArgParser.model_service_worker_args()

Method Definition

ArgParser.model_service_worker_args() (lines 102–157)

@staticmethod
def model_service_worker_args():
    parser = argparse.ArgumentParser(
        prog="model-service-worker",
        description="TorchServe backend model worker"
    )
    # ... argument definitions ...
    return parser

This static method constructs and returns an argparse.ArgumentParser tailored for the backend worker process. The worker is a separate OS process spawned by the TorchServe frontend to load and serve a specific model.

Arguments

Argument	Type	Required	Default	Description
--sock-type	str (choices: unix, tcp)	Yes	N/A	Socket type for frontend-to-worker communication. On Linux, unix domain sockets are preferred for performance. On Windows, tcp is required.
--sock-name	str	No	None	Socket name or path. For unix type, this is the filesystem path to the domain socket. For tcp type, this is unused (see --port).
--host	str	No	None	Host address to bind the worker when using TCP sockets.
--port	int	No	None	Port number for the worker when using TCP sockets.
--metrics-config	str	No	None	Path to the metrics configuration file for the worker process.
--async	flag	No	False	Enable asynchronous inference mode in the worker.

Socket Type Selection

The --sock-type argument is the only required parameter and determines the inter-process communication mechanism between the TorchServe frontend (Java) and the backend worker (Python):

• unix -- Uses Unix domain sockets. This is the default on Linux and macOS. The socket file path is specified via --sock-name. Unix sockets avoid TCP overhead and provide lower-latency communication.

• tcp -- Uses TCP sockets. Required on Windows where Unix domain sockets are unavailable. The worker binds to --host and --port.

Usage Context

The worker argument parser is consumed by TorchModelServiceWorker, which is the Python entry point for each backend worker process. When TorchServe's frontend decides to scale up a model (based on configuration or load), it spawns a new worker process with these CLI arguments:

# Typical invocation by the frontend:
# python -m ts.model_service_worker --sock-type unix --sock-name /tmp/ts_worker_1.sock

parser = ArgParser.model_service_worker_args()
args = parser.parse_args()
worker = TorchModelServiceWorker(
    sock_type=args.sock_type,
    sock_name=args.sock_name,
    host=args.host,
    port=args.port,
)
worker.run()

Distinction from Server Args

The ArgParser class contains two separate parser methods:

Method	Purpose	Linked Principle
ts_parser()	Server-level arguments (ports, config, model store)	Pytorch_Serve_Server_Lifecycle
model_service_worker_args()	Worker-level arguments (socket type, async mode)	Pytorch_Serve_Distributed_Worker

This separation reflects the architectural boundary between the Java frontend (configured via ts_parser) and the Python backend workers (configured via model_service_worker_args).

Relationship to Principles

This implementation directly supports the Pytorch_Serve_Distributed_Worker principle. The worker argument parser defines the communication and configuration contract between the TorchServe frontend and each spawned backend worker process, which is fundamental to the distributed worker architecture.

Metadata

Pytorch_Serve Pytorch_Serve_Distributed_Worker 2026-02-13 18:52 GMT