Gateway allowlist request: Knyazev AI high-throughput agent infrastructure #1479
Operator
- Name: Nikita Knyazev
- GitHub: @knyazev741
- Project: Knyazev AI / self-hosted agent infrastructure
- Contact: via this GitHub issue
Requested creator address
Public key:
Please consider adding this address to devshard_escrow_params.allowed_creator_addresses.
The key is dedicated exclusively to devshard escrow creation. In accordance with the current self-hosted gateway guide, the creator will be funded only after allowlist membership is confirmed.
Models
MiniMaxAI/MiniMax-M2.7— primarymoonshotai/Kimi-K2.6— secondary / evaluation
Use case
We operate a private AI-agent and automation infrastructure with parallel worker pipelines. The immediate workload includes agent orchestration, code and log analysis, structured extraction, evaluation workloads, and high-volume background processing.
Our target operating range is 100–200 concurrent inference requests. A community broker is useful for initial compatibility testing, but it does not meet our requirements because:
- broker-side concurrency limits are below our target;
- we require direct GNK settlement and self-custody;
- we need control over escrow pooling, rotation, settlement, retry policy, and capacity-aware routing;
- we do not want an intermediary in the request path for internal workloads.
This request is for a private self-hosted gateway, not a public broker-directory listing and not resale of raw inference.
Initial deployment plan
- Gateway-only deployment on an existing private Linux server
- Official
libermans/gonka-devshard-proxycontainer - API bound to localhost/private infrastructure only
GATEWAY_MAX_CONCURRENT_REQUESTS=512- Multiple devshards pooled for throughput and epoch rotation
- Capacity-aware limits enabled
- Circuit breaker, bounded retries with jitter, and fallback for unavailable network capacity
- Secrets stored with restricted filesystem permissions; the creator key is dedicated and not reused
Validation and contribution plan
After approval we will stage traffic gradually:
- One manually managed escrow and deterministic functional checks.
- Concurrency ramp: 1 / 3 / 10 / 25 / 50 / 100 / 200.
- Measure success rate, HTTP error distribution, TTFT, p50/p95/p99 latency, output throughput, and settlement/refund behavior.
- Enable multiple-escrow pooling and controlled rotation only after the single-escrow path is verified.
- Share anonymized benchmark and reliability results with the Gonka community if useful.
Initial broker-based testing already showed why direct capacity testing matters: MiniMax handled sequential requests reliably during one sample, while a 10-concurrent sample produced substantial upstream 502 variance. We want to test the native devshard/operator path and contribute actionable capacity data rather than hide network behavior behind broker-specific limits.
Governance and operations commitments
- We understand that allowlist inclusion is an on-chain governance decision and is not guaranteed.
- We will respond to maintainer and community questions promptly.
- We will not fund or attempt to open escrows until the address is confirmed on the allowlist.
- We will start with private/internal traffic and staged load, not an immediate public endpoint.
- We will publish operational findings and adjust limits if governance or network operators request it.
Thank you for considering the request.
💬 Comments (3)
Community discussion is now open in Gonka #dev-chat:
https://discord.com/channels/1336477374442770503/1336787104935579668/1528292662245855403
We have asked active hosts what evidence or operational commitments they would want before supporting inclusion in the next governance-approved creator allowlist batch. We will keep this issue updated with any requested details. The dedicated creator address remains unfunded, and the gateway will not be deployed until on-chain allowlist membership is confirmed.
Hi @knyazev741, thanks for opening issue and for already opening the discussion in #dev-chat. That's exactly the right move, and it answers your own question about the process better than I could: there's no maintainer-controlled queue here — Gonka is decentralized, so an address gets added to devshard_escrow_params.allowed_creator_addresses only through on-chain governance (a standalone param-change proposal or inclusion in a governance-approved upgrade batch). Building visible support with active hosts/operators in the community before a proposal is assembled is the strongest thing you can do while you wait.
OpenBroker https://github.com/gonka-ai/gonka/discussions/1363 would address the throughput concern — it's GNK-native, no markup, and has been load-tested well past your 100–200 concurrent range — but it's custodial by design (you deposit GNK to an operator-controlled address and run under their API key), and it abstracts the escrow/settlement path away from you. Since your stated requirements are self-custodied GNK settlement, direct control of escrow pooling/rotation/retry, and no intermediary in the request path — plus the explicit goal of measuring the native devshard/operator path rather than broker-specific behavior — a broker doesn't substitute for the creator path here. So the allowlist request is the correct path, not something to redirect.
Keep this issue updated with anything the hosts ask for in #dev-chat, thanks
🔄 Auto-synced from Issue #1479 every hour.
Hi @tcharchian — could you please point us to the preferred path for getting this address considered in the next governance-approved allowlist batch, and to the community channel where support should be discussed before a proposal?
To clarify the operator-specific need: this is not a request for a broker-directory listing. We need the creator path itself for self-custodied GNK settlement, control of escrow pooling/rotation, and a private workload targeting 100–200 concurrent requests. We will stage the load and publish anonymized capacity/reliability measurements back to the community.
The dedicated address remains unfunded, following the current gateway guide's instruction not to fund or deploy until allowlist membership is confirmed. We are ready to provide any additional operator details or revise the scope for governance review.