An engineering team must raise the throughput of a customer-facing LLM service on a fixed GPU budget without weakening its trustworthiness guarantees. Which measures let them serve more concurrent users while preserving the safety behaviour the service already passes? Select THREE.
- ABatch concurrent requests for generation while still running the input and output guardrails on every individual request in the batch. Correct
- BRe-run the model's safety evaluation suite after applying any efficiency change, such as quantisation, before promoting it to production. Correct
- CCache responses only for identical, non-personalised prompts and bypass the cache for any request containing user-specific or sensitive content. Correct
- DDisable the output guardrail during peak load so the safety check stops adding latency when the service is busiest.
- EShorten the maximum context window so the model processes fewer tokens, accepting that some retrieved safety context may be truncated.
Why A is correct: Batching raises GPU utilisation and throughput, and keeping per-request guardrails means each user is still screened, so efficiency does not bypass safety.
Why B is correct: Efficiency changes can silently degrade safety-critical behaviour, so re-testing the safety suite confirms the optimised model still meets the trustworthiness bar.
Why C is correct: Caching repeated public answers cuts compute, while excluding personalised prompts prevents one user's sensitive output being served to another.
Why D is wrong: Dropping the output filter does cut latency, but it removes protection exactly when traffic and risk are highest, which is when enforcement matters most.
Why E is wrong: A smaller window saves compute, but truncating retrieved grounding or policy context can weaken factual and safety behaviour the service relied on.