Testing AI Systems Across All Four Layers

Testing an AI system means testing four layers separately: infrastructure, model, orchestration/agent, and application. Each layer fails differently, so each needs its own tool, and all four results need to land in one place.

Our previous post discussed how it's easier for teams to test the scaffolding around AI systems but not the AI itself. You load test your infrastructure, red team the application. But what about the model's actual reasoning and the agent's decision making? That's mostly untouched. And you realize these issues when your agents start 'misbehaving'.

This post walks through each layer tool by tool, with the output each tool produces, and ends with where all four sets of results should land.

Which tool tests each layer of the AI stack?

Each layer of the AI stack needs its own testing tool, because each one fails in a different way. Here's the tool used for each layer in this walkthrough and the output it produces.

How does Testkube orchestrate AI testing across the stack?

Testkube handles test orchestration for the AI stack. It runs the testing tool for each layer as a Test Workflow in your clusters and sends every result to one execution history. Testkube isn't an AI evaluation tool, so it doesn't score a model's reasoning or red-team your prompts itself.

None of these tools talk to each other by default. NVIDIA's tooling checks GPU health. RAGAS evaluates model output. DeepEval checks agent and RAG behavior. Promptfoo red-teams the deployed application. Four tools, four output formats, four places those results live.

Testkube sits underneath all four tools and makes their results usable together.

• Testkube turns any of these tools, whatever script or CLI it ships with, into a standardized, executable Test Workflow, the same CRD-based building block whether it's running a GPU health check or a DeepEval suite. One catalog, one way to define, label, and version every test across all four layers, instead of four bespoke setups nobody maintains consistently.
• All of these tools run as workflows inside your own Kubernetes clusters, triggered by CI/CD, a schedule, an API call, or a Kubernetes event, with Testkube handling the setup and teardown for each one.
• Every workflow's log, artifacts, and results land in the same place, regardless of which of the four tools produced them. You get full lifecycle visibility per run, plus an analytics view tracking pass rates and trends across every layer at once, instead of four dashboards you have to cross-reference by hand.
• Because everything reports through the same execution history, Testkube's AI agents can correlate a failure at one layer against signals from another, without someone stitching four tools' output together manually.

That's the same tool-sprawl problem we discussed in the previous post. Without a platform pulling these results into one place, you can run every one of these tests perfectly and still have no answer to "is this AI system actually trustworthy," because that answer only exists when you can see all four signals side by side.

Layer 1: How do you test AI infrastructure and GPUs?

Test AI infrastructure with a Test Workflow that requests a GPU and then queries the model-serving process directly. The check confirms the model loaded and reports how much GPU memory it holds and how fast it answers.

Start at the bottom. This layer holds the compute, storage, networking and, most importantly, the GPUs. Any hardware-dependent workload needs these checks, AI or not. For AI workloads, the signal changes: the question is whether the model finished loading and whether the GPU holds the memory it claims to.

We've written about testing GPU resources in Kubernetes with Testkube before, and the pattern from that post still holds here, just pointed at an AI-specific workload instead of a generic CUDA matrix calculation.

The short version: Kubernetes exposes hardware through the Device Plugins framework, the NVIDIA Device Plugin advertises GPUs to the scheduler, and a Test Workflow requests that GPU the same way any Pod would.

apiVersion: testworkflows.testkube.io/v1
kind: TestWorkflow
metadata:
  name: model-serving-gpu-check
  namespace: testkube
spec:
  container:
    resources:
      limits:
        nvidia.com/gpu: 1
        memory: 200Mi
        cpu: 100m
      requests:
        nvidia.com/gpu: 1
        memory: 200Mi
        cpu: 100m
  pod:
    nodeSelector:
      cloud.google.com/gke-accelerator: nvidia-tesla-t4
  steps:
    - name: Check GPU allocation and model load state
      run:
        image: your-model-serving-check-image

In the original hardware testing post, the workload was a CUDA sample proving the GPU was schedulable at all. That's a fine proof point for "does this cluster have a working GPU node," but not an AI-specific signal on its own.

