Nishi Family › Compare › GPU Worker Mesh and Distributed Inference

Nishi Compare · capabilities, evidence and delivery

GPU Worker Mesh and Distributed Inference

Compare capabilities and delivery evidence. Source discovery, qualification, deployment and accepted outcomes are separate; an open contract names work still to verify.

A NAS orchestrator dispatching capability-scoped jobs to GPU workers (laptop 5080 images, west 3090 video, cloud) and pushing results to the gallery -- Nishi vs NVIDIA Triton and Ray Serve and Modal and KServe

Overview

The purpose, declared position and evidence coverage of this domain. Source presence and completed acceptance are different measures.

Where we are. Measured 2026-08-19. Every row of the mesh is present and proven: ocap dispatch, cross-host routing, sovereign actuation, daemonless governance, a content-addressed registry, batching scheduler, load balancing, autoscale to zero, streaming, admission, multi-model residency -- with three exceeds on sovereignty and capability scoping. The matrix carries no symbol gaps; this plan admits four watch contracts on the rows where Triton, Ray and Modal lead: circuit-breaker failover, on-demand model load, fused batched execution and a live remote replica.

Where we need to go. Make the mesh robust and fast -- breakers, on-demand residency, fused batches -- then prove the cluster with a remote replica serving live, keeping zero per-call cost and the ocap grant as the exceed.

The unit. 1 u = one measured session-leg. Calibration from landed rungs: the mangagen panel compositor went from existing substrate to shipped and live-verified in ONE leg (2026-08-13); the citations rung went from 3 to 55 domains in one leg across seven seats (2026-08-18); a greenfield engine with a bite-proven gate has measured 2 to 4 legs. Estimates recalibrate as rungs land and PR7 actuals write back.
Cost to robust: 2.5 u. Through M0.
Cost to throughput: 5 u. Through M1.
Cost to cluster: 7 u. Everything below.

Latest recorded release

No valid dated release entry is recorded for this domain.

Release entries describe recorded changes; they do not establish that every capability passed evaluation.

17 of 21 capability source symbols found|3 of them authored stronger-claims|4 open|coverage 809/1000|adoption 9 full / 8 partial

Evidence profile — what the gaps on this board actually are

Measured by nx_swcompare_evidence, read back by nx_evprofile_lib. Every figure is a count with its denominator — there is deliberately no score, no grade and no percentage anywhere in this band, because a stored scalar is a field a seat can edit and a counted partition is not.

evidence|grounded 17/17|unsupported 0|gates green 7/7|proven able to fail 7/7|never bitten 0|green at 0/0 7|open gaps 4|of them unnamed 0|of them proof withheld 0|flips ready 0

proven able to fail counts the gates that have a RECORDED RED — nx_gate_bite mutated the gate subject, rebuilt it, watched the gate go red, and that record is inside the shared TTL. never bitten is its complement over the same denominator: those gates ran and were green, and nothing has ever shown them able to detect anything, so their green is a statement about this run and not about the gate. green at 0/0 is a separate and much weaker observation — the gate printed GREEN on a zero denominator, so its own tooth counter says it examined nothing. A gate can be green, non-zero, and still never bitten; that is the common case and it is now visible instead of implied.

partition: grounded + unsupported = 17 vs present 17 · named + unnamed + withheld = 4 vs open 4 · both reconcile

liar-kill conj=GPQN · all four conjuncts held

graded document: BUILDROOT tree, 7451 bytes · gates map: PRIMARY · stamped 3d 13h ago · source ../knowledge/status/evstamp_workermesh.verdict

Gap classWhat it is, and the work it names
VACUOUS-GATEA gate reported GREEN on a ZERO denominator. A gate with real teeth and a broken counter, and a gate with no teeth at all, are indistinguishable from outside; that indistinguishability is the finding, so it is reported here and never convicted.
This band reports the referee counts. The per-axis worklist rows — which axis is unsupported, which watch is ready to flip, which gap is unnamed — are printed by nx_swcompare_evidence workermesh itself and are not carried on the stamp, so this page names the classes and the producer names the rows. That split is stated rather than hidden: a count without a worklist is not actionable, and this band is honest about which half of that it is.

Production map

Follow the dependencies, declared acceptance criteria and recorded priorities. Inspect source binding before treating a rank as executable work.

Ranking source binding: PLAN_MATRIX_BOUND_ONLY. Recorded priorities require current acceptance evidence and resource checks before execution.

Ranking matches the captured plan and matrix only. Latest execution outcome, research freshness, accepted delivery and investment return are unverified.

Recorded priority estimates

Order from nx_compare_rank (nx_dr_ocm: (deficit + cost-of-delay + option + enables) x sponsor x self-sufficiency x momentum / cost). FINISH rows are rungs whose symbol is present but whose organ is short of full adoption: listed before new work by this heuristic. Priority is not measured delivery cost or execution readiness. Stamp: # asof=1790081762 domain=workermesh target_version=0.1 rungs=4 done=0 open=4 finish=0 ranker=nx_dr_ocm

#StageRungPriorityDerivation
#10.1Circuit breaker (R0) wd_circuit dossier1700v=17 m=1 c=10
#20.1On-demand load and unload (R1) mx_load_on_demand dossier800v=12 m=1 c=15
#3laterRemote replica live (R3) lb_remote_replica dossier600v=12 m=1 c=20
#4laterFused batched execution (R2) mb_fused_exec dossier240v=6 m=1 c=25

Declared roadmap — contract, acceptance, executor, effort

RungCloses withDefinition of done (pre-declared)ExecutorEst.
Circuit breaker (R0)wd_circuitPer-worker failure history opens a breaker after N failures, half-opens on a schedule and closes on success; N and the schedule are conf rows; a flapping fixture is shed, a healthy one is routedOrgan1 u
On-demand load and unload (R1)mx_load_on_demandA request for a non-resident model triggers load under the VRAM budget with LRU eviction and the request completes; idle models unload on the autoscale schedule; VRAM before and after printedOrgan1.5 u
Fused batched execution (R2)mb_fused_execA batching-capable backend executes n greater than 1 as one forward pass; measured seconds per image at batch 4 below sequential by a PRE-DECLARED margin on the 5080Organ2.5 u
Remote replica live (R3)
after R0
lb_remote_replicaThe 3090 box or a cloud replica joins as an endpoint row, serves live traffic through the balancer and is skipped when it drops; the routing log names the replica per requestOrgan2 u

Milestones

MilestoneRungsCumulative
M0 · RobustR0,R12.5 u
M1 · ThroughputR25 u
M2 · ClusterR37 u
Ladder verdict. NOT DECLARED. This board names no dated best-in-class or frontier target and no rung roles (sotatarget and rungrole rows on its plan); the ranker labels it NO-LADDER until it does, and until then its rungs climb toward a target nobody has written down. Bars read NO-BAR against the current month 2026-10.
Bar freshness, counted
ClassCountNote
bars0sotabar rows on the plan
fresh0the bar month is the current month
attested0an older bar with a this-month barscan reporting no newer entry
stale0a this-month scan saw a newer month the bar ignores
unattested0nobody looked this month
malformed0a sotabar row missing a field
duplicate0bar ids an earlier row already carries
bars, summed0RECONCILED: the parts sum to the total 0
current month2026-10the month every bar is judged against
Treatment verdict. NOT DECLARED. No rung on this board declares its three-step treatment (a treat row naming the MCP row, the API route, the primitive it composes, the workflow that composes it and the agent beat that runs it); the ranker labels every rung TREATMENT-UNDECLARED until it does.

