Multi-Tenant LLM Cost Attribution Architecture (2026): Per-Tenant P&L

Q: Why does naive per-tenant LLM cost attribution drift 5-30% from the provider invoice?

Five structural reasons. Provider invoices do not contain tenant IDs — they bill at the organisation level per model per day, so reconciling per-call telemetry with provider invoices requires an internal cost model that maps token counts back to dollars at the published rate per model per modality. Token counting at the application layer drifts from the provider's counting — local tiktoken or equivalent counters get within a few percent on text input but miss tool-call payload overhead, function-calling boilerplate the SDK injects, system-prompt prefixes, and vision-mode image accounting. Cached and uncached input bill at different rates across providers (OpenAI, Anthropic, Bedrock all have prompt-cache discounts that vary) and a cost model that does not separately track cache state will systematically over-charge cached and under-charge uncached. Multi-call requests get attributed to the wrong tenant when only the outer call carries the tenant tag — classifier, router, retriever, generator, and judge sub-calls disappear from the attribution. Background jobs (embedding, re-indexing, nightly evaluation) consume tokens but lack a user-session context — without explicit tenant context propagation through the job system they get attributed to nothing or to the wrong owner. Cumulative drift across these five sources is typically 5-30% on the first run.

Q: What is the four-layer architecture that produces accurate per-tenant cost attribution?

Layer 1 — gateway as single ingress for all LLM calls. Holds provider API keys, knows the cost model, emits the audit-log event, hard-fails on missing tenant context. Bypassing the gateway is a build failure in the application test suite. Layer 2 — append-only audit log streamed to a durable warehouse (S3 + Athena, BigQuery, ClickHouse, Snowflake). Per-call metadata: tenant ID, user ID, feature ID, correlation ID grouping sub-calls of one user request, provider, model, modality, prompt-template version, routing decision, prompt cache status, latency, input token count, output token count, error code. Schema is published, versioned, stable; late-arriving events accepted with original timestamp. Layer 3 — versioned cost model: small lookup table keyed by (provider, model, modality, input/output, cached/uncached) → dollars per million tokens, versioned with effective-date ranges so historical attribution stays correct when prices change. Reconciliation against provider invoice runs monthly; expect ≤ 2% agreement after the second iteration. Layer 4 — roll-up service producing (tenant, period) → (token counts, dollar cost, request counts, p95 latency) at the granularity finance needs. Inputs to finance reporting, billing engine, per-tenant cost alerting, routing-table tuning.

Q: Why must the gateway be a hard requirement rather than a recommended pattern?

Because once any application surface bypasses the gateway, the per-tenant attribution loses its closure property. A single bypass for a "quick experiment" produces a class of LLM calls invisible to the audit log; per-tenant cost is undercounted by exactly the bypass volume; the warehouse query that everyone trusts is silently wrong; the noisy-neighbour alerting misses the bypassing surface; the unit-economics calculation has a hole the size of the bypass. The discipline is that bypassing the gateway is a build failure in the application test suite — the SDK wrapper hard-fails if the tenant context is not set, and the gateway is the only path to the provider API. Provider API keys live exclusively at the gateway; application code never sees them. The gateway pays back on a long list of capabilities — cost attribution, rate limiting, routing, observability, multi-provider fallback, prompt-template versioning, eval-gate enforcement — but the cost-attribution use case is the one that hard-fails first when discipline slips, which makes it the canary for the broader gateway discipline.

Q: What is the implementation order and how long does each layer take?

Week 1 — gateway and tagging: build (or wire to existing) LLM gateway, set tenant context propagation through the application stack (HTTP middleware for inbound requests, explicit context for background jobs, correlation ID in tracing), hard-fail on missing tenant context, emit structured audit-log event per call. Week 2 — audit log and cost model: stream audit-log events to the warehouse, build the cost-model lookup table (publish the rate sheet for providers in use, version with effective dates), run the first reconciliation against the provider invoice (expect 5-15% drift on first run, investigate, expect ≤ 2% drift on second run). Week 3 — roll-up and per-tenant alerting: build the (tenant, period) roll-up, wire per-tenant cost alerts (anomaly detection plus threshold-based), expect 2-3 noisy-neighbour tenants to surface in the first week of alerting that nobody knew about — this is the immediate payback. Week 4 onward — optional value layers: usage-based pricing on top of the roll-up, per-tenant routing decisions on top of the cost telemetry, per-tenant SLA reporting, per-tenant eval suites, per-tenant cost forecasting. Each subsequent layer is a real product capability that becomes cheap to build because the four-layer architecture exists underneath.

Q: What are the four shapes of LLM noisy neighbour and how do you handle each?

The volume noisy neighbour: their request volume is 50× to 500× the median. Architectural response — per-tenant rate limiting at the gateway, with limits set per pricing tier and lifted on commercial agreement; the rate limit composes with the standard distributed rate-limiter pattern. The token-mix noisy neighbour: their average tokens per request is 10× to 50× the median because their inputs are larger or their use case demands longer outputs. Architectural response — per-tenant token-budget enforcement at the gateway (cap input length, cap output length, surface a clear error to the client when capped) and per-tenant cost reporting to the customer-success team. The model-tier noisy neighbour: their workload uses the most expensive model tier exclusively (Claude Opus, GPT-4o on every request) when median tenants use cheaper tiers. Architectural response — per-tenant routing rules, the routing table allows the most expensive model for tenants on a pricing tier that supports it, routes to a cheaper default for lower tiers, with explicit upgrade paths surfaced in the product. The async-job noisy neighbour: their background workload consumes more tokens in a single overnight burst than the rest of the tenant base in a week. Architectural response — per-tenant async-job quotas, scheduling controls (spread across off-peak window), and per-tenant background-cost reporting separated from foreground cost so the two can be priced differently.

