What size server do you need for AI presentation generation?

For a controlled pilot that uses a hosted text model, begin testing around 4–8 vCPU, 8–16 GB RAM, and 100 GB of fast SSD storage. For a shared departmental service, test around 8–16 vCPU, 16–32 GB RAM, and 250 GB or more of SSD storage. Add a GPU only when you run a local model, a local image-generation service, or another GPU-dependent provider.

For local inference, GPU selection depends on model weights, quantization, context length, and simultaneous requests. A model fitting in VRAM does not prove that it will meet your latency or concurrency target. Reserve memory for the runtime and KV cache, then validate the complete workflow with real documents and deck exports.

Start with the presentation workload, not the server catalog

Before comparing CPUs and GPUs, define what the service must do. A ten-slide sales deck generated from a short prompt is not equivalent to a thirty-slide board presentation generated from several PDFs. Measure at least the following workload variables:

• Presentations per business day: average demand determines cost, but the busiest hour determines capacity.
• Peak simultaneous jobs: count generation jobs, not logged-in users.
• Slides per presentation: more slides increase content generation, asset processing, rendering, and storage.
• Source-document profile: record file type, page count, file size, OCR requirements, and whether multiple documents are combined.
• Text-model path: hosted API, internal model gateway, Ollama, LM Studio, vLLM, or another OpenAI-compatible endpoint.
• Image path: uploaded assets, stock images, hosted image generation, or local image generation.
• Export formats: editable PPTX, PDF, PNG previews, or several formats per job.
• Latency objective: define an acceptable median and 95th-percentile completion time.
• Retention: determine how long uploads, generated assets, presentations, and exports remain available.

Use production-like inputs. A benchmark made entirely from short text prompts will understate the CPU, memory, storage, and time required for document-heavy workflows.

Separate application capacity from model capacity

The most important sizing decision is whether Presenton and the model provider share one machine. The Presenton self-hosting guide describes a container that includes the web application, REST API, MCP server, editing, templates, export, persistent data, and multi-user workspaces. Text, image, search, and database providers remain configurable.

When Presenton calls a hosted or separately managed model endpoint, the application node does not need enough VRAM to hold that model. Its workload is primarily parsing, orchestration, rendering, and storage. If you run the application, Ollama, and image generation on one server, all components compete for CPU, RAM, GPU memory, disk bandwidth, and thermal headroom.

For a production environment, separating the application tier from the inference tier makes capacity easier to reason about. It also lets teams scale or replace the model service without moving presentation data and application state.

Calculate peak concurrency before choosing hardware

Average daily volume hides the moments when users are waiting. Estimate simultaneous work during the busiest interval with a simple capacity relationship:

Expected jobs in progress ≈ peak arrivals per minute × average job duration in minutes

If a department starts four jobs per minute during its busiest period and a representative job takes three minutes, roughly twelve jobs may be active. That does not mean every component must process twelve jobs simultaneously. A queue can protect expensive resources, but the wait must remain within the service objective.

Add headroom for burstiness, retries, and large documents. A practical test plan should include the expected peak, then a higher load that demonstrates how the system fails. Watch whether it queues predictably, rejects work cleanly, or degrades until every job times out.

Record separate timings for ingestion, model inference, media work, rendering, and export. A single end-to-end duration cannot tell you which resource to increase.

Size CPU and RAM for parsing, orchestration, and export

CPU remains important even when the text model runs elsewhere. Uploaded documents must be read, slide content must be assembled, templates must be applied, and browser-based rendering or export processes must complete reliably.

CPU sizing factors

• the number of document extractions that can run concurrently;
• OCR and image-heavy PDF processing;
• simultaneous preview, PPTX, and PDF exports;
• background workers and queue consumers;
• database, reverse-proxy, monitoring, or security agents sharing the host;
• local model CPU offload, which can dramatically change utilization and latency.

RAM sizing factors

• the application and worker processes;
• Chromium or other rendering processes;
• document parsing and decompression;
• in-memory images and slide assets;
• local embeddings or memory services;
• filesystem cache and safe operating headroom;
• local-model weights when inference uses system RAM or CPU offload.

Do not size a host so the benchmark only passes with nearly all RAM consumed. Leave enough headroom for operating-system cache, deployment agents, spikes, and upgrades. Sustained swapping is a capacity failure, even if requests eventually finish.

Size GPU and VRAM for local models

A GPU is optional when Presenton uses a hosted text provider. It becomes relevant when the organization runs Ollama, LM Studio, vLLM, ComfyUI, or another local GPU service. Presenton’s current open-source repository documents GPU-capable Docker deployment and multiple hosted, local, and OpenAI-compatible providers.

Estimate VRAM as a budget with several consumers:

Required VRAM ≈ model weights + KV cache + runtime workspace + concurrent-request overhead + safety margin

The downloaded model size is only one part of that equation. Quantization can reduce weight memory, but context length and concurrency still matter. Ollama’s context-length documentation states that increasing context length increases memory use and recommends checking actual offload and allocated context with ollama ps. The vLLM serving reference likewise exposes controls for model length, GPU-memory utilization, KV-cache allocation, and concurrent sequences.

