Clinic kiosks call a local GPU service to classify chest X-ray triage images in under a second per request. Which workload type is this?
Select an answer to reveal the explanation.
Short Explanation
Each kiosk tap is a quick ‘what do you see?’ to a model that already went to school. That’s inference—fast, per-request serving—not distributed optimization of model weights on large X-ray datasets.
Full Explanation
Clinic kiosks calling a local GPU service to classify chest X-ray triage images in under a second per request exemplify inference: low-latency, request-driven serving of a trained model. The model weights are already fixed for that serving window; each kiosk request triggers a forward pass (and post-processing), not distributed optimization of model weights on large X-ray datasets. Distributed optimization of model weights on large X-ray datasets conflates training with serving and would never meet sub-second triage latency. Batch inference — queued scoring of stored X-ray studies for reports may prepare scores for later review, but it does not classify X-ray images for live kiosks. Fine-tuning — nightly retraining of a triage model on labeled scans is a different training cadence and does not match discriminative medical image classification under tight latency. Exam caveat: clinical inference still requires model governance, PHI controls, and human escalation paths; calling it inference does not waive validation or safety review. Operational check: measure p95/p99 latency under expected kiosk concurrency, confirm the service loads a validated checkpoint rather than training in-line, and keep training jobs off the inference path used by triage kiosks.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.