A Gemini app is too slow and costly. What do you optimize?
Why B is the answer
Model choice, prompt length and output limits, for cost and latency
Model choice, prompt length and output limits all drive the cost and latency of a Gemini app.
In detail
- Model choice, prompt length and output limits decide cost and latency.
- Measure quality after each change.
Use case
An illustrative scenario, not a real incident.
A Gemini app moves simple calls to a smaller model, shortens prompts and caps output, so cost and latency fall.
See it in different ways
stateDiagram-v2 [*] --> Prompting Prompting --> Rag: lacks current facts Prompting --> FineTuning: quality or format is not reached Prompting --> Done: meets the need Rag --> Done FineTuning --> Done
mindmap
root(("Cost and latency"))
n1["Model"]
n2["Smaller model"]
n3["Input"]
n4["Shorter prompt"]
n5["Output"]
n6["Lower limit"]Key point: Tune model, prompt and output.
Why the other options are wrong
- A. The training split of a model that you are not training
- That is unrelated to a Gemini app.
- C. The number of notebooks in your Agent Platform Workbench project
- Notebooks are not in the request path.
- D. The retention period of logs in your Cloud Storage bucket
- Log retention does not affect latency.

