A PyTorch model relies on a custom C++ operator and a SentencePiece tokenizer that are not present in any Vertex AI prebuilt serving container, and the team's inference handler must run tokenisation before the forward pass. They need online serving on Vertex AI. Which packaging approach lets them deploy this model successfully?
- AUse the prebuilt PyTorch serving container and pass the tokeniser and custom operator as extra files in the model artifact directory at deploy time.
- BConvert the model to the XGBoost format so the prebuilt XGBoost container can run the custom operator and tokeniser without extra dependencies.
- CBuild a custom serving container that installs the C++ operator and tokeniser dependencies and implements the prediction route, then deploy it to a Vertex AI online endpoint. Correct
- DDeploy the model to a batch prediction job, because batch jobs automatically install any missing system libraries the handler imports.
Why A is wrong: Bundling extra files seems to extend the prebuilt container, but that container only installs its fixed dependency set, so an unlisted system library and a compiled custom operator will not be available at runtime and serving fails.
Why B is wrong: Switching to the XGBoost container sounds like a way to dodge missing PyTorch dependencies, but XGBoost is a gradient-boosting runtime that cannot execute a PyTorch graph or a custom C++ operator, so the model could not run at all.
Why C is correct: A custom container lets the team install the exact system libraries, compile the custom operator, and implement the preprocessing prediction route, which is the supported path when prebuilt containers lack required dependencies.
Why D is wrong: Choosing batch prediction appears to sidestep container limits, but batch jobs use the same container constraints and do not auto-install arbitrary system libraries, and the requirement is online serving rather than offline scoring.