Keenable’s seed round puts retrieval on the GPU plan

The event: independent retrieval becomes funded infrastructure

Dealroom reported on August 25, 2026 that Keenable.ai had emerged from stealth with a $26 million seed round led by Accel, with participation from Conviction Investment Partners and angel investors. The company is building independent web-search and retrieval infrastructure for AI labs, inference providers and other large-scale AI applications. TechCrunch also profiled Keenable the same day, describing a web search index exceeding 100 billion documents and an API already used in production at AI labs and inference providers during both training and runtime.

The important change is not only that another AI infrastructure company raised money. It is that web search, retrieval and index access are being treated as a first-order dependency for AI systems. For many model-serving teams, retrieval is no longer a nice-to-have feature that can be bolted onto a chatbot. It is part of how agents answer current questions, how inference providers add grounding to completions, and how training or evaluation workflows collect and refresh external context.

For operators of small and mid-size GPU estates, from a quarter rack to a few racks, this matters because retrieval moves pressure away from a single GPU scheduling problem and into a full-stack resource allocation problem. A retrieval-heavy AI service needs CPU for crawling, parsing and ranking; storage for documents, embeddings and index shards; network for fan-out and freshness; GPUs or accelerators for embedding, reranking and generation; and tenancy controls so one customer’s batch refresh does not take down another customer’s low-latency inference endpoint.

ClastIQ is built for that class of operator: real hardware, finite power, mixed CPU and GPU nodes, multiple tenants, and the need to turn infrastructure into a governed service rather than a collection of hand-built clusters. Keenable’s round is a useful signal because it shows where customer demand is moving. Even if an operator never builds a web-scale index, the same retrieval pattern will arrive inside enterprise AI, sovereign AI, local inference and sector-specific data products.

Retrieval changes the bottleneck profile

A pure model-serving cluster is hard enough: keep GPUs busy, isolate tenants, provide container images, expose inference endpoints, and meter usage. Retrieval adds several more moving parts.

First, the workload is mixed. Embedding jobs may run well on GPUs, NPUs or other accelerators. Parsing, deduplication and filtering are CPU-heavy. Vector search and keyword search often need memory, fast local SSDs, or distributed storage. Reranking can be bursty and GPU-backed. Generation may require larger slices or full accelerators, depending on the model.

Second, the workload has different time horizons. Crawling and indexing can be scheduled in batches. Embedding refreshes may run overnight. Interactive retrieval-augmented generation has latency commitments. Evaluation jobs are periodic but can be large. If all of these run on one flat Kubernetes cluster with no strong quotas or scheduling policy, the batch work will eventually collide with production inference.

Third, retrieval creates storage governance questions. The operator must know which tenant owns which index shards, which dataset is allowed to leave a jurisdiction, who pays for replicated storage, and how to retire data. In GCC and MENA deployments, those questions are not abstract. A university, bank, public-sector body or regulated enterprise may require that documents, embeddings and logs remain in-country or on a named site. Sovereign AI is not only about where the model weights sit. It is also about where the retrieved context, user prompts, audit logs and derived embeddings live.

Fourth, retrieval creates a metering problem. A tenant may consume 200 GPU-hours for embedding, 20 TB-months of Ceph capacity, 40 million vector queries, and 8 vCPU-years of parsing work. If the operator can only invoice or charge back on whole servers, the economics will be wrong. The GPU may look underutilised while the CPUs and disks are saturated, or the storage team may carry the cost of a tenant whose inference spend looks small.

What a small GPU estate will actually hit

Consider an operator with two racks containing 4 GPU servers and 8 CPU/storage servers. The GPU servers may be NVIDIA, AMD, or a mixed fleet acquired across procurement cycles. The CPU nodes run Kubernetes system services, index builders, API gateways, monitoring, CI jobs, and Ceph. The GPU nodes support model serving, embedding, reranking and occasional fine-tuning.

The first bottleneck is usually not raw accelerator count. It is fragmentation. One tenant asks for full GPUs for batch embeddings. Another wants small partitions for interactive reranking. A third wants VMs because its security team has not approved containers. A fourth needs Kubernetes and expects self-service namespaces. Without a platform layer, the operator ends up reserving whole machines for each tenant. Utilisation falls, and every exception becomes an operations ticket.

The second bottleneck is storage placement. Retrieval workloads generate many files, indexes and intermediate artifacts. If the operator stores these on local disks without a plan, rebuilds become painful. If everything is sent to a single shared storage pool without quotas, one index refresh can fill the pool. If backups and replicas are not charged back, tenants have no economic signal to clean up old embeddings or stale corpora.

