Putting It Together: Building a Text-to-Image Service End to End

Identity statement: a minimal text-to-image service is five stages in a fixed order — encode, denoise, optimize, serve, and operate (monitoring plus versioning around the whole pipeline) — where each stage's job was already established by an earlier lesson in this module, and this lesson's contribution is showing how they chain.

[GROUND TRUTH] (Sources/nca-genm/domain-6-software-development.md) states the composition directly: "a CLIP text encoder produces context embeddings → a diffusion U-Net (trained with a framework, GPU-accelerated via cuDNN) denoises to an image → the model is optimized with TensorRT and served with Triton, with monitoring and versioning around it."

Stages 1 and 2 are the CLIP-plus-diffusion pipeline M6-03 already built completely; stages 3 and 4 are the two NVIDIA SDK jobs M6-04 named as the standing build/optimize/serve trap's optimize-and-serve half; stage 5 is the software-quality discipline M6-05 covered. This lesson does not re-derive any of the five — it runs them in sequence against one concrete example.

Treat every number below as a constructed scenario — illustrative, chosen to be realistic in shape, not measurements from any specific deployed system or named model checkpoint.

SERVICE: a text-to-image feature for a home-decor app, generating a preview
         image from a user's written room description.

PROMPT: "a minimalist living room with a linen sofa, a low wooden coffee
         table, and large windows letting in soft afternoon light"

STAGE 1 — ENCODE (CLIP text encoder, M4-03 / M6-03):
  1 forward pass through CLIP's text encoder
  output: context embedding v_prompt (768-dim)
  latency: ~8 ms on the serving GPU

STAGE 2 — DENOISE (diffusion U-Net reverse process, M6-01 / M6-02 / M6-03):
  50 reverse-process steps (a common illustrative step count for a
  latency-conscious deployment, trading some quality for speed versus a
  100+ step high-quality setting)
  each step: 1 U-Net forward pass, conditioned on v_prompt
  latency: ~40 ms per step x 50 steps = ~2,000 ms (2 seconds) BEFORE
           optimization

STAGE 3 — OPTIMIZE (TensorRT, M6-04 / M5-06):
  performed once, offline, before this pipeline ever serves a live request
  fuses U-Net operations, calibrates to FP16, tunes kernels for the
  deployment GPU
  effect: per-step U-Net latency drops from ~40 ms to ~14 ms
          (illustrative ~2.8x speedup from fusion and reduced precision)
  STAGE 2, RE-MEASURED after optimization:
    ~14 ms per step x 50 steps = ~700 ms

STAGE 4 — SERVE (Triton, M6-04):
  the optimized U-Net and the CLIP text encoder are both loaded as
  versioned models on Triton
  concurrent requests are dynamically batched where request timing allows
  end-to-end latency per request, optimized: ~8 ms (encode) + ~700 ms
    (denoise) = ~708 ms, before network/queueing overhead
  throughput: batching several concurrent prompts' denoising steps
    together raises throughput well above the single-request latency
    figure would suggest, at some added per-request latency under load

STAGE 5 — OPERATE (monitoring + versioning, M6-05):
  monitored signals: p50/p95 end-to-end latency, error rate on malformed
    prompts, GPU utilization, and a sampled output-quality check
  versioning: the CLIP encoder version, the U-Net checkpoint version, and
    the TensorRT-compiled artifact's version are all tracked together as
    one deployable unit, so a regression can be traced to exactly one
    changed component
  RESULT: a generated preview image of the described living room, returned
    in roughly 0.7-1 second end to end under normal load

Read the latency figures across stages 2 and 3 together, because that comparison is the concrete demonstration of what M6-04 named abstractly: TensorRT's optimization is not a rounding error, it is the difference between a ~2-second and a ~0.7-second response for the identical model, and that difference is realized entirely before Triton ever serves a single request — optimization is a one-time, offline cost that pays back on every subsequent request the service handles.

Objective 6.4/6.5's synthesis is partly a decision between named alternatives, and the decision most directly in this module's control is how many reverse-process steps to run. This is a second constructed scenario, illustrative rather than measured, isolating that one design choice against the same optimized per-step cost from section 2.

SAME SERVICE, two deployment configurations, same optimized U-Net
(~14 ms per step after TensorRT):

CONFIGURATION A — latency-optimized (e.g., an interactive preview feature
                  where the user is waiting on screen):
  steps: 25 (fewer reverse-process steps)
  denoise latency: ~14 ms x 25 = ~350 ms
  total (encode + denoise): ~8 ms + ~350 ms = ~358 ms
  quality tradeoff: coarser denoising per M6-02's own step/quality
    relationship — fewer steps means less refinement, and fine detail
    or compositional accuracy may visibly suffer versus more steps

