Title: Quiz 15 — Serving Adapted and Quantized Models — Handoff to AIINFRA 200
Course: AIINFRA 201: Model Adaptation — Fine-Tuning & Quantization > Section: Week 15 — Serving Adapted and Quantized Models — Handoff to AIINFRA 200

Q: vLLM and Hugging Face TGI both support loading a single base model once and serving many LoRA adapters against it per-request.
- True
- False
A: True

Q: What is the hard constraint that governs whether multiple LoRA adapters can be served together against the same base model instance?
- They must all have been trained on the same dataset
- They must all target the same base model architecture and dtype
- They must all use the same rank (r) value
- They must all be quantized to the same bit-width
A: They must all target the same base model architecture and dtype

Q: When serving a quantized base model in vLLM, which LoRA adapters are supported?
- Any adapter, regardless of which layers it targets
- Only adapters that modify attention and MLP projection layers
- Only adapters that modify embed_tokens and lm_head
- Only adapters trained with QLoRA specifically
A: Only adapters that modify attention and MLP projection layers

Q: If a LoRA adapter targets unsupported layers or is loaded with an incorrect path/format in vLLM, the server will raise a clear error and refuse to start.
- True
- False
A: False

Q: Name one benefit and one cost of merging a LoRA adapter into its base model before deployment.
Feedback: Sample/expected answer: Benefit: removes PEFT-specific runtime code dependencies and can modestly improve inference latency. Cost: loses the ability to hot-swap adapters (and, for quantized models, risks performance degradation from low-rank approximation interacting with quantization-induced rounding).

Q: According to this week's lecture, what should you do before attempting full fine-tuning to achieve a desired model behavior?
- Go straight to full fine-tuning for best results
- First validate the behavior is achievable with LoRA/QLoRA
- Quantize the model first, then fine-tune
- Merge an existing adapter and test it in production
A: First validate the behavior is achievable with LoRA/QLoRA

Q: Merging a 4-bit quantized fine-tuned LoRA adapter back into the base model is always a safe, lossless simplification.
- True
- False
A: False

Q: In this week's lab, you served the same fine-tuned model through more than one path (e.g., Ollama and llama.cpp/vLLM). What is one reason a "silently working" server is not sufficient proof that your adapter is applying correctly?
Feedback: Sample/expected answer: Because unsupported adapter layers or bad paths/formats can cause the adapter to silently fail to apply while the server keeps running normally — so you must test with prompts that specifically probe the fine-tuned behavior to confirm the adapter is actually active.