Litmus: Fair Pricing for Serverless Computing

Serverless clouds charge you by how long your function runs, and to keep machines busy they pack many tenants' functions together — so when the machine gets crowded, your function slows down and, perversely, you pay more for the provider's own overcommitment; this paper (Binghamton University and Intel Labs — Qi Pei, Yipeng Wang, Seunghee Shin) argues the provider should discount that congestion, and builds Litmus, which prices a discount from how congested the machine is rather than from expensive per-function profiling, sensing congestion for free by watching how much the function's own startup slows down, and lands within 0.2 percent of the ideal fair price even under heavy load.

The argument in one glance

Problem

You pay by the second, so when the provider crowds the machine, you pay for its mistake

Serverless computing is popular because you only pay for what you use: you upload a function, and the platform bills you in proportion to how long it runs. To make money, the provider packs many tenants' short-lived functions onto the same machines and lets them share resources, keeping utilization high. But sharing has a cost that lands on the wrong party. When the machine gets overcrowded, your function contends for caches, memory bandwidth, and cores with everyone else's, and it slows down. Because you are billed by execution time, that slowdown does not just waste your time — it increases your bill. So the more aggressively the provider overcommits the machine, the more you pay, even though the congestion is entirely the provider's doing and outside your control. The tenant is charged extra for the provider's overcommitment, which is precisely backwards.
What people did

Discount the bill by how much each function was actually slowed

The fair fix seems obvious: the provider should compensate a tenant for the slowdown by discounting the bill by the amount the function was delayed due to interference. Prior work (POPPA) does this by measuring each task's slowdown directly — periodically sampling how the function performs so it can estimate how much slower it ran than it would have alone.
Why it fell short

Measuring each function's true slowdown is too expensive to do

The catch is that discounting by actual slowdown requires knowing what the function would have run in isolation, and you cannot know that without a reference. Getting one means profiling each individual function — running or sampling it enough to learn its congestion-free behavior — and prior studies show this per-function assessment imposes heavy overhead, the very inefficiency serverless is trying to avoid. Sampling each task to gauge its slowdown burdens the system it is meant to keep cheap. So the honest, per-function way to compute a fair discount is impractical at serverless scale, and providers are left charging the unfair time-proportional price.
This paper's idea

Discount by the machine's congestion, and sense it free from the function's own startup

Litmus reframes the problem: instead of measuring each function's individual loss, discount based on the machine's state — how congested the system is — and presume the tenant's slowdown from that state. This avoids per-function profiling entirely, because two tables built once offline map an observed congestion level to a presumed slowdown. To read the machine's congestion cheaply and continuously, Litmus runs a "Litmus test": it exploits the fact that serverless functions all do largely the same memory-heavy work during startup, so it watches how much the function's own startup slows down and reads the congestion level off that — a free probe with no added overhead. It also splits resources into private and shared, charging each differently since only shared resources suffer contention. Litmus lands within 0.2 percent of the ideal per-slowdown price even under heavy congestion.

Why this problem is worth solving

The unfairness is structural, baked into how serverless makes money and how it bills.

Serverless computing lets tenants deploy stateless functions and pay only for the resources consumed during execution, which is the pay-as-you-go promise that drew a majority of cloud users to it. But two things about how the platform operates put the tenant in a bind. First, to maximize machine utilization — the provider’s whole economic incentive — the platform co-runs many functions from many tenants on the same hardware, sharing caches, memory bandwidth, and cores. Second, the bill is proportional to execution time. Put those together and interference becomes a tax on the victim: when the machine is crowded and a tenant’s function slows down because of contention it did not cause and cannot see, the function takes longer, and because the price tracks time, the tenant pays more for the same work. The tenant has no control over how densely the provider packs the machine, yet bears the cost of that packing twice, in slower service and a higher bill. This is not a rare edge case; it is the normal consequence of combining resource sharing for efficiency with time-based billing, so it affects the common case of serverless operation. Making the pricing fair — charging tenants for their work, not for the provider’s overcommitment — is therefore a first-order correctness issue for the dominant cloud paradigm, not a minor billing tweak.

The reason it stays unfixed is that the fair correction is expensive to compute the obvious way.