CONFIGURATION B — quality-optimized (e.g., a batch job generating final
                  marketing images overnight, with no user waiting):
  steps: 100 (more reverse-process steps)
  denoise latency: ~14 ms x 100 = ~1,400 ms
  total (encode + denoise): ~8 ms + ~1,400 ms = ~1,408 ms
  quality tradeoff: finer denoising, generally sharper and more accurate
    to the prompt's compositional detail, at roughly 4x configuration A's
    latency

Neither configuration is "the correct" choice in the abstract — the decision rule is the same shape M3-01's experiment-design lesson already established for any tradeoff: name the constraint that actually matters for the deployment. An interactive feature where a user is watching a loading indicator favors configuration A's roughly one-third-second response even at some quality cost; an overnight batch job with no one waiting favors configuration B's roughly 1.4-second response for the better result, because latency is not the binding constraint there at all. This is a decision TensorRT's optimization (stage 3) does not make for you — TensorRT reduces the cost per step, but how many steps to run in the first place is a separate, service-level design choice made on top of that reduced cost.

Each stage in section 1 depends on the previous stage's output in a way that makes reordering nonsensical, not merely suboptimal, and a scenario question testing "putting it together" is often testing exactly this dependency structure.

The two truly fixed dependencies are encode-before-denoise (a structural requirement of conditioning) and train-before-optimize (you cannot optimize a model that does not yet exist). Optimize-before-serve is a strong recommendation rather than an absolute requirement — Triton can technically serve an unoptimized model — but skipping it forfeits exactly the latency improvement section 2's numbers demonstrate.

M6-03 established stage-symptom attribution for the CLIP-plus-diffusion pipeline specifically; this section extends that same reasoning across all five stages of the full service.

Every fact in sections 1 through 4 already existed somewhere in this module. What this lesson's synthesis adds is a property none of the five stages have individually: an end-to-end latency and reliability budget that only exists once all five are chained. M6-01 never had to reason about whether its U-Net's skip connections mattered at production scale; M6-04 never had to reason about how much TensorRT's speedup actually mattered against a full request's latency; M6-05 never had to reason about which specific component a version regression traced back to inside a five-stage pipeline. Composition is where those questions first become answerable, because they are questions about the system, not about any one of its parts.

Trace the chain of dependency backward from this lesson's worked example and every prior lesson in this module (plus M4-03, outside the module) turns out to be load-bearing at a specific, nameable point. M4-03 is where the shared embedding space that makes stage 1's context embedding meaningful was built — without it, "encode the prompt" would have no vector space to land in. M6-01 is where skip connections were established as the reason stage 2's output is sharp rather than blurred. M6-02 is where the distinction between a single U-Net call and the many-call reverse process was drawn, which is exactly why stage 2 in section 2's worked example runs 50 separate forward passes rather than one. M6-03 is where conditioning was shown to require re-supplying the embedding at every one of those 50 calls, not just the first — a fact this lesson's stage 2 relies on without restating it. M6-04 is where TensorRT and Triton's distinct jobs were named, which is what makes stage 3's latency drop and stage 4's continuous serving two separate line items rather than one blurred "inference" step. M6-05 is where reproducibility, versioning, and validation were established as named practices, which stage 5 applies directly rather than inventing from scratch. None of those six citations is decorative — each one is the specific fact this lesson's corresponding stage depends on to make sense at all.

⭐ THE EARNED INSIGHT None of this module's five prior lessons was wrong to treat its own mechanism in isolation — that is the correct way to learn each piece precisely. But a working system is not simply five correct pieces sitting next to each other; it is five correct pieces with a fixed dependency order, a measurable end-to-end latency budget, and a version-tracking discipline that lets a failure be traced back to exactly one of them. That composition, not any single mechanism, is what a "putting it together" scenario question is actually testing — not whether you know each piece, but whether you can place a described symptom or a described design choice at the correct stage of the assembled whole.

Software Development is 15% of the NCA-GENM exam. [GROUND TRUTH] (Sources/nca-genm/domain-6-software-development.md) explicitly frames putting it together as its own subsection, stating that a minimal build combining CLIP, a diffusion U-Net, TensorRT, and Triton mirrors the domain's objectives end to end. This is a direct signal that the exam does not treat objectives 6.1 through 6.5 as five independent facts — it expects a candidate to also recognize the assembled system a scenario describes, and to place a described symptom or design decision at the correct point in that assembly.

