Secure Vector Ingestion at Enterprise Scale: Accelerating TLS-Protected Embedding Pipelines on Dell PowerEdge R770 with Intel QuickAssist Technology

Executive Summary

Enterprise AI has moved from pilot to production. Retrieval-augmented generation (RAG), semantic search, and AI agents now operate against proprietary data at scale. Each of these workloads depends on a continuous flow of vectorized content into databases such as Qdrant, and that traffic travels over TLS-encrypted channels. As ingestion volumes climb into the millions of operations per hour, the cryptographic cost of every TLS handshake becomes a measurable tax on infrastructure. CPU cycles shift to key exchange, fewer cycles remain for the AI workloads that drive business value, and rack-level power consumption rises accordingly.

The Dell PowerEdge R770, configured with Intel Xeon 6780P processors and Intel QuickAssist Technology (QAT), reduces that tax at the platform level. By offloading RSA-2048, RSA-4096, ECDSA-P256, and ECDSA-P384 handshake operations from general-purpose CPU cores to dedicated QAT engines, enterprises achieve substantially higher secure ingestion throughput while improving energy efficiency across the AI data pipeline. Benchmark results compare four production-grade Rustls crypto providers under an identical Qdrant ingestion workload, giving infrastructure leaders a defensible basis for platform decisions.

Key Results at a Glance

Securing the AI Data Pipeline Without Throttling It

Every modern AI application that touches enterprise data eventually depends on a vector database. RAG systems retrieve grounded context from one. Semantic search ranks results through one. Multimodal agents recall prior interactions from one. In each case, the value of the system is bounded by how quickly fresh, authoritative content moves into the database and how securely it travels between services.

Production deployments do not treat encryption as optional. Internal compliance frameworks, customer contracts, and regulatory regimes such as HIPAA, PCI DSS, and the EU AI Act push enterprises toward TLS-everywhere architectures, including service-to-service traffic inside the data center. Every vector written to Qdrant, Weaviate, Milvus, or a comparable database arrives over a TLS-protected connection, and every connection begins with an asymmetric handshake.

Why handshake cost matters at AI scale

RSA-2048 and RSA-4096 remain the dominant algorithms in enterprise TLS deployments today, while ECDSA-P256 and ECDSA-P384 are gaining ground in TLS 1.3 and mutual TLS service meshes. All four are computationally demanding on general-purpose CPUs, and all four scale linearly with connection rate. A pipeline that ingests tens of millions of vectors per day will generate hundreds of thousands of handshakes per minute as embedding workers, ingestion services, and rebalancing jobs open and reuse short-lived connections.

On a CPU-only deployment, this creates three compounding problems for infrastructure teams:

• Throughput ceiling. TLS handshakes consume cores that would otherwise serve embedding requests, capping the effective ingestion rate of the pipeline.
• Stranded compute. Cores pinned to crypto work cannot be reclaimed by the embedding model server or the database, leaving expensive silicon underutilized for the workloads that matter.
• Power and thermal pressure. Crypto-bound CPU utilization translates directly into watts and BTUs, eroding rack-level density targets and inflating operating cost per ingested vector.

The opportunity cost is concrete. Every core spent on a handshake is a core not spent generating embeddings, serving inference, or running the next AI workload the business needs to land.

Hardware-Accelerated TLS on Dell PowerEdge R770

Dell PowerEdge R770 servers paired with Intel Xeon 6780P processors expose Intel QuickAssist Technology as an integrated accelerator for symmetric and asymmetric cryptographic operations. When OpenSSL routes handshake operations through the in-tree QAT driver, RSA and ECDSA computations move off general-purpose cores and onto dedicated QAT engines. The throughput gains are substantial, and the CPU capacity that software-only crypto would have consumed is freed for work at the application layer.

Four Rustls crypto providers were evaluated under an identical Qdrant ingestion workload. This allows infrastructure architects to see exactly where QAT acceleration changes the throughput and efficiency profile of the platform.

Why this comparison matters

Comparing four providers under identical conditions isolates the contribution of the accelerator from the contribution of the software stack. Ring, AWS-LC, and OpenSSL 3.5 establish the realistic ceiling that a well-tuned software-only deployment can reach on the platform. The OpenSSL + QAT configuration then shows how much additional headroom hardware acceleration unlocks on top of that ceiling, on the same chassis, with the same workload, and within the same power envelope.

Solution Architecture

