OpenGNK — локальный OpenAI-совместимый прокси для Gonka
Оригинал: OpenGNK - A Local OpenAI-Compatible Proxy for Gonka
Когда мы создавали и тестировали proxy.gonka.gg (https://proxy.gonka.gg) — нашу конечную точку облачного API для вывода Gonka — мы заметили в сообществе закономерность: разработчики также хотели подписывать запросы на вывод и передавать их в сеть из локальной среды, хранить свои закрытые ключи на своих машинах и подключать Gonka напрямую к существующим инструментам без какого-либо посредника (облачного прокси). Они просили предоставить самостоятельную версию того, что мы создали для себя.
Встречайте opengnk — легкий прокси-сервер на базе Docker, который представляет децентрализованную сеть искусственного интеллекта Gonka как полностью стандартный OpenAI-совместимый API, работающий полностью на вашей собственной машине.
На данный момент статистика такова:
2к просмотров за месяц 258 установок
2к просмотров за месяц
258 установок
Почему это существует
Как мы все знаем, сеть Gonka — это децентрализованная сеть вывода. Узлы используют оборудование графического процессора, принимают подписанные запросы на вывод и возвращают завершения. Каждое приложение в мире, использующее ИИ — от агентов LangChain до Cursor и ваших собственных скриптов Python — использует протокол OpenAI. Разрыв между «у меня есть учетная запись Gonka» и «я могу использовать Gonka в своем приложении» был настоящим трением (особенно с белыми списками TransferAgent — потенциальная необходимость в нескольких узлах для отправки запросов и т. д.). Мы просто увидели много вопросов о том, как использовать вывод, и попытались решить возникшую «проблему». Кроме того, у нас есть сборщик (gonka.gg/faucet), который позволяет пользователям бесплатно проверять логические выводы из локальной среды.
opengnk полностью устраняет пробел. Вы указываете любому OpenAI-совместимому клиенту http://localhost:8080/v1, и он просто работает. Никаких изменений SDK. Нет специального кода интеграции. Никакой привязки к поставщику.
Что он делает
OpenAI-совместимый REST API
Прокси предоставляет /v1/models и /v1/chat/completions — как потоковые, так и непоточные — с точно такими же формами запросов и ответов, что и API OpenAI. Любая библиотека или инструмент, поддерживающий пользовательский base_url, работает «из коробки».
из импорта openai OpenAI client = OpenAI (base_url = "http://localhost:8080/v1", api_key = "not-needed",) response = client. чат . доработки. create (model = "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8", messages = [{ "role": "user", "content": "Hello!" }], )
Вот и вся интеграция. Тот же фрагмент работает с TypeScript, Curl, LangChain, LlamaIndex или чем-либо еще, поддерживающим OpenAI.
Прозрачное подписание запроса
Каждый запрос к узлу Gonka должен быть подписан вашим закрытым ключом secp256k1. opengnk обрабатывает это полностью в фоновом режиме — ваши ключи остаются на вашем компьютере, и каждый восходящий запрос подписывается с помощью ECDSA, прежде чем он покинет прокси. Вы никогда не трогаете логику подписи самостоятельно.
Автоматическое обнаружение конечных точек
Сеть Gonka имеет множество узлов-участников. opengnk автоматически извлекает список активных участников с узла генезиса, фильтрует его до исправных узлов агента передачи, внесенных в белый список, и направляет туда ваши запросы. Если узел неработоспособен или отклоняет запрос, его обрабатывает прокси-сервер. Вы никогда не выбираете узлы вручную.
Круговой алгоритм с несколькими кошельками
Один кошелек может подпадать под ограничения по ставкам. OpenGNK поддерживает несколько кошельков, настроенных в виде списка, разделенного запятыми, и автоматически выполняет циклические запросы к ним. Это умножит вашу эффективную пропускную способность пропорционально количеству кошельков:
GONKA_WALLETS = privkey1:gonka1addr1,privkey2:gonka1addr2,privkey3:gonka1addr3
Каждый запрос переходит к следующему кошельку. Прокси-сервер записывает, какой кошелек использовался, чтобы вы могли проверить распространение.
Встроенный пользовательский интерфейс веб-чата
Полный интерфейс чата доступен по адресу http://localhost:8080 – отдельная установка не требуется. Это полезно для тестирования, изучения моделей и демонстрации прокси другим. Он также показывает панель различий для очистки конфиденциальности (подробнее об этом ниже).
Вызов инструмента/функции
Вызов инструментов — одна из наиболее важных функций для рабочих процессов агентного ИИ, и узлы Gonka имели для нее различные уровни встроенной поддержки (до недавнего обновления). opengnk обрабатывает оба случая - когда поддерживается собственный TC, а когда нет.
Собственный режим (для узлов, развернутых с помощью --enable-auto-tool-choice или аналогичного) .env opengnk должен быть:
NATIVE_TOOL_CALLS = правда
Прокси пересылает ваши инструменты и поляtool_calls без изменений и автоматически выравнивает содержимое массива в стиле OpenAI ([{"type":"text","text":"..."}]) в простые строки, которые требуются узлам Gonka. Все типы сообщений нормализуются, включая сообщения role: «tool», поэтому восходящий поток никогда не получает смешанный формат контента.
Режим моделирования (резервный вариант для узлов без встроенной поддержки) можно включить с помощью конфигурации .env:
SIMULATE_TOOL_CALLS = правда
Это более интересный вариант. Если узел не поддерживает вызов собственных инструментов, прокси-сервер:
Удаляет поля Tools и Tool_choice из запроса (который восходящий поток отклонит)
- Вводит системное приглашение, описывающее доступные инструменты и инструктирующее модель ответить структурированным JSON.
- Анализирует выходные данные модели в формате JSON.
- Преобразует его обратно в стандартный формат ответа OpenAItool_calls — Finish_reason: "tool_calls", content: null, структурированный массивtool_calls.
Ваше приложение видит совершенно стандартный ответ OpenAI и обрабатывает двусторонний вызов инструмента как обычно. Полный цикл — вопрос → вызов инструмента → результат инструмента → окончательный ответ — работает точно так же, как и в OpenAI, в обоих режимах.
Дезинфекция конфиденциальности
Сообщество запросило в TG Chats
Это особенность, которой мы гордимся с технической точки зрения.
Прокси-сервер может автоматически удалять конфиденциальные данные из ваших сообщений, прежде чем они покинут ваш компьютер, и восстанавливать исходные значения в ответе. Восходящий LLM полностью работает с токенами-заполнителями — он никогда не видит ваши реальные данные.
Что редактируется:
Ключи и токены API (sk-, pk-, ghp_, Bearer и т. д.)
Адреса электронной почты и номера телефонов
Полные имена людей (английские и русские)
Номера кредитных карт и IBAN
Приватные ключи и учетные данные любого формата
Как это работает:
Ваше сообщение поступает на прокси
- Классификаторы сканируют текст и заменяют конфиденциальные значения стабильными заполнителями («TOKEN_000001», «TOKEN_000002», ...)
- Один и тот же токен используется повторно, если одно и то же значение появляется несколько раз, поэтому LLM может последовательно рассуждать об этом, даже не зная, что это такое.
- Отредактированное сообщение пересылается на вышестоящий узел.
- Когда ответ возвращается, заполнители заменяются обратно на исходные, прежде чем ваше приложение их увидит.
Веб-интерфейс показывает разницу между тем, что вы набрали, и тем, что было отправлено, с выделенными конфиденциальными значениями.
Два слоя классификатора работают параллельно:
Sidecar NER — это микросервис Python, использующий две модели NER: Natasha для русского языка (кириллические имена, организации, местоположения) и spaCy en_core_web_sm для английского языка. Он предоставляет конечную точку /classify и выполняется менее чем за 100 мс на процессоре.
Классификатор LLM — это локальная модель, работающая внутри Ollama — по умолчанию qwen3:4b-instruct-2507-q4_K_M (~2,6 ГБ, 4-битное квантование). Он обрабатывает вещи, которые NER не может надежно обнаружить: ключи API, пароли, токены и учетные данные произвольного формата. Цепочка мыслей подавляется с помощью управляющего токена /no_think, поэтому модель возвращает только массив конфиденциальных строк JSON. Типичная задержка составляет 5–20 секунд на процессоре.
Оба классификатора работают одновременно с общим 120-секундным бюджетом. Если какой-либо из них выполняется медленно или недоступен, он пропускается, а остальные результаты по-прежнему применяются. Прокси никогда не блокируется на неопределенный срок.
Проверка диапазона гарантирует отсутствие частичных совпадений: обнаруженный диапазон применяется только в том случае, если символы, непосредственно окружающие его, являются разделителями слов. Это предотвращает ложные срабатывания, такие как сопоставление sd@example.com внутри asd@example.com.
Запуск санации осуществляется одной командой:
docker compose --profile санировать вверх -d
Если задержка важнее покрытия, вы можете отключить уровень LLM и полагаться только на NER, который по-прежнему распознает имена, организации и местоположения с задержкой менее 100 мс.
Начало работы в 3 шага
№ 1. Клонировать git clone https://github.com/gonkalabs/opengnk.git cd opengnk # 2. Настройте cp .env.example .env # Добавьте GONKA_PRIVATE_KEY и GONKA_ADDRESS # 3. Беги, беги
Прокси-сервер подключен по адресу http://localhost:8080. Нулевая зависимость от хоста — все работает в Docker, локальная установка Go не требуется.
Под капотом
Проект написан на Go и структурирован вокруг нескольких специализированных внутренних пакетов:
внутренний/подписывающий — ECDSA secp256k1 подписывает восходящие запросы
внутренний/восходящий — HTTP-клиент, обнаружение конечных точек, фильтрация белого списка агента передачи
внутренний/кошелек — пул с несколькими кошельками с циклической маршрутизацией
Internal/toolsim — симуляция вызова инструмента (быстрое внедрение + анализ JSON)
внутреннее/очистка — ядро редактирования и восстановления, интерфейс классификатора, клиент NER, классификатор LLM
- Internal/api — обработчики HTTP для всех конечных точек.
Internal/config — загрузка переменной среды
Вся кодовая база имеет открытый исходный код под лицензией MIT. Мы верим в открытый исходный код — ту же философию, которая лежит в основе всего, что мы создаем в Gonka Labs. Любой может проверить его, запустить локально, разветвить или внести свой вклад.
Подключение к proxy.gonka.gg
opengnk — это локальная версия proxy.gonka.gg (https://proxy.gonka.gg), нашего облачного API для вывода Gonka. Если вам нужна управляемая конечная точка без настройки, вам подойдет proxy.gonka.gg. Если вам нужен полный контроль — ваши ключи на вашем компьютере, ваши собственные ограничения скорости, ваши собственные гарантии конфиденциальности — opengnk — это ответ.
Оба используют один и тот же протокол, совместимый с OpenAI. Переключение между ними осуществляется одним изменением base_url.
Что дальше
opengnk уже используется разработчиками, работающими на Gonka, подключая его к агентам (OpenClaw и т. д.), Cursor, локальным скриптам и пользовательским приложениям. Мы продолжим вносить изменения в зависимости от потребностей сообщества.
Если вам нужна какая-то функция — дополнительная поддержка конечных точек, новые классификаторы очистки, улучшенная многомодельная маршрутизация или что-то еще — откройте проблему или сообщите нам в чате Telegram. Мы отправляем быстро.
GitHub: github.com/gonkalabs/opengnk (https://github.com/gonkalabs/opengnk) Gonka Labs: gonkalabs.com (https://gonkalabs.com) | гонка.гг (https://gonka.gg)
When we were building and testing proxy.gonka.gg (https://proxy.gonka.gg) - our cloud API endpoint for Gonka inference - we noticed a pattern in the community: developers also wanted to sign inference request and transmit them to the Network from local environment, keep their private keys on their own machines, and plug Gonka directly into their existing tooling without any intermediary (cloud proxy). They were asking for a self-hosted version of what we had built for ourselves.
Meet opengnk - a lightweight, Docker-based proxy that exposes the Gonka decentralised AI network as a fully standard OpenAI-compatible API , running entirely on your own machine.
Currently, statistics are:
2k views in a month 258 installs
2k views in a month
258 installs
Why this exists
As we all know, the Gonka network is a decentralised inference network. Nodes run GPU hardware, accept signed inference requests, and return completions. Every application in the world that does AI - from LangChain agents to Cursor to your own Python scripts - speaks the OpenAI protocol. The gap between "I have a Gonka account" and "I can use Gonka in my app" was real friction (especially with TransferAgent whitelists - potential need for multiple nodes to send requests to, etc). We just saw a lot of questions about how to use inference, and tried to solve the arising "problem". Also, we have a faucet (gonka.gg/faucet) thus enabling users to test inference from local environment for free.
opengnk eliminates gap entirely. You point any OpenAI-compatible client at http://localhost:8080/v1 and it just works. No SDK changes. No custom integration code. No vendor lock-in.
What it does
OpenAI-compatible REST API
The proxy exposes /v1/models and /v1/chat/completions - both streaming and non-streaming - with the exact same request and response shapes as the OpenAI API. Any library or tool that supports a custom base_url works out of the box.
from openai import OpenAI client = OpenAI ( base_url = "http://localhost:8080/v1" , api_key = "not-needed" , ) response = client . chat . completions . create ( model = "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8" , messages = [{ "role" : "user" , "content" : "Hello!" }], )
That is the entire integration. The same snippet works with TypeScript, curl, LangChain, LlamaIndex, or anything else that speaks OpenAI.
Transparent request signing
Every request to a Gonka node must be signed with your secp256k1 private key. opengnk handles this entirely in the background - your keys stay on your machine, and every upstream request is signed with ECDSA before it leaves the proxy. You never touch the signing logic yourself.
Automatic endpoint discovery
The Gonka network has many participant nodes. opengnk automatically fetches the active participant list from a genesis node, filters it to healthy, whitelisted Transfer Agent nodes, and routes your requests there. If a node is unhealthy or rejects the request, the proxy handles it. You never pick nodes manually.
Multi-wallet round-robin
A single wallet may fall under rate limits. OpenGNK supports multiple wallets configured as a comma-separated list, and round-robins requests across them automatically. This multiplies your effective throughput proportionally to the number of wallets:
GONKA_WALLETS = privkey1:gonka1addr1,privkey2:gonka1addr2,privkey3:gonka1addr3
Each request cycles to the next wallet. The proxy logs which wallet was used so you can verify the distribution.
Built-in web chat UI
There is a full chat interface at http://localhost:8080 - no separate installation needed. It is useful for testing, exploring models, and demonstrating the proxy to others. It also shows the privacy sanitization diff panel (more on that below).
Tool / function calling
Tool calling is one of the most important features for agentic AI workflows, and Gonka nodes had varying levels of native support for it (prior to recent update). opengnk handles both cases - when native TC is supported and when not.
Native mode (for nodes deployed with --enable-auto-tool-choice or similar) .env of the opengnk shall be:
NATIVE_TOOL_CALLS = true
The proxy forwards your tools and tool_calls fields unchanged, and automatically flattens OpenAI-style array content ( [{"type":"text","text":"..."}] ) to plain strings that Gonka nodes require. All message types are normalized - including role: "tool" messages - so the upstream never receives a mixed content format.
Simulation mode (fallback for nodes without native support) can be turned on with .env config:
SIMULATE_TOOL_CALLS = true
This is the more interesting one. When a node does not support native tool calling, the proxy:
Strips the tools and tool_choice fields from the request (which the upstream would reject)
Injects a system prompt that describes the available tools and instructs the model to respond with structured JSON
Parses the model's JSON output
- Converts it back into the standard OpenAI tool_calls response format - finish_reason: "tool_calls" , content: null , structured tool_calls array
Your application sees a perfectly standard OpenAI response and handles the tool-call round-trip as usual. The full cycle - ask → tool call → tool result → final answer - works exactly as it does with OpenAI, in both modes.
Privacy sanitization
Community requested in TG Chats
This is the feature we are proud of from a technical standpoint.
The proxy can automatically strip sensitive data from your messages before they leave your machine, and restore the original values in the response. The upstream LLM operates entirely on placeholder tokens - it never sees your real data.
What gets redacted:
API keys and tokens ( sk- , pk- , ghp_ , Bearer , etc.)
Email addresses and phone numbers
Full person names (English and Russian)
Credit card numbers and IBANs
Private keys and credentials of any format
How it works:
Your message arrives at the proxy
- Classifiers scan the text and replace sensitive values with stable placeholders ( «TOKEN_000001» , «TOKEN_000002» , ...)
- The same token is reused if the same value appears multiple times - so the LLM can reason consistently about it without ever knowing what it is
The redacted message is forwarded to the upstream node
When the response comes back, placeholders are swapped back to the originals before your app sees them
The web UI shows a side-by-side diff of what you typed versus what was sent, with sensitive values highlighted.
Two classifier layers run in parallel:
The NER sidecar is a Python microservice running two NER models: Natasha for Russian (Cyrillic names, organisations, locations) and spaCy en_core_web_sm for English. It exposes a /classify endpoint and runs in under 100ms on CPU.
The LLM classifier is a local model running inside Ollama - by default qwen3:4b-instruct-2507-q4_K_M (~2.6 GB, 4-bit quantized). It handles things NER cannot reliably detect: API keys, passwords, tokens, and credentials of arbitrary format. Chain-of-thought thinking is suppressed via the /no_think control token so the model returns only the JSON array of sensitive strings. Typical latency is 5–20 seconds on CPU.
Both classifiers run concurrently under a shared 120-second budget. If either is slow or unavailable, it is skipped and the remaining results still apply. The proxy never blocks indefinitely.
Span validation ensures no partial matches: a detected span is only applied if the characters immediately surrounding it are word delimiters. This prevents false positives like matching sd@example.com inside asd@example.com .
Starting sanitization is a single command:
docker compose --profile sanitize up -d
If latency matters more than coverage, you can disable the LLM layer and rely only on NER - which still catches names, organisations, and locations with sub-100ms latency.
Getting started in 3 steps
# 1. Clone git clone https://github.com/gonkalabs/opengnk.git cd opengnk # 2. Configure cp .env.example .env # Add your GONKA_PRIVATE_KEY and GONKA_ADDRESS # 3. Run make run
The proxy is up at http://localhost:8080 . Zero host dependencies - everything runs in Docker, no local Go installation needed.
Under the hood
The project is written in Go and structured around a few focused internal packages:
internal/signer - ECDSA secp256k1 signing of upstream requests
internal/upstream - HTTP client, endpoint discovery, Transfer Agent whitelist filtering
internal/wallet - multi-wallet pool with round-robin routing
internal/toolsim - tool-call simulation (prompt injection + JSON parsing)
internal/sanitize - redaction and restoration core, classifier interface, NER client, LLM classifier
internal/api - HTTP handlers for all endpoints
internal/config - environment variable loading
The entire codebase is open source under the MIT license. We believe in open source - the same philosophy that drives everything we build at Gonka Labs. Anyone can inspect it, run it locally, fork it, or contribute.
Connection to proxy.gonka.gg
opengnk is the self-hosted version of proxy.gonka.gg (https://proxy.gonka.gg) , our cloud API for Gonka inference. If you want a managed endpoint with no setup, proxy.gonka.gg is there. If you want full control - your keys on your machine, your own rate limits, your own privacy guarantees - opengnk is the answer.
Both speak the same OpenAI-compatible protocol. Switching between them is a single base_url change.
What's next
opengnk is already being used by developers building on Gonka - plugging it into agents (OpenClaw, etc), Cursor, local scripts, and custom applications. We will keep iterating based on what the community needs.
If there is a feature you want - additional endpoint support, new sanitization classifiers, better multi-model routing, anything - open an issue or tell us in the Telegram chat. We ship fast.
GitHub: github.com/gonkalabs/opengnk (https://github.com/gonkalabs/opengnk) Gonka Labs: gonkalabs.com (https://gonkalabs.com) | gonka.gg (https://gonka.gg)
Когда мы создавали и тестировали proxy.gonka.gg (https://proxy.gonka.gg) — нашу конечную точку облачного API для вывода Gonka — мы заметили в сообществе закономерность: разработчики также хотели подписывать запросы на вывод и передавать их в сеть из локальной среды, хранить свои закрытые ключи на своих машинах и подключать Gonka напрямую к существующим инструментам без какого-либо посредника (облачного прокси). Они просили предоставить самостоятельную версию того, что мы создали для себя.
Встречайте opengnk — легкий прокси-сервер на базе Docker, который представляет децентрализованную сеть искусственного интеллекта Gonka как полностью стандартный OpenAI-совместимый API, работающий полностью на вашей собственной машине.
На данный момент статистика такова:
2к просмотров за месяц 258 установок
2к просмотров за месяц
258 установок
Почему это существует
Как мы все знаем, сеть Gonka — это децентрализованная сеть вывода. Узлы используют оборудование графического процессора, принимают подписанные запросы на вывод и возвращают завершения. Каждое приложение в мире, использующее ИИ — от агентов LangChain до Cursor и ваших собственных скриптов Python — использует протокол OpenAI. Разрыв между «у меня есть учетная запись Gonka» и «я могу использовать Gonka в своем приложении» был настоящим трением (особенно с белыми списками TransferAgent — потенциальная необходимость в нескольких узлах для отправки запросов и т. д.). Мы просто увидели много вопросов о том, как использовать вывод, и попытались решить возникшую «проблему». Кроме того, у нас есть сборщик (gonka.gg/faucet), который позволяет пользователям бесплатно проверять логические выводы из локальной среды.
opengnk полностью устраняет пробел. Вы указываете любому OpenAI-совместимому клиенту http://localhost:8080/v1, и он просто работает. Никаких изменений SDK. Нет специального кода интеграции. Никакой привязки к поставщику.
Что он делает
OpenAI-совместимый REST API
Прокси предоставляет /v1/models и /v1/chat/completions — как потоковые, так и непоточные — с точно такими же формами запросов и ответов, что и API OpenAI. Любая библиотека или инструмент, поддерживающий пользовательский base_url, работает «из коробки».
из импорта openai OpenAI client = OpenAI (base_url = "http://localhost:8080/v1", api_key = "not-needed",) response = client. чат . доработки. create (model = "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8", messages = [{ "role": "user", "content": "Hello!" }], )Вот и вся интеграция. Тот же фрагмент работает с TypeScript, Curl, LangChain, LlamaIndex или чем-либо еще, поддерживающим OpenAI.
Прозрачное подписание запроса
Каждый запрос к узлу Gonka должен быть подписан вашим закрытым ключом secp256k1. opengnk обрабатывает это полностью в фоновом режиме — ваши ключи остаются на вашем компьютере, и каждый восходящий запрос подписывается с помощью ECDSA, прежде чем он покинет прокси. Вы никогда не трогаете логику подписи самостоятельно.
Автоматическое обнаружение конечных точек
Сеть Gonka имеет множество узлов-участников. opengnk автоматически извлекает список активных участников с узла генезиса, фильтрует его до исправных узлов агента передачи, внесенных в белый список, и направляет туда ваши запросы. Если узел неработоспособен или отклоняет запрос, его обрабатывает прокси-сервер. Вы никогда не выбираете узлы вручную.
Круговой алгоритм с несколькими кошельками
Один кошелек может подпадать под ограничения по ставкам. OpenGNK поддерживает несколько кошельков, настроенных в виде списка, разделенного запятыми, и автоматически выполняет циклические запросы к ним. Это умножит вашу эффективную пропускную способность пропорционально количеству кошельков:
GONKA_WALLETS = privkey1:gonka1addr1,privkey2:gonka1addr2,privkey3:gonka1addr3
Каждый запрос переходит к следующему кошельку. Прокси-сервер записывает, какой кошелек использовался, чтобы вы могли проверить распространение.
Встроенный пользовательский интерфейс веб-чата
Полный интерфейс чата доступен по адресу http://localhost:8080 – отдельная установка не требуется. Это полезно для тестирования, изучения моделей и демонстрации прокси другим. Он также показывает панель различий для очистки конфиденциальности (подробнее об этом ниже).
Вызов инструмента/функции
Вызов инструментов — одна из наиболее важных функций для рабочих процессов агентного ИИ, и узлы Gonka имели для нее различные уровни встроенной поддержки (до недавнего обновления). opengnk обрабатывает оба случая - когда поддерживается собственный TC, а когда нет.
Собственный режим (для узлов, развернутых с помощью --enable-auto-tool-choice или аналогичного) .env opengnk должен быть:
NATIVE_TOOL_CALLS = правда
Прокси пересылает ваши инструменты и поляtool_calls без изменений и автоматически выравнивает содержимое массива в стиле OpenAI ([{"type":"text","text":"..."}]) в простые строки, которые требуются узлам Gonka. Все типы сообщений нормализуются, включая сообщения role: «tool», поэтому восходящий поток никогда не получает смешанный формат контента.
Режим моделирования (резервный вариант для узлов без встроенной поддержки) можно включить с помощью конфигурации .env:
SIMULATE_TOOL_CALLS = правда
Это более интересный вариант. Если узел не поддерживает вызов собственных инструментов, прокси-сервер:
Удаляет поля Tools и Tool_choice из запроса (который восходящий поток отклонит)
Ваше приложение видит совершенно стандартный ответ OpenAI и обрабатывает двусторонний вызов инструмента как обычно. Полный цикл — вопрос → вызов инструмента → результат инструмента → окончательный ответ — работает точно так же, как и в OpenAI, в обоих режимах.
Дезинфекция конфиденциальности
Сообщество запросило в TG Chats
Это особенность, которой мы гордимся с технической точки зрения.
Прокси-сервер может автоматически удалять конфиденциальные данные из ваших сообщений, прежде чем они покинут ваш компьютер, и восстанавливать исходные значения в ответе. Восходящий LLM полностью работает с токенами-заполнителями — он никогда не видит ваши реальные данные.
Что редактируется:
Ключи и токены API (sk-, pk-, ghp_, Bearer и т. д.)
Адреса электронной почты и номера телефонов
Полные имена людей (английские и русские)
Номера кредитных карт и IBAN
Приватные ключи и учетные данные любого формата
Как это работает:
Ваше сообщение поступает на прокси
Веб-интерфейс показывает разницу между тем, что вы набрали, и тем, что было отправлено, с выделенными конфиденциальными значениями.
Два слоя классификатора работают параллельно:
Sidecar NER — это микросервис Python, использующий две модели NER: Natasha для русского языка (кириллические имена, организации, местоположения) и spaCy en_core_web_sm для английского языка. Он предоставляет конечную точку /classify и выполняется менее чем за 100 мс на процессоре.
Классификатор LLM — это локальная модель, работающая внутри Ollama — по умолчанию qwen3:4b-instruct-2507-q4_K_M (~2,6 ГБ, 4-битное квантование). Он обрабатывает вещи, которые NER не может надежно обнаружить: ключи API, пароли, токены и учетные данные произвольного формата. Цепочка мыслей подавляется с помощью управляющего токена /no_think, поэтому модель возвращает только массив конфиденциальных строк JSON. Типичная задержка составляет 5–20 секунд на процессоре.
Оба классификатора работают одновременно с общим 120-секундным бюджетом. Если какой-либо из них выполняется медленно или недоступен, он пропускается, а остальные результаты по-прежнему применяются. Прокси никогда не блокируется на неопределенный срок.
Проверка диапазона гарантирует отсутствие частичных совпадений: обнаруженный диапазон применяется только в том случае, если символы, непосредственно окружающие его, являются разделителями слов. Это предотвращает ложные срабатывания, такие как сопоставление sd@example.com внутри asd@example.com.
Запуск санации осуществляется одной командой:
docker compose --profile санировать вверх -d
Если задержка важнее покрытия, вы можете отключить уровень LLM и полагаться только на NER, который по-прежнему распознает имена, организации и местоположения с задержкой менее 100 мс.
Начало работы в 3 шага
Прокси-сервер подключен по адресу http://localhost:8080. Нулевая зависимость от хоста — все работает в Docker, локальная установка Go не требуется.
Под капотом
Проект написан на Go и структурирован вокруг нескольких специализированных внутренних пакетов:
внутренний/подписывающий — ECDSA secp256k1 подписывает восходящие запросы
внутренний/восходящий — HTTP-клиент, обнаружение конечных точек, фильтрация белого списка агента передачи
внутренний/кошелек — пул с несколькими кошельками с циклической маршрутизацией
Internal/toolsim — симуляция вызова инструмента (быстрое внедрение + анализ JSON)
внутреннее/очистка — ядро редактирования и восстановления, интерфейс классификатора, клиент NER, классификатор LLM
Internal/config — загрузка переменной среды
Вся кодовая база имеет открытый исходный код под лицензией MIT. Мы верим в открытый исходный код — ту же философию, которая лежит в основе всего, что мы создаем в Gonka Labs. Любой может проверить его, запустить локально, разветвить или внести свой вклад.
Подключение к proxy.gonka.gg
opengnk — это локальная версия proxy.gonka.gg (https://proxy.gonka.gg), нашего облачного API для вывода Gonka. Если вам нужна управляемая конечная точка без настройки, вам подойдет proxy.gonka.gg. Если вам нужен полный контроль — ваши ключи на вашем компьютере, ваши собственные ограничения скорости, ваши собственные гарантии конфиденциальности — opengnk — это ответ.
Оба используют один и тот же протокол, совместимый с OpenAI. Переключение между ними осуществляется одним изменением base_url.
Что дальше
opengnk уже используется разработчиками, работающими на Gonka, подключая его к агентам (OpenClaw и т. д.), Cursor, локальным скриптам и пользовательским приложениям. Мы продолжим вносить изменения в зависимости от потребностей сообщества.
Если вам нужна какая-то функция — дополнительная поддержка конечных точек, новые классификаторы очистки, улучшенная многомодельная маршрутизация или что-то еще — откройте проблему или сообщите нам в чате Telegram. Мы отправляем быстро.
GitHub: github.com/gonkalabs/opengnk (https://github.com/gonkalabs/opengnk) Gonka Labs: gonkalabs.com (https://gonkalabs.com) | гонка.гг (https://gonka.gg)