Gateway allowlist request #1397
Operator
Victor Yuritsyn — independent operator Contact: GitHub @yuritsin-code
Address
gonka1calhwf505afx0aeeuzjsraw0y3wvak06gklee2
Models
- MiniMaxAI/MiniMax-M2.7
- moonshotai/Kimi-K2.6
Use case
We run production Telegram assistant bots (property management / supplier ordering) with an async LLM cascade. Gonka currently serves our non-PII text tier via a community broker; we already operate continuous canary monitoring of network availability (30/60/120s backoff, circuit breaker with local fallback) and would like to move to direct devshard escrow to pay inference from our own GNK.
Expected volume is modest initially (thousands of requests/day ceiling), growing with our bot fleet. Happy to share our availability telemetry with the network if useful.
💬 Comments (2)
Hi @yuritsin-code. As with any devshard_escrow_params.allowed_creator_addresses change, this happens only through on-chain governance (a param-change proposal or a governance-approved upgrade batch) — filing the issue registers intent, but inclusion and timing are governance-dependent, not a maintainer toggle.
Your trace is right, and there is no hidden sticky path.
The group is not operator-selectable and there is no per-session / per-agent group_size. Slots are sampled on-chain at escrow creation (weighted-random by each participant's PoC validation weight for the model), sized to the governance parameter DevshardEscrowParams.GroupSize — currently 16. The creator can't pin members or force group_size=1. The group is a verification/redundancy set, not a cache-affinity router. For each nonce exactly one slot executes (nonce % group); the others are verifiers that validate the result. Rotating the executor is intentional, so consecutive-turn KV/prefix-cache affinity is not a design goal today. The routing is determined entirely by the on-chain group + nonce, not by the gateway. So it is identical whether you stay on a community broker, use OpenBroker, or run your own devshard gateway — self-hosting will not buy you KV-cache affinity.
Given you're already in production and the goal is GNK-native, no-markup, self-paid inference, the option that works today without the governance wait is OpenBroker (https://openbroker.gonka.gg/, discussion #1363): it deducts your balance 1-to-1 with actual escrow cost (no markup, no enrollment/approval), and serves the network models.
🔄 Auto-synced from Issue #1397 every hour.
Hi Gonka team,
We've been analyzing the devshard protocol to understand how multi-turn agent workloads perform on the network, and we have two questions based on our code review.
1. Executor affinity for consecutive nonces
We traced the routing logic in the open-source code:
devshard/user/session.go:592:hostIdx := int(nonce % uint64(len(s.group)))devshard/host/host.go:743:executorSlot := h.group[start.InferenceId%uint64(len(h.group))].SlotIDdevshard/user/session.go:724:InferenceId: nonceThis means each nonce is routed to
nonce % len(group), and since InferenceId == nonce, the target host IS the executor. Consecutive nonces are distributed round-robin across the group.Question: For multi-turn agent conversations where each turn is a new nonce, does the round-robin rotation mean that turns go to different executors (breaking KV-cache affinity), or is there a mechanism (group_size=1 for agent sessions, sticky routing, or a different code path) that keeps a conversation on the same executor?
2. vLLM prefix caching status
We reviewed the reference
node-config.jsonfiles indeploy/join/and the participant quickstart docs. None include--enable-prefix-caching. Since vLLM 0.6.0+ requires this flag explicitly (it was default before), we cannot determine if prefix caching is active on Gonka nodes.Question: Is vLLM Automatic Prefix Caching enabled on Gonka inference nodes? What vLLM version does MLNode use?
Thanks for your time — this helps us understand the right strategy for deploying agent workloads on Gonka.