Inspect a rung and its prerequisites

Declared nodes 4. Rank input binding: PLAN_MATRIX_BOUND_ONLY. Dependency order is authored. Implementation, acceptance evidence, authority and resource readiness are unverified. No action is recommended or dispatched here.

Plan SHA-256 ea85661e611666fb7c1a62c7593528de810ec14f04fbba192673cc0d210d1683. Target rows 0; role rows 0. Existing risks and release worklog retain their own scope; no node completion is inferred.

Runtime observation coverage: 0 of 4 rungs have current, identity-bound execution observations. Observation may report RED. Accepted completion remains unknown; source presence, qualification and deployment do not establish it.

Use Enter or Space on a rung to inspect its contract. Prerequisite links locate another rung in this list; open its summary to inspect it. Estimates are authored effort, not forecasts.

  1. R0 — Circuit breaker

    Prerequisites: None declared; this does not establish execution eligibility.

    Contract: wd_circuit

    Acceptance: Per-worker failure history opens a breaker after N failures, half-opens on a schedule and closes on success; N and the schedule are conf rows; a flapping fixture is shed, a healthy one is routed

    Authored effort: 1. Executor kind: Organ. Responsible, accountable and verifier not established. Inspect retained worklog.

    Runtime observation: UNKNOWN; outcome UNKNOWN; observed epoch -1. Declared owner: . Receipt , SHA-256 . Identity-bound observation is not accepted completion. Qualification and deployment remain unverified by this projection.

  2. R1 — On-demand load and unload

    Prerequisites: None declared; this does not establish execution eligibility.

    Contract: mx_load_on_demand

    Acceptance: A request for a non-resident model triggers load under the VRAM budget with LRU eviction and the request completes; idle models unload on the autoscale schedule; VRAM before and after printed

    Authored effort: 1.5. Executor kind: Organ. Responsible, accountable and verifier not established. Inspect retained worklog.

    Runtime observation: UNKNOWN; outcome UNKNOWN; observed epoch -1. Declared owner: . Receipt , SHA-256 . Identity-bound observation is not accepted completion. Qualification and deployment remain unverified by this projection.

  3. R2 — Fused batched execution

    Prerequisites: None declared; this does not establish execution eligibility.

    Contract: mb_fused_exec

    Acceptance: A batching-capable backend executes n greater than 1 as one forward pass; measured seconds per image at batch 4 below sequential by a PRE-DECLARED margin on the 5080

    Authored effort: 2.5. Executor kind: Organ. Responsible, accountable and verifier not established. Inspect retained worklog.

    Runtime observation: UNKNOWN; outcome UNKNOWN; observed epoch -1. Declared owner: . Receipt , SHA-256 . Identity-bound observation is not accepted completion. Qualification and deployment remain unverified by this projection.

  4. R3 — Remote replica live

    Prerequisites: R0 (acceptance unverified)

    Contract: lb_remote_replica

    Acceptance: The 3090 box or a cloud replica joins as an endpoint row, serves live traffic through the balancer and is skipped when it drops; the routing log names the replica per request

    Authored effort: 2. Executor kind: Organ. Responsible, accountable and verifier not established. Inspect retained worklog.

    Runtime observation: UNKNOWN; outcome UNKNOWN; observed epoch -1. Declared owner: . Receipt , SHA-256 . Identity-bound observation is not accepted completion. Qualification and deployment remain unverified by this projection.

Learning and practice paths

No structured learning path is declared for this plan. Existing research, roadmap and worklog remain available above.

Rung dossiers — every record that bears on a rung, in one place

Joined by symbol, never typed. Each dossier is assembled on every publish from the rows this board already carries: the plan's rung row, the matrix row that carries its contract symbol (its status re-measured by the one symbol ruler), the gate the organ declares and the verdict the evidence referee recorded on its last run, the reference marks in the rung text, the design rows that name the rung and the work log filed against it. The capability matrix links each cell to its dossier and each dossier links back to its cell and forward to the rungs it stands on; a dependency naming no rung on this plan is written as UNRESOLVED rather than linked. Absences are named: NO-MATRIX-ROW, NO-GATE-DECLARED, UNRECORDED.
Gate verdicts: UNSTAMPED — no per-gate verdict artifact is published for this domain yet (nx_swcompare_evidence workermesh writes it beside its stamp); every gate below reads UNRECORDED until it runs.
Gate declarations: knowledge/organ_gate.conf read from this working directory (1 rows) and from the estate root (196 rows); rows in both counted once: 0; declarations read: 197. Every declaration in either copy counts, so a stub beside the publisher can never hide the root.
R0 Circuit breaker · cell WATCHING · gate NO-GATE-DECLARED
Contractwd_circuit · executor Organ · 1 u · stands on nothing
Definition of donePer-worker failure history opens a breaker after N failures, half-opens on a schedule and closes on success; N and the schedule are conf rows; a flapping fixture is shed, a healthy one is routed
Matrix cellFailover with health history and circuit breaker · runtime/nx_worker_dispatch.nx · WATCHING decl
GateNO-GATE-DECLARED — knowledge/organ_gate.conf carries no row for nx_worker_dispatch; declare nx_worker_dispatch TAB <gate> and the ship loop proves it and the verdict lands here.
Work logno log row names this rung yet
R1 On-demand load and unload · cell WATCHING · gate NO-GATE-DECLARED
Contractmx_load_on_demand · executor Organ · 1.5 u · stands on nothing
Definition of doneA request for a non-resident model triggers load under the VRAM budget with LRU eviction and the request completes; idle models unload on the autoscale schedule; VRAM before and after printed
Matrix cellOn-demand model load and unload · runtime/nx_mesh_mux.nx · WATCHING decl
GateNO-GATE-DECLARED — knowledge/organ_gate.conf carries no row for nx_mesh_mux; declare nx_mesh_mux TAB <gate> and the ship loop proves it and the verdict lands here.
Work logno log row names this rung yet
R2 Fused batched execution · cell WATCHING · gate NO-GATE-DECLARED
Contractmb_fused_exec · executor Organ · 2.5 u · stands on nothing
Definition of doneA batching-capable backend executes n greater than 1 as one forward pass; measured seconds per image at batch 4 below sequential by a PRE-DECLARED margin on the 5080
Matrix cellFused batched forward on the worker · runtime/nx_mesh_batch.nx · WATCHING decl
GateNO-GATE-DECLARED — knowledge/organ_gate.conf carries no row for nx_mesh_batch; declare nx_mesh_batch TAB <gate> and the ship loop proves it and the verdict lands here.
Work logno log row names this rung yet
R3 Remote replica live · cell WATCHING · gate NO-GATE-DECLARED
Contractlb_remote_replica · executor Organ · 2 u · stands on R0
Definition of doneThe 3090 box or a cloud replica joins as an endpoint row, serves live traffic through the balancer and is skipped when it drops; the routing log names the replica per request
Matrix cellRemote replica live across hosts · runtime/nx_mesh_lb.nx · WATCHING decl
GateNO-GATE-DECLARED — knowledge/organ_gate.conf carries no row for nx_mesh_lb; declare nx_mesh_lb TAB <gate> and the ship loop proves it and the verdict lands here.
Work logno log row names this rung yet