To discount a bill fairly, you must know how much the function was actually slowed by congestion, which means comparing its observed execution time against what it would have taken running alone. But that isolation baseline is exactly what you do not have in a shared system — the function only ever ran while contending with others. Recovering it requires profiling the specific function: running or repeatedly sampling it to characterize its congestion-free performance, per function, per tenant. Prior work that takes this route measures each task’s slowdown by sampling, and the studies show the assessment imposes heavy overhead — you are spending real system resources to figure out how much to refund, which eats into the very efficiency that shared serverless exists to provide. Worse, serverless functions are short-lived and enormously numerous, so any per-function measurement cost is multiplied across a huge, churning population, making it prohibitive precisely where it would be needed most. The core difficulty, then, is that fairness seems to demand a per-function measurement that fairness’s own setting cannot afford. Breaking that bind requires a way to estimate the loss without profiling each function, which is the opening Litmus exploits by moving the measurement from the individual function to the shared machine state.

What people did before, and where it broke

Time-proportional billing (the status quo). Charge each tenant strictly in proportion to how long their function executes. Where it broke. When the shared machine is congested, functions slow down and their bills rise, so tenants pay more for interference the provider caused, which is unfair and unaccountable.
Per-function slowdown discounts by sampling (POPPA). Measure each task’s slowdown directly by sampling its performance, then discount the bill by the observed slowdown. Where it broke. Estimating each function’s isolation baseline requires per-function profiling that imposes heavy overhead, undercutting the efficiency shared serverless depends on, especially across huge numbers of short-lived functions.
Pre-profiling every function offline. Characterize each function’s congestion-free behavior in advance so slowdowns can be computed later. Where it broke. Serverless functions are arbitrary tenant code, numerous and constantly changing, so pre-profiling all of them is infeasible, and the information would be needed for functions never seen before.
Ignoring congestion and hoping isolation holds. Assume the platform isolates tenants well enough that interference is negligible. Where it broke. High-utilization serverless deliberately overcommits and shares resources, so isolation is often not achievable and slowdowns are real, leaving the time-proportional bill systematically unfair.
The gap. No pricing scheme discounted for congestion without per-function profiling — measuring the shared machine’s state cheaply and presuming each tenant’s loss from that state, so a fair discount could be applied continuously and at serverless scale.

How Litmus works

Turning per-function slowdown accounting into a cheap machine-state discount

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Compensate for congestion, and do it by pricing the machine’s state rather than the tenant’s function. Litmus starts from a fairness principle: when the platform cannot isolate a tenant, and its function is slowed by congestion the provider created, the provider should give back that loss as a discount. The obstacle everyone hits is that measuring the loss per function is too expensive. Litmus’s reframing is to stop trying to measure each function and instead measure the shared thing that causes the loss — the machine’s congestion level — and presume the tenant’s slowdown from it. Because the congestion level is a property of the machine, not of any one function, it can be sensed once and applied to everyone running on that machine, and the presumed-slowdown mapping is precomputed offline into a table, so no runtime per-function profiling is needed. This trades a little precision (a presumed slowdown rather than the exact one) for enormous savings in overhead, and the paper shows the precision lost is tiny. Insisting that a tenant be charged fairly for work done under contention it did not cause, and building the pricing around cloud economics rather than raw resource counting, is the same fairness-in-the-bill concern the low-cost cloud-computing work covered elsewhere on this site engages, treating what the tenant pays, not just what the machine does, as the thing to get right.

Sense congestion for free by watching the one workload every function shares: its startup. The elegant heart of Litmus is how it reads the machine’s congestion without adding any probe. It exploits an observation about serverless specifically: functions perform largely identical operations during startup — a memory-heavy initialization phase — regardless of what the function itself does. That makes the startup a built-in, standardized reference workload that runs on every invocation anyway. So Litmus times the startup and compares it against the known uncongested startup time; the ratio is the “Litmus test,” revealing how congested the machine is right now, at zero extra cost because the startup was going to happen regardless. It is a canary that every function carries for free. Turning an unavoidable, uniform piece of the workload into a lightweight sensor for the system’s condition is the same clever-signal instinct the noisy-cloud tuning work covered elsewhere on this site relies on, extracting a reliable read of interference from behavior the system already produces rather than from a costly dedicated measurement. Litmus’s version is especially clean because the startup is both universal across functions and reliably memory-bound, exactly the traits that make it a good congestion gauge.

Charge private and shared resources differently, because only sharing causes contention. A single congestion discount applied to the whole bill would be blunt, because not everything a function uses is contended. Litmus refines the model by splitting resources into private, dedicated to the tenant and immune to others’ interference, and shared, where contention actually happens. It charges private use at the full base rate — there is no congestion loss to compensate there — and applies the congestion-based discount only to shared use, where the slowdown really occurred. Because the two categories are affected differently, separating them makes the discount reflect the real degradation rather than smearing an average across resources that were never contended, which is what lets Litmus land within a fraction of a percent of the ideal price. Attributing cost precisely to where contention does and does not occur, rather than treating a shared machine as uniformly congested, is the same discipline the shared-microservice resource-management work covered elsewhere on this site applies, distinguishing the parts of a co-located workload that actually interfere from those that run undisturbed so that guarantees and charges track reality.