The third bottleneck is power. A few racks can be power-limited before they are space-limited. Retrieval workloads tempt users to run batch work at the same time production inference peaks. If policy does not shape that demand, the operator either trips facility limits or holds back capacity permanently, reducing sellable GPU-hours.

The fourth bottleneck is accounting. A search or retrieval tenant may use fewer GPU-hours than a model-training tenant but far more CPU and storage. A simple GPU-only utilisation dashboard will not show whether the service is profitable.

ClastIQ addresses these as one operating problem rather than separate projects. Bare-metal provisioning through MAAS and Juju establishes a repeatable base. Kubernetes and VM tenancy can run on the same fleet. GPU partitioning through MIG where supported, time-slicing where appropriate, and accelerator-aware scheduling allow smaller slices to be sold or assigned without dedicating whole servers. Ceph provides shared storage with quota and policy controls. Metering and chargeback connect GPU-hours, CPU, memory, storage and tenant identity.

A worked example: making retrieval capacity billable

Assume a 32-GPU estate serving three tenant classes: inference endpoints, retrieval and embedding jobs, and internal development. The site has an all-in IT load of 35 kW for the relevant servers, storage and network. The operator carries $120,000 per month in allocated costs for depreciation, colocation or facility power, support, network, storage media, software operations and spares. This is not a universal number; it is a simple model for comparing utilisation.

There are 32 GPUs × 24 hours × 30 days = 23,040 available GPU-hours per month.

If weak tenancy and manual scheduling produce 42% billable GPU utilisation, the estate sells or allocates 9,677 GPU-hours. The effective cost per billable GPU-hour is:

$120,000 ÷ 9,677 = $12.40 per GPU-hour.

Now apply a more governed operating model. Full GPUs are reserved only for tenants that need them. Reranking services receive small accelerator partitions or time-sliced capacity. Batch embedding jobs run in lower-priority queues and are preemptible outside agreed windows. Development namespaces get hard quotas. Storage and CPU are charged back, so tenants do not treat them as free.

If billable utilisation rises to 70%, the estate allocates 16,128 GPU-hours per month. The effective cost per billable GPU-hour becomes:

$120,000 ÷ 16,128 = $7.44 per GPU-hour.

If the operator charges an internal or external rate of $8 per GPU-hour for the GPU component, monthly GPU revenue is:

16,128 × $8 = $129,024.

At 35 kW, that is $129,024 ÷ 0.035 MW = $3.69 million per MW-month, or about $44.2 million per MW-year before adding storage, CPU and network charges. The exact rate may be higher or lower, but the point is stable: utilisation and allocation policy change the economics more than small differences in server list price.

A retrieval tenant in this estate might receive the following monthly chargeback:

• 2,400 GPU-hours for embedding and reranking at $8.00 = $19,200
• 14,000 vCPU-hours for parsing and index maintenance at $0.04 = $560
• 18 TB-months of Ceph replicated storage at $35 = $630
• 6 TB-months of snapshot retention at $12 = $72

Total: $20,462 for the month.

That bill is useful because it tells the tenant where optimisation matters. If they reduce embedding refreshes by 20%, they save real money. If they keep stale indexes forever, they see the storage cost. If they need a reserved low-latency endpoint, it can be priced differently from preemptible batch work.

Controls that matter in practice

The table is intentionally operational. Retrieval infrastructure becomes manageable when each symptom maps to an enforceable control. A policy written in a spreadsheet is not enough; it has to become scheduling, quota, storage and network behaviour.

For example, a tenant running production retrieval might receive a Kubernetes namespace with hard CPU, memory, storage and accelerator limits. Resource names vary by hardware vendor and partitioning plugin, but the control pattern is the same:

kubectl create namespace tenant-retrieval-prod

cat <<'EOF' | kubectl apply -f -
apiVersion: v1
kind: ResourceQuota
metadata:
  name: retrieval-prod-quota
  namespace: tenant-retrieval-prod
spec:
  hard:
    requests.cpu: 96
    requests.memory: 384Gi
    requests.storage: 20Ti
    persistentvolumeclaims: 40
    nvidia.com/gpu: 4
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: retrieval-prod
value: 800000
globalDefault: false
description: Production retrieval and reranking priority
EOF

On an AMD-based estate, a mixed accelerator estate, or a site using partitioned devices, the resource names and device plugins change. The operator discipline does not: declare the tenant boundary, define what it can consume, assign priority, and meter the outcome.

Kubernetes and VMs on the same fleet

Retrieval teams do not all arrive with the same runtime model. Some want Kubernetes-native deployment with Helm charts, autoscaling and service meshes. Others bring licensed software that expects VMs. Some public-sector or financial-sector teams may require VM isolation for specific components while allowing containerised batch jobs elsewhere.