Q: Which pricing model — cost-plus, tier-cap, or outcome — is right for my SaaS?

Cost-plus: customer is billed actual provider cost plus a fixed margin. Operationally simple, transparent, common in early enterprise pilots. Risk — customer optimises prompt to reduce cost in ways that hurt product experience; perceives any margin above 0% as exploitative. Pick this when the customer is a sophisticated buyer who wants transparency and the margin is small enough not to invite negotiation. Usage-tier: pricing tiers map to capped token consumption per period; cost-attribution telemetry is the input to enforcement (upgrade or throttle at tier boundary). Risk — customers near the boundary get unpredictable behaviour at month-end, support cost of explaining tier mechanics is non-trivial. Pick this when the workload is predictable enough that customers can self-select the right tier and the support overhead is acceptable. Outcome: customer is billed per business outcome (per resolved support ticket, per processed document, per generated piece of content) and LLM cost is internal. Cost-attribution telemetry is internal — used to ensure per-outcome margin stays positive. Risk — internal cost surprises (provider price increase, model swap that doubles tokens) are not pass-through and margin compresses without customer awareness; this is the model with the cleanest customer experience and the highest internal discipline cost. Pick this when product maturity supports stable per-outcome economics and the team has the cost telemetry to detect margin compression early.

Q: How do background jobs and async pipelines fit into per-tenant cost attribution?

Background jobs that consume LLM tokens — embedding a corpus, re-indexing a knowledge base, running a nightly evaluation suite, periodic re-ranking — must propagate tenant context explicitly because there is no inbound request header to read it from. The architectural pattern: every background job has a tenant_id field as a first-class job parameter, the job framework refuses to enqueue a job without it, the job framework propagates tenant_id into the job execution context, and the LLM gateway reads tenant_id from the context as it would from an inbound request header. The audit log treats background-job calls identically to foreground calls but the feature_id field distinguishes "background:embedding" from "background:reindex" from foreground feature IDs, so the per-tenant roll-up can break down foreground vs background spend. This breakdown is operationally important — many SaaS pricing models charge for foreground usage and absorb background as an internal cost, and the per-tenant economics depend on knowing how much background spend each tenant generates. Without explicit tenant context propagation through the job system, background spend gets attributed to nothing (silent under-attribution per tenant) or to the operations team (mis-attribution), and the per-tenant unit economics are wrong by the background-spend factor.

Q: What is the maturity ladder for multi-tenant LLM cost attribution?

Stage 0 — Single bill, no attribution: provider invoice arrives at month-end, finance allocates by guessing, per-tenant unit economics are unknown. Stage 1 — Tagging in place, no reconciliation: per-call tagging at the application layer, warehouse has the events, nobody has reconciled the warehouse roll-up against the provider invoice; numbers exist, nobody trusts them. Stage 2 — Gateway, audit log, cost model, reconciliation: single gateway ingress, published cost model, monthly reconciliation against provider invoice within 2%, per-tenant cost reports go to finance and customer-success. Stage 3 — Per-tenant policy: per-tenant rate limits, per-tenant routing rules, per-tenant alerting (threshold + anomaly), per-tenant SLA reporting; the gateway is the enforcement layer, the audit log is the evidence. Stage 4 — Per-tenant pricing live: usage-based or outcome-based pricing on top of the roll-up, per-tenant margin reportable in real time, per-tenant cost forecasting is part of the customer-success motion. Most multi-tenant LLM SaaS products in early 2026 are at Stage 0 or Stage 1; the investment to move to Stage 2 is approximately two engineering weeks, the investment to move to Stage 3 is another two; the payback at each stage is immediate and large.

Q: How do I handle provider price changes without breaking historical reports?

The cost model is versioned with effective-date ranges. Each row in the lookup table has (provider, model, modality, input_or_output, cached, dollars_per_million_tokens, effective_from, effective_to). When a provider changes its rates, a new row is inserted with the new effective_from and the previous row gets its effective_to set to the change date — the previous row is never overwritten. Roll-up queries join the audit-log timestamp against the appropriate cost-model row, so a query against historical data uses the historical rates and produces the same number it produced before the price change. Without this discipline, historical reports silently shift when prices change — last quarter's tenant cost report cannot be reproduced, the reconciliation against the provider invoice for last quarter no longer matches, finance loses confidence in the cost model. The cost-model version history is small (provider price changes happen monthly to quarterly per provider, the table is hundreds of rows over a year) and the discipline is cheap; the consequences of skipping it are large. Treat the cost model as event-sourced from the day it ships.

Q: How portable is this architecture across providers (OpenAI, Anthropic, Bedrock, self-hosted)?

Highly portable; the architecture is provider-agnostic by design. The gateway abstracts the provider API behind a single internal interface; provider-specific quirks (token counting, prompt caching, function-calling overhead, modality handling) are normalised inside the gateway and surface in the audit log as common fields. Provider-specific cost calculation lives in the cost model, not in the application code; adding a new provider is "add rows to the cost-model lookup table and add a thin adapter to the gateway." Self-hosted models (vLLM cluster, Triton, llama.cpp behind a router) are first-class citizens in the same architecture — the cost model for a self-hosted model is "amortised GPU-hour cost / tokens served per GPU-hour" at the chosen utilisation assumption, with the same versioned-effective-date discipline so utilisation changes update the cost model without breaking history. The only adjustment for self-hosted is that the reconciliation step against an external invoice does not apply directly; the equivalent is reconciliation against the internal infrastructure cost ledger (cloud bill or capex amortisation) on the same monthly cadence. The four-layer architecture survives provider mix changes without modification — adding a fourth provider, swapping one for another, or moving a workload from API to self-hosted are all configuration changes within the same architecture.