AI a Cloudflare platformon

15.1A hat építőelem — és mire való melyik

15.2Workers AI — inference bindingként

A modell-futtatás ugyanaz a bindings-élmény, mint minden más (1. modul): nincs API-kulcs, nincs endpoint, nincs SDK — a binding maga a hozzáférés.

{ "ai": { "binding": "AI" } }

export default defineEventHandler(async (event) => {
  const { env } = event.context.cloudflare;
  const { text } = await readBody(event);

  const res = await env.AI.run("@cf/meta/llama-3.3-70b-instruct-fp8-fast", {
    messages: [
      { role: "system", content: "Foglald össze magyarul, 3 mondatban." },
      { role: "user", content: text },
    ],
  });

  return { summary: res.response };
});

A katalógusban szöveg-generáló modellek (köztük function calling / reasoning képesek), embedding-modellek, kép- és beszédmodellek vannak — a lista folyamatosan bővül, ezért konkrét modellnevet mindig a friss katalógusból vegyél. Elérhető három módon: binding, REST API, illetve OpenAI-kompatibilis endpoint (/v1/chat/completions) — ez utóbbi azért fontos, mert a meglévő OpenAI-SDK-s kódod base URL-cserével átirányítható.

15.3AI Gateway — a legjobb ár-érték a listán

Ez az a darab, amit ma is bevezethetnél, még mielőtt bármit Cloudflare-re költöztetnél: egy proxy az AI-hívásaid elé, ami cache-el, logol, rate limitel, és költséget mér — szolgáltatófüggetlenül. A kódváltozás egyetlen sor, a base URL:

import OpenAI from "openai";

const openai = new OpenAI({
  apiKey: env.OPENAI_API_KEY,
  baseURL: `https://gateway.ai.cloudflare.com/v1/${ACCOUNT_ID}/default/openai`,
});
// innentől minden hívás a Gatewayen megy át — a kód többi része változatlan

Mit nyersz vele konkrétan a te SaaS-odban:

• Cache — az azonos promptokra adott válaszok újrahasznosítása. Ha van egy „magyarázd el ezt a hibakódot" funkciód, amit sok user ugyanúgy hív, ez azonnali pénz- és latencia-megtakarítás.
• Rate limiting — a Gateway szintjén, mielőtt a szolgáltatód drága endpointjához érne. Kiegészíti a 7. modul tenant-limiterét: ott az üzleti kvóta, itt a költségvédelem.
• Költség- és használatkövetés — melyik modell, mennyi token, mennyi pénz. Multitenant rendszerben ez az alapja a „AI-funkció tenantonkénti költsége" kérdésnek (a részletes meteringhez az Analytics Engine, 9. modul).
• Fallback és retry — ha az elsődleges szolgáltató elesik, átirányítás egy másikra; a te kódodban ez nem jelenik meg.
• Log — mi ment ki, mi jött vissza; hibakereséshez és minőség-ellenőrzéshez felbecsülhetetlen.

15.4RAG a gyakorlatban: Vectorize vs. AI Search

A tipikus SaaS-igény: „a felhasználó kérdezhessen a saját dokumentumaiból / a súgónkból". Erre két szint van:

AI Search — a kulcsrakész út

Feltöltöd a tartalmat, ő indexeli (beépített tárral és vektor-indexszel), te pedig keresel vagy kérdezel rá. Nem kell embedding-pipeline-t építened, chunkolni, vektor-indexet karbantartanod:

const instance = env.AI_SEARCH.get("tenant-acme-docs");

// feltöltés + indexelés
await instance.items.uploadAndPoll("onboarding.md", content);

// keresés / kérdés
const results = await instance.search({
  messages: [{ role: "user", content: "hogyan hívok meg egy webhookot?" }],
});

Ami a te multitenant modelledbe illik: a namespace-binding futásidőben tud instance-okat létrehozni és kezelni — vagyis tenantonként külön tudásbázis, ugyanazzal a mintával, amit az 5b. modulban a per-tenant D1-eknél láttál. Az adatszeparáció így nem prompt-fegyelem kérdése, hanem architektúra.

Vectorize — ha te akarod kézben tartani

Ha saját chunkolási és rangsorolási logikád van (vagy a beágyazást máshol állítod elő), a Vectorize adja a nyers vektor-adatbázist: index létrehozás, upsert, lekérdezés metaadat-szűréssel. Tipikus párosítás: Workers AI embedding-modell → Vectorize index → a találatokat a promptba. Multitenantnál a metaadat-szűrés (tenant_id) vagy a külön indexek adják az izolációt — és ez ugyanaz a döntés, mint a shared vs. per-tenant DB (5b. modul).

15.5Agents SDK — ha nem chat, hanem folyamat kell

Az „agent" itt nem marketingszó: az Agents SDK Durable Objectsre épül (7. modul), és pontosan azt adja, ami egy hosszú életű, állapotos AI-folyamathoz kell — mindegyik ismerős a kurzusból:

• Állapot az agent saját SQLite-tárában (beszélgetés, memória, részeredmények) — nem kell külön session-store.
• Címezhetőség: egy agent-példány = egy user/tenant/feladat, névvel elérve.
• WebSocket a streameléshez, hibernationnel (olcsó a nyitott kapcsolat).
• Ütemezés és Workflows-integráció: az agent tud „aludni" és később folytatni — pont a 7. modul durable execution mintája.
• MCP-támogatás mindkét irányban: az agented eszközöket hívhat, és a saját rendszered is kiajánlható MCP-szerverként.

Mikor releváns ez neked? Nem a „csetablak a sarokban" funkcióhoz (arra elég egy Worker + AI Gateway). Akkor, ha az AI-funkciód több lépéses és hosszú: dokumentum-feldolgozó folyamat emberi jóváhagyással, onboarding-asszisztens, ami napokon át kísér egy tenantot, vagy háttér-agent, ami éjszaka végigmegy adatokon és javaslatokat készít.

15.6Browser Rendering — a „láthatatlan" hasznos darab

Fejléc nélküli böngésző Workersből, Puppeteer-szerű API-val. Nem AI-funkció, de gyakran ezzel párosul (agent, ami weboldalt olvas). A te SaaS-odban viszont önmagában is hasznos, mert olyan feladatokat old meg, amikre eddig külön Lambda + Chromium kellett:

• PDF-generálás HTML-ből (számla, riport) — a 13. modul „sharp/natív modul nem megy" problémájának egyik kerülőútja.
• Screenshot (OG-képek, előnézetek, vizuális regresszió).
• Scraping / import ügyféladatokhoz.

15.7Bevezetési sorrend a te SaaS-odban

15.8Ellenőrizd magad