For almost every engine in this repo the honest answer to 'does it run in production, and at what scale' is NO EVIDENCE FOUND - and that negative is worth more than an inferred answer

Asked to record real-world deployment evidence for each engine, the actual yield on 2026-10-04 was TWO engines with first-party-adjacent numeric field reports from named production sites: [[sglang]] (issue #40877, DeepSeek-V4.1-Flash on 8x RTX PRO 6000, 'field data from running ... as a production SGLang backend', with the author stating the numbers 'come from a working day of production use') and [[vllm]] (issue #56700, the same model on the same 8x RTX PRO 6000 hardware, a 3-day bring-up). Beyond those, what exists is: vendor assertion of scale without a number, a named deployment with no published measurements, or nothing at all. Examples of each. VENDOR SCALE ASSERTION: [[nvidia-dynamo]], [[llm-d]], [[niche-kserve]], [[niche-ray-serve]] and [[triton-inference-server]] are all infrastructure whose entire purpose is production serving, and all of them publish capability and integration claims rather than their own traffic. NAMED DEPLOYMENT, NO NUMBERS: [[text-generation-inference]] is recorded as powering Hugging Chat and the HF Inference API/Endpoints - that is a real, named, large deployment, and the vendor publishes no throughput, no request volume and no fleet size for it. ALREADY KNOWN TO THIS REPO: [[alt-cerebras-csl-sdk]] and [[alt-groq-groqflow]] have dedicated records for the fact that no throughput figure is published at all. NOTHING: [[niche-lightllm]], [[niche-lmdeploy-turbomind]], [[ktransformers]], [[exllamav3]], [[exllamav2]], [[mlc-llm]], [[niche-medusa]], [[niche-eagle]], [[distserve]], [[semi-pd]], [[niche-loongserve]], [[spinquant-research-harness]] and [[smoothquant-reference]] surfaced no deployment evidence at all in searches of their repos, READMEs, docs and issue trackers.

Two distinct causes that need to be kept apart. (a) Some of these are research artifacts where non-deployment is the POINT and there is nothing to find - LoongServe, DistServe, Semi-PD, Medusa, SpinQuant, SmoothQuant and EAGLE are paper-code releases, and their authors never intended a deployment story, so the absence of evidence is not a criticism of anything. (b) For the rest, the cause is that PRODUCTION SITES DO NOT PUBLISH THEIR NUMBERS, and vendor blogs about serving stacks are written to sell the stack rather than to characterise it. Neither cause is repairable by more searching, which is the honest conclusion: a second afternoon of searching would not change this.

Treat deployment evidence as a graded claim rather than a boolean, and say which grade a record is at. The grades this repo can currently support: (1) a first-party production site with hardware, configuration and measured throughput attached - currently [[sglang]] and [[vllm]] only; (2) a named production deployment with no numbers, e.g. [[text-generation-inference]] at Hugging Chat; (3) an infrastructure project whose existence implies deployments but which publishes no scale, e.g. [[triton-inference-server]] and [[niche-kserve]]; (4) an artifact-evaluation or paper submission, where non-deployment is documented intent; (5) NO EVIDENCE FOUND as of the date searched. Record the DATE of the search, because grade (5) is the only grade that decays. Also record explicitly when a figure is a vendor's own load-test number rather than a production observation - the repo already has records in the other direction (see the LoongServe note that no independent throughput was verified), and this gotcha is the deployment-side counterpart.

This is the most important negative in the whole assignment and the one most likely to be quietly dropped, because an empty 'production evidence' field looks like an omission rather than a finding. Stating it as a graded, dated claim is what makes it survive a re-read. ALSO IMPORTANT AND EASY TO GET WRONG: 'no evidence found' is NOT 'not deployed'. Several engines here are almost certainly deployed widely and simply do not publish about it - [[llama-cpp]] and [[ollama]] in particular, where adoption is visible through download counts and dependent projects (Ollama's own record notes it vendors llama.cpp as a submodule with a pinned LLAMA_CPP_VERSION) rather than through any deployment claim. Equally, a project being on PyPI, in a vendor product, or in a Kubernetes operator's supported list is evidence of USE, not of production SCALE. WHAT I COULD NOT VERIFY: no request-volume, QPS, fleet-size or GPU-count figure was found for ANY engine record in this repo other than the two field reports named above; no independent third-party benchmark of vLLM or SGLang as deployed systems (rather than in a lab) was found; and the 'in production' claims on vendor pages were not treated as citable because they carry no number and no load condition. See [[ev-maintenance-status-is-four-dated-facts]] for the adjacent dated-fact discipline, since a dormant engine is the most likely reason an engine's production footprint is small.