This module's own scope note, quoted at the start of M6-01, sets the altitude for every one of its six lessons including this one: understand the architectures and SDK roles and how they fit together, not ship a production service from scratch. This lesson's synthesis honors that altitude specifically by staying at the level of "which stage owns which job, in which order, with what measurable consequence" rather than descending into implementation details — no exam question on this domain expects you to write the code that calls Triton's API or configures TensorRT's calibration settings, but a well-constructed scenario question absolutely can describe the resulting system's behavior and expect you to reason about it correctly at exactly the depth this lesson has modeled.

The question tends to arrive in a small number of recognizable shapes.

1. Full-pipeline-ordering items. "What is the correct end-to-end sequence for a text-to-image service, from prompt to served output?" The keyed answer is the five-stage order from section 1; distractors reorder stages or omit one, most often omitting the optimize step or the versioning/monitoring wrapper.
2. Cross-stage symptom-attribution items. A scenario describes a failure somewhere in a deployed service and asks which component is responsible. The keyed answer routes the symptom to its owning stage, exactly as section 5 works through.
3. Component-substitution items. A question tests whether TensorRT and Triton, or CLIP and the U-Net, are being treated as interchangeable when they are not — the standing traps from M6-04 and M6-03, reapplied at the full-system level.
4. "What does putting it together add" items. A question probes whether a candidate understands that the assembled system introduces properties (end-to-end latency, cross-component version tracking) that no individual stage has alone.

What the distractors typically look like

The reliable distractor families here are: reordering the five stages in a way that violates a real dependency (denoise before encode, optimize before a model exists); attributing a systemic symptom (slow production latency, an unexplained output change) to the wrong stage by picking whichever component the question mentions most recently; and describing monitoring or versioning as optional refinements rather than as named, required parts of the domain's own "putting it together" framing.

Encoding the prompt with CLIP's text encoder into a context embedding. Every later stage depends on this one completing first: the diffusion U-Net's reverse process needs that embedding to condition on at every step, so there is no image to generate, optimize, or serve until stage 1 has produced a vector for the pipeline to work from. This is also why a scenario describing a service that appears to "denoise before encoding" is describing something structurally impossible, not merely an unusual design choice — the dependency is fixed by what conditioning actually requires, not by convention.

Notice that this same fixed ordering is also what makes stage 1 the cheapest possible point to catch a broken or malformed prompt. M6-05's input-validation practice, applied at this exact point in the pipeline, means a request that fails validation never reaches stages 2 through 5 at all — no wasted denoising steps, no optimized-model inference cycles spent on an input that was never going to produce a usable result. Placing validation anywhere later in the chain would mean paying most of the pipeline's cost before discovering the request should have been rejected in the first place.

Not necessarily, and this is exactly the kind of system-level reasoning the assembled pipeline introduces that no single stage's lesson could test on its own. A single-request benchmark, run in isolation, measures the encode-plus-denoise latency alone; production latency also includes contention from Triton handling multiple concurrent requests, batching wait time, and network overhead the isolated benchmark never included. Before concluding the model or its optimization is at fault, check whether the gap is explained by serving-stage contention under real load — a healthy model and a correctly-optimized artifact can still show worse end-to-end latency in production simply because production has traffic testing did not.

• A minimal text-to-image service is five ordered stages: encode (CLIP), denoise (diffusion U-Net), optimize (TensorRT), serve (Triton), and operate (monitoring plus versioning) — each stage built by an earlier lesson in this module, chained here for the first time.
• Encode-before-denoise and train-before-optimize are fixed dependencies; optimize-before-serve is a strong recommendation that captures both TensorRT's and Triton's benefits together.
• TensorRT's optimization is a one-time, offline cost that pays back on every subsequent request — in this lesson's worked example, cutting per-step U-Net latency by roughly two-thirds before Triton ever serves a single request.
• A production symptom should be routed to exactly one of the five stages, using the same stage-symptom reasoning M6-03 and M6-05 established, extended here across the full assembled system.
• Composition introduces properties no individual stage has alone: an end-to-end latency budget, and a version-tracking discipline spanning all three deployed components (encoder, checkpoint, optimized artifact).
• Monitoring and versioning are named, required parts of "putting it together," not optional refinements layered on afterward.

Work through each item before checking the answer key. Every option is a real claim about some stage of this pipeline — the task is matching it to the described scenario, not spotting an obviously fabricated distractor.

1. What are the five stages of a minimal text-to-image service, in order?
   • A. Serve, optimize, denoise, encode, operate.
   • B. Encode, denoise, optimize, serve, operate.
   • C. Optimize, encode, serve, denoise, operate.
   • D. Operate, encode, optimize, denoise, serve.
