The unifying finding of this slice: what practitioners optimise for is integration cost and ecosystem maturity, not measured throughput - the same driver explains every engine and hardware preference recorded here

Every strong consensus in this sentiment layer resolves to the same underlying variable, and it is not performance. On engines: llama.cpp wins on dependency count and quant coverage, vLLM wins on Day-1 model support and contributor headcount, SGLang wins on multinode setup simplicity, TensorRT-LLM wins when the hardware is fixed. On hardware: the 3090 wins on VRAM per dollar, and DRAM prices rising in 2026 actively strengthened that recommendation - 'RAM Prices are skyrocketing and it is entirely unfeasable imo to buy'. What people regret is ecosystem and driver maturity (sm121 missing tcgen05, CUTLASS unvalidated on SM120), what resists migration is version coupling, and what caps a stack is a missing scheduler. Throughput appears in the corpus mostly as a tiebreaker or as something practitioners decline to argue about: 'it is very fluid and hard to say which is really best', 'they are now neck and neck', 'any shootoff will be "it depends" rather than a A or B is better.'

The inference stack is young enough, and the hardware/software coupling tight enough, that the dominant real-world cost of a choice is not the throughput it forgoes but the maintenance surface it creates. A stack with more moving parts loses even when it benchmarks better, because the parts are independently versioned and their compatibility is not transitive - see sent-migration-resistance-version-coupling-not-performance. A part whose libraries are not validated loses on features regardless of its FLOPS, because the missing features are the ones the vendor advertised - see sent-regret-non-blackwell-engine-support-lags. This is the gap the repo otherwise does not record: a platform can benchmark well and be avoided, and the reason will be in this variable.

When choosing an engine or a part, ask three questions the corpus answers consistently: how many independently versioned components do I have to pin together, does the vendor's kernel library enumerate my exact architecture, and what is the migration cost if I am wrong. Weight those above a benchmark delta unless the delta is large and the workload is throughput-bound.

This is the interpretive record for the slice and the one a general reader should read first. Two caveats so it is not over-read. First, it is a claim about the self-hosted-inference community specifically, not about all inference engineering - an organization with a fixed model, fixed hardware and a steady request rate rationally does the opposite and accepts build complexity for throughput, which is the TensorRT-LLM case. Second, the same slice records the counter-camp with equal prominence: 20 upvotes, 'price and performance are not why users here are going local', and a 69-upvote owner for whom the value was freeing his desktop from the job rather than any throughput figure. The variable is integration cost - which includes, for a hobbyist, not having to own the machine.