Technical Fundamentals

Technical Fundamentals is 6.1% of the CCDV-F blueprint, three or four of the 53 scored questions and the largest sub-skill in its domain. It covers the resource mechanics around a call: rate limits and their separate dimensions, streaming and why long generations need it, what really drives latency, and how token usage is reported.

Written by Kiran Manne

6.1% of the CCDV-F blueprint, which is roughly 3 questions of 53. It sits inside Model Selection and Optimization, worth 16.8% in total.

Technical Fundamentals is the largest sub-skill in Model Selection and Optimization at 6.1 percent, three or four of the 53 scored questions. Its subject is the plumbing around a call rather than the model or the message format: how requests are metered, how a response travels, what makes one call slower than another, and how the tokens you are billed for are reported back.

This is where a candidate whose experience runs through a framework wrapper is most exposed, because a wrapper handles all of it. It opens the stream, it backs off on a throttle, it accumulates the response, and it reports one number for usage. Under load, when a service is being throttled or a long generation is timing out, the wrapper is exactly the layer you have to look underneath.

The organising insight is that a request consumes three separate resources and each is limited on its own terms. It occupies a slot, so requests per minute is a ceiling. It carries input tokens, metered per minute. And it produces output tokens, metered separately again. A workload can sit comfortably inside two of those ceilings and be throttled by the third, which is why one number for capacity is never the right answer.

What the exam tests here

Rate limiting as several independent dimensions, and diagnosing which one a workload is hitting
Responding to a throttled request correctly, including honouring the interval the response supplies
Streaming as an incremental event sequence, and why a long generation needs it
What drives time to first token versus total time, and which levers move which
Reading the token usage breakdown, including the parts reported separately from the plain input count
Measuring rather than estimating: counting tokens for a specific model, querying capabilities rather than assuming them

Three limits, not one

Capacity is metered along separate axes: how many requests you may start in a window, how many input tokens you may send in it, and how many output tokens you may generate.

A chat product with short prompts usually meets the request ceiling first. A document-analysis job with enormous prompts and one-line answers meets the input ceiling while barely touching the others. A generation workload producing long artefacts meets the output ceiling.

The diagnostic value is that each has a different remedy: batching or queueing for the first, trimming or reusing context for the second, shorter or streamed outputs and more headroom for the third. Adding parallel workers helps only when the constraint is the number of slots.

Throttling, and the polite way to respond

A throttled request comes back with a distinct status meaning too many requests, and the response usually carries an interval telling you how long to wait. Honouring that interval beats inventing a delay, because a fixed sleep across a fleet produces a thundering herd and an aggressive retry consumes the very headroom you are waiting for. Add jitter to whatever backoff you use, so clients do not synchronise.

The official libraries already retry this class with backoff a small number of times by default, which is worth knowing in both directions: you inherit sensible behaviour, and you can end up with two retry layers if you write your own on top without turning theirs down.

Streaming is a sequence of events, not a faster call

A streamed request returns incrementally: the message frame first, then blocks opening, deltas appending to them, blocks closing, and a final event carrying the completed message metadata.

The total time to a finished answer is not reduced, so streaming is not a throughput optimisation. What changes is that the first useful output arrives in a fraction of the time.

There is also a hard reason to use it that has nothing to do with perception. A request permitted to generate a very large number of output tokens can run longer than the client's request timeout, so a non-streaming call with a large cap can fail on the clock rather than on the content. Long generations belong on the streaming path by default, with the library's helper assembling the final message when you do not need each event.

Read usage rather than estimating it

Every response reports what it consumed, and the breakdown has more parts than candidates expect. The plain input figure counts only the portion neither written to nor served from a cache; tokens written into a cache and tokens read from one are reported as their own numbers and priced differently again. Adding all three together gives the true size of the prompt that was processed. Output tokens include the reasoning the model did as well as the visible answer.

Two measurement habits follow. Log the breakdown per call rather than one total, because the components move independently and that movement is the signal. And when you need a count before sending, use the counting endpoint against the specific model identifier, since tokenisation is a property of the model rather than of the text.

Where candidates go wrong

Trap: adding workers to fix a throttled workload

Horizontal scaling is the reflex for a slow queue and it addresses only one of the three ceilings. If the limit being hit is input tokens per minute, ten workers send the same volume of tokens and are throttled together, having achieved nothing but a larger retry storm.

Identify the dimension first, which the throttling response and your own usage logs will tell you, then apply the matching remedy: fewer or smaller prompts, reuse of a stable prefix, an asynchronous path for work nobody is waiting on, or a quota increase. Parallelism is the answer only when slots are the constraint.

Trap: treating streaming as an optimisation

Because a streamed response starts arriving almost immediately, it is easy to record it as a performance win and reach for it when a cost or throughput problem is described. It changes neither. The same tokens are generated and billed, and the final token lands at roughly the same moment either way.

What streaming genuinely buys is perceived responsiveness and the ability to finish a long generation without hitting a client timeout. Asked how to reduce spend, streaming is a distractor. Asked why a large generation fails after several minutes with nothing returned, it is the answer.

Trap: sizing a request against the context window alone

Two separate ceilings apply, and confusing them produces both of the classic errors. The context window bounds the request and the response together; the output cap is a separate parameter bounding only what this response may generate.

Sizing prompts against the window while leaving a small output cap yields answers truncated mid-sentence, with the reason recorded on the response rather than raised. Setting a very large cap without streaming yields a call that runs past the client timeout. Reserve room for the answer inside the window, set the cap to what the answer actually needs, and stream when that number is large.

Common questions

How many CCDV-F questions come from Technical Fundamentals?

6.1 percent of the blueprint, so three or four of the 53 scored questions, and the largest of the four sub-skills in Model Selection and Optimization. Together with LLM Fundamentals it makes up two thirds of that domain's weight.

Which rate limit am I actually hitting?

Look at the shape of your traffic before changing anything. Many small calls exhaust the per-minute request allowance, a few very large prompts exhaust the input-token allowance, and long generations exhaust the output-token allowance. The throttling response and your own usage logs distinguish them, and each has a different fix, so guessing wastes a deployment.

Does streaming make a request cheaper or faster?

Neither. The same tokens are produced and billed, and the last token lands at about the same time. What changes is that output becomes visible almost immediately, and that a long generation can complete without exceeding the client's request timeout, which is why it is effectively required for very large outputs.

Why does the reported input token count look too small?

Because the plain input figure excludes tokens served from or written to a cache, which are reported as separate numbers. The full size of the processed prompt is the sum of the three. Logging only the plain figure makes a well-cached workload look impossibly cheap and hides the moment caching stops working.

The rest of Model Selection and Optimization

Practise this

The CCDV-F bank covers every sub-skill in the blueprint, weighted the way the real paper is. Free sample questions need no account.

Free CCDV-F questions