The benchmark implements an end-to-end secure vector ingestion pipeline that mirrors how production RAG and semantic search systems move data into a vector database. Document text enters the system, embeddings are generated on CPU, and the resulting vectors are written to Qdrant over a Rustls-protected channel. The TLS handshake path is the variable under test. Every other component remains constant across runs.

Pipeline stages

• Stage 1: Embedding generation. Qwen3-Embedding-0.6B is served on CPU through Intel OpenVINO Model Server (OVMS) in maximum-throughput mode. The client streams document chunks through the OVMS embedding API and receives dense vectors. This stage is a supporting load, not the primary benchmark target.
• Stage 2: Vector preparation. A single client process collects the embeddings produced in Stage 1 and prepares them for ingestion into Qdrant.
• Stage 3: Secure ingestion via Rustls. The client opens a TLS-protected connection to Qdrant using the selected Rustls crypto provider, negotiates the configured algorithm, and writes vectors. Each provider runs to completion before the next begins, ensuring clean attribution of CPU and power consumption.

Configuration under test

Two dimensions are exposed to the operator. The TLS algorithm set is fixed so that every provider is measured on the same cryptographic work. The provider selection is variable so that operators can compare any subset against the QAT-accelerated configuration.

QAT Configuration (Fixed)

To produce repeatable, defensible results, the QAT backend is locked to a single configuration profile across all runs. Operators who later tune for their own workloads can use these settings as a known-good starting point.

Reference architecture

The following diagram describes the technical architecture. All components run on a single Dell PowerEdge R770 chassis.

Performance Benchmark

The benchmark compares the OpenSSL + Intel QAT configuration against the best-performing software provider on each metric (AWS-LC for every algorithm in this evaluation), across all four TLS algorithms under test. All measurements come from the same Dell PowerEdge R770 chassis under identical workload conditions. Each ingestion request carries 100 vectors at 8 KB per vector (800 KB per request).

Throughput: More Secure Ingestion per Server

QAT acceleration delivers between 1.39x and 1.66x higher ingestion request throughput than the best software provider across all four algorithms. The gains are most pronounced on RSA-4096, where the heavier key size amplifies the advantage of dedicated hardware offload. For an enterprise running a fleet of ingestion servers, these gains translate directly into more vectors written per hour without adding chassis, deferring capital expenditure and reducing the operational complexity of horizontal scale-out.

Figure 1 | Sustained ingestion request throughput by TLS algorithm. Each ingestion request carries 100 vectors at 8 KB per vector.

CPU Utilization: Understanding the Throughput-Utilization Tradeoff

QAT acceleration shifts the performance profile of the platform. While delivering 1.39x to 1.66x higher throughput, the QAT configuration consumes moderately more CPU (5.5 to 6.6 percentage points above the best software provider). This is expected behavior: the system is performing significantly more useful work per unit time. The QAT engines handle the asymmetric cryptography, but the higher ingestion rate drives additional CPU activity in Qdrant indexing, network stack processing, and vector preparation.

Figure 2 | CPU utilization at sustained throughput.

The critical insight is not raw CPU percentage in isolation but throughput delivered per unit of CPU consumed. QAT achieves up to 1.66x more work while using only modestly more CPU, resulting in a substantially better throughput-to-utilization ratio. At 29.6% CPU on RSA-2048, the system retains over 70% of its compute capacity for co-located embedding generation, inference serving, and retrieval ranking.

Energy Efficiency: More Work per Watt

Energy efficiency, measured as ingestion requests sustained per watt of CPU package power, improves across all four algorithms when handshake operations move to QAT engines. The gains range from 1.25x on ECDSA-P384 to 1.50x on RSA-4096, where the heavy compute cost of 4096-bit key exchange makes hardware offload particularly effective.

Figure 3 | Ingestion requests sustained per watt of measured CPU package power.

Latency: tighter tail budgets for SLA-driven workloads

Figure 4| Median (P50) ingestion latency by TLS algorithm.

Median (P50) ingestion latency drops by 1.30x to 1.71x with QAT acceleration. For RAG, semantic search, and agent workloads that publish strict end-to-end response budgets, reducing the median ingestion latency creates measurable headroom in the rest of the pipeline. That headroom can be reinvested in larger context windows, additional retrieval steps, or more sophisticated reranking.

Effective Payload Throughput: Data Movement at the Application Layer

Figure 5 | Effective payload throughput (MB/s) by TLS algorithm.

Each ingestion request carries 100 vectors at 8 KB per vector (800 KB per request). Effective payload throughput quantifies the actual rate of secure data movement into Qdrant at the application layer. QAT acceleration sustains between 1.39x and 1.66x more effective payload than the best software provider, directly accelerating the rate at which fresh content becomes available for retrieval.

