RAM, GPU and Storage Planning for Large Agisoft Metashape Projects

Describe the workload the system must process—not only the largest project remembered.

• Record typical, demanding and exceptional image counts separately.
• Include image dimensions, megapixels, bit depth, compression and source file format.
• Identify single-camera, multi-camera, multispectral, thermal, panoramic or mixed-sensor projects.
• Describe aerial nadir, oblique, corridor, terrestrial, close-range and combined capture geometry.
• Record total source-data volume and expected annual project volume.
• Identify whether images are processed in one chunk or several connected chunks.
• Note masks, laser scans, control data or other inputs that add project complexity.
• Separate current requirements from plausible growth during the useful life of the system.

Planning evidence: a workload register containing at least one typical and one demanding representative project.

Hardware demand is created by the workflow and its settings.

• List required stages: matching, alignment, optimization, depth maps, point cloud, mesh, DEM, orthomosaic, tiled model, texture or export.
• Record intended quality, downscaling, filtering, face count, texture size and output resolution where relevant.
• Identify which intermediate products must be retained for reprocessing or audit.
• Define whether final products are viewed locally, published online, transferred to GIS/CAD or archived.
• Record required coordinate systems and export formats that may affect file size and delivery.
• Distinguish occasional maximum-quality work from routine production settings.
• Define acceptable turnaround time and whether overnight or unattended processing is permitted.
• Identify tasks that may run concurrently with Metashape on the same machine.

Planning evidence: a workflow map connecting each required output with its processing stages and quality settings.

Memory capacity can determine whether a processing stage is feasible on one machine.

• Measure peak physical-memory use during representative stages rather than relying on average utilization.
• Reserve memory for the operating system, Metashape interface, monitoring tools and other required applications.
• Investigate paging or swap activity, out-of-memory errors and large performance drops.
• Identify stages whose memory use changes with image count, resolution, geometry or selected output.
• Check motherboard and processor memory capacity before choosing the initial module configuration.
• Preserve a practical expansion path where larger projects are expected.
• Use compatible, stable memory configurations suitable for sustained processing loads.
• Test memory stability before production deployment.
• Do not assume that adding RAM will accelerate stages that were not memory-constrained.

Planning evidence: observed peak RAM, system overhead, required headroom and documented upgrade limit.

Evaluate the GPU against the operations Metashape can accelerate and the models users must display.

• Confirm the current Metashape version supports the candidate GPU and operating environment.
• Review compute capability, supported API, driver maturity and available VRAM.
• Identify GPU-accelerated workflow stages used by the organization.
• Monitor GPU compute utilization and VRAM allocation during a representative pilot.
• Consider display requirements for large, detailed point clouds, meshes and textures.
• Check chassis space, power supply, power connectors, cooling and sustained thermal behaviour.
• Confirm whether one balanced GPU is preferable to a more complex multi-GPU design for the actual workload.
• Use current compatible drivers and preserve the working driver/software configuration in deployment records.
• Avoid selecting a GPU solely by product name, gaming performance or advertised memory capacity.

Planning evidence: candidate GPU compatibility, pilot utilization, VRAM observations and power/thermal validation.

Both sustained clock behaviour and useful parallelism matter across the workflow.

• Review both single-thread and multi-thread performance rather than only total core count.
• Observe CPU utilization by processing stage during the pilot.
• Check sustained frequency under long workloads, not only short benchmark boost values.
• Evaluate the processor together with memory channels, maximum RAM, PCIe resources and platform expandability.
• Avoid allocating the entire budget to extreme core count if RAM, GPU or storage remains the actual bottleneck.
• Confirm cooling, motherboard power delivery and chassis airflow support sustained full load.
• Consider energy, noise and reliability requirements for office, laboratory or server-room deployment.
• Document BIOS, firmware and stability settings used in production.

Planning evidence: a platform comparison that includes CPU behaviour, maximum memory, expansion, cooling and total system cost.

Source images are only one part of the required storage footprint.

• Measure source data, project files, depth maps, point clouds, models, textures, DEMs, orthomosaics and exports.
• Separate active processing storage from backup and long-term archive where appropriate.
• Use suitable SSD storage for active projects and confirm sustained performance under the expected workload.
• Maintain sufficient free space for temporary growth, revisions, duplicate project states and export generation.
• Define naming, versioning and retention rules before project volume increases.
• Confirm backup frequency, destination, restore procedure and responsible operator.
• Evaluate redundancy as an availability measure, not as a replacement for backup.
• Plan secure transfer and storage for confidential or regulated datasets.
• Test restoration of a representative project rather than assuming the backup is usable.

Planning evidence: active, backup and archive capacity estimates supported by a real project storage inventory.

A fast workstation that cannot sustain load is not production-ready.

• Monitor CPU, GPU and storage temperatures during long representative operations.
• Check for thermal throttling, driver resets, unexpected termination and clock instability.
• Size the power supply for sustained component demand and reasonable expansion headroom.
• Verify airflow around memory, voltage regulators, GPU and storage devices.
• Avoid unstable overclocking or unsupported memory settings in production systems.
• Consider uninterruptible power, graceful shutdown and job recovery requirements.
• Review office noise, dust, ambient temperature and server-room constraints.
• Run memory and system stability tests before accepting the machine.
• Preserve processing logs when investigating failures.

Planning evidence: a sustained-load acceptance test with temperature, stability and failure-recovery observations.

Scaling architecture should follow the operational requirement, not the appearance of complexity.

• Determine whether one expandable workstation can meet the workload and deadline.
• Identify projects whose memory capacity or duty cycle may justify a HEDT or server platform.
• For network processing, map client, server, worker and shared-storage responsibilities.
• Confirm that all participating systems can access the required project and source-data paths consistently.
• Evaluate network and storage throughput, reliability and concurrent access.
• Check current Metashape edition, version and licensing requirements before designing a distributed environment.
• For cloud processing, include upload, synchronization, storage, security and cost-control requirements.
• Define monitoring, failed-job response and support ownership.
• Test the complete architecture with a real project before depending on it for a deadline.

Planning evidence: an architecture diagram and test record covering compute, shared storage, network, licensing and recovery.

A useful pilot reproduces the characteristics that create the production load.

• Select a dataset that represents image resolution, sensor type, overlap, scene complexity and intended outputs.
• Use the same Metashape version and relevant settings planned for production.
• Record start and finish time by stage, not only total elapsed time.
• Capture peak RAM, swap, CPU, GPU, VRAM, disk use and storage growth.
• Record temperatures, driver warnings, retries, failed tasks and manual interventions.
• Repeat important stages where cache, background activity or environmental conditions could distort the result.
• Keep the project and log available for future hardware or software comparisons.
• Do not assume that time, memory and storage scale linearly with image count.
• State exactly what the pilot demonstrates and what remains uncertain.

Planning evidence: a reproducible pilot report with dataset, settings, software, hardware, telemetry, results and limitations.

The final specification should remain understandable after quotations arrive.

• List required capabilities separately from preferred brands or model names.
• Define minimum installed RAM and verified maximum upgrade capacity.
• Specify GPU class, usable VRAM, supported drivers and power/cooling requirements.
• Define CPU platform requirements together with memory and PCIe expansion.
• Separate active SSD capacity, backup capacity and archive responsibility.
• Include operating system, Metashape edition, licensing and network requirements.
• Require burn-in, stability testing, documentation and warranty/support terms.
• Define the acceptance dataset and success conditions for delivery.
• Record which assumptions require revalidation if datasets or outputs change.

Planning evidence: a vendor-neutral specification connected to the approved workload and acceptance test.