Kimi K3 measured packages and prices

RunInfra lists 1 measured package for Kimi K3. The newest published row, kimi-k3-b300x8-k3turbo, costs $500 one-time on B300 with vLLM 0.23.1. Its speed result is 2.12x faster. Request profile: Single-stream decode with one variable between the two columns of this comparison. Both columns were measured on 2026-07-31 in one window, one container, one engine install, on the same 8x B300 cards, run back to back with an idle drain between them, and the comparison verified the request profiles identical across the arms, including per-point prompt fingerprints, before rendering any number. The baseline column is the batch profile and the optimized column is the interactive profile. The throughput figures are per-request decode rates at concurrency 1, the speed one user experiences, not per-GPU figures and not node aggregates: 55.15 output tokens per second p50 for the batch profile and 119.84 for the interactive profile, which is 2.17x. Dividing either figure by eight describes nothing real because all eight cards cooperate on one stream, and multiplying by eight would invent a many-stream aggregate this profile did not measure. The profile, stated exactly: single-stream sequential, concurrency 1, 8 timed requests per arm, 1024 prompt tokens target, 1024 output tokens requested per request, temperature 0.0, ignore_eos on, streaming, a fixed seed, and 8 of 8 requests ok on each arm. The latency stats beside each column are end-to-end request times from the same runs: the interactive profile median request finishes in 9.0 seconds instead of 19.1, its time to first token is better in this window (429.30 ms against 535.06), and its time per output token is higher (23.10 ms against 18.13). Know the boundary of this result before you deploy on it: the 2.17x is a concurrency-1 fact, and the same window measured how the advantage narrows with load on 32768-token-prompt workloads, +89.59 percent per GPU at concurrency 1, +17.83 percent at concurrency 8, and flat at concurrency 32 (minus 0.83 percent, inside the measurement noise floor) where time to first token still improves. Version 3 published a different tuning of the interactive profile whose advantage INVERTED at concurrency 32, and told you to switch to the batch profile above roughly concurrency 8; a one-variable window then measured the two tunings against each other and the version 4 tuning won at every point, so that rule is retired. This is a 1024-token profile, not the 32K repo-scale profile version 2 published, and version 2 per-GPU throughput figure must not be compared with these per-request rates.. Concurrency 1. That result applies only to those recorded conditions. Proof verified Jul 31, 2026. Other package prices and measurements remain separate below.