deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

SOKKAN launches Swiss inference tier on four Intel Arc Pro B60 GPUs with no NVIDIA inside

A Geneva company is selling AI inference from Intel Arc Pro B60 hardware it owns, publishing measured throughput numbers alongside the limits of a non-NVIDIA software stack.

SOKKAN launches Swiss inference tier on four Intel Arc Pro B60 GPUs with no NVIDIA inside

SOKKAN Inference, a product of Geneva-based Ninabot Sàrl, has gone live with an inference tier called Swiss that runs on hardware the company owns in Meyrin, Geneva — and that contains no NVIDIA silicon. In an engineering post on dev.to, the team behind the service published both the throughput they measured and the places where the stack breaks down, making it one of the more candid accounts of serving models commercially on Intel Arc Pro hardware.

The hardware bet

According to the post, SOKKAN already operated two EU-sovereign tiers from French datacenters but had no answer for customers whose data may not leave Switzerland at all. Buying GPUs in the middle of a memory shortage pushed them away from NVIDIA: a month of chasing second-hand RTX 3090s ended in lost auctions, while the Intel Arc Pro B60 — 24 GB of VRAM on a 2-slot blower card — was still available near MSRP at CHF 614 per card. Four cards cost roughly CHF 2,450 and delivered 96 GB of VRAM. The chassis is a 2018 X299 workstation with an i9-9980XE and 64 GB of DDR4 that also carries production workloads, which the authors say makes every benchmark pessimistic.

What runs on the cards

Three models are resident. Card 0 runs gpt-oss-20b in MXFP4 on an Intel XPU build of vLLM 0.21, occupying 13 GB. Card 1 serves Qwen3-Coder-30B-A3B as a Q4_K_XL GGUF through llama.cpp's SYCL backend, using 17.7 GB. Cards 2 and 3 together hold Qwen3-Next-80B-A3B at Q3_K_XL, also via llama.cpp SYCL, at 35.6 GB. All three are mixture-of-experts models with roughly 3B active parameters, which is what lets them cohabit on one machine. The Swiss tier itself is card 0.

The measured numbers

For gpt-oss-20b under vLLM, a single request sustains 35.1 tokens per second, four concurrent requests still get 33.6 tok/s each for 133.9 tok/s aggregate, and an earlier run at eight concurrent requests reached 241 tok/s aggregate. Prefill measures around 5,000 tok/s on a 4,300-token prompt, and continuous batching keeps per-request speed nearly flat as load grows. Power draw for all four cards is 163 W idle and 211 W peak under twelve concurrent requests, at temperatures of 52–62 °C. The whole machine moves from 13% to 19% UPS load, working out to roughly CHF 750 a year in electricity at Swiss prices. Tool calling works on all three models, though gpt-oss requires specific vLLM flags and the harmony parser — without them, requests return zero tool calls and empty content.

Where it does not scale

The 80B model is the weak point, and the post attributes this to the runtime rather than the model. llama.cpp has no continuous batching, so under concurrency the 80B drops from 32.0 tok/s for one user to 14.5 tok/s each for two and 7.0 tok/s each for four — and aggregate throughput actually regresses from 32 to 20.7 tok/s, meaning four users complete less total work than one. vLLM on Intel XPU, meanwhile, only serves quantisations that have a native XPU kernel: MXFP4 gpt-oss works, but every other quantised MoE the team tried routed its expert layers to Marlin, an NVIDIA kernel, and failed with a device_capability error. Dense AWQ runs if float16 is forced; AWQ MoE does not. Attempts at vLLM tensor parallelism across the four cards wedged the machine three times in a day even with ample free RAM, which the authors suspect is a DMA or PCIe problem on the old chipset rather than memory pressure. llama.cpp, which loads sequentially, spread gpt-oss-120b across the four cards at 18.8 tok/s decode without incident.

The tier as sold

The commercial offering is deliberately narrow: a 20B-class model suited to chat, RAG and agents, but not frontier coding. Data stays in Switzerland, failover goes to a neighbouring card in Geneva rather than to an EU provider, and if that is also down the client receives a clear error instead of a silent detour. Capacity is capped at four concurrent requests, above which the API returns a 429 rather than queueing. Pricing is CHF 0.60 per million input tokens and CHF 2.40 per million output tokens, prepaid and metered to the token. The endpoint is Anthropic Messages-compatible, so Claude Code and other Anthropic clients work by changing environment variables. The company says reselling raw tokens is not the business case; the point is hosting services on top of the model with the same residency guarantee, and the same four-card configuration is becoming SOKKAN Anchor, an on-prem appliance for organisations that have banned the cloud entirely.

Why it matters

The post is a rare public data point on operating a commercial inference service without NVIDIA hardware. It shows the Intel route is viable at small scale — 35 tok/s per request with near-linear scaling under vLLM is genuinely usable — while documenting exactly where the software stack, not the silicon, sets the ceiling: no continuous batching in llama.cpp and a thin set of working XPU kernels in vLLM. For teams facing strict data-residency requirements, the architecture described here, including its honest failure modes and its fail-in-place failover policy, is a useful reference for what a sovereign inference tier can realistically promise today.

  • #intel-arc
  • #ai-inference
  • #vllm
  • #llama-cpp
  • #data-sovereignty