A small estate cannot afford to split its hardware into permanently separate islands for every runtime preference. If four GPU servers are divided into one Kubernetes island, one VM island, one development island and one reserved island, there may be no single pool large enough to absorb demand spikes. That is how operators end up with idle GPUs next to waiting jobs.

ClastIQ’s model is to provision the bare metal consistently, then support Kubernetes and VM tenancy on the same fleet. The operator can place a VM-based indexing appliance beside Kubernetes-based embedding jobs, while still applying quota, chargeback and storage policy. This is particularly important for GCC and MENA operators serving local enterprises, universities, ministries, media groups or Arabic-language AI teams. The buyer may care less about whether the workload is fashionable and more about whether it can run under local operational control, with local support, on hardware that the operator owns.

Storage is part of the product, not plumbing

A retrieval system without storage discipline becomes a cost leak. Documents are ingested, parsed, chunked, embedded and indexed. Each stage can leave artifacts behind. If tenants are experimenting, they may create multiple versions of the same corpus. If teams are tuning chunk size or embedding models, storage use can multiply quickly.

Ceph is a practical fit for this layer because it can provide shared block, object and file-style storage patterns depending on deployment design. The more important point is not the brand of storage software, but that storage must be governed as part of the AI platform. A tenant should not be able to consume 80% of a shared pool because its crawler loop ran over a weekend. A production index should have a clear replication and backup policy. A development corpus should have a deletion date. A sovereign dataset should have placement rules.

For chargeback, storage should be split at least into active indexed data, retained snapshots, and archive or backup capacity. Those classes have different costs and different operational consequences. Replicated high-performance storage is not the same product as cold retention.

Power and revenue per megawatt

GPU operators increasingly think in megawatts, even at small scale. A quarter rack may not sound like a regional cloud, but it still has a power envelope and an economic target. Retrieval workloads complicate the power curve because they combine steady services with bursty batch work.

A disciplined platform can help in three ways. First, it can schedule batch embedding and index rebuilds into lower-demand windows. Second, it can prevent development jobs from consuming production headroom. Third, it can expose the relationship between power, utilisation and revenue.

If the 35 kW estate above stays at 42% billable utilisation, the operator’s revenue per megawatt will be structurally limited no matter how capable the hardware is. Raising utilisation to 70% does not require pretending the GPUs are busy at every second. It requires turning more of the available time into governed, billable, tenant-attributed work. That is the difference between raw device utilisation and business utilisation.

For a GCC operator, this can be the line between importing cloud services and hosting local AI capacity economically. Power, land, fibre, sovereign data requirements and Arabic or regional content needs all interact. A local retrieval service may be valuable precisely because documents, prompts and embeddings remain under national or organisational control. But sovereignty without utilisation can become an expensive idle asset. Utilisation without governance can become an audit problem. The operating target is both.

What Keenable signals for operators

Keenable is building at web scale, with an index reported above 100 billion documents. Most small and mid-size operators will not build that. But the workload shape will appear locally: enterprise document retrieval, Arabic and bilingual search, media archive search, legal and regulatory assistants, customer support copilots, national knowledge bases, and inference endpoints that need grounding.

The infrastructure lesson is to prepare the estate for mixed demand before the first large retrieval tenant arrives. That means avoiding hard-coded assumptions that every AI workload is a full-GPU container. It means treating CPUs and storage as billable resources. It means building a policy model that can say yes to both a VM tenant and a Kubernetes tenant without dedicating half a rack to each. It means keeping air-gap and sovereign deployment options available where the customer requires them.

ClastIQ’s role in that operating model is not to replace the application layer. Keenable and similar providers may supply APIs, indexes, data products or retrieval services. The operator still needs to run local hardware efficiently: provision it, partition it, assign it, meter it, protect it and support it. That is the part that determines whether a few racks behave like a governed regional platform or like a collection of expensive servers.

What to do this week

1. Inventory current GPU, CPU, memory, storage and power utilisation by tenant, not only by node.
2. Define at least three scheduling classes: production inference, production retrieval, and preemptible batch indexing or embedding.
3. Put hard quotas on development namespaces and VM tenants before the next shared index or embedding project starts.
4. Separate active index storage, snapshots and archive retention in the chargeback model.
5. Test one mixed-tenant workflow: a VM-based service, a Kubernetes embedding job, and a shared Ceph-backed dataset with metering enabled.
6. For GCC or MENA deployments, document which datasets, embeddings, logs and backups must remain in-country or on-site.

ClastIQ runs this on the operator’s own hardware — request a demo.

Sources

• Dealroom: Keenable emerges from stealth with $26 million seed round
• TechCrunch: Accel-backed Keenable is indexing the web for AI agents