Wafer AI Speeds Inference by Tuning Software Across GPUs

Wafer is the name of an AI inference company, not a new wafer-scale chip. Its stated business is to run already-trained models more efficiently on available accelerators by adjusting the deployment stack. In September 2026, the company announced a $40 million Series A financing. That fundraising figure says investors financed expansion; it does not prove every model will run faster or cost less. The useful question for an AI developer is what Wafer tunes, on which hardware and workload, and how the measured result compares with the developer's own baseline.

Inference begins after training

Training changes a model's parameters using data and substantial computation. Inference uses those trained parameters to respond to a prompt. At inference time, a service must load the model, process incoming text, generate output tokens and handle many simultaneous requests. Speed and cost depend on more than the GPU model: batching, caching, scheduling, model format and the software kernels that drive the chip can all affect performance.

Bit.Fan’s report on Wafer’s funding and inference business says Wafer uses an AI agent to tune engines, kernels, caches, quantization and scheduling across NVIDIA and AMD GPUs. This describes a software optimization layer. It is a different proposition from manufacturing new GPUs. A buyer of inference capacity should ask which part of that stack Wafer controls and whether the chosen configuration remains reliable under production traffic.

Investor Wing Venture Capital’s announcement confirms participation in Wafer's $40 million Series A. Wing describes agents searching across model, engine, kernel and hardware choices according to traffic shape and performance constraints. That wording matters: there is no single “fastest GPU” independent of the requests being served. An optimization that helps sustained long outputs may not help many tiny calls, and a configuration that saves compute may trade off latency or model quality.

What a developer should measure

Throughput is often reported as output tokens per second or completed requests per unit time. Latency asks how long a user waits, including time to first token and total response time. Cost may be expressed per million tokens, per request or per hour of reserved compute. A useful evaluation holds the model version, prompt mix, output length, concurrency and service level constant while comparing providers. If one test uses a different quantization setting or more aggressive batching, a headline throughput ratio alone is incomplete.

Vercel's GLM 5.2 Fast integration note reports that, in Vercel's own small-context, large-context and tool-call benchmarks, Wafer achieved about twice the throughput of other serverless providers serving GLM 5.2. It gives more than 170 output tokens per second for small context and more than 200 for large context in that testing. Those are specific observations for a model and serving environment, not a promise that any model on any GPU will be twice as fast.

A first-party benchmark from a customer is stronger evidence for that customer's use case than a vendor slogan, but it still requires its test conditions. A developer should reproduce representative requests, including short answers, long reasoning chains, tool calls and high-concurrency periods. Observe quality and error rates alongside speed. A service that runs fast in a controlled sample might behave differently when request size and traffic fluctuate.

Why hardware choice matters without a universal winner

Bit.Fan's report also relays an internal Wafer test comparing AMD MI355X and NVIDIA B200 throughput and cost for GLM 5.2. Internal tests are a starting lead, not an independent benchmark for all applications. The relevant comparison is end-to-end cost of usable output under the same workload and quality standard. GPU purchase prices, cloud rental rates, memory capacity and availability can all alter the answer.

An inference stack may tune how much work is grouped into a batch, which kernel implements an operation, and where cached context is stored. Changing one knob can help one metric while hurting another. Larger batches may improve aggregate throughput but make an individual request wait longer. More compact model representations may lower memory demand while changing numerical behavior. Production deployment needs explicit constraints on acceptable latency, quality and reliability, not a blind pursuit of the biggest tokens-per-second number.

Read the financing news as context

Bit.Fan says Wafer reached $8 million annualized recurring revenue with eight employees and a valuation above $200 million. Those figures are reported company and funding claims; the two linked first-party sources here confirm the funding participation and a bounded customer benchmark, not audited revenue or a lasting valuation. Annualized revenue extrapolates a current run rate and can change. Neither it nor a financing round guarantees sustained margins in the expensive inference market.

Wafer AI's practical appeal is the possibility of getting more useful model output from existing compute. For a user deciding whether to integrate it, the next step is not to assume a fundraising headline equals technical superiority. Define the workload, compare measured latency and cost under identical conditions, and watch behavior after deployment. The company, hardware and benchmark each answer a different part of that decision.