GiP: Inference Quality Axis Registry — расширение CacheQualityWeight до измеримой полезной работы
Оригинал: GiP: Inference Quality Axis Registry — extending CacheQualityWeight toward measurable useful work
Обновление: измерение завершено + векторная проверка
Оригинальный GiP описывает архитектуру системы. Этот комментарий доказывает, что вектор работает, а это означает: поведение разработчиков может заметно изменить качество сети по тем же направлениям, которые определяет этот GiP.
Основная претензия
Качество сети не фиксировано. Это зависит от того, как разработчики структурируют свои запросы. Протокол может изучить эту структуру и укрепить ее.
Это не гипотетически. Вот измеренный путь:
Шаг 1. Сеть сегодня (измеряется, а не прогнозируется)
L8 CV = 0,83 — задержка колеблется на 83% от среднего значения каждую эпоху. L9 = 94,33% — в среднем 2624 вывода за эпоху не удались. Пик: 13 020 (эпоха 175). L6 = 0,0005 — случайная маршрутизация M=571 делает кеш математически бесполезным. Общий балл: 0,4832/1,0
Это базовый уровень. Случайная маршрутизация, никакой обратной связи, никаких структурированных шаблонов.
Шаг 2. SDK меняет вектор
Протестировано 5 доменов, по 3 варианта запроса каждый, полностью MiniLM-L6-v2 (dim=384, без графического процессора):
Без SDK: среднее попарное сходство участников = 0,49. С шаблонами SDK (DX7): 0,80. Дельта: +62,1%.
Один участник, использующий структурированные подсказки, повышает вероятность попадания в кэш для всех остальных участников в том же домене. Это общая, а не индивидуальная оптимизация.
Шаг 3: Управление регулирует порог
СходствоThresholdBps уже контролируется управлением (PR № 859 (https://github.com/gonka-ai/gonka/pull/859), значение по умолчанию: 9700).
Каждый шаг: ноль изменений кода, ноль развертываний, одно голосование руководства. Каждый шаг обратим. Протокол находится под контролем.
Худший случай: нулевое воздействие
повтор_фракция=5%, поток=50%, M=571, порог=0,97 без изменений: hit_rate = 0,05 × (1/571) × 0,50 = 0,000044 ≈ 0 CacheQualityWeight = 0. Функция отключена по умолчанию. В худшем случае = сегодня. Нулевая регрессия.
Что это значит для протокола
GiP #860 (https://github.com/gonka-ai/gonka/discussions/860) не касается кеша. Кэш — это фаза 0.
GiP #860 (https://github.com/gonka-ai/gonka/discussions/860) посвящен замыканию цикла обратной связи: разработчик использует SDK → структурированные подсказки → активирует L6 → записи QualityReporter → GetQualityWeightedExecutor лучше маршрутизирует → лучшие узлы получают трафик → улучшаются L8/L9 → SDK сообщает о лучших результатах → управление снижает порог → ужесточает цикл.
Протокол в настоящее время не имеет такого цикла. Каждый вывод одинаково невидим для сети. Этот пробел закрывает этот GiP.
Что осталось
Один пробел: узел тестовой сети с CacheQualityParams.Enabled=true для 1 эпохи. Это закрывает измерение в режиме повтора_фракции (настоящие заголовки X-Cache, реальные попадания/промахи). Все остальное либо измеряется по действующей сети, либо ограничивается худшим случаем.
Полная спецификация с номерами: docs/specs/inference-quality-protocol.md в ветке PR #859 (https://github.com/gonka-ai/gonka/pull/859).
Последний вариант предлагает вам возможность самостоятельно проверить качество на любом уровне вывода клиент/хост/GNK.
В зависимости от того, как вы настраиваете контекст SDK и реализуете AXIOS, последним шагом будет взаимодействие с понимающими участниками и обсуждение обоснованных гипотез для их подтверждения на уровне тестового производства. Тонкая настройка матрицы и корректировка вычислений, учитывая, что идея решает проблемы с производительностью и улучшает пользовательский опыт на всех уровнях, уже не так недостижима, как это было во времена первого потока. В целом, приятно иметь возможность сначала добавить этот параметр в качестве опции протокола. Я надеюсь, что кто-то найдет это актуальным.
PS: Срок действия курсора истек, поэтому я пока изучу соответствующую документацию, процессы и философию протокола.
Обновление: доказательство реализации теперь находится в отдельном репозитории. Агент в gonkalabs/gonka-agent использует тот же протокол (semcache, X-Inference-Feedback, два рабочих пространства). docs/testing.md записывает реальный прогон с двумя участниками (доказательство 860): участник A холодный, участник B частичное попадание 0,79, экономия времени ~ 23%. Таким образом, вектор «взаимозависимости участников» из этого GiP больше не является гипотетическим — он воспроизводим. Когда доступны dev-цепи или экспериментальная ветка, на нее можно указать этот стек, не меняя дизайн.
Обновление: двоичная сингулярность — PQM > 1.0 проверено (11 марта 2026 г.)
источник № 859 (https://github.com/gonka-ai/gonka/pull/859)
Вектор «взаимозависимости участников» из последнего обновления теперь масштабируется до полного набора экспериментов и готового к использованию стека развертывания.
4 эксперимента с Bookworm (только процессор, без графического процессора):
PQM > 1,0 = двоичный уровень дает лучшие результаты, чем одиночный холодный вывод графического процессора. Реестр осей качества, предложенный в этом документе, теперь поддается сквозному измерению.
Что развернуто:
- Полный стек развертывания: LITE/MEDIUM/HARD (K3s)/PRODUCTION — Deploy/binary-singularity/ (https://github.com/Mayveski/gonka/tree/feature/gip-semantic-cache-trust-layer/deploy/binary-singularity)
- SDK gonka-agent с хранилищем PatternSlot + совместным использованием сетки — gonkalabs/gonka-agent (https://github.com/gonkalabs/gonka-agent/tree/dev/binary-singularity)
- Промежуточное программное обеспечение качества: POST /quality/search + POST /quality/slots/share — обмен слотами между участниками.
- Поиск косинуса процессора с квантованием int8 в ячеистом пуле — попадание в слот ~5 мс против среднего значения для графического процессора ~1280 мс
Как теперь измеряются оси из этого GiP:
Сетевая корреляция (оперативные данные, эпохи 161-191, 2 503 595 выводов):
L6: 0,000473 → 0,27+ (571× со специализацией)
L8: среднее значение 1280 мс → попадание в слот ~5 мс (250 ×)
- L9: 90,4 % → 100 % отслеживаются в цикле агента.
Память: 16 ГБ видеопамяти → 19–23 МБ оперативной памяти ЦП (700 ×)
Экономия графического процессора при 20% специализации: 940 698 в эпоху (~ 155 800 долларов в год за полный протокол)
Цикл обратной связи, описанный в этом GiP, теперь закрыт:
Разработчик использует агент → структурированная задача → выделенный слот → общий для ячеистого пула → другой участник находит слот → LLM получает контекст → лучший ответ → PQM растет → управление может снизить порог → ужесточается цикл.
Это был недостающий элемент: не просто кэш, а коллективная семантическая память, которая объединяется с каждым участником.
Комплексное руководство для всех уровней пользователей (разработчики, исследователи, юридические/жилищные рабочие процессы, участники): GUIDE.md (https://github.com/Mayveski/gonka/blob/feature/gip-semantic-cache-trust-layer/deploy/binary-singularity/GUIDE.md).
Остается один вопрос: включить CacheQualityParams в тестовой сети на 1 эпоху — закроет единственный пробел (repeat_fraction как измеренное число).
@libermans (https://github.com/libermans)
С уважением, Маевский_А, спасибо 4 с наилучшими результатами <3
История взносов
- PR Feature/821 Continuous PoC Complete # 856 (https://github.com/gonka-ai/gonka/pull/856) — Continuous PoC Complete: исправлена критическая ошибка сериализации в feat(inference): добавлена основа непрерывного PoC # 845 (https://github.com/gonka-ai/gonka/pull/845) (ContiniousPocParams никогда не сохранялся в цепочке), добавлено полное сокращение для трех новых коллекции, расчет эпох с помощью EconomicPocWeight и защищенная от Меркла система запросов/ответов. Закрывает проект GiP Continuous PoC + реализацию #821 (https://github.com/gonka-ai/gonka/issues/821).
- PR-подвиг (семантический кеш): конвейер качества L2 — адаптивный уровень согласованности + замыкание цикла концентратора [без дополнительного графического процессора] # 859 (https://github.com/gonka-ai/gonka/pull/859) — семантический кеш + CacheQualityWeight: двухуровневый кеш (точное совпадение L1, косинусное сходство L2), аддитивный бонус качества при урегулировании эпохи, параметры, контролируемые управлением, 20 тестов без графического процессора или живая цепь.
Мотивация
tokenomics-v2/bitcoin-reward.md прямо назвал открытый пробел: «Нет стимула для разнообразия моделей или качества использования». PR №859 (https://github.com/gonka-ai/gonka/pull/859) — это первая конкретная реализация этого направления, но она измеряет только одну ось: повторное использование.
Более глубокий вопрос: может ли протокол вознаграждать узлы за качество их вычислений, а не только за их объем? Узел, который зарабатывает больше, потому что его результат был полезен, начинает оптимизировать результаты, а не пропускную способность. Это меняет поведение во всей сети.
Предлагаемое решение
Расширьте CacheQualityParams до QualityAxisRegistry — управляемой карты, где каждая ось имеет свой вес и контракт на отправку:
- Повторное использование (уже в PR feat(semantic-cache): конвейер качества L2 — адаптивный уровень согласованности + замыкание цикла хаба [без дополнительного графического процессора] #859 (https://github.com/gonka-ai/gonka/pull/859) — неявное, внутреннее для DAPI
- Непрерывность сеанса — DAPI видит глубину сеанса без какой-либо интеграции.
- Явная обратная связь — единый тег обратной связи при следующем запросе API, тот же контракт, совместимый с OpenAI.
- Поддающийся проверке результат — разработчик отмечает задачу решенной и отправляет ее с помощью существующего шаблона MsgSubmitCacheQualitySummary.
Качественная доставка сигнала уже в основном доступна:
API — inference_id в каждом ответе, обратная связь в виде тега при следующем запросе
SDK — оборачивает вызов, автоматически собирает неявные сигналы
Виджет — встраиваемый пользовательский интерфейс, нулевой код от разработчика
- Неявные сигналы — DAPI изначально отслеживает глубину сеанса и семантическое повторение.
Webhook — узел отправляет событие при закрытии вывода, приложение возвращает результат
CLI / authz — MsgSubmitCacheQualitySummary уже в InferenceOperationKeyPerms с полным Grant→Exec→Revoke
Шаблон расчета CacheQualityParams + эпоха, представленный в № 859 (https://github.com/gonka-ai/gonka/pull/859), является достаточно универсальным, чтобы переносить все это без перестройки уровня вознаграждения.
Дорожная карта реализации
- Merge PR Feature/821 Continuous POC Complete #856 (https://github.com/gonka-ai/gonka/pull/856) (непрерывный PoC) + PR feat(semantic-cache): конвейер качества L2 — адаптивный уровень согласованности + закрытие цикла хаба [без дополнительного графического процессора] #859 (https://github.com/gonka-ai/gonka/pull/859) (основа качества кэша)
Обсуждение GiP: определение схемы и параметров управления QualityAxisRegistry
- Расширьте MsgSubmitCacheQualitySummary для переноса многоосной полезной нагрузки.
- Расширьтеquality_reporter.go для агрегирования счетчиков по осям за эпоху.
Уровень доставки SDK/вебхука
Открытый вопрос
CacheQualityWeight в PR № 859 (https://github.com/gonka-ai/gonka/pull/859) уже устанавливает шаблон расчета эпох для бонусов за качество. Есть ли у сообщества желание расширить это до полного реестра оси качества в качестве следующего GiP, или разговор должен начаться после выхода #856 (https://github.com/gonka-ai/gonka/pull/856) и #859 (https://github.com/gonka-ai/gonka/pull/859)?
Обновление: измерение завершено + векторная проверка
Оригинальный GiP описывает архитектуру системы. Этот комментарий доказывает, что вектор работает, а это означает: поведение разработчиков может заметно изменить качество сети по тем же направлениям, которые определяет этот GiP.
Основная претензия
Качество сети не фиксировано. Это зависит от того, как разработчики структурируют свои запросы. Протокол может изучить эту структуру и укрепить ее.
Это не гипотетически. Вот измеренный путь:
Шаг 1. Сеть сегодня (измеряется, а не прогнозируется)
L8 CV = 0,83 — задержка колеблется на 83% от среднего значения каждую эпоху. L9 = 94,33% — в среднем 2624 вывода за эпоху не удались. Пик: 13 020 (эпоха 175). L6 = 0,0005 — случайная маршрутизация M=571 делает кеш математически бесполезным. Общий балл: 0,4832/1,0
Это базовый уровень. Случайная маршрутизация, никакой обратной связи, никаких структурированных шаблонов.
Шаг 2. SDK меняет вектор
Протестировано 5 доменов, по 3 варианта запроса каждый, полностью MiniLM-L6-v2 (dim=384, без графического процессора):
Без SDK: среднее попарное сходство участников = 0,49. С шаблонами SDK (DX7): 0,80. Дельта: +62,1%.
Один участник, использующий структурированные подсказки, повышает вероятность попадания в кэш для всех остальных участников в том же домене. Это общая, а не индивидуальная оптимизация.
Шаг 3: Управление регулирует порог
СходствоThresholdBps уже контролируется управлением (PR № 859 (https://github.com/gonka-ai/gonka/pull/859), значение по умолчанию: 9700).
Каждый шаг: ноль изменений кода, ноль развертываний, одно голосование руководства. Каждый шаг обратим. Протокол находится под контролем.
Худший случай: нулевое воздействие
повтор_фракция=5%, поток=50%, M=571, порог=0,97 без изменений: hit_rate = 0,05 × (1/571) × 0,50 = 0,000044 ≈ 0 CacheQualityWeight = 0. Функция отключена по умолчанию. В худшем случае = сегодня. Нулевая регрессия.
Что это значит для протокола
GiP #860 (https://github.com/gonka-ai/gonka/discussions/860) не касается кеша. Кэш — это фаза 0.
GiP #860 (https://github.com/gonka-ai/gonka/discussions/860) посвящен замыканию цикла обратной связи: разработчик использует SDK → структурированные подсказки → активирует L6 → записи QualityReporter → GetQualityWeightedExecutor лучше маршрутизирует → лучшие узлы получают трафик → улучшаются L8/L9 → SDK сообщает о лучших результатах → управление снижает порог → ужесточает цикл.
Протокол в настоящее время не имеет такого цикла. Каждый вывод одинаково невидим для сети. Этот пробел закрывает этот GiP.
Что осталось
Один пробел: узел тестовой сети с CacheQualityParams.Enabled=true для 1 эпохи. Это закрывает измерение в режиме повтора_фракции (настоящие заголовки X-Cache, реальные попадания/промахи). Все остальное либо измеряется по действующей сети, либо ограничивается худшим случаем.
Полная спецификация с номерами: docs/specs/inference-quality-protocol.md в ветке PR #859 (https://github.com/gonka-ai/gonka/pull/859).
Последний вариант предлагает вам возможность самостоятельно проверить качество на любом уровне вывода клиент/хост/GNK.
В зависимости от того, как вы настраиваете контекст SDK и реализуете AXIOS, последним шагом будет взаимодействие с понимающими участниками и обсуждение обоснованных гипотез для их подтверждения на уровне тестового производства. Тонкая настройка матрицы и корректировка вычислений, учитывая, что идея решает проблемы с производительностью и улучшает пользовательский опыт на всех уровнях, уже не так недостижима, как это было во времена первого потока. В целом, приятно иметь возможность сначала добавить этот параметр в качестве опции протокола. Я надеюсь, что кто-то найдет это актуальным.
PS: Срок действия курсора истек, поэтому я пока изучу соответствующую документацию, процессы и философию протокола.
Обновление: доказательство реализации теперь находится в отдельном репозитории. Агент в gonkalabs/gonka-agent использует тот же протокол (semcache, X-Inference-Feedback, два рабочих пространства). docs/testing.md записывает реальный прогон с двумя участниками (доказательство 860): участник A холодный, участник B частичное попадание 0,79, экономия времени ~ 23%. Таким образом, вектор «взаимозависимости участников» из этого GiP больше не является гипотетическим — он воспроизводим. Когда доступны dev-цепи или экспериментальная ветка, на нее можно указать этот стек, не меняя дизайн.
Обновление: двоичная сингулярность — PQM > 1.0 проверено (11 марта 2026 г.)
источник № 859 (https://github.com/gonka-ai/gonka/pull/859)
Вектор «взаимозависимости участников» из последнего обновления теперь масштабируется до полного набора экспериментов и готового к использованию стека развертывания.
4 эксперимента с Bookworm (только процессор, без графического процессора):
PQM > 1,0 = двоичный уровень дает лучшие результаты, чем одиночный холодный вывод графического процессора. Реестр осей качества, предложенный в этом документе, теперь поддается сквозному измерению.
Что развернуто:
- Полный стек развертывания: LITE/MEDIUM/HARD (K3s)/PRODUCTION — Deploy/binary-singularity/ (https://github.com/Mayveski/gonka/tree/feature/gip-semantic-cache-trust-layer/deploy/binary-singularity)
- SDK gonka-agent с хранилищем PatternSlot + совместным использованием сетки — gonkalabs/gonka-agent (https://github.com/gonkalabs/gonka-agent/tree/dev/binary-singularity)
- Промежуточное программное обеспечение качества: POST /quality/search + POST /quality/slots/share — обмен слотами между участниками.
- Поиск косинуса процессора с квантованием int8 в ячеистом пуле — попадание в слот ~5 мс против среднего значения для графического процессора ~1280 мс
Как теперь измеряются оси из этого GiP:
Сетевая корреляция (оперативные данные, эпохи 161-191, 2 503 595 выводов):
L6: 0,000473 → 0,27+ (571× со специализацией)
L8: среднее значение 1280 мс → попадание в слот ~5 мс (250 ×)
- L9: 90,4 % → 100 % отслеживаются в цикле агента.
Память: 16 ГБ видеопамяти → 19–23 МБ оперативной памяти ЦП (700 ×)
Экономия графического процессора при 20% специализации: 940 698 в эпоху (~ 155 800 долларов в год за полный протокол)
Цикл обратной связи, описанный в этом GiP, теперь закрыт:
Разработчик использует агент → структурированная задача → выделенный слот → общий для ячеистого пула → другой участник находит слот → LLM получает контекст → лучший ответ → PQM растет → управление может снизить порог → ужесточается цикл.
Это был недостающий элемент: не просто кэш, а коллективная семантическая память, которая объединяется с каждым участником.
Комплексное руководство для всех уровней пользователей (разработчики, исследователи, юридические/жилищные рабочие процессы, участники): GUIDE.md (https://github.com/Mayveski/gonka/blob/feature/gip-semantic-cache-trust-layer/deploy/binary-singularity/GUIDE.md).
Остается один вопрос: включить CacheQualityParams в тестовой сети на 1 эпоху — закроет единственный пробел (repeat_fraction как измеренное число).
@libermans (https://github.com/libermans)
С уважением, Маевский_А, спасибо 4 с наилучшими результатами <3
History of contributions
- PR Feature/821 continuous poc complete #856 (https://github.com/gonka-ai/gonka/pull/856) — Continuous PoC complete: fixed critical serialisation bug in feat(inference): add continuous PoC foundation #845 (https://github.com/gonka-ai/gonka/pull/845) (ContinuousPocParams never persisted on-chain), added full pruning for three new collections, epoch settlement with EffectivePocWeight, and Merkle-proof challenge/response system. Closes GiP Continuous PoC design + implementation #821 (https://github.com/gonka-ai/gonka/issues/821) .
- PR feat(semantic-cache): L2 quality gate pipeline — adaptive coherence floor + hub loop closure [no extra GPU] #859 (https://github.com/gonka-ai/gonka/pull/859) — Semantic cache + CacheQualityWeight: two-level cache (L1 exact-match, L2 cosine similarity), additive quality bonus at epoch settlement, governance-controlled params, 20 tests without GPU or live chain.
Motivation
tokenomics-v2/bitcoin-reward.md explicitly named an open gap: "No incentive for model diversity or utilization quality." PR #859 (https://github.com/gonka-ai/gonka/pull/859) is the first concrete implementation of that direction — but it only measures one axis: reuse.
The deeper question: can the protocol reward nodes for the quality of their computation, not just its volume? A node that earns more because its result was useful starts optimizing for outcomes, not throughput. That changes behavior across the entire network.
Proposed solution
Extend CacheQualityParams toward a QualityAxisRegistry — a governance-controlled map where each axis has its own weight and submission contract:
- Reuse (already in PR feat(semantic-cache): L2 quality gate pipeline — adaptive coherence floor + hub loop closure [no extra GPU] #859 (https://github.com/gonka-ai/gonka/pull/859) ) — implicit, internal to DAPI
Session continuity — DAPI sees session depth without any integration
Explicit feedback — single feedback tag on the next API request, same OpenAI-compatible contract
Verifiable outcome — developer marks task resolved and submits via existing MsgSubmitCacheQualitySummary pattern
Quality signal delivery is already mostly available:
API — inference_id in every response, feedback as a tag on next request
SDK — wraps the call, collects implicit signals automatically
Widget — embeddable UI, zero code from developer
Implicit signals — DAPI observes session depth and semantic repetition natively
Webhook — node pushes event on inference close, app returns outcome
CLI / authz — MsgSubmitCacheQualitySummary already in InferenceOperationKeyPerms with full Grant→Exec→Revoke
CacheQualityParams + epoch settlement pattern introduced in #859 (https://github.com/gonka-ai/gonka/pull/859) is generic enough to carry all of these without rebuilding the reward layer.
Implementation roadmap
- Merge PR Feature/821 continuous poc complete #856 (https://github.com/gonka-ai/gonka/pull/856) (continuous PoC) + PR feat(semantic-cache): L2 quality gate pipeline — adaptive coherence floor + hub loop closure [no extra GPU] #859 (https://github.com/gonka-ai/gonka/pull/859) (cache quality foundation)
GiP discussion: define QualityAxisRegistry schema and governance params
Extend MsgSubmitCacheQualitySummary to carry multi-axis payload
Extend quality_reporter.go to aggregate per-axis counters per epoch
SDK / webhook delivery layer
Open question
CacheQualityWeight in PR #859 (https://github.com/gonka-ai/gonka/pull/859) already establishes the epoch settlement pattern for quality bonuses. Is there appetite in the community to extend this toward a full quality axis registry as the next GiP, or should the conversation start after #856 (https://github.com/gonka-ai/gonka/pull/856) and #859 (https://github.com/gonka-ai/gonka/pull/859) land?
Update: measurement complete + vector proof
The original GiP describes the system architecture. This comment proves the vector works — meaning: developer behavior can shift network quality measurably, through the same axes this GiP defines.
The core claim
Network quality is not fixed. It is a function of how developers structure their requests. The protocol can learn that structure and reinforce it.
That's not a hypothetical. Here's the measured path:
Step 1: Network today (measured, not projected)
L8 CV = 0.83 — latency swings 83% from mean, every epoch. L9 = 94.33% — 2,624 inferences fail per epoch on average. Peak: 13,020 (epoch 175). L6 = 0.0005 — M=571 random routing makes cache mathematically useless. Composite score: 0.4832 / 1.0
This is the baseline. Random routing, no feedback, no structured patterns.
Step 2: SDK changes the vector
Tested 5 domains, 3 request variants each, all-MiniLM-L6-v2 (dim=384, no GPU):
Without SDK: average pairwise similarity across participants = 0.49. With SDK templates (DX7): 0.80. Delta: +62.1%.
One participant using structured prompts raises cache hit probability for every other participant in the same domain. This is a commons, not an individual optimization.
Step 3: Governance steers the threshold
SimilarityThresholdBps is already governance-controlled (PR #859 (https://github.com/gonka-ai/gonka/pull/859) default: 9700).
Each step: zero code changes, zero deployments, one governance vote. Each step is reversible. The protocol is in control.
Worst case: zero impact
repeat_fraction=5%, stream=50%, M=571, threshold=0.97 unchanged: hit_rate = 0.05 × (1/571) × 0.50 = 0.000044 ≈ 0 CacheQualityWeight = 0. Feature off by default. Worst case = today. Zero regression.
What this means for the protocol
GiP #860 (https://github.com/gonka-ai/gonka/discussions/860) is not about cache. Cache is Phase 0.
GiP #860 (https://github.com/gonka-ai/gonka/discussions/860) is about closing the feedback loop: Developer uses SDK → structured prompts → L6 activates → QualityReporter records → GetQualityWeightedExecutor routes better → better nodes win traffic → L8/L9 improve → SDK reports better outcomes → governance lowers threshold → loop tightens.
The protocol currently has no such loop. Every inference is equally invisible to the network. That's the gap this GiP closes.
What remains
One gap: testnet node with CacheQualityParams.Enabled=true for 1 epoch. This closes live repeat_fraction measurement (real X-Cache headers, real hit/miss). Everything else is either measured from live network or bounded by worst case.
Full spec with numbers: docs/specs/inference-quality-protocol.md in the PR #859 (https://github.com/gonka-ai/gonka/pull/859) branch.
The final variation offers you the opportunity to test the quality for yourself at any level of client/host/GNK inference.
Depending on how you configure the SDK context and implement AXIOS, the final step is to engage with such understanding participants and discuss valid hypotheses to confirm them at the test production level. Fine-tuning the matrix and adjusting the calculations, given that the idea addresses performance issues and improves the user experience at all levels, is no longer as unattainable as it was at the time of the first thread. Overall, it's nice to have the opportunity to deliver this setting as a protocol option first. I hope someone finds it relevant.
PS: The cursor has expired, so I'll study the related docs, processes, and protocol philosophy for now.
Update: Implementation proof is now in a separate repo. The agent at gonkalabs/gonka-agent uses the same protocol (semcache, X-Inference-Feedback, two workspaces). docs/testing.md records a real two-participant run (Proof 860): Participant A cold, Participant B partial hit 0.79, ~23% time saved. So the “participant interdependence” vector from this GiP is no longer hypothetical — it’s reproducible. When dev-chains or an experimental branch is available, this stack can be pointed at it without changing the design.
Update: Binary Singularity — PQM > 1.0 proven (2026-03-11)
sourced in #859 (https://github.com/gonka-ai/gonka/pull/859)
The "participant interdependence" vector from the last update is now scaled to a full experiment suite and production-ready deploy stack.
4 experiments on Bookworm (CPU-only, no GPU):
PQM > 1.0 = the binary layer produces better results than single cold GPU inference. The quality axis registry proposed in this GiP is now measurable end-to-end.
What's deployed:
- Full deploy stack: LITE / MEDIUM / HARD (K3s) / PRODUCTION — deploy/binary-singularity/ (https://github.com/Mayveskii/gonka/tree/feature/gip-semantic-cache-trust-layer/deploy/binary-singularity)
- gonka-agent SDK with PatternSlot store + mesh sharing — gonkalabs/gonka-agent (https://github.com/gonkalabs/gonka-agent/tree/dev/binary-singularity)
Quality middleware: POST /quality/search + POST /quality/slots/share — inter-participant slot exchange
int8-quantized CPU cosine search in mesh pool — ~5ms slot hit vs ~1280ms GPU mean
How axes from this GiP are now measured:
Network correlation (live data, epochs 161-191, 2,503,595 inferences):
L6: 0.000473 → 0.27+ (571× with specialization)
L8: 1280ms mean → ~5ms slot hit (250×)
L9: 90.4% → 100% tracked in agent loop
Memory: 16 GB VRAM → 19-23 MB CPU RAM (700×)
GPU saves at 20% specialization: 940,698/epoch (~$155,800/year full protocol)
The feedback loop this GiP described is now closed:
Developer uses agent → structured task → slot distilled → shared to mesh pool → other participant finds slot → LLM gets context → better answer → PQM grows → governance can lower threshold → loop tightens.
This was the missing piece: not just cache, but a collective semantic memory that compounds with every participant.
Comprehensive guide for all user levels (developers, researchers, legal/housing workflows, contributors): GUIDE.md (https://github.com/Mayveskii/gonka/blob/feature/gip-semantic-cache-trust-layer/deploy/binary-singularity/GUIDE.md)
One ask remains: enable CacheQualityParams on testnet for 1 epoch — closes the only gap ( repeat_fraction as a measured number).
История взносов
Мотивация
tokenomics-v2/bitcoin-reward.md прямо назвал открытый пробел: «Нет стимула для разнообразия моделей или качества использования». PR №859 (https://github.com/gonka-ai/gonka/pull/859) — это первая конкретная реализация этого направления, но она измеряет только одну ось: повторное использование.
Более глубокий вопрос: может ли протокол вознаграждать узлы за качество их вычислений, а не только за их объем? Узел, который зарабатывает больше, потому что его результат был полезен, начинает оптимизировать результаты, а не пропускную способность. Это меняет поведение во всей сети.
Предлагаемое решение
Расширьте CacheQualityParams до QualityAxisRegistry — управляемой карты, где каждая ось имеет свой вес и контракт на отправку:
Качественная доставка сигнала уже в основном доступна:
API — inference_id в каждом ответе, обратная связь в виде тега при следующем запросе
SDK — оборачивает вызов, автоматически собирает неявные сигналы
Виджет — встраиваемый пользовательский интерфейс, нулевой код от разработчика
Webhook — узел отправляет событие при закрытии вывода, приложение возвращает результат
CLI / authz — MsgSubmitCacheQualitySummary уже в InferenceOperationKeyPerms с полным Grant→Exec→Revoke
Шаблон расчета CacheQualityParams + эпоха, представленный в № 859 (https://github.com/gonka-ai/gonka/pull/859), является достаточно универсальным, чтобы переносить все это без перестройки уровня вознаграждения.
Дорожная карта реализации
Обсуждение GiP: определение схемы и параметров управления QualityAxisRegistry
Уровень доставки SDK/вебхука
Открытый вопрос
CacheQualityWeight в PR № 859 (https://github.com/gonka-ai/gonka/pull/859) уже устанавливает шаблон расчета эпох для бонусов за качество. Есть ли у сообщества желание расширить это до полного реестра оси качества в качестве следующего GiP, или разговор должен начаться после выхода #856 (https://github.com/gonka-ai/gonka/pull/856) и #859 (https://github.com/gonka-ai/gonka/pull/859)?