For an actual model-serving check, you swap that step for something that queries the serving process directly: is the model loaded, how much GPU memory is it actually holding, is inference latency inside bounds. Same Test Workflow shape, same GKE Autopilot setup from that earlier post provisioning the node on demand, different question being asked of it.

This is the layer that resembles familiar chaos and load testing the most closely. The only real shift is which counters you're reading off the node.

GPU checks are one slice of infrastructure testing. Our guide to infrastructure testing in Kubernetes covers the wider set of areas worth validating before workloads hit the cluster.‍

Layer 2: How do you test model output quality?

Test model output quality by scoring responses against a maintained test set instead of checking for one exact answer. Run the same prompt twice and you can get two different answers, both defensible. A binary pass/fail check can't handle that variation.

For RAG systems specifically, RAGAS measures two things that matter:

• Faithfulness: does the answer stay grounded in what was actually retrieved, or did the model hallucinate?
• Answer relevancy: does the answer actually address the question?

Rather than expecting a fixed output, you score against a maintained set of test cases and watch whether those scores hold steady across runs.

The evaluation flow is simple:

1. Testkube starts a workflow that runs RAGAS across all 20 test cases.
2. Each case is evaluated against two metrics: faithfulness and answer relevancy.
3. Results are exported in InfluxDB line protocol format so they can be tracked consistently over time.
4. If either metric falls below its configured threshold (0.80 for both faithfulness and answer relevancy), the test fails.
5. The developer gets immediate feedback in the logs, including the specific test cases that failed.

You can find the full test implementation, metric calculations, and Testkube integration in the Testkube RAGAS GitHub repository. The output is a metrics report with mean, min and max scores per metric, per category and per test case. It catches a quality drop on the run where it happens, before users report it.

Layer 3: How do you test RAG pipelines and agents?

Test RAG pipelines and agents by scoring the whole chain of steps on every code change and blocking the merge when a score drops. The previous post flagged this layer as the one where small errors compound silently. A mistake three steps into a chain surfaces later as a symptom that looks nothing like its cause.

The demo here comes from a RAG quality gate built with Testkube and DeepEval, gating a RAG pipeline as it moves through CI. The flow is straightforward:

git push (RAG code change)
↓
GitHub Action triggered
↓
Testkube runs a TestWorkflow with 20 automated test cases
↓
DeepEval scores: Faithfulness, Contextual Recall, Answer Relevancy
↓
Pass or fail - a quality drop blocks the merge

The Test Workflow lives in the repo, triggered by a GitHub Action on every push, and runs as a Kubernetes pod that clones the repo, installs dependencies, and runs the DeepEval test suite against a set of fixed Q&A test cases:

metrics = [
    FaithfulnessMetric(threshold=0.80),
    ContextualRecallMetric(threshold=0.75),
    AnswerRelevancyMetric(threshold=0.80),
]

Each metric checks something specific. Faithfulness asks whether the answer hallucinated anything not present in the retrieved context. Contextual recall asks whether the retriever found the relevant documents in the first place. Answer relevancy asks whether the response addresses the question. If any of the three drops below its threshold, the test fails and the merge is blocked. It's the same gate you'd expect from any CI quality gate, just scoring an LLM's output instead of a unit test's assertion.

What comes out the other end is a results JSON with a score per metric, per test case: 20 cases run, 20 sets of three scores, an aggregate pass or fail. To track those scores across runs in Testkube Insights, you can also report DeepEval results as JUnit XML.

Below is the InfluxDB format ingested by Testkube for custom metrics. In this scenario, the data is generated by the Testkube ai-metrics-parser from the DeepEval result files.

deepeval,metric=answer_relevancy,suite=rag-quality-gate cost=0.000315,errors=0i,failed=0i,mean_score=0.8,passed=1i,tests=1i

deepeval,metric=contextual_recall,suite=rag-quality-gate cost=0.000183,errors=0i,failed=0i,mean_score=1,passed=1i,tests=1i