2. Why must encoding happen before denoising?
   • A. It does not need to — the two can run in either order.
   • B. The diffusion U-Net's reverse process needs a context embedding to condition on at every step, so there is nothing to condition against until encoding completes.
   • C. Triton requires encoding to complete before it will accept any request.
   • D. TensorRT cannot optimize a model until encoding has run once.
3. What does TensorRT's optimization step actually change about the pipeline?
   • A. It changes what content the model generates.
   • B. It changes the trained weights' values through additional training.
   • C. It reduces per-step inference latency through fusion, precision calibration, and kernel tuning, applied once, offline.
   • D. It replaces the need for a serving layer entirely.
4. A deployed service benchmarks fast in isolated testing but is noticeably slower in production. What is the most likely explanation?
   • A. The model's weights degraded after deployment.
   • B. TensorRT's optimization silently reverted.
   • C. Concurrent request contention and batching wait time at the serving stage, not present in an isolated single-request benchmark.
   • D. CLIP's text encoder requires retraining periodically.
5. A production image generator starts producing different results for the same prompt and seed after a routine update, with no code change intended to affect output. What is the most likely cause?
   • A. Random noise seeds cannot be fixed in production.
   • B. An unpinned or silently-changed component — the encoder, checkpoint, or optimized artifact were not versioned together.
   • C. Triton automatically retrains models on a schedule.
   • D. CLIP's contrastive objective is inherently nondeterministic.
6. Generated images consistently match their prompts but are noticeably blurrier than expected. Which stage is most likely responsible?
   • A. Stage 1 (encode).
   • B. Stage 2's U-Net architecture, specifically missing or weak skip connections.
   • C. Stage 4 (serve).
   • D. Stage 5 (operate).
7. Can Triton serve a model that has not been optimized with TensorRT?
   • A. No — Triton requires TensorRT optimization as a prerequisite.
   • B. Yes, but doing so forfeits the latency improvement optimization would have provided.
   • C. No — only CLIP-encoded inputs can be served by Triton.
   • D. Yes, and there is no latency difference either way.
8. What does "putting it together" test that no individual stage's lesson could test on its own?
   • A. Whether you can define each stage's mechanism in isolation.
   • B. Whether you can compute an end-to-end latency budget and trace a symptom to the correct stage within the assembled system.
   • C. Whether CLIP's contrastive loss converges.
   • D. Whether TensorRT and Triton are the same tool.

Answers

1. B. Encode, denoise, optimize, serve, operate — the fixed order this lesson builds around, matching the source material's own "CLIP → U-Net → TensorRT → Triton, with monitoring and versioning around it" framing.
2. B. Conditioning requires a context embedding to already exist before the reverse process's steps can be steered by it; there is a structural dependency, not merely a convention, between the two stages.
3. C. TensorRT's job is inference-time optimization (fusion, precision calibration, kernel tuning) applied once, offline, before serving — it does not retrain weights, change content, or replace serving.
4. C. An isolated benchmark does not include the contention multiple concurrent requests create at the serving stage; production latency reflects that contention in a way a single-request test cannot.
5. B. Without all three deployed components — encoder, checkpoint, optimized artifact — versioned together, a routine update can silently swap one of them, changing output even with a fixed prompt and seed.
6. B. Blur with otherwise-correct content is the signature symptom of a U-Net architecture issue (missing or weak skip connections), not an encoding, serving, or operations problem.
7. B. Triton can technically serve an unoptimized model, but doing so gives up the real latency benefit TensorRT's optimization would have provided — the two are not mutually required, but skipping optimization has a real, measurable cost.
8. B. Composition-level questions — an end-to-end latency budget, and routing a production symptom to the correct one of several assembled stages — only become answerable once all five stages are chained together, which is exactly what no single stage's own lesson could test in isolation.

This module has now built a complete multimodal generative system from its architecture up through its deployment discipline: a U-Net's structure and its two generative roles, a CLIP-conditioned diffusion pipeline, the NVIDIA SDK stack that trains, optimizes, and serves it, and the prompt-engineering and software-quality practices that keep it trustworthy in production. The next module turns from building the system to auditing it responsibly — bias, privacy, content authenticity, and the trustworthy-AI checklist a system this capable of generating convincing synthetic media specifically demands. Next: M7-01 opens the Trustworthy AI module with the ethical principles — privacy, safety, transparency, and nondiscrimination — a system like this text-to-image service has to be evaluated against before it ships.