Following a function’s bill through Litmus

Pricing a serverless function fairly under congestion without profiling it

A trace, drawn from the paper's design, of how Litmus computes a congestion-aware discount for a tenant's function.

Step 1 of 5

Offline: the provider fills the congestion and performance tables

Before deployment, the provider profiles how the standardized startup slows down at several congestion levels (the congestion table) and how a set of reference functions slow down at each level (the performance table). This is a one-time offline cost, not per tenant function.

Reference functions stand in for real functions, so no individual tenant function ever needs runtime profiling.

Why it works

Pricing the machine, not the function, removes per-function profiling. The isolation baseline of each function is unknowable cheaply → but congestion is a property of the shared machine, sensed once → so a precomputed table maps congestion to a presumed slowdown, avoiding runtime profiling entirely.
The startup phase is a free, uniform congestion probe. A dedicated congestion measurement would add overhead → but every function’s startup does the same memory-heavy work anyway → so timing that startup reads congestion at zero extra cost, on every invocation.
Presumed slowdown is close enough to actual to be fair. An estimate could be far from the true loss → but reference functions capture how congestion affects functions at each level → so the discount tracks the ideal per-slowdown price within 0.2 percent even under heavy load.
Splitting private and shared makes the discount precise. A blanket discount would mischarge uncontended resources → but only shared resources suffer congestion, so only they are discounted → so the bill reflects the real degradation rather than an average smeared across everything.
Offline tables scale to serverless churn. Profiling each of countless short-lived functions is prohibitive → but the tables are built once and reused for all functions → so the cost does not grow with the huge, constantly-changing function population.

What it costs (trade-offs and scope)

It presumes each function’s slowdown rather than measuring it. By design Litmus applies the slowdown that a reference function would suffer at the observed congestion level, not the true slowdown of the specific function, so a function whose sensitivity to contention differs markedly from the reference set could be over- or under-compensated; the 0.2 percent average masks such per-function variation.
It depends on the startup being a faithful congestion sensor. The Litmus test works because serverless startups are largely identical and memory-heavy; functions with atypical startups, or runtimes where startup is not representative of the contention a function later experiences, would give a less reliable congestion read.
The tables must be built and kept current. The congestion and performance tables require offline profiling of startups and reference functions, and their accuracy depends on the reference set and hardware matching the real deployment, so changes in the fleet or workload mix may require re-profiling.
Private-versus-shared classification must be right. The accuracy gain from charging the two categories differently assumes resources are correctly attributed to private or shared; misclassifying which resources are actually contended would erode the precision of the discount.
It is a pricing correction, not a performance fix. Litmus makes the bill fair when the provider overcommits, but it does not make the congested function faster; it also does not by itself remove the provider’s incentive to overcommit, only the tenant’s penalty for it, and the evaluation is a study of pricing accuracy rather than a deployed commercial billing system.

The evaluation

Pricing a serverless function under system congestion

Property	Time-proportional billing	Per-function sampling (POPPA)	Litmus
Compensates for congestion slowdown
Needs per-function profiling
Runtime overhead
Distinguishes private vs shared resources
Reported pricing accuracy

A comparison drawn from the paper. Litmus is evaluated across environments with varying congestion against the ideal price that discounts proportional to true slowdown; the 0.2-percent-average deviation is the paper's reported result, achieved without the per-function profiling overhead of sampling-based schemes.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

The full paper text was available (the authors’ arXiv version, 2408.00731), so this account of the mechanism — the unfairness of time-proportional billing under provider-caused congestion, the impracticality of per-function slowdown profiling, Litmus’s machine-state discount that presumes slowdown from a congestion level, the startup-based Litmus test that senses congestion for free from the memory-heavy uniform startup phase, the offline congestion and performance tables, and the private-versus-shared charging split — follows the paper’s own description. The headline number is the paper’s reported result: Litmus prices within 0.2 percent on average of the ideal per-slowdown price even in a heavily congested system. That figure is from a study across environments of varying congestion; it reflects accuracy against a defined ideal, and per-function variation is folded into the average. Exact per-environment numbers, the table construction (including the reference-function generators), and the charging-rate formulas should be read from the paper itself. Litmus is a pricing methodology evaluated for accuracy, not a deployed commercial billing system.

