Provider käynnistyy backend-osoitteella ja usage-taustalla:
$ bus-api-provider-llm \
--jwt-secret "$BUS_LLM_JWT_SECRET" \
--backend-url http://127.0.0.1:11434 \
--usage-backend events \
--events-url "$BUS_EVENTS_API_URL" \
--api-token "$BUS_API_TOKEN"
OpenAI-yhteensopiva pyyntö kulkee saman /v1-muodon läpi kuin SDK-asiakkaat odottavat. Kun asiakas lähettää POST /v1/chat/completions -pyynnön mallilla gpt-test, proxyn vastaus säilyttää backendin OpenAI-tyylisen muodon:
{
"id": "chatcmpl_e2e",
"usage": {
"prompt_tokens": 2,
"completion_tokens": 3,
"total_tokens": 5
}
}
Tokenin tarkistus tapahtuu providerissa ennen backend-forwardointia. Backend ei näe clientin alkuperäistä Authorization-headeria, joten käyttäjän Bus auth -token ei vuoda mallipalvelulle. Provider kirjaa erikseen request-tapahtuman ja usage-tapahtuman; OpenAI-tyyliset prompt_tokens, completion_tokens ja total_tokens normalisoituvat sisäisen usage-keräilyn kentiksi.
Jos LLM-runtime herätetään event-polun kautta, provider voi odottaa backend-palvelun readiness-reittiä ennen kuin se proxyttää varsinaisen SDK-pyynnön. Polku on konfiguroitava --backend-ready-path- ja timeout-asetuksilla; runtime-eventtien kanssa oletuksena voidaan käyttää /v1/models-probea. Kun BUS_EVENTS_LISTENER_REQUIRED=1 on käytössä, /readyz raportoi myös runtime- ja usage-response-listenerien yhteyden.
Usage-taustaksi voi valita suoran PostgreSQL-yhteyden, muistitaustan tai Bus Events -polun. Event-tilassa LLM-provider julkaisee bus.usage.record.request -tapahtumat ja odottaa korreloidut bus.usage.record.response -vastaukset, jolloin käyttödataa tallentava prosessi voi olla erillinen bus-integration-usage-työntekijä.
bus-api-provider-usage pysyy keräilysyötteen omistajana, eikä LLM-providerista tule laskutusrekisteriä. Nykyinen provider-pinta löytyy bus-api-provider-llm-dokumentaatiosta, usage-keräilyn rajat löytyvät bus-api-provider-usagen dokumentaatiosta ja event-worker on kuvattu bus-integration-usagen dokumentaatiossa.