Business Impact

For infrastructure leaders, the value of QAT-accelerated TLS appears in four areas that matter to the P&L: throughput delivered per server, energy consumed per unit of work, the compute headroom available for co-located AI workloads, and the speed at which fresh content reaches downstream services.

Defer Capital Expenditure

Hardware-accelerated handshakes raise the ceiling on secure ingestion operations per server. With up to 1.66x throughput gains, teams running large-scale RAG, semantic search, or agentic AI pipelines can ingest substantially more vectors per hour from each Dell PowerEdge R770 chassis. That defers server procurement and reduces the operational complexity of horizontal scale-out.

Improve Energy Economics Across the Rack

Power consumption is increasingly the binding constraint on AI infrastructure expansion. Moving handshake operations from general-purpose cores to purpose-built QAT engines delivers up to 1.50x more secure operations per watt within the same rack power budget. The result is a measurable reduction in energy cost per ingested vector across the AI data pipeline.

Consolidate AI Workloads on Fewer Chassis

With QAT handling cryptographic offload and the system operating at under 31% CPU utilization even at peak throughput, over 69% of compute capacity remains available for embedding generation, inference serving, retrieval ranking, or other workloads competing for resources on the same chassis. In environments where AI models and ingestion pipelines share infrastructure, this consolidation directly improves utilization economics.

Accelerate Time-to-Retrieval for Downstream Services

Higher ingestion throughput compresses the time between content arrival and content availability for retrieval. For agent workloads that depend on near-real-time context, that compression is the difference between a responsive system and one that lags behind the user.

Conclusion

Secure vector ingestion sits on the critical path of every enterprise AI initiative that depends on retrieval, search, or grounded generation. The cost of getting it wrong extends beyond a failed compliance audit. It means a slower AI pipeline, underutilized compute, a rising energy bill against an infrastructure budget already under pressure, and retrieval latency that erodes the user experience of every downstream service.

Dell PowerEdge R770 with Intel Xeon 6780P and integrated Intel QAT addresses this challenge at the platform level. By offloading RSA-2048, RSA-4096, ECDSA-P256, and ECDSA-P384 handshake operations from general-purpose cores to dedicated accelerators, the platform delivers up to 1.66x ingestion throughput, up to 1.50x energy efficiency, and retains over 69% of CPU capacity for the AI workloads that depend on it. For organizations that have already standardized on Dell PowerEdge servers for AI infrastructure, QAT activation is a configuration choice, not a re-platforming exercise.

Addendum: Benchmark Methodology

Workload definition

The benchmark exercises a secure vector upsert workload (UPSERT_100). RPS refers to ingestion requests per second, not TLS handshakes per second. Every ingestion request flows through a TLS-protected Rustls connection, so the cryptographic work performed by the crypto provider directly bounds how many requests the pipeline can sustain.

Isolation of the variable under test

Every variable that is not the crypto provider, including the embedding model, batch size, socket pinning, thread count, concurrency, and Qdrant configuration, is held constant across runs. Each provider executes the full ingestion workload to completion for each of the four algorithms before the next provider begins.

Primary and secondary metrics

Two classes of metrics are captured. Primary metrics quantify the work delivered. Secondary metrics quantify the cost of delivering that work, in CPU cycles and watts.

Derived KPIs

Three derived metrics translate the raw measurements into language that infrastructure leaders use when defending platform decisions. Each is computed per algorithm so that RSA-2048 and RSA-4096 results remain attributable.

Telemetry

System-level metrics are collected through Prometheus across every run. During the QAT-accelerated run, additional telemetry is captured directly from the QAT engines so that engine utilization, latency, and bandwidth can be correlated with the application-level throughput numbers.

• System telemetry: CPU utilization, CPU power, memory utilization, and total system power.
• QAT telemetry (QAT runs only): Device utilization, peak public key engine (PKE) percentage, per-operation latency, input bandwidth, and output bandwidth.

Addendum: System Under Test

Hardware

Software stack

QAT run configuration

Copyright © 2026 Metrum AI, Inc. All Rights Reserved. This project was commissioned by Dell Technologies. Dell and other trademarks are trademarks of Dell Inc. or its subsidiaries.

***DISCLAIMER - Performance varies by hardware and software configurations, including testing conditions, system settings, application complexity, the quantity of data, batch sizes, software versions, libraries used, and other factors. The results of performance testing provided are intended for informational purposes only and should not be considered as a guarantee of actual performance.