Palantir Compute and Usage Optimization

Overview

Optimize from measured Foundry usage and telemetry, not invented data-volume bands. Separate transform-build consumption from interactive Compute Module replica consumption because they have different controls and failure modes.

Prerequisites

• Identify the pipeline, build jobs, Compute Modules, schedules, owners, service objectives, and current usage window.
• Capture build duration, requested and observed CPU/memory, queue time, input change rate, output volume, and module replica activity.
• Read references/official-docs.md and confirm contract-specific pricing or usage questions with the account owner or Palantir representative.
• Define correctness and latency constraints that cannot be traded away.

Current Contract

• Python transforms can use single-node engines or Spark; required feature support constrains the choice.
• Foundry build metrics expose requested and observed CPU and memory, enabling evidence-based resource changes.
• Incremental transforms can reduce repeated work only when their transaction semantics remain correct.
• Compute Module usage is measured while replicas are starting or active, including predictive autoscaling behavior.