How can you speed up Kubeflow Pipelines runs without extra cost?

You are using Kubeflow Pipelines to develop an end-to-end PyTorch-based MLOps pipeline. The pipeline reads data from BigQuery, processes the data, conducts feature engineering, model training, model evaluation, and deploys the model as a binary file to Cloud Storage. You are writing code for several different versions of the feature engineering and model training steps, and running each new version in Vertex AI Pipelines. Each pipeline run is taking over an hour to complete. You want to speed up the pipeline execution to reduce your development time, and you want to avoid additional costs. What should you do?

  1. Comment out the part of the pipeline that you are not currently updating.
  2. Enable caching in all the steps of the Kubeflow pipeline. Source Reference Answer
  3. Delegate feature engineering to BigQuery and remove it from the pipeline.
  4. Add a GPU to the model training step.

Community Votes

B
100%

100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The question tests the concept of pipeline step caching: a step is skipped if its inputs and code have not changed, so only modified steps (like new feature engineering or training versions) are re-run; the trap is mistaking other optimizations like BigQuery delegation or GPU addition for direct, cost-free speedups.

For speeding up Kubeflow Pipelines development when iterating on multiple versions, enabling step caching is the community-endorsed answer; it reuses outputs of unchanged steps across runs, reducing execution time and avoiding additional compute costs.

Choosing C (Delegate feature engineering to BigQuery) is the most likely wrong answer because it appears to reduce pipeline work; however, it changes the end-to-end design and does not reuse already-computed training or evaluation steps, while caching directly addresses redundant execution of unchanged steps.

Community Discussion (3 comments)

Yan_X 👍 7 Selected: B
B 'Different version of feature engineering and model training', so enable cache can help to reuse results of previous run. Guess not be C, as it mentioned 'end-to-end' MLOps, if delegate to BigQuery, it is not 'end-to-end' now.
omermahgoub 👍 1
B, and here's why: 1. Caching directly addresses the issue of redundant computations, especially for frequently used feature engineering versions 2. End-to-End" MLOps, Kubeflow Pipelines handle all stages, including feature engineering, maintaining your desired "end-to-end" workflow.
JG123 👍 1
Answer is C

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

B is correct because Kubeflow Pipelines caching lets you reuse the outputs of steps whose code and inputs have not changed. In this scenario, you are modifying only feature engineering and model training versions, but other steps like data loading, evaluation, and deployment may be identical; caching those unchanged steps cuts the per-run time dramatically. One commenter noted that 'different version of feature engineering and model training' means caching helps reuse results from previous runs, and it avoids the extra cost of recomputing unchanged stages. Another commenter added that caching directly addresses redundant computations, especially for frequently used feature engineering versions, while still maintaining an end-to-end KFP workflow.

Why the Other Options Are Wrong

A (Comment out the part of the pipeline you are not updating) is manual and error-prone; it weakens the end-to-end pipeline and still requires rerunning the remaining steps, and the commented-out parts are not tested automatically. C (Delegate feature engineering to BigQuery) changes the architecture and may be a good optimization in some systems, but it does not address repeated executions of model training or evaluation, and it violates the stated 'end-to-end' pipeline requirement. D (Add a GPU to the model training step) could speed up training but incurs additional cost, directly contradicting the requirement to 'avoid additional costs' and does nothing for feature engineering or other unchanged stages.

Community Comment Notes

The top comment (7 likes) chose B and also correctly rejected C by pointing out that delegating feature engineering to BigQuery breaks the 'end-to-end' MLOps pipeline requirement. A second comment expanded on B, explaining that caching avoids redundant computation for unchanged versions, which is the key idea. One lower-liked comment answered C, likely because moving feature engineering to BigQuery seems like a natural performance optimization; however, the consensus clearly favors B because caching is the only option that both speeds up runs and avoids extra cost without changing the pipeline architecture.

Official Reference

Exam Strategy

When asked about speeding up pipeline runs without extra cost, look for an answer that reuses previous work, such as caching. Remember that Kubernetes or Kubeflow step caching skips a step only when its code and inputs are unchanged, so during development you can iterate on one step while all other steps are reused from prior runs.

Related Analysis

Practice All PMLE Questions

Access 65 questions with complete answers and detailed explanations.

View Full PMLE Practice Test →

← Back to PMLE Study Guide