Background

Why fair billing matters as much as fast systems

It is worth stepping back to see why a pricing paper belongs among systems research. Cloud computing is not just a technical arrangement but an economic contract: the whole appeal of serverless is the promise that you pay only for what you use, and that promise is what draws a majority of cloud users to it. But a promise about payment is only as good as the accounting behind it, and here the accounting has a hidden flaw — the meter runs on wall-clock time, which the provider partly controls by deciding how densely to pack the machine. When the incentives of the party that sets the price (pack tightly for utilization) conflict with the interests of the party that pays it (run fast and cheap), the pricing mechanism itself becomes the place where fairness is won or lost, no matter how good the underlying scheduler is. So designing the billing to charge for the tenant’s work rather than the provider’s overcommitment is a systems problem with real economic stakes, not a mere accounting detail. This attention to the cost the tenant actually bears, and to aligning what is charged with what is fairly owed, is the same economic lens the spot-and-on-demand cost-optimization work covered elsewhere on this site brings to cloud usage, treating the dollar cost of computation as a first-class quantity to design around. Litmus applies that lens to the provider’s side of the meter, arguing the provider owes a refund when its own crowding slows you down.

If you remember only three things

1. Serverless bills tenants in proportion to execution time, and to maximize utilization the platform co-runs many tenants' functions on shared hardware; when the machine is congested a function slows down, so the tenant pays more for interference the provider caused — an unfairness that is the normal consequence of combining resource sharing with time-based billing, not an edge case. The fair fix is to discount the congestion loss, but computing it per function requires knowing the function's isolation baseline, which needs per-function profiling that prior work (POPPA, via sampling) shows imposes heavy overhead.
2. Litmus reframes fairness as pricing the machine's state rather than the tenant's function: it discounts based on the system congestion level and presumes each tenant's slowdown from it, using two offline tables (a congestion table mapping startup slowdown to congestion level, and a performance table mapping congestion level to presumed function slowdown) so no per-function runtime profiling is needed. It senses congestion for free with a "Litmus test" — timing the function's own startup, which is memory-heavy and largely identical across all serverless functions, so its slowdown reveals current congestion at zero added cost — and it charges private (dedicated) and shared (contended) resources at different rates since only shared use suffers interference.
3. Across environments of varying congestion, Litmus prices within 0.2 percent on average of the ideal price that would discount by true slowdown, even under heavy congestion, without the profiling overhead of sampling-based schemes. It presumes rather than measures each function's slowdown (so atypical functions may be mis-compensated), depends on the startup being a faithful congestion sensor and on accurate offline tables and private/shared classification, and is a pricing correction — it makes the bill fair but does not make the congested function faster.

Check yourself

Check your understanding

1. Why is standard serverless billing unfair to tenants when the system is congested?
2. Why is the obvious fix — discounting each function by its measured slowdown — impractical?
3. How does Litmus sense the machine's congestion level without adding overhead?
4. What does Litmus achieve, and what are its main limitations?

Sources

The paper is “Litmus: Fair Pricing for Serverless Computing” by Qi Pei and Seunghee Shin (Binghamton University) and Yipeng Wang (Intel Labs), published at ASPLOS 2024 (Volume 4), DOI 10.1145/3622781.3674181. It is licensed CC BY-NC-ND.

This explainer is based on the paper’s full text, obtained from the authors’ arXiv preprint (arXiv:2408.00731). The account of the mechanism — the unfairness of time-proportional serverless billing when the provider co-runs functions and congestion slows a tenant’s function; the impracticality of estimating per-function slowdown, which requires profiling that imposes heavy overhead (as in the prior POPPA approach that samples each task); Litmus’s new pricing model that offers discounts based on the machine’s congestion state while presuming the tenant’s loss under that state; the Litmus test that measures congestion for free using the function’s startup process, based on the observation that serverless functions perform largely identical, memory-heavy operations during startup; the offline congestion table (startup slowdowns at each congestion level) and performance table (reference-function slowdowns at each congestion level) that avoid runtime profiling; and the split of resources into private and shared with different charging rates because only shared resources suffer contention — follows the paper’s own description. The reported result cited here is the paper’s own: Litmus prices within 0.2 percent on average of the ideal price that discounts tenants proportional to their slowdown, even in a heavily congested system. Exact per-environment numbers, the table-construction details (including the reference-function generators), and the charging-rate formulas should be read from the paper itself.