Français
APPLIED AI — LEVEL INTERMEDIATE

Session 8 — Infrastructure & Deployment

From notebook to 10,000 users · Yann Isola · Works 100% offline

💸 Token cost calculator

The cost of an LLM (Large Language Model) application is calculated as follows: entry tokens × entry price + exit tokens × exit price . Play with the pattern, volume, prompt caching (prompt caching) and the template routing to see the bill melt away.
⚠ Price list fictional , inspired by orders of magnitude by mid-2026. In production, always check your supplier's daily schedule.

⚙️ Settings

📊 Result

Job$ / day
Entry — stable tokens
Input — variable tokens
Exit
Daily total

Estimated monthly cost (×30):

💡 Tip: activate caching then routing, and observe the invoice. This is Exercise 1 of the session.

🧠 What this calculator teaches

  • The exit costs 3 to 5× the entrance ⚠ — shortening responses is a cost AND latency lever.
  • Caching only works if the prompt is well structured : stable content at the beginning, variable at the end. A dynamic timestamp at the head of the prompt = cache invalidated.
  • Routing is often the biggest lever : the majority of requests from a support assistant are simple.

🏗️ Deployment Architecture Builder

Drag and drop (or click) components to assemble a request's path from client to response. The latency estimate adjusts, and the checker reports dangerous omissions (exposed API key, absence of logging, etc.).
⚠ Indicative latencies, for educational purposes.

🧰 Available components (click or drag to pipeline)

🔗 Your pipeline (order = request path)

Drop your first component here… (start with the Client 😉)

🧠 Reminders for proper assembly

  • There API key lives in the backend, never in the client → a backend is mandatory between client and LLM provider.
  • There logging costs almost nothing in latency and saves every diagnosis.
  • THE answer cache serves frequently asked questions without calling the model: latency ~10 ms instead of several seconds.
  • There queue (queue) is the pattern of massive asynchronous loads — it “breaks” the synchronous path: the user does not receive the response immediately.

🔭 Monitoring dashboard — SupportBot in production

Mock-up of a production dashboard with animated metrics: latency in percentiles (p50 / p95 / p99), TTFT (Time To First Token), error rate, token budget, cache rate. Use the button “Simulate an incident” to see the alerts trigger.

Availability (24 hours)

99,95 %
SLA objective: ≥ 99.9%

Error rate (5 min)

0,4 %
alert if > 2% for 5 min

Latency

2.1s
p50 1.1 sec · p95 above · p99 4.2 sec — ALS: p95 < 3 sec

TTFT p95 (streaming)

640ms
first token — objective < 1000ms

Token budget (months)

42 %
alerts at 50 / 80 / 100%

Cache rate (prompt caching)

91 %
share of stable tokens served from the cache

Model routing

81 %
share of traffic served by the small model

429 errors (rate limit)

2 / hour
all solved by exponential backoff
[08:00:12] ✅ Service started — all nominal metrics

🧠 How to read this dashboard

  • The average lies : look at the p95 and the p99, not the average. SLAs (Service Level Agreement) are written in percentiles.
  • Each alert has a documented action : “IF error rate > 2% FOR 5 min THEN penalty notified DOES check supplier status, activate degraded mode”.
  • This dashboard does not see the quality of the responses — this requires continuous evaluations and user feedback 👍/👎 (Session 9!).