Questions to answer before selecting a GPU

1. Which exact model and quantization will be approved?
2. How much source text must fit in one request?
3. How many inference requests must run concurrently?
4. Can requests queue, or must several users receive tokens at the same time?
5. Will image generation share the same GPU?
6. Is CPU offload acceptable at the required latency?
7. Does the platform require ECC memory, redundant power, or a supported data-center form factor?

Benchmark with the exact runtime configuration. A model that technically loads into VRAM may leave too little cache capacity for long documents or multiple jobs. Conversely, a remote provider can eliminate application-node GPU requirements entirely.

Plan storage and network capacity

The official self-hosting guide mounts /app_data so presentations and settings survive container replacement. That persistent area can include uploads, generated assets, presentations, settings, and local memory. Capacity planning must include growth, backup copies, and temporary working space—not only the final PPTX files.

Storage estimate

Monthly storage ≈ jobs × average retained bytes per job × retention multiplier

Retained bytes per job = uploads + generated assets + presentation data + exports + logs

Measure this with a representative batch. Image-heavy decks and multiple export formats can make the retained footprint much larger than the original document. Include database backups, object-storage versioning, snapshots, and restore staging space.

Use SSD-backed storage for active work. Monitor free capacity, I/O latency, inode use, and backup duration. If persistent storage is remote, test rendering and export during network congestion.

Network estimate

Hosted providers move part of the compute burden off the server but make network reliability and egress policy part of the critical path. Measure request volume, uploaded documents, generated images, provider responses, and exports. For private or air-gapped deployments, verify that every configured text, image, search, telemetry, and update path matches the data-boundary requirement.

Use starting configurations for testing—not as guarantees

The following profiles are deliberately conservative planning baselines. They are not official Presenton minimums, and they assume fast SSD storage and a modern 64-bit server platform. Adjust them after measuring the workload.

If a pilot requires unusually large PDFs, OCR, thirty-plus slides, local image generation, or several simultaneous exports, start above the smallest profile. If the organization already runs an internal model gateway, size Presenton against that service’s latency and quotas rather than duplicating model infrastructure.

Run a benchmark that represents production

A defensible capacity test uses a fixed corpus and repeatable measurements. Build a benchmark set containing:

• a prompt-only deck;
• a normal DOCX source document;
• a text PDF;
• a scanned or image-heavy PDF if OCR is in scope;
• a large multi-document job near the approved limit;
• a custom corporate template with required fonts and assets;
• the expected slide counts and export formats;
• at least one intentionally invalid or oversized upload.

Run each scenario after a cold start and again after the system is warm. Then run mixed jobs at one, two, four, and the expected peak concurrency. Capture:

Do not optimize only for requests per minute. A smaller or more heavily quantized model may improve throughput while reducing structure quality, factual reliability, or template adherence. Use the evaluation approach in the local-model presentation benchmark alongside infrastructure measurements.

Know when to scale up and when to scale out

Scale up when a single worker is limited by CPU, RAM, or a model that must reside on one larger GPU. Scale out when requests are independent and can be distributed across multiple application workers, inference replicas, or export workers.

A queue is useful when it bounds concurrency and communicates status. It is not a substitute for capacity when wait times continually exceed the service objective. For production API workflows, return job identifiers, expose progress, and apply retry-safe client behavior.

Avoid common AI server sizing mistakes

Buying for model parameters alone

Model size does not describe context memory, concurrency, document processing, image generation, or exports. Size the complete pipeline.

Using average traffic

Presentation work often clusters before meetings and reporting deadlines. Benchmark the busiest hour and burst conditions.

Combining every service on one GPU

A local text model and local image generator can each work alone yet fail when sharing VRAM. Test them together or isolate their capacity.

Ignoring output quality

Throughput is irrelevant if the model fails to produce stable structure or editable content. Track acceptance rate and human correction time.

Leaving storage and backups until later

Uploads and generated assets accumulate. Backup and restore throughput must be included before production.

Treating a successful demo as a load test

One short prompt proves functionality. It does not prove concurrency, long-document behavior, recovery, or operational headroom.

On-prem AI server sizing checklist

1. Define the peak jobs per minute and acceptable completion-time objective.
2. Record typical and worst-case source documents, slide counts, and exports.
3. Decide whether text and image models are hosted, internal, or local.
4. Draw the application, inference, storage, database, and network boundaries.
5. Select a starting application profile and a separately justified GPU profile.
6. Build a fixed benchmark corpus using approved business documents.
7. Measure pipeline stages, p50/p95 duration, resource saturation, errors, and output quality.
8. Add headroom for bursts, backups, upgrades, monitoring, and failure recovery.
9. Retest at expected peak concurrency and above it.
10. Document the final assumptions so capacity can be reviewed when models or workflows change.

For the surrounding deployment architecture, security, identity, and operating model, read the on-premise AI deployment guide and the self-hosted presentation API guide.