deepeval,metric=faithfulness,suite=rag-quality-gate cost=0.000378,errors=0i,failed=0i,mean_score=1,passed=1i,tests=1i

deepeval,suite=rag-quality-gate errors=0i,failed=0i,passed=3i

That's the kind of output that's easy to check in isolation and easy to lose track of if it's sitting in its own GitHub Actions log while your infrastructure and application results live somewhere else entirely.

Layer 4: How do you red-team an AI application?

Red-team an AI application by attacking its deployed prompts and guardrails the way a hostile user would, then recording which attacks got through. This is the layer closest to the security testing you already run. Jailbreaks, prompt injection and policy violations stand in for the usual OWASP-style attack list.

Promptfoo is the tool that fits here, running in red-team mode against your deployed prompts and testing against the OWASP Top 10 for LLM Applications: prompt injection attempting to override system instructions, jailbreak attempts, PII leakage, and more. Worth noting: OpenAI announced it would acquire Promptfoo in March 2026. That is worth weighing if you are choosing a long-term red-teaming dependency, but it is not a reason on its own to avoid the tool.

The reason this layer needs its own kind of test, separate from Layer 2's model eval, is scope. The question is whether your specific application, with your system prompt and guardrails, holds up. A model can pass every general safety benchmark and still have an application built on top of it that leaks its system prompt to the first person who asks the right way.

A Promptfoo red-team config is written in YAML, so it's easy to version and run through a Test Workflow like any other test in this stack. The output is a report of attack attempts with pass/fail per vulnerability category: which jailbreak variants got through, which injection attempts the guardrails caught, and where the attack surface is thin.

In the example below, we built Finbuddy, a chat application that helps people learn finance terms. Without proper guardrails or a system prompt, anyone can trick it into sharing sensitive information. We ran Promptfoo with its default configuration, and the report surfaced the vulnerabilities in our prompt.

The report.json output shows how each prompt performed and which vulnerabilities Promptfoo discovered. To try it yourself, see the code in the Testkube Promptfoo GitHub repo.

Because instructions and data share the same channel in these systems, this isn't a category of test you run once and check off. It runs continuously, the same way you'd never consider a security scan "done" after a single pass.

Red-teaming prompts follows the same execution pattern as running a security scanner in-cluster. See that pattern in action in security testing in Kubernetes with OWASP ZAP.

Why do AI test results need to live in one place?

AI test results need to live in one place because no single layer can tell you whether the whole system is trustworthy. Left alone, the four tools in this walkthrough put their results in four places: an infrastructure check in one dashboard, a model eval script's console output, a GitHub Actions log for the RAG gate, and a red-team report in whatever directory Promptfoo wrote it to. Nobody reviews all four in the same sitting, because nothing puts them in the same place.

Testkube closes that gap. It doesn't care which tool produced a result, whether that's an NVIDIA health check, RAGAS scores, DeepEval metrics or a Promptfoo red-team report. It gives all of them one place to run and one place to be reviewed, so infrastructure, model, agent, and application results sit next to each other instead of scattered across four tools nobody cross-references.

That centralization is also what makes the next step possible. Testkube's AI agents already do a version of root cause correlation at the infrastructure layer, correlating a k6 test failure with cluster signals and filing a Jira ticket automatically, without someone manually cross-referencing logs. That pattern isn't proven yet across all four AI-system layers. Once every layer reports to the same place, it becomes the natural next step.

You can't point an AI agent at signals it can't see. Centralized visibility across all four layers has to exist first, which is why the orchestration layer comes before the triage layer.

Conclusion

Four layers, four tools: NVIDIA-based checks for infrastructure, RAGAS for the model, DeepEval for the RAG pipeline and agent layer, Promptfoo for the deployed application's guardrails. Each one testing something the others structurally can't, run through Testkube so the results actually end up somewhere you can compare them.

Our previous post argued that the model and orchestration layers are the two your team is probably skipping. This post showed what closing that gap looks like in practice.

Want to see what testing all four layers together looks like for your own AI system? Talk to the Testkube team.

Frequently Asked Questions

{{banner-get-started}}