Raw capture — raw/gpu-self-hosting.md
url: https://aistack.imec-int.com/blog/gpu-self-hosting title: "How many devs can you fit on a GPU? — self-hosting explained" subtitle: "A reality check on self-hosting the model behind your coding agent." author: Steven L., Wouter V.d.B., Michaël M., Ioana F., Jan F., Christian M., Maxim C., Arathy U., Bohdan D., Sepideh P., Baptist V., Jeroen B., Robbert V.C., Mathias F., Hendrik M., Jannick V. (aistack / imec) date_fetched: 2026-08-01 date_published: 2026-07-23 date_updated: 2026-07-29 site: aistack (imec)
A reality check on self-hosting the model behind your coding agent.
Update (29 July 2026): We have run Kimi K3 through the same setup, served with SGLang. At 1.4TB of weights, K3 does not fit within the memory budget of the 8×B200 node used for GLM-5.2 (1.5TB of total HBM leaves no headroom for KV cache). This run therefore used an 8×B300 node, which brings 288GB of HBM per GPU instead of 192GB, or 2.3TB per node. That averages out to around 20% higher hardware cost than the 8×B200 setup, depending on your rental provider.
In our runs, K3 served 16 concurrent sessions (GLM-5.2 managed 24). Aggregate token throughput is about 30% lower (122 vs 170 tok/s at 16 users), and median task time is about 50% longer (38 vs 26 minutes). That makes K3 roughly 8 times slower than our Claude Code baseline. However, K3 makes up for it in quality, resolving 86.4% of tasks, 24 percentage points above both GLM-5.2 and Opus 4.8 (62.5% for both). One caveat is that our benchmark tasks from SWEBench Pro may have been in K3's training data, so treat that resolution rate with a grain of salt.
The warning signs were everywhere the first half of this year: GitHub Copilot switched to token-based billing, Uber burned through its annual AI tools budget in just four months, and developers reported projected cost jumps from $29 to $750 a month. We even invented words for it: "tokenmaxxing", "token panic", "token budgets".
The median employee currently spends ~$140 per year on AI API usage. Sounds harmless, until you look at the tail: the 90th percentile nears ~$7,300 per year, and the 99th approaches ~$90,000. For many organisations agentic AI adoption is only just beginning, so expect these numbers to change in the year ahead.
Why is the bill so volatile? Because of how we use AI agents: Currently, over 70% of ARR across major model providers comes from coding use cases. The more of your workflow you hand to agents, the higher your token bill becomes.
Many organizations start their AI coding agent adoption using one of the major frontier model providers like OpenAI or Anthropic through API access. A few months in, more and more organizations are at least considering the alternatives for a number of reasons: token pricing models become more costly, users are upgrading to newer and more expensive AI models and agent adoption in the organization starts to boom.
There are sensible alternatives out there that are certainly worth a closer look: switching to API routers; using cheaper model tiers for routine work while only escalating the hard 20% to a frontier model and others. However, if your token consumption becomes significant or if you're working with sensitive data, you might want to abandon the API approach altogether and setup your own inference stack. When ownership of hardware is on the table, you'll need to understand what renting or owning a GPU actually gives you in return. When does it make sense to make that switch? Read on as we give you the tools to decide for yourself.
So you've decided to investigate whether buying or leasing your own GPUs makes sense. Once configured correctly, it will give you an API endpoint you can plug into your coding tools, much like Anthropic, OpenAI or other model providers offer.
In contrast to the frontier APIs, your own endpoint has a ceiling on output tokens per second but you only reach it when the system is fully loaded. One developer working alone leaves most of that ceiling unused, but the same hardware serving forty-eight agent sessions in parallel is a different story. Your ceiling is determined by the model, the GPU(s), and the serving configuration.
Unlike an API usage model where you are charged per token consumed, running your own setup signifies you pay for the underlying infrastructure and the cost of keeping it running. In all but a few cases that means you're also paying for it even when you're not generating tokens. Whether that trade-off works for you, is decided by two questions. The first is how much of the pool are you using.
You size for the peak and pay for it 24/7. Utilisation, not headcount, is what makes or breaks the cost case. Real demand is not constant, but spiky. For many organizations, tokens for coding tasks will be near-zero overnight, ramp up through the morning, dip visibly at lunch, and peak again mid-afternoon. This means you buy hardware for the peak load, but you pay for it 24/7 (unless you rent 'GPU spot instances', but these are harder to rely on in this case).
The shape of your peak in usage matters as much as the volume: a single-timezone team concentrates token demand into narrower spikes than the same headcount spread across timezones: same tokens, higher peak usage, but spread out longer.
Published data on enterprise inference workloads serving internal developer tools reports average GPU utilization of 15–22%, though even a well-run deployment currently rarely exceeds 25–35% (and that is being generous).
One emerging trend may work in your favor here: As organizations mature in their agent driven workflows, more and more sessions are starting to come from automated agents rather than people (scheduled jobs, agents autonomously picking up a bug report at 3am, etc.). This allows for work that doesn't adhere to office hours. If scheduled with intent, these automated sessions can soak up overnight capacity you are paying for anyway.
A token pool occupied by just one developer feels wonderful - tokens stream in faster than you can read. The question is what happens at five, ten or twenty concurrent developer sessions, because AI coding agents are greedy, bursty clients that not only consume tokens, but also browse the web, execute files or compile code.
One of your main concerns when moving away from a frontier model provider API should be developer experience. When looking at benchmark results you will often see tokens-per-second used to gauge how well a model performs on a given GPU setup. While it is an easy to understand metric, we find it less useful in this context. After all, you can burn thousands of tokens with no satisfiable result, or you can switch to a smaller model that ends up using 10 times more tokens. The better unit of value delivery is a task successfully completed, and while that is harder to quantify in general, that's what we'll often return to in the analysis below.
The better unit of value delivery is a task successfully completed.
To make task completion measurable we use a subset of tasks from SWEBench Pro by ScaleLabs, a popular set of longer-horizon code engineering tasks. While it is most often used to pit individual models against each other, our team is using it specifically to create a more lifelike and challenging enough workload as we compare the cost and performance of different model and hardware combinations under real use cases that would make sense for your organization.
We run our subset of coding tasks using a given model on a specific hardware setup at increasing levels of user concurrency and evaluate how this impacts the time to complete individual tasks. This will help to find that sweet spot of how many concurrent users you can have active for your chosen setup before tasks simply start taking too long to complete.
Over the last weeks our team was hard at work to do ~100 runs of a selection of 64 real coding tasks from SWEBench Pro across different and appropriate hardware configurations to calculate precisely the right metrics (median time per tasks, tok/s/u and many more).
Guided by open-weight quality rankings from Artificial Analysis, we paired each hardware tier with a leading model that fits its memory budget:
If you're interested in renting or buying hardware, several options are available. Below we introduce four popular contenders that we'll come back to throughout this post. Each of those also comes with a best-in-class open weights model that nicely fits the hardware.
We're leaning heavily into NVIDIA here, which has a lot to do with what was easily available to us. There are definitely similar alternatives from other suppliers, which we'll get to in later posts. For now, consider these as reference choices rather than specific endorsements.
NVIDIA DGX Spark. This is the box for a team that wants to try self-hosting without talking to procurement: it sits on a desk and costs less than a conference trip. It can fit Qwen3.6-35B-A3B. That's a surprisingly big model for such a machine.
NVIDIA H200. A powerful, single accelerator. Perhaps surprisingly, it actually does not buy you a lot more in terms of the models you can host compared to a DGX Spark. This is mostly determined by the available memory (128GB for the DGX Spark vs. 141GB for the H200). However, what you do get is a bigger token pool which translates in throughput speed for higher concurrencies.
NVIDIA HGX H200 with 4×H200s. If you want to host more powerful models, but don't want to fully break the bank, this is a solid option. With 4×H200s, you can host bigger models such as DeepSeek-V4-Flash, which promise a very good compromise in terms of speed, concurrency and quality.
HGX B200 with 8×B200's. A powerful reference system, as it lets you serve state-of-the-art open source models like GLM-5.2 that currently come closest to the frontier models in terms of quality. This is your option if quality is the main concern.
So what about having a DGX Spark sitting on your desk within reach? Well, unsurprisingly, it does not come with a big token pool. In our tests, we could not push it beyond 1-2 concurrent users and were confronted with an avalanche of time-out errors and the likes. If you're happy with Qwen3.6, it can be a fit for you, but don't expect it to scale in speed, concurrency or model quality. It shows that - despite Linkedin headlines - we're not there yet that we can simply download frontier intelligence on an affordable desktop box. Simpler things like code completion? That is less of an issue.
This is where paying extra for that professional H200 pays off, for the same model it can generate at least 30 times more tokens/s for Qwen3.6. Actually, don't be surprised that Qwen3.6 generates so many tokens, even on a single H200 - it's still quite a small (and thus less capable) model.
We can also see here that DeepSeek-V4-Flash on the HGX H200 comes with an even bigger token pool (of course on 4×H200s) and only reaches that potential at high concurrency. In contrast, for GLM-5.2 on the HGX B200, the token pool is smaller despite it running on the most powerful hardware in our tests. Indeed, 16 concurrent sessions seems to more or less saturate the GPUs and the total pool is only about 175 tokens/s for GLM-5.2. Bigger, more powerful models come with smaller token pools, and the hardware we selected doesn't fully compensate for that.
The collapse problem. Some lines crash down instead of tapering off to a maximal value. Both Qwen3.6 on H200 and DeepSeek-V4-Flash on the HGX H200 take a nose dive after concurrency 48 and 64. The reason has to do with the specifics of the inference engine (vLLM), its default parameters and how it balances compute between prefill and decode requests, as well as important resources such as the effective KV-cache size and its usage. Additionally, the usage of speculative decoding which speeds up token generation for low concurrency can hurt performance for higher ones. But don't despair too quickly, if you optimize the inference engine (e.g. vLLM) for your workloads, you can deal better with such issues and get even more out of the system - the authors promise to cover this in an upcoming blogpost.
You may not want to max out your token pool, as individual developers may perceive your solution as a snail compared to their trusted Codex or Claude companion. With the latter as a baseline we can see that GLM-5.2 struggles already from 8 concurrent sessions onwards despite the impressive HGX B200 hardware. Just as with the relatively small pool size, we see here that serving a frontier model at scale is very challenging.
On the other end of the spectrum, the DGX Spark is slow even for 1 user, and simply unusable for multiple users. Both DeepSeek-V4-Flash and Qwen3.6 are holding up longer, up to 32 users and then take a dive. Note that DeepSeek-V4-Flash is close to Qwen3.6-35B-A3B but runs on more expensive hardware - trading off that investment for higher quality while maintaining speed under load. Of course, for both, compared to GLM-5.2, the price you pay is the lower quality.
Comfortable concurrency per setup:
| Model | Comfortable concurrency |
|---|---|
| Qwen3.6 (DGX Spark) | just 1 — and still slow, almost 3× slower than Claude Code |
| Qwen3.6 (H200) | easily 32 and at 48 you are 2× slower than Claude Code |
| DeepSeek-V4-Flash | easily 32 and at 48 you are 2× slower than Claude Code |
| GLM-5.2 | 8 is pushing it — already 3× slower than Claude Code |
The utilization gap. At comfortable concurrencies, you still leave some tokens on the table. For DeepSeek-V4-Flash on HGX H200 at c=32, with happy devs, you only use 1,381 tokens/s, while the pool for c=64 is 1,717 tokens/s, or 24% more. Don't simply expect you will get the full pool out of a system as it's often advertised.
When it comes down to how to invest in your AI coding agents, your choices are not limited to sticking to your model API provider of choice or outright buying the hardware. There's also the option of renting your GPUs, with suppliers ranging from Hyperscalers to NeoScalers, AI Factories or other parties. Each come with different prices, but also different guarantees, services and integrations.
To compare fairly, the team reran the SWEBench Pro task set against the official APIs of the different model providers and kept track of the token costs. For buying, or renting, hardware, the cost is determined by how long it takes to run such a set of tasks. As discussed, this depends on the concurrency. For each of the systems, they take the optimal concurrency from a cost perspective, the one that uses the GPU optimally. Note this may be a point that impacts user experience. DGX Spark was not included in this comparison as it really is a different beast in terms of pricing and performance.
Hardware costs are depreciated over 5 years, not including additional power or maintenance costs as those depend on organisation specifics.
Cost comparison per 64-task run:
| System (Model/HW/Walltime) | API Cost | Buy Cost | Buy Cost (30% usage) | Rented Cost |
|---|---|---|---|---|
| Qwen3.6 (1×H200, 28 min) | $57.67* | $0.43 | $1.43 | $1.62 |
| DeepSeek-V4-Flash (4×H200, 31 min) | $2.13 | $1.90 | $6.33 | $7.19 |
| GLM-5.2 (8×B200, 101 min) | $92 | $13.84 | $46.12 | $71.23 |
| Anthropic API (Opus 4.8) | $98 | N/A | N/A | N/A |
*Alibaba list price (no caching for the model). Hardware purchase and rental prices are publicly advertised rates as of July 2026.
Key takeaways from the cost analysis:
There's no single winner. Priced at real-world utilisation, buying only pays off if you keep the box busy — a 4×H200 needs to stay 89% loaded, the B200 rack just 15%. Below that, renting or a cheap open-weights API often wins. Buy GPUs for what an invoice can't price — control, privacy, latency — not for cost alone.
The critical variable for coding agents: up to 98% of input tokens are cached, and this is where DeepSeek-V4-Flash API pricing beats even the smaller Qwen3.6 model by a landslide.
And you are not alone. Yet here you are, reading about moving away from them. Truth be told, while open-weight models are always lagging a couple months behind the frontier models from Anthropic, OpenAI or Google, the best of them have become very usable in 2026. Moreover, the gap between open-weight and closed models is closing as we speak with new releases such as GLM 5.2 and Kimi K3.
The gap between open-weight and closed models is closing as we speak.
For the tasks we ran, we reproduced the prevailing insights by model quality evaluators such as Artificial Analysis. Here are the resolution rates (pooled over all runs and concurrencies) for the models in question with Claude Code as harness on a sample of 64 tasks from SWE Bench Pro:
| Model | Resolution Rate |
|---|---|
| Kimi K3 | 86.4% |
| GLM-5.2 | 62.5% |
| Anthropic Opus 4.8 (API) | 62.5% |
| DeepSeek-V4-Flash | 39.1% |
| Qwen3.6 | 35.4% |
Remember though that such benchmarks are only a proxy for how good a model will work for your use case - and you will have to test that for yourself. Luckily, just for the quality of the model, you can judge that with free or cheap APIs in a limited test.
Between 0 and 64. Or at least according to the configurations we looked at — but the fact that it's a range is the point we're making here.
If you're serious about investing in your own hardware, here are some key takeaways:
Your mileage may vary of course. Hence, measure your own workload. Get a better view on your peaks. And keep on doing it as your organization matures into using AI coding agents. While your current numbers may point towards API usage for now, in a few months' time this may be much different.
Steven L., Wouter V.d.B., Michaël M., Ioana F., Jan F., Christian M., Maxim C., Arathy U., Bohdan D., Sepideh P., Baptist V., Jeroen B., Robbert V.C., Mathias F., Hendrik M., Jannick V.
Core to our philosophy is that the details of the real-world workload matter when thinking about your AI stack - both software and hardware. To measure this, we set up a system that mimics as much as possible the behavior of coding agents.
Hardware tested: - DGX Spark (Lenovo ThinkStation PGX) sitting on our desks - A single H200 hosted in our on-premise datacenter (with 24 CPU cores, 64GB memory) - A HGX 4×H200 connected via NVLink hosted in our on-premise datacenter - A HGX 8×B200, hosted by a dedicated AI cloud infra provider
Models and serving configurations: - Qwen3.6-35B-A3B on DGX Spark with vLLM settings from recipes.vllm.ai (using MTP speculative decoding) - Qwen3.6-35B-A3B on H200 with vLLM settings from recipes.vllm.ai (using MTP speculative decoding) - DeepSeek-V4-Flash hosted with tensor parallelism 4 and the vLLM settings from recipes.vllm.ai (adapted from the 8×H200 recipe, using MTP speculative decoding) - GLM-5.2 hosted with tensor parallelism 8 and the SGLang settings recommended by modal.com (using EAGLE speculative decoding)
Workload configuration: - Multiple workers running agentic coding tasks in parallel against the endpoint, each in a separate Docker container - Each task gets a coding task from the Harbor task format - Workers hosted on the infra of a sandbox provider, running on commodity CPUs
Task phases: 1. Setup to ensure prerequisites are installed 2. The actual code generation loop which drives requests to inference endpoint 3. A final evaluation to check if the generated code passes tests
Setup and evaluation phases were retained as they act as a basic resemblance to the work a developer does outside of coding - like grabbing a coffee in between two tasks. However, task time in plots is reported on the actual code generation only. The inclusion of the setup and evaluation lower the effective concurrency of the endpoint as at any time some agents are in such a phase and not sending requests.
Task set: 64 tasks sampled from SWEBench Pro by ScaleLabs.
Metrics: Sustained throughput in the bulk of the taskset, excluding the end of the queue when only few straggling tasks remain. Individual short peaks go a lot higher (especially for GLM-5.2) but these levels are not consistent for longer times.
Variance: While small for tokens/s, task times and resolution rate, it is especially outspoken in the occurrence of the collapse of the throughput of Qwen3.6 and DeepSeek-V4-Flash at higher concurrences. This has to do with the stochasticity of the incoming requests when using so many workers. The team picked the lowest concurrency level at which collapse happens, as this indicates the setup is no longer reliable for production purposes.