dossiers=4 cells_joined=4 no_matrix_row=0 (sum 4) gates_recorded=0 gates_unrecorded=0 no_gate_declared=4 (sum 4 of cells_joined) evgates=UNSTAMPED

Capability comparisons

Compare the field, search individual capabilities and open their source and adoption evidence. Documented presence does not establish comparative quality.

Position map — centrality and distinctiveness

The four-quadrant map the field uses for brand strategy (Dawar and Bagga, HBR June 2015), re-derived from this matrix on every publish. Centrality is the share of the category's feature mass a player covers, each feature weighted by how many hold it; distinctiveness is the average lead over each rival on the rows the player holds; breadth is the depth-weighted share of the whole matrix (the bubble); depth is how deeply the rows held are held; momentum is the day-over-day move off the spine (green rising, red falling, grey until day two); the dashed path runs first day → previous day → today. Dividers are the category means. Axes are fitted to the field of play, so read the tick numerals, not the frame. Rival marks are documented presence, so a rival's position reads the record, never its quality. The picture grades its own readability below; the table beside it is the same data for a screen reader or a second method.

Rows. 21 feature rows mapped of 21 matrix rows; 0 substrate rows (kernels, bounds and instruments the plan's rungrole marks substrate) are the estate's scaffolding, not category features, and stay off the map
Views. 2D cut: centrality, distinctiveness · 3D cube: centrality, distinctiveness, breadth · axes registered: centrality, distinctiveness, breadth, depth, momentum · a board picks its own in knowledge/compare/workermesh.cdmap (cut|x|y, cube|x|y|z); absent = the HBR defaults
Position map, two-dimensional cutOne bubble per player. Bubble area is breadth, the ring colour is momentum, the dashed lines are the category means, and both axes are fitted to the field of play with their tick numerals shown. Every value is repeated in the table that follows. 800 850 900 950 1000 80 100 120 140 160 180 200 220 centrality (permil, fitted 800–1000) distinctiveness (permil, fitted 80–220) mean 936 mean 140 Unconventional Aspirational Peripheral Mainstream Nishi, centrality 820, distinctiveness 196, breadth 587, depth 725, momentum 0 NVIDIA Triton, centrality 966, distinctiveness 129, breadth 714, depth 833, momentum 0 Ray Serve, centrality 966, distinctiveness 120, breadth 714, depth 833, momentum 0 Modal, centrality 966, distinctiveness 148, breadth 761, depth 888, momentum 0 KServe, centrality 966, distinctiveness 111, breadth 714, depth 833, momentum 0 Nishi NVIDIA Triton Ray Serve Modal KServe

bubble area = breadth · ring = momentum (green rising, red falling, grey until day two) · dashed = category means · axes fitted to the field of play: centrality 800–1000, distinctiveness 80–220 of 0–1000 permil (the full range put every player in one corner)
readability of the 2D cut, self-graded by the layout ruler: label overlaps 0 · labels over marks 0 · off-canvas 0 · unresolved labels 0 · mark overlaps 0 (a fact of the data: two players that close are that close) · data spread 667 permil of the plot · quadrant words unseated 0
text contrast, measured with wcag2-ratio (floors from contrast.conf), light theme: labels 16.24 (floor 4.50) · notes 16.24 (floor 4.50) · quadrant words 5.89 (floor 4.50) · tick numerals 5.89 (floor 4.50) · axis titles 5.59 (floor 4.50) · dark theme: labels 13.78 (floor 4.50) · quadrant words 5.55 (floor 4.50) · axis titles 5.97 (floor 4.50) · dark classes under their floor 0 (one figure serves both themes: a dark shortfall is a token to fix, never a class to hide) · classes refused under their floor 0 (a refused class is not drawn; the scale classes are measured, never hidden) · export: SVG PNG (receipt, rendered by the estate's own rasteriser from this page)
Position map, three-dimensional cubeThe same players in an isometric cube. Each axis is fitted to its own field of play and carries numerals on the floor grid and the vertical axis; each bubble drops a dotted line to its floor shadow so height reads as height. Values are in the table that follows. 800 850 900 950 1000 80 100 120 140 160 180 200 220 550 600 650 700 750 800 centrality distinctiveness breadth Nishi: centrality 820, distinctiveness 196, breadth 587 KServe: centrality 966, distinctiveness 111, breadth 714 Ray Serve: centrality 966, distinctiveness 120, breadth 714 NVIDIA Triton: centrality 966, distinctiveness 129, breadth 714 Modal: centrality 966, distinctiveness 148, breadth 761 Nishi NVIDIA Triton Ray Serve Modal KServe
axes fitted: centrality 800–1000 · distinctiveness 80–220 · breadth 550–800 permil · farther bubbles are painted first, nearer ones over them · the floor shadow is each bubble's (x, y) at height 0
readability of the 3D cube, self-graded by the layout ruler: label overlaps 0 · labels over marks 0 · off-canvas 0 · unresolved labels 0 · mark overlaps 2 (a fact of the data: two players that close are that close) · data spread 459 permil of the plot
Position map, small multiplesEvery pair of registered axes as one small cut. Each panel fits both axes to the field of play, the dashed lines are the category means, bubble area is breadth and the ring colour is momentum; the legend below names the colours. 800 1000 80 220 distinctiveness vs centrality Nishi: centrality 820, distinctiveness 196 NVIDIA Triton: centrality 966, distinctiveness 129 Ray Serve: centrality 966, distinctiveness 120 Modal: centrality 966, distinctiveness 148 KServe: centrality 966, distinctiveness 111 800 1000 550 800 breadth vs centrality Nishi: centrality 820, breadth 587 NVIDIA Triton: centrality 966, breadth 714 Ray Serve: centrality 966, breadth 714 Modal: centrality 966, breadth 761 KServe: centrality 966, breadth 714 800 1000 700 950 depth vs centrality Nishi: centrality 820, depth 725 NVIDIA Triton: centrality 966, depth 833 Ray Serve: centrality 966, depth 833 Modal: centrality 966, depth 888 KServe: centrality 966, depth 833 800 1000 480 520 momentum vs centrality Nishi: centrality 820, momentum 500 NVIDIA Triton: centrality 966, momentum 500 Ray Serve: centrality 966, momentum 500 Modal: centrality 966, momentum 500 KServe: centrality 966, momentum 500 80 220 550 800 breadth vs distinctiveness Nishi: distinctiveness 196, breadth 587 NVIDIA Triton: distinctiveness 129, breadth 714 Ray Serve: distinctiveness 120, breadth 714 Modal: distinctiveness 148, breadth 761 KServe: distinctiveness 111, breadth 714 80 220 700 950 depth vs distinctiveness Nishi: distinctiveness 196, depth 725 NVIDIA Triton: distinctiveness 129, depth 833 Ray Serve: distinctiveness 120, depth 833 Modal: distinctiveness 148, depth 888 KServe: distinctiveness 111, depth 833 80 220 480 520 momentum vs distinctiveness Nishi: distinctiveness 196, momentum 500 NVIDIA Triton: distinctiveness 129, momentum 500 Ray Serve: distinctiveness 120, momentum 500 Modal: distinctiveness 148, momentum 500 KServe: distinctiveness 111, momentum 500 550 800 700 950 depth vs breadth Nishi: breadth 587, depth 725 NVIDIA Triton: breadth 714, depth 833 Ray Serve: breadth 714, depth 833 Modal: breadth 761, depth 888 KServe: breadth 714, depth 833 550 800 480 520 momentum vs breadth Nishi: breadth 587, momentum 500 NVIDIA Triton: breadth 714, momentum 500 Ray Serve: breadth 714, momentum 500 Modal: breadth 761, momentum 500 KServe: breadth 714, momentum 500 700 950 480 520 momentum vs depth Nishi: depth 725, momentum 500 NVIDIA Triton: depth 833, momentum 500 Ray Serve: depth 833, momentum 500 Modal: depth 888, momentum 500 KServe: depth 833, momentum 500
Nishi NVIDIA Triton Ray Serve Modal KServe
10 panels over 5 registered axes, every pair once (the lower axis on x, the higher on y) · each panel fitted to its own field of play, first and last tick numerals shown · no labels in a small cut, the legend names the colours; the grade below reports the mark terms only (MM summed over the panels, spread averaged)
readability of the small multiples, self-graded by the layout ruler: label overlaps 0 · labels over marks 0 · off-canvas 0 · unresolved labels 0 · mark overlaps 23 (a fact of the data: two players that close are that close) · data spread 534 permil of the plot
PlayerQuadrantcentralitydistinctivenessbreadthdepthmomentumRows heldDays on spineFirst seen
NishiUnconventional8201965877250 since 2026-09-2317102026-09-15
NVIDIA TritonMainstream9661297148330 since 2026-09-2318102026-09-15
Ray ServeMainstream9661207148330 since 2026-09-2318102026-09-15
ModalAspirational9661487618880 since 2026-09-2318102026-09-15
KServeMainstream9661117148330 since 2026-09-2318102026-09-15
DayMatrix rows reviewedPlayers recorded
2026-09-15215
2026-09-16215
2026-09-17215
2026-09-18215
2026-09-19215
2026-09-20215
2026-09-21215
2026-09-22215
2026-09-23215
2026-10-08215

players 5|matrix rows 21|feature mass 89|centrality mean 936|distinctiveness mean 140|axes 5|spine days 10 (shown 10)|rows written today 0|readability defects 2D 0 cube 0|spine knowledge/status/cdmap/workermesh.spine

How to read this evidence. A Nishi source mark records whether the named symbol is declared in the selected source file. It does not establish working behavior or accepted delivery. A watching tag names an expected source entry; discovering it updates source coverage only. A dark tag means the file exists but the named symbol was not found: inspect the source and contract before assuming the capability is missing or renaming code. Peer codes are authored assessments; unassessed means no comparison is established, not absence. Qualification, deployment identity, runtime observations and acceptance must carry their own evidence. Adoption records the catalog's observed path through source, build, promotion, registration and invocation; libraries use importer evidence and gates use declared execution surfaces. A full catalog path does not establish quality, freshness or a successful user outcome. Partial and unknown states retain their stated next action. Census stamps: importers asof 1790637268, gate census asof 1790104131 (unix seconds; -1 = census absent).

Capability matrix — measured against source

◉ authored stronger claim; source present● present◐ partial○ absent? unassessed; excluded from relative comparison · click any capability for its evidence

Peer cell coverage: authored assessed 84, unassessed 0. Authored assessments are not verified outcomes.

CapabilityNishiNVIDIA TritonRay ServeModalKServe
Capability-scoped job dispatchMeasured: WORKERDISPATCHGATE exists in runtime/nx_worker_dispatch.nx, verified at emit. Ray and Modal are Best at programmatic dispatch [ray-serve] [modal-scale]; Nishi routes by job type to the right worker class and enforces the grant deny-by-default Adoption: RUN-BY:fork:nx_mesh_run — fully adopted (top of its ladder).
Pros Implementing source symbol found; runtime acceptance separate; fully adopted on the estate ladderCons behind Ray Serve (leads), Modal (leads)
●●◉◉●
Cross-host GPU worker routingMeasured: wd_route exists in runtime/nx_worker_dispatch.nx, verified at emit. Ray and K8s-native KServe route across a cluster as Best [moritz2018] [kserve-kpa]; Nishi routes image to the 5080 and video to the 3090 and other to cloud Adoption: RUN-BY:fork:nx_mesh_run — fully adopted (top of its ladder).
Pros Implementing source symbol found; runtime acceptance separate; fully adopted on the estate ladderCons behind Ray Serve (leads), Modal (leads), KServe (leads)
●●◉◉◉
Sovereign end-to-end actuationMeasured: MESHGENGATE exists in runtime/nx_mesh_gen.nx, verified at emit. All frameworks serve inference; Nishi proved a single organ POST-decode-publish loop over its own TCP with zero shell rival marks uncited — the Yes, Best or Part codes on this row are an observation read with no reference mark behind them Adoption: RUN-BY:fork:nx_mesh_run — fully adopted (top of its ladder).
Pros Implementing source symbol found; runtime acceptance separate; fully adopted on the estate ladderCons none on the measured axes (rival marks are documented presence, not depth)
●●●●●
Native GPU container governance daemonlessMeasured: nx_pe_emit_container exists in runtime/nx_pe_container_win.nx, verified at emit. Triton and Ray need a server daemon and Modal is cloud and KServe needs Kubernetes; Nishi governs the worker natively via Job Objects no daemon no VM. SYMBOL REPOINTED 2026-09-01: the row cited CreateJobObjectW, which is a WINDOWS API NAME and not a sovereign function, so the one-symbol ruler correctly refused it and the OLD substring ruler had been grounding the row against a COMMENT. THE SAME ROW APPEARS IN THREE BOARDS (containers, swarm, workermesh) AND WAS THE ENTIRE RED FOR ALL THREE -- one cause, three domains, which is why collapsing to causes before sizing a campaign matters. The defining sovereign function in that organ is nx_pe_emit_container. A ROW THAT CITES A FOREIGN OS API HAS NO SOVEREIGN DEFINITION TO GROUND AGAINST -- name the wrapper, never the syscall it wraps rival marks uncited — the Yes, Best or Part codes on this row are an observation read with no reference mark behind them Adoption: SOURCE-ONLY — PARTIAL: source exists, never compiled: /api/build it.
not adopted: source exists, never compiled: /api/build it
Pros Implementing source symbol found; runtime acceptance separate; ahead of NVIDIA Triton, Ray Serve, Modal, KServeCons not adopted yet: source exists, never compiled: /api/build it
●◐◐◐◐
Content-addressed model and artifact registryMeasured: CONTAINERREGISTRYGATE exists in runtime/nx_container_registry.nx, verified at emit. Triton model repository is the reference; Nishi has a SHA-256 content-addressed registry with integrity-verified pull rival marks uncited — the Yes, Best or Part codes on this row are an observation read with no reference mark behind them Adoption: BUILT-UNPROMOTED — PARTIAL: compiled, never promoted to the serving root: /api/promote it.
not adopted: compiled, never promoted to the serving root: /api/promote it
Pros Implementing source symbol found; runtime acceptance separateCons behind NVIDIA Triton (leads), Modal (leads), KServe (leads); not adopted yet: compiled, never promoted to the serving root: /api/promote it
●◉●◉◉
Push results to consumable storageMeasured: mg_gen exists in runtime/nx_mesh_gen.nx, verified at emit. All can write outputs; Nishi decodes the worker response and publishes to the gallery in the same sovereign organ rival marks uncited — the Yes, Best or Part codes on this row are an observation read with no reference mark behind them Adoption: RUN-BY:fork:nx_mesh_run — fully adopted (top of its ladder).
Pros Implementing source symbol found; runtime acceptance separate; fully adopted on the estate ladderCons none on the measured axes (rival marks are documented presence, not depth)
●●●●●
Model load and unloadMeasured: sd-server exists in runtime/nx_pe_container_sdserver.nx, verified at emit. Triton and Modal do dynamic model load and unload as Best; Nishi loads and unloads the worker (VRAM 0 to 10.9GB to 0) but manually not yet on demand rival marks uncited — the Yes, Best or Part codes on this row are an observation read with no reference mark behind them Adoption: SOURCE-ONLY — PARTIAL: source exists, never compiled: /api/build it.
not adopted: source exists, never compiled: /api/build it
Pros Implementing source symbol found; runtime acceptance separateCons behind NVIDIA Triton (leads), Modal (leads), KServe (leads); not adopted yet: source exists, never compiled: /api/build it
●◉●◉◉
Worker health probe and livenessMeasured: wd_probe exists in runtime/nx_worker_dispatch.nx, verified at emit. Mature frameworks have rich health and failover as Best; Nishi has a basic reachability probe rival marks uncited — the Yes, Best or Part codes on this row are an observation read with no reference mark behind them Adoption: RUN-BY:fork:nx_mesh_run — fully adopted (top of its ladder).
Pros Implementing source symbol found; runtime acceptance separate; fully adopted on the estate ladderCons behind NVIDIA Triton (leads), Ray Serve (leads), Modal (leads), KServe (leads)
●◉◉◉◉
Dynamic request batchingMeasured: MESHBATCHGATE exists in runtime/nx_mesh_batch.nx, verified at emit. Triton fuses requests into one GPU forward pass [triton-modelconfig] [crankshaw2017]; Nishi has a sovereign batch SCHEDULER (coalesce by preferred-size OR max-delay, sim 32 into 4 batches of 8) AND live n=K batched EXECUTION (proven: genbatch 3 = 3 images in ONE round-trip on the 5080); MEASURED-HONEST -- the current sd.cpp engine runs n greater than 1 SEQUENTIALLY (20.3s per image batched vs 19.3s sequential) so today the win is fewer dispatches and connections not fewer forward passes; true fused throughput needs a batching-capable backend -- Nishi now HAS the compute primitive (nx_batch_infer, a sovereign fused batched-GEMM, bit-exact vs sequential via weight-stationary reuse); the CPU reuse win is modest (compute-bound), the large win is GPU kernel-launch amortization Adoption: REGISTERED-UNAUTHORISED — PARTIAL: registered, no cap ever minted; no execution surface runs it either (clock, cron, daemon, roster, actlog and surfaced forks checked).
not adopted: registered, no cap ever minted; no execution surface runs it either (clock, cron, daemon, roster, actlog and surfaced forks checked)
Pros Implementing source symbol found; runtime acceptance separateCons behind NVIDIA Triton (leads); not adopted yet: registered, no cap ever minted; no execution surface runs it either (clock, cron, daemon, roster, actlog and surfaced forks checked)
●◉●●●
Multi-worker load balancing across replicasMeasured: MESHLBGATE exists in runtime/nx_mesh_lb.nx, verified at emit. Balancing across replicas is Best in every framework; Nishi now health-probes each replica (bounded 1s non-blocking) and round-robins among the healthy ones skipping the down -- PROVEN live routing to the laptop 5080 and skipping the offline west 3090; west or a cloud replica joins as one endpoint row rival marks uncited — the Yes, Best or Part codes on this row are an observation read with no reference mark behind them Adoption: RUN-BY:fork:nx_mesh_run — fully adopted (top of its ladder).
Pros Implementing source symbol found; runtime acceptance separate; fully adopted on the estate ladderCons behind NVIDIA Triton (leads), Ray Serve (leads), Modal (leads), KServe (leads)
●◉◉◉◉
Autoscaling scale-to-zero on demandMeasured: MESHAUTOSCALEGATE exists in runtime/nx_mesh_autoscale.nx, verified at emit. Modal and KServe scale-to-zero are Best [modal-scale] [knative-autoscaling]; Nishi has a proven policy controller AND now a HANDS-OFF host-agent (nx_mesh_hostagent) that autonomously forks the worker on demand and reaps it on idle -- PROVEN with a real process (probe 0 to 1 to 0, native fork and kill lifecycle); Nishi idle is a TRUE 0 MB 0 procs so scale-to-zero costs almost nothing Adoption: REGISTERED-UNAUTHORISED — PARTIAL: registered, no cap ever minted; no execution surface runs it either (clock, cron, daemon, roster, actlog and surfaced forks checked).
not adopted: registered, no cap ever minted; no execution surface runs it either (clock, cron, daemon, roster, actlog and surfaced forks checked)
Pros Implementing source symbol found; runtime acceptance separateCons behind Ray Serve (leads), Modal (leads), KServe (leads); not adopted yet: registered, no cap ever minted; no execution surface runs it either (clock, cron, daemon, roster, actlog and surfaced forks checked)
●●◉◉◉
Streaming responsesMeasured: MESHSTREAMGATE exists in runtime/nx_mesh_stream.nx, verified at emit. Token and chunk streaming is standard; Nishi now emits a valid Server-Sent-Events stream -- accepted then one progress event per step (step total pct) then a terminal result with the artifact URL, consumable by a browser EventSource and the same shape as our live /api/events [whatwg-sse]; the natural frame-delivery channel for video on the west 3090 Adoption: REGISTERED-DARK — PARTIAL: callable, authorised, completed MCP invocation not established by supplied journal window; lifetime history unknown (direct execution may be recorded elsewhere; this scan does not establish lifetime use); no execution surface runs it either (clock, cron, daemon, roster, actlog and surfaced forks checked).
not adopted: callable, authorised, completed MCP invocation not established by supplied journal window; lifetime history unknown (direct execution may be recorded elsewhere; this scan does not establish lifetime use); no execution surface runs it either (clock, cron, daemon, roster, actlog and surfaced forks checked)
Pros Implementing source symbol found; runtime acceptance separateCons behind Ray Serve (leads), Modal (leads); not adopted yet: callable, authorised, completed MCP invocation not established by supplied journal window; lifetime history unknown (direct execution may be recorded elsewhere; this scan does not establish lifetime use); no execution surface runs it either (clock, cron, daemon, roster, actlog and surfaced forks checked)
●●◉◉●
Request queue and admission controlMeasured: MESHBATCHGATE exists in runtime/nx_mesh_batch.nx, verified at emit. Queueing and backpressure protect the GPU under load; Nishi now has a bounded queue with admission control -- sim proved 100 requests at cap 64 admits 64 and sheds 36 with backpressure, never over-cap, and no request starves rival marks uncited — the Yes, Best or Part codes on this row are an observation read with no reference mark behind them Adoption: REGISTERED-UNAUTHORISED — PARTIAL: registered, no cap ever minted; no execution surface runs it either (clock, cron, daemon, roster, actlog and surfaced forks checked).
not adopted: registered, no cap ever minted; no execution surface runs it either (clock, cron, daemon, roster, actlog and surfaced forks checked)
Pros Implementing source symbol found; runtime acceptance separateCons behind NVIDIA Triton (leads), Ray Serve (leads), Modal (leads); not adopted yet: registered, no cap ever minted; no execution surface runs it either (clock, cron, daemon, roster, actlog and surfaced forks checked)
●◉◉◉●
Multi-model multiplexing on one GPUMeasured: MESHMUXGATE exists in runtime/nx_mesh_mux.nx, verified at emit. Serving many models on shared GPU memory is Best in the frameworks; Nishi now has a VRAM-budgeted LRU model residency -- route by model-id, keep the hot models loaded, evict the least-recently-used to fit a new one, refuse an oversized model; composes with autoscale load-unload and the content-addressed model registry rival marks uncited — the Yes, Best or Part codes on this row are an observation read with no reference mark behind them Adoption: REGISTERED-DARK — PARTIAL: callable, authorised, completed MCP invocation not established by supplied journal window; lifetime history unknown (direct execution may be recorded elsewhere; this scan does not establish lifetime use); no execution surface runs it either (clock, cron, daemon, roster, actlog and surfaced forks checked).
not adopted: callable, authorised, completed MCP invocation not established by supplied journal window; lifetime history unknown (direct execution may be recorded elsewhere; this scan does not establish lifetime use); no execution surface runs it either (clock, cron, daemon, roster, actlog and surfaced forks checked)
Pros Implementing source symbol found; runtime acceptance separateCons behind NVIDIA Triton (leads), Ray Serve (leads), Modal (leads), KServe (leads); not adopted yet: callable, authorised, completed MCP invocation not established by supplied journal window; lifetime history unknown (direct execution may be recorded elsewhere; this scan does not establish lifetime use); no execution surface runs it either (clock, cron, daemon, roster, actlog and surfaced forks checked)
●◉◉◉◉
EXCEED sovereign: own-stack no serving frameworkSource present; authored stronger claim: MESHGENGATE in runtime/nx_mesh_gen.nx, verified at emit. The whole mesh is our own TCP client plus base64 plus container governance plus dispatch -- no Triton no Ray no CUDA serving runtime no cloud dependency Adoption: RUN-BY:fork:nx_mesh_run — fully adopted (top of its ladder).
Pros Source symbol found; stronger capability claim is authored; ahead of NVIDIA Triton, Ray Serve, Modal, KServe; fully adopted on the estate ladderCons none on the measured axes (rival marks are documented presence, not depth)
◉○○○○
EXCEED unique
capability-scoped resource accessSource present; authored stronger claim: wd_authorize in runtime/nx_worker_dispatch.nx, verified at emit. A job may only call the worker and storage its capability grants -- deny-by-default MCP-style trusted-to-do-work enforcement none of the frameworks have this model [miller2006] Adoption: RUN-BY:fork:nx_mesh_run — fully adopted (top of its ladder).
Pros Source symbol found; stronger capability claim is authored; ahead of NVIDIA Triton, Ray Serve, Modal, KServe; fully adopted on the estate ladderCons none on the measured axes (rival marks are documented presence, not depth)
◉○○○○
EXCEED sovereign: zero-cost on your hardware auditableSource present; authored stronger claim: mg_gen in runtime/nx_mesh_gen.nx, verified at emit. Runs on your own GPUs at no per-call cost with the whole loop readable bits-up; the managed frameworks are cloud-metered or heavyweight infra Adoption: RUN-BY:fork:nx_mesh_run — fully adopted (top of its ladder).
Pros Source symbol found; stronger capability claim is authored; ahead of NVIDIA Triton, Ray Serve, Modal, KServe; fully adopted on the estate ladderCons none on the measured axes (rival marks are documented presence, not depth)
◉○○○○
Failover with health history and circuit breakerDARK — runtime/nx_worker_dispatch.nx EXISTS but does not declare wd_circuit: something shipped at this path under another name, and this mark would read open forever. Repoint the contract to the real entry point (the plan rung AND this row) or rename the function; the flip follows on the next beat, and the comparewatch- plane row reads DARK until then. The reachability probe exists; a breaker that opens on repeated failure and half-opens on a schedule is the mature-framework bar rival marks uncited — the Yes, Best or Part codes on this row are an observation read with no reference mark behind them
dossierwatching wd_circuit
Pros none measured yetCons behind NVIDIA Triton (leads), Ray Serve (leads), Modal (leads), KServe (leads); open contract; expected source declaration not established
○◉◉◉◉
On-demand model load and unloadDARK — runtime/nx_mesh_mux.nx EXISTS but does not declare mx_load_on_demand: something shipped at this path under another name, and this mark would read open forever. Repoint the contract to the real entry point (the plan rung AND this row) or rename the function; the flip follows on the next beat, and the comparewatch- plane row reads DARK until then. Load and unload exist manually; on-demand by request with the LRU residency already shipped closes the row rival marks uncited — the Yes, Best or Part codes on this row are an observation read with no reference mark behind them
dossierwatching mx_load_on_demand
Pros none measured yetCons behind NVIDIA Triton (leads), Ray Serve, Modal (leads), KServe (leads); open contract; expected source declaration not established
○◉●◉◉
Fused batched forward on the workerDARK — runtime/nx_mesh_batch.nx EXISTS but does not declare mb_fused_exec: something shipped at this path under another name, and this mark would read open forever. Repoint the contract to the real entry point (the plan rung AND this row) or rename the function; the flip follows on the next beat, and the comparewatch- plane row reads DARK until then. The scheduler batches and the backend runs sequentially; a batching-capable backend turns fewer dispatches into fewer forward passes rival marks uncited — the Yes, Best or Part codes on this row are an observation read with no reference mark behind them
dossierwatching mb_fused_exec
Pros none measured yetCons behind NVIDIA Triton (leads), Ray Serve, Modal, KServe; open contract; expected source declaration not established
○◉●●●
Remote replica live across hostsDARK — runtime/nx_mesh_lb.nx EXISTS but does not declare lb_remote_replica: something shipped at this path under another name, and this mark would read open forever. Repoint the contract to the real entry point (the plan rung AND this row) or rename the function; the flip follows on the next beat, and the comparewatch- plane row reads DARK until then. Round-robin over healthy replicas is proven on the LAN; a remote replica (west 3090, cloud) serving live is the cluster proof rival marks uncited — the Yes, Best or Part codes on this row are an observation read with no reference mark behind them
dossierwatching lb_remote_replica
Pros none measured yetCons behind NVIDIA Triton, Ray Serve (leads), Modal (leads), KServe (leads); open contract; expected source declaration not established
○●◉◉◉
Rival-claim provenance. Every Yes, Best or Part mark in a rival column is a claim about someone else's product. A cited row carries a reference mark that resolves to a pinned mirror (the refs gate measures that); an uncited row is an observation read and is badged in its evidence until a reference lands. The badge is the receipt, never the proof: a mark proves a mirror exists, not that the mirror supports the code. The rows are counted below.
Rival claims, counted
ClassCountNote
rows with rival marks18rows carrying a Yes, Best or Part in a rival column
cited5a reference mark resolves to a pinned mirror
uncited13an observation read, badged until a reference lands
rows, summed18RECONCILED: the parts sum to the total 18

Delivery and evidence

Inspect risks, technical debt, rendered observations, experiments and references. Read scope and limitations alongside every result.

On these two registers. Rows are declared in the domain's plan file and carry the debt id, which is the join key back to the sovereign debt plane — that plane, not this page, is the authority on state. Reconciling them automatically (the regen reading the plane and refreshing these rows) is a named, owed rung; until it lands, treat an id here as a pointer to look up, not a status to trust.
Honest verdict. The coverage above records source-symbol presence. Stronger comparisons are authored claims, not measured runtime superiority or accepted outcomes. A watch contract names an expected source symbol; finding it changes source discovery only. Qualification, deployment and runtime acceptance require their own evidence.

Person · product · place — not yet measured for this domain

Every compare carries this layer. Declare knowledge/compare/workermesh.ppp (rows surface|nishi or c1..c4|label|url|connect naming OUR live surface and each rival's front door), run nx_ppp_probe domain workermesh, and this section fills itself on the next beat: the same ruler on both sides — privacy and CX (third-party hosts, tracker classes, cookies, security headers), design and longevity (design hygiene, computed WCAG contrast, render-blocking resources, unsized media, script weight, theme and motion queries), findability (landmarks, skip link, on-site search, breadcrumb, headings, internal links).

The field — discovered, not chosen

Rows written by nx_field_discover from workermesh.seeds: the industry's own lists (Wikipedia wikitext, GitHub topics, awesome lists) read mechanically, every candidate counted across seeds. The matrix columns above are a SEAT'S pick; this band is the population they were picked from, and the stats line measures one against the other. A rival here is a lead, never a verdict — it earns a column when its capabilities are read and pinned.

Discovery receipt. One row per counter the run wrote, in the receipt's own order; the rival rows follow in their own table.
Field discovery, counted
ClassCountNote
seeds4
scanned4
fetched4
reused0
failed0
named4
candidates4
mentions4
capped0
RankRivalSeedsMentionsFirst seedKindLink
1NVIDIA Triton11col0-nvidianamedhttps://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/user_guide/model_configuration.html
2Ray Serve11col1-raynamedhttps://docs.ray.io/en/latest/serve/index.html
3Modal11col2-modalnamedhttps://modal.com/docs/guide/scale
4KServe11col3-kservenamedhttps://kserve.github.io/website/docs/model-serving/predictive-inference/autoscaling/kpa-autoscaler

field candidates 4|shown 4 of 4|matrix columns in the field 4 of 4|discovered rivals with no column 0|malformed rows 0 (counted, never rendered)|read-capped 0

Exclusive and shared capabilities

One capability is graded on one board; every other board references it. The fleet duplicate census (nx_rivalcensus dupes, on the fleetdupes clock row) reads every board's matrix and names each capability graded as a row on two or more boards, with a home derived from evidence: rung when exactly one board's plan contracts the symbol (that board is starred), gates when no plan contracts it and exactly one board's executed gate map runs the organ's gate (that board is plussed), ambiguous when several boards carry the deciding evidence (a decision for their seats), and none when no evidence decides it, with the reason beside it: unmapped (no board of the duplicate declares a gates map; declare the maps) or unproven (a map exists and runs none of the organ's gates; gate the organ on its proving board, or declare it a shared library by policy). A home elsewhere means this board should carry an @xrow reference to the home board's row rather than a graded row of its own; a home here means the other boards should. The table is this board's slice of one estate-wide census: the shape is shared, the rows are the board's.

This board grades 18 capabilities: 12 exclusive to it and 6 shared with other boards. Shared rows on this page: 6 = home here 0 + home elsewhere 1 + ambiguous 1 + undecided 4 + refused 0 (partition 6); undecided = unmapped 0 + unproven 4 + unevidenced 0; homonyms 0; since the previous census: new 0, resolved 0. Census FRESH age_s=6389.

CapabilityOrganBoards grading itHomeRuleEvidenceStanding on this board
WORKERDISPATCHGATEnx_worker_dispatch.nxswarm, workermesh—noneunprovenundecided
MESHAUTOSCALEGATEnx_mesh_autoscale.nxswarm, workermesh—noneunprovenundecided
nx_pe_emit_containernx_pe_container_win.nxswarm, workermesh, containers—noneunprovenundecided
CONTAINERREGISTRYGATEnx_container_registry.nxswarm, workermesh, containers*containersrungplanhome elsewhere
adopt: @xrow containers|CONTAINERREGISTRYGATE|home by rung (fleet duplicate census)
sd-servernx_pe_container_sdserver.nxworkermesh, containers—noneunprovenundecided
lb_remote_replicanx_mesh_lb.nxworkermesh*, engineshift*—ambiguousplanambiguous

Gaps from the record — what the estate does that no board carries

The record census (nx_goalmap record) reads the invoked-tool population and every plan queue row and files each organ or directive that NO matrix, plan or gates row names. A row here is a callout the boards missed: adjudicate it onto a board or declare it infrastructure. Census state STALE (age 1395494 s), sources read 4 of 7 declared — a BLIND census is a FLOOR: unread sources can only add rows.

kindnameboardsourceevidence

rows shown 0|this board's directives 0|estate-wide un-boarded organs 452 (listed in full on /compare/ecosystem)|census rows 639|malformed 0 (counted, never rendered)

References

Beyond a link list. Every reference below resolves twice — the publisher's copy and, where banked, the estate's own non-rottable library mirror with a content pin — and carries its evidence class plus the exact claim on this page it grounds. Keyed marks like [key] in the matrix notes jump here. A dash means honestly absent, never assumed.
  1. [triton-modelconfig] NVIDIA. Triton Inference Server -- Model Configuration (user guide): model repository layout, instance groups, dynamic_batching (preferred batch sizes, max queue delay), sequence batching and model warmup. publisher · read in our library knowledge/fetched/cmp_workermesh_triton-modelconfig.html · pin h531bec727c4e04515c0d9657db12bd5cb71532af826e22864f6e15c29ec95b2d · accessed 2026-08-18 · vendor-docGrounds: The NVIDIA Triton column: Dynamic request batching (Triton fuses requests into one GPU forward pass -- the preferred-size OR max-delay policy nx_mesh_batch mirrors), Content-addressed model and artifact registry (the model repository is the reference), Model load and unload (Best) and Multi-model multiplexing on one GPU.
  2. [ray-serve] Anyscale / Ray project. Ray Serve: Scalable and Programmable Serving (docs.ray.io/en/latest/serve): deployments, replicas, autoscaling, request batching, model composition and streaming responses on a Ray cluster. publisher · read in our library knowledge/fetched/cmp_workermesh_ray-serve.html · pin h4d68895f641dfbfb10eadc8fe24ef29c9655836f7a5b5a14e0d58dacde8331d6 · accessed 2026-08-18 · vendor-docGrounds: The Ray Serve column: Capability-scoped job dispatch and Cross-host GPU worker routing (Best at programmatic dispatch across a cluster), Multi-worker load balancing across replicas, Streaming responses and Autoscaling scale-to-zero (Best) -- the serving layer our sovereign mesh_gen loop is graded against.
  3. [moritz2018] Moritz, Nishihara, Wang, Tumanov, Liaw, Liang, Elibol, Yang, Paul, Jordan, Stoica. Ray: A Distributed Framework for Emerging AI Applications. USENIX OSDI 2018. publisher · read in our library knowledge/fetched/cmp_workermesh_moritz2018.html · pin h78f4b1e52b0a2fdb2e1853f519f36ee1b9b4dec27b0b3f6afb6423ff8941eca0 · accessed 2026-08-18 · published-paperGrounds: The distributed substrate under the Ray Serve column: the dynamic task graph, distributed scheduler and object store that make Cross-host GPU worker routing and Multi-worker load balancing across replicas Best in Ray -- the published architecture our single-organ TCP dispatch is contrasted with.
  4. [modal-scale] Modal Labs. Scaling out (modal.com/docs/guide/scale): every Function is an autoscaling pool of containers, scale to zero by default when idle, min_containers and max_containers, and concurrent inputs. publisher · read in our library knowledge/fetched/cmp_workermesh_modal-scale.html · pin hf7099caee48204296a4bceed81e37633dba524236a09c1d1a818c3f1906b2d37 · accessed 2026-08-18 · vendor-docGrounds: The Modal column: Autoscaling scale-to-zero on demand (Best -- the bar the nx_mesh_hostagent fork-on-demand reap-on-idle proof is measured against), Capability-scoped job dispatch (Best programmatic dispatch), Model load and unload and the cloud-metered contrast in EXCEED sovereign: zero-cost on your hardware auditable.
  5. [kserve-kpa] KServe Authors. Autoscaling with Knative Pod Autoscaler (kserve.github.io/website/docs/model-serving/predictive-inference/autoscaling/kpa-autoscaler): concurrency-based autoscaling of InferenceServices, scale to zero via minReplicas 0 in Knative serverless mode. publisher · read in our library knowledge/fetched/cmp_workermesh_kserve-kpa.html · pin h87aee1efb0ca25cdd3c53a55700281cd3cb3e9f657597b2f5585bed6413c63ac · accessed 2026-08-18 · vendor-docGrounds: The KServe column: Autoscaling scale-to-zero on demand (Best) and Cross-host GPU worker routing (K8s-native routing across a cluster as Best), plus the needs Kubernetes note in Native GPU container governance daemonless.
  6. [crankshaw2017] Crankshaw, Wang, Zhou, Franklin, Gonzalez, Stoica. Clipper: A Low-Latency Online Prediction Serving System. USENIX NSDI 2017. publisher · read in our library knowledge/fetched/cmp_workermesh_crankshaw2017.html · pin h13f076342574c8cc9773645ca3421a5247c599c8b777af81524d6321192e0373 · accessed 2026-08-18 · published-paperGrounds: The Dynamic request batching and Request queue and admission control rows: adaptive batching that trades queueing delay for GPU throughput under a latency objective is this paper's contribution -- the published bar for the coalesce-by-preferred-size-OR-max-delay scheduler and the bounded queue with backpressure (100 at cap 64 admits 64 sheds 36).
  7. [whatwg-sse] WHATWG. HTML Living Standard, section 9.2 Server-sent events: the EventSource interface and the text/event-stream wire format. publisher · read in our library knowledge/fetched/cmp_probe_whatwg_sse.html · pin h56e4bbeb7c54f2f55a01cdfd9cbc68ec25bb03849caa18814690b3049573761b · accessed 2026-08-18 · published-standardGrounds: The Streaming responses row: nx_mesh_stream emits a valid Server-Sent-Events stream (accepted, per-step progress, terminal result with the artifact URL) consumable by a browser EventSource -- the wire format is normative here and is the same shape as our live /api/events. Not mirrored: the sovereign fetcher could not complete the TLS 1.2 body transfer from html.spec.whatwg.org (verified live via a second reader).
  8. [miller2006] Miller, M. S. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. PhD dissertation, Johns Hopkins University, 2006 (JScholarship record; author copy at erights.org). publisher · read in our library knowledge/fetched/cmp_workermesh_miller2006-jhu.html · pin h3bb2fcee5cba1d79f76b834d676e96b8005f68f978d4713248b3103f4abbc170 · accessed 2026-08-18 · published-paperGrounds: The EXCEED unique: capability-scoped resource access row and Capability-scoped job dispatch: a job may only call the worker and storage its capability grants, deny-by-default -- the object-capability discipline this dissertation formalises, which none of the four frameworks model.
  9. [knative-autoscaling] Knative Authors. Knative Serving -- Autoscaling (knative.dev/docs/serving/autoscaling): the Knative Pod Autoscaler, concurrency and RPS targets, scale-to-zero and scale bounds. publisher · read in our library knowledge/fetched/cmp_workermesh_knative-autoscaling.html · pin h4af390da890a19b69db70d699695d1d8f30cbcbacfd951314c8bbc603344d312 · accessed 2026-08-18 · vendor-docGrounds: The Autoscaling scale-to-zero on demand row: KServe's scale-to-zero is Knative's KPA, so the Knative autoscaler is the mechanism behind the KServe Best cell -- and the class the swarm register names as KubeEdge/Knative-class scale-to-zero.

generated by nx_swcompare_matrix (sovereign NishiLang organ) from knowledge/compare/workermesh.matrix · source checks show implementation presence; runtime and user-outcome evidence are reported separately · JavaScript supports page controls