GiP #860 — Inference Quality Protocol: Semantic Inference Optimization

Фон

Это обсуждение представляет собой проектный документ, предшествующий реализации. PR [#859 (https://github.com/gonka-ai/gonka/pull/859)] (семантический кеш) — это первая веха реализации; он существует для проверки гипотезы об инфраструктуре, а не для определения всей системы. Здесь определена вся система.

Согласно процессу проверки @akup (https://github.com/akup), описанному в [#856 (https://github.com/gonka-ai/gonka/pull/856)] и [#802 (https://github.com/gonka-ai/gonka/discussions/802)]: сначала проектируйте, затем кодируйте. Этот GiP и является тем этапом проектирования. PR [#859 (https://github.com/gonka-ai/gonka/pull/859)] строго ограничен тем, что обосновывает этот документ на этапе 0.

PR [#859 (https://github.com/gonka-ai/gonka/pull/859)] представляет CacheQualityWeight — вознаграждение за повторное использование кеша. Это работающая реализация, но ее область действия намеренно ограничена: она решает одну часть более крупной проблемы.

В этом обсуждении предлагается, что представляет собой эта более крупная проблема, как она связана со всем, что уже есть в протоколе, и как выглядит полное решение.

Пробел: качество не имеет протокольного представления

Сеть Gonka имеет строгую экономическую модель вычислений: Proof-of-Compute измеряет генерацию nonce, проверяет ее на всех узлах и преобразует в вес эпохи. Каждый узел понимает, оптимизирует и стимулирует PoC.

Качество вывода — был ли ответ полезным, точным, своевременным или соответствующим типу запроса — не имеет эквивалентного протокольного представления. Он невидим для цепи.

Это не критика. Это естественный этап развития. PoC необходимо было приземлиться первым (см. [#856 (https://github.com/gonka-ai/gonka/pull/856)], [#821 (https://github.com/gonka-ai/gonka/issues/821)]). Но по мере роста сети отсутствие качественного сигнала приводит к предсказуемым отказам:

• Закон Гудхарта — любая отдельная метрика становится целью и перестает измерять то, что должна была измерять. CacheQualityWeight, основанный исключительно на reuseCount, будет управляться маршрутизацией, а не улучшением качества.

• Слепота маршрутизации — GetRandomExecutor распределяет трафик равномерно независимо от того, какой узел лучше справляется с какой задачей. Узел, специализирующийся на генерации кода, получает тот же трафик, что и узел, оптимизированный для трансляции.

• Нет пути обратной связи — участники, отправляющие запросы на вывод, не имеют возможности сообщить, был ли результат полезен. Их опыт не улучшает протокол.

• Разногласия разработчиков — у разработчиков, интегрирующих Gonka, нет встроенных в протокол рекомендаций о том, как структурировать запросы для получения наилучших результатов, какую модель использовать для какой задачи или как измерять собственное качество вывода с течением времени.

Измерено на основе данных сети в реальном времени (эпохи 161–191, 2 503 595 выводов):

Составной показатель качества = 0,7236 (6 измеренных осей, 4 прогнозируемых) Ключевые узкие места: L8 Постоянство задержки: балл 0,32 (CV = 0,68, σ = 876 мс — высокая дисперсия) L0 Стабильность вычислений: балл 0,65 (CV = 0,35 — вес снизился на 60 % от пиковой до минимума) L6 Повторное использование (совместное): балл 0,00 (M=571 → hit_rate ≈ 0) L4 Полезность: не измеряется — механизма не существует.

Разрыв в качестве измерим. Путь улучшения поддается количественной оценке.

Что предлагает этот GiP

Контролируемая руководством многомерная система измерения качества и маршрутизации, поэтапно построенная на основе инфраструктуры PR [#859 (https://github.com/gonka-ai/gonka/pull/859)].

Он состоит из двух взаимосвязанных компонентов:

1 — Реестр оси качества (измерение)

Десять осей, каждая из которых активируется независимо с помощью весов управления:

Суммарный балл:

QualityScore = Σ(wi × Li) — веса являются параметрами управления.

Реестр является аддитивным. Ничего не сломается, если вес равен нулю. Оси активируются, когда руководство решает, что измерения достаточно надежны, чтобы повлиять на вознаграждение.

2 — Оптимизация семантического вывода (маршрутизация + опыт разработчика)

По мере того, как протокол накапливает завершенные выводы, он строит семантическую карту шаблонов выполнения: какие типы задач на каких узлах выполняются успешно, какие модели лучше всего обрабатывают какие архетипы запросов, как выглядят задержка и скорость выполнения в зависимости от специализации.

Эта карта позволяет сделать две вещи:

Сторона протокола (DAPI):

• GetQualityWeightedExecutor заменяет GetRandomExecutor.

• Потоки трафика пропорциональны QualityScore, а не равномерны.

• Узлы, специализирующиеся на определенном типе задач, привлекают больше трафика → более высокая частота обращений → более высокий CacheQualityWeight → больше вознаграждений → более глубокая специализация.

Цикл экономический, а не административный

Сторона разработчика/участника:

• GET /v1/models/profiles — предоставляет центроиды специализации узла и показатели качества.

• Заголовки ответов: X-Suggested-Model, X-Task-Archetype, X-Quality-Score.

• Разработчики узнают, какую модель использовать для своей рабочей нагрузки, на основе данных протокола, а не методом проб и ошибок.

• Протокол становится центром знаний, а не просто диспетчером вычислений.

Это не быстрая модификация. Протокол не меняет то, что отправляют пользователи. Он предоставляет метаданные: «для этого типа запроса вот что, как известно сети, работает». Разработчики и клиенты действуют на основе этой информации добровольно.

Почему это не на грани осуществимости

Технические примитивы проверены, внедрены и находятся в производстве по всей отрасли:

Инфраструктуры от PR [#859 (https://github.com/gonka-ai/gonka/pull/859)] достаточно для этапов 0–4. Для этапов 5–7 требуются дополнительные конечные точки и клиентская библиотека (обсуждается ниже).

Измеренные доказательства

Все числа воспроизводятся из общедоступных конечных точек. Никакие личные данные не используются.

Базовая линия сети (gonka.gg/api/public, эпохи 161–191):

Выводы: всего 2 503 595 (в среднем 75 016 в эпоху) Участники: 109–197 в эпоху Промахи: 3,25 % (биномиальный тест: k = 81 360 << критическое 251 140, α = 0,05 → PASS) Завершение: среднее 90,4 %, диапазон 72–99 %, σ = 7,4 %

Живой вывод (proxy.gonka.gg, Qwen3-235B, 16 запросов):

Задержка без потока: среднее значение = 1280 мс, σ = 876 мс, CV = 0,68 ← узкое место первичного качества Точность потока: 8/8 SSE [DONE] получено (100%) мс/выходной токен: среднее 154 мс

Множитель специализации:

M=571 (Qwen3-32B, общий): hit_rate = 0,000473 M=12 (QwQ-32B, low-M): hit_rate = 0,0225 → 47,6× улучшение M=1 (уникальная модель): hit_rate = 0,27 → 571× улучшение

Экономическое обоснование специализации является математическим, а не умозрительным.

Моделирование маршрутизации:

Гипотезы (все ДОКАЗАННЫЕ на основе измеренных данных):

Возможно многоосное измерение качества → 6/10 осей измеряются из работающей сети

Специализация повышает качество → множитель 47,6× доказан математически из топологии

• В протоколе отсутствует петля обратной связи по качеству → L4/L5 сегодня не имеют механизма протокола.

Маршрутизация с учетом качества улучшает экономику сети → доказано моделированием маршрутизации

Дорожная карта реализации

Фаза 7 — это продукт, ориентированный на разработчиков, а не предложение протокола. Он находится в отдельном репозитории под эгидой Gonka Labs. Протокол (этапы 0–6) предоставляет данные и конечные точки; SDK делает их эргономичными. Разделение их означает:

• Протокол может развиваться со скоростью протокола (управление, безопасность, консенсус).

• SDK может поставляться в темпе разработки (выпуски еженедельные, разрешены критические изменения).

• Сторонние SDK (плагин LangChain, серверная часть маршрутизатора LiteLLM, сервер MCP) могут независимо создаваться на одних и тех же конечных точках фазы 6.

Стратегия инструментов разработчика (объем этапа 7)

Пробел сегодня: у разработчиков, интегрирующих Gonka, нет стандартного шаблона. Они пишут необработанные HTTP-вызовы, выбирают модели вручную, не имеют информации о качестве вывода и не получают указаний от протокола о том, как улучшить свою рабочую нагрузку.

SDK заполняет этот пробел, используя инфраструктуру, которая появится у протокола после этапа 6.

Что включает в себя SDK

Конечные точки протокола (этап 6): POST /v1/chat/completions Совместимость с OpenAI (существующий, proxy.gonka.gg) GET /v1/models/profiles Показатели качества + центроиды специализации (этап 6) POST /v1/chat/completions X-Inference-Feedback: заголовок +1/-1 (этап 3) Заголовки ответов (этап 6): X-Quality-Score: 0,82 Оценка качества узла для этого запроса X-Предлагаемая модель: Qwen/QwQ-32B Лучшая модель для этого типа задачи X-Task-Archetype: проверка кода Обнаруженная категория задач X-Cache: HIT/MISS Результат кэширования (фаза 0)

Разработка SDK (TypeScript/Python)

TypeScript (вставка на основе Axios, совместимая с OpenAI-SDK):

импортировать {GonkaClient} из "@gonka-labs/sdk"; const client = новый GonkaClient ({apiKey:process.env. GONKA_API_KEY, baseURL: "https://proxy.gonka.gg/v1",qualityFeedback: true, // автоматическая отправка X-Inference-Feedback на основе ответа autoRoute: true, // выбор модели из /v1/models/profiles для типа задачи }) ; константный ответ = ожидание клиента. чат . доработки. create ( { messages : [ { role : "user" , content : "review this code: ..." } ], // модель не требуется: SDK определяет архетип задачи → направляет к QwQ-32B, если код задачи } ); // SDK присоединяет метаданные качества к объекту ответа: console. журнал (ответ. качество. оценка); // 0.82 консоль. журнал (ответ. качество. предложенная модель); // Консоль «Qwen/QwQ-32B». журнал (ответ. качество. кэшХит); // ложь

Python (на основе httpx, добавление для пакета openai):

из gonka import GonkaClient client = GonkaClient (api_key = os. environ ["GONKA_API_KEY"], auto_route = True,quality_feedback = True,) ответ = client. чат . доработки. create ( messages = [{ "role" : "user" , "content" : "translate to French: ..." }], # SDK направляет к специализированному узлу перевода через /v1/models/profiles ) print (response .quality ) # QualityMetadata(score=0.91, cache_hit=True, latency_ms=340)

Чего это достигает

• Разработчики сразу же получают выводы о лучших практиках, не читая документацию по протоколам.

• Каждый запрос SDK отправляет X-Inference-Feedback, улучшая данные L4 для всех узлов.

• Выбор модели определяется данными о качестве протокола, а не догадками.

Частота попаданий в кэш увеличивается, поскольку autoRoute концентрирует трафик на специализированных узлах (↑ M→1)

• Цикл обратной связи по качеству замыкается: SDK → сигнал L4 → GetQualityWeightedExecutor → лучшая маршрутизация → более высокий показатель качества → SDK сообщает о лучших результатах → цикл

Связь с существующими шаблонами с открытым исходным кодом

Gonka SDK не является новым архитектурным изобретением — он следует устоявшимся шаблонам. Что делает его специфичным для Gonka, так это то, что сигналы маршрутизации и качества поступают из реестра качества внутри цепочки, а не из централизованной службы. Это отличительная черта.

Расширение прототипа (фаза 1)

Расширьте CacheQualityEpochSummary дополнительными осями:

message CacheQualityEpochSummary { // существующие поля 1–7 (PR #859) uint32complete_rate_bps = 8 ; // L9: MsgFinish / (MsgFinish + MsgMiss + MsgInvalidate) uint32 avg_latency_ms = 9; // L8: средняя задержка запроса uint32 latency_stddev_ms = 10; // L8: σ(latency) — сигнал согласованности uint32stream_fidelity_bps = 11 ; // L7: SSE Done_chunks / total_chunks × 10000 int64 Feedback_score_sum = 12 ; // L4: Σ сигналы обратной связи (+1/-1) int64 Feedback_count = 13 ; // L4: количество сигналов обратной связи в эту эпоху }

Параметры веса управления (новые поля в CacheQualityParams):

// axis_weights[i] — вес Ли в базисных пунктах. Сумма должна быть равна 10000. // По умолчанию: [1000,1000,1500,1000,1000,500,1000,1000,1000,1000] повторенный uint32 axis_weights = 8; // max_cache_entries ограничивает рост InMemoryCacheStore. // По умолчанию: 50000. При 1,5 КБ/запись: пик ~75 МБ. Требуется для производственных узлов. uint64 max_cache_entries = 9;

Ограничение масштаба (честно)

В настоящее время InMemoryCacheStore не имеет ограничения на количество участников. В масштабе основной сети (75 000 выводов/эпоху, 384-мерные встраивания, MaxCacheAgeEpochs=10): пик ~1,15 ГБ ОЗУ и O(75 000) косинусного сканирования на запрос.

Параметр управления max_cache_entries (фаза 1) ограничивает это. При N=50 000: пик ~75МБ, сканирование O(50К) — приемлемо на любом современном узле. Вызов EvictExpired на каждой границе эпохи сохраняет ограничение хранилища во времени.

Связанная работа

• PR [feat(semantic-cache): конвейер качества L2 — уровень адаптивной когерентности + замыкание цикла концентратора [без дополнительного графического процессора] #859 (https://github.com/gonka-ai/gonka/pull/859)] — инфраструктура семантического кэша (от этого зависит это обсуждение)

• PR [ Ak issue782 0.2.11 #793 (https://github.com/gonka-ai/gonka/pull/793) ] — EpochGroupCache: per-block epoch state (merge prerequisite for 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) )

• PR [ [P2] Ak Issue554 Исправлен бесплатный вывод № 703 (https://github.com/gonka-ai/gonka/pull/703) ] — бесплатное исправление безопасности вывода (предварительное условие слияния для feat(semantic-cache): конвейер качества L2 — уровень адаптивной когерентности + замыкание цикла концентратора [без дополнительного графического процессора] # 859 (https://github.com/gonka-ai/gonka/pull/859) )

• PR [ Feature/821 Continuous PoC Complete #856 (https://github.com/gonka-ai/gonka/pull/856) ] — Continuous PoC Complete ([Проектирование непрерывного PoC + реализация #821 (https://github.com/gonka-ai/gonka/issues/821)]): непосредственно проверяет ось L0. ContinuousPoC теперь представляет собой действующую инфраструктуру; Измерение качества (L0: стабильность вычислений, измеренное CV=0,35) лежит на вершине этого фундамента. Выбор времени выбран намеренно: сначала выполняется PoC, затем следует уровень качества.

• PR [Улучшения производительности StartInference и FinishInference # 812 (https://github.com/gonka-ai/gonka/pull/812) ] — производительность StartInference/FinishInference (снижает стоимость горячего пути для каждого вывода, включая HIT кэша)

• PR [[P2] Fix/784 безопасность ошибок атомарности фонда #789 (https://github.com/gonka-ai/gonka/pull/789) ] — исправление атомарности фонда: ось L2 (правильность) отслеживает уровень аннулирования. Исправления атомарности уменьшают число ложных признаний недействительными, улучшая базовый показатель L2.

• GiP [Экспортер Prometheus для мониторинга узлов № 840 (https://github.com/gonka-ai/gonka/discussions/840)] — Экспортер Prometheus: /admin/v1/cache/stats является источником A в предложенном там треугольнике перекрестной проверки из трех источников.

• GiP [Gonka Node Manager — автоматическое развертывание, обновление и мониторинг узлов #816 (https://github.com/gonka-ai/gonka/discussions/816)] — Node Manager: стандарт развертывания k8s, который максимизирует частоту попадания в кэш за счет специализации модели (M=1 на узел)

• Обсуждение [Непрерывный PoC #802 (https://github.com/gonka-ai/gonka/discussions/802)] — процесс, ориентированный на проектирование: этот GiP явно следует этому процессу.

• Проблема [Исследование пропущенных выводов на некоторых узлах (основные причины + устранение) № 820 (https://github.com/gonka-ai/gonka/issues/820)] — пропущенные выводы: оси L2 (правильность) и L9 (степень завершения) непосредственно количественно определяют основную причину

• Проблема [тесты LogInfo в тестовой сети для StartInference и FinishInference #839 (https://github.com/gonka-ai/gonka/issues/839)] — log_format=json: уменьшение задержки в 3 раза; необходимое условие для честных измерений базовой линии L8 (согласованность задержки)

Открытые вопросы для сообщества

• Управление весом: кто предлагает начальные значения axis_weights? Каков процесс внесения поправок при добавлении новой оси?

Управление весом: кто предлагает начальные значения axis_weights? What's the amendment process when a new axis is added?

• Стимул обратной связи L4: следует ли вознаграждать участников (даже номинально) за отправку отзывов? Без стимулов принятие будет низким.

Стимул обратной связи L4: следует ли вознаграждать участников (даже номинально) за отправку отзывов? Без стимулов принятие будет низким.

• Вебхук для разработчиков L5: согласие или отказ по умолчанию? Какова модель конфиденциальности данных о результатах?

Вебхук для разработчиков L5: согласие или отказ по умолчанию? Какова модель конфиденциальности данных о результатах?

• Объем SDK: должна ли Фаза 7 быть проектом Gonka Labs или репозиторием, принадлежащим сообществу? Какова модель управления самим SDK?

Объем SDK: должна ли Фаза 7 быть проектом Gonka Labs или репозиторием, принадлежащим сообществу? Какова модель управления самим SDK?

• max_cache_entries по умолчанию: 50 000 является консервативным. Существует ли предпочтительная граница, основанная на ожидаемых профилях оборудования узла?

max_cache_entries по умолчанию: 50 000 является консервативным. Существует ли предпочтительная граница, основанная на ожидаемых профилях оборудования узла?

• Интеграция ContinuousPoC: должен ли ContinuousPoCEpochSummary.efficient_poc_weight быть частью расчета оси L0 или оставаться отдельной дорожкой PoC? ( @akup (https://github.com/akup) , @Mayveski (https://github.com/Mayveski) )

Интеграция ContinuousPoC: должен ли ContinuousPoCEpochSummary.efficient_poc_weight быть частью расчета оси L0 или оставаться отдельной дорожкой PoC? ( @akup (https://github.com/akup) , @Mayveski (https://github.com/Mayveski) )

Полный проектный документ с оценками, моделированием маршрутизации и матрицей сценариев: docs/specs/inference-quality-protocol.md в ветке PR [#859 (https://github.com/gonka-ai/gonka/pull/859)].

Качество вывода — был ли ответ полезным, точным, своевременным или соответствующим типу запроса — не имеет эквивалентного протокольного представления. Он невидим для цепи.

Качество ответа (с точки зрения точности LLM) является частью самой модели безопасности: управление точно определяет, какие модели обслуживаются, а перекрестная проверка проверяет это. Сам процесс проверки требует некоторого улучшения, но идея состоит в том, чтобы гарантировать одинаковое качество от всех участников явно, а не путем обратной связи.

Слепота маршрутизации — GetRandomExecutor распределяет трафик равномерно независимо от того, какой узел лучше справляется с какой задачей. Узел, специализирующийся на генерации кода, получает тот же трафик, что и узел, оптимизированный для трансляции.

То же самое: оно распределялось только между работниками, которые служили точно такой же модели. Хозяин не может сам выбрать другой вариант

Идея измерения производительности в целом — хорошее направление. Но я чувствую, что нынешнее предложение не учитывает то, как сеть работает сейчас.

РЭ

@gmorgachev (https://github.com/gmorgachev) Спасибо, обращаясь к каждому пункту:

1. Качество ответа (точность LLM) и модель безопасности. Мы не заменяем управление или перекрестную проверку. Они по-прежнему определяют, какие модели разрешены, и проверяют идентичные результаты. В GiP #860 (https://github.com/gonka-ai/gonka/discussions/860) оси L0–L2 (стабильность вычислений, доступность, корректность) — это именно то, что уже есть в цепочке (RTV, валидация, стабильность веса). L4 (полезность) и L5 (результат) — это дополнительные сигналы сверху: «был ли этот результат полезен?» или «задача решена», а не замена «все участники возвращают одинаковый результат для одной и той же модели».

2. Маршрутизация и «хост не может выбрать другую модель» Согласен: хост не выбирает модель. В #869 (https://github.com/gonka-ai/gonka/discussions/869) GetQualityWeightedExecutor предназначен для работы внутри одной и той же модели: запрос уже привязан к модели (как сегодня), а вес влияет только на то, какой узел из тех, кто обслуживает эту модель, получит запрос. Таким образом, трафик по-прежнему осуществляется только между работниками одной и той же модели; изменение заключается в том, что «среди них выберите вариант с лучшими L6/L8/L9 (повторное использование, задержка, завершение) для этой модели».

3. «Предложение не учитывает то, как работает цепочка сейчас» В PR #859 (https://github.com/gonka-ai/gonka/pull/859) CacheQualityWeight вшит в существующий поток: он добавляется в baseCount там же, где вес PoC (module/chainvalidation.go, расчет). Никакого второго пути расчета — просто дополнительный член в той же формуле. Фазы 0–6 в #869 (https://github.com/gonka-ai/gonka/discussions/869) основаны на этом: расширить прототип (поля 8–13), сообщить L7/L8 в QualityReporter, проанализировать X-Inference-Feedback, маршрутизировать по качеству между исполнителями для одной и той же модели. Таким образом, мы явно строим поверх текущей логики цепочки, а не рядом с ней.

Что уже сделано: Мы проверили гипотезу #860 (https://github.com/gonka-ai/gonka/discussions/860) на реальной настройке: gonkalabs/gonka-agent (семантический кеш, два участника, разные рабочие области). R-3 в docs/testing.md показывает, что участник Б получает частичное попадание (0,79) из кеша А — тот же домен (гонка Go), другая структура. Это сценарий «один участник структурирует запросы → другой извлекает выгоду из кэша» из этого GiP; Измеряются повторное использование L6 и сэкономленное время. Промежуточное программное обеспечение L6/L8/L9 + X-Inference-Feedback находится в gonkalabs/opengnk. Таким образом, предложение не только на бумаге — оно реализуется по пути агент → прокси → сеть, сохраняя при этом текущую цепочку и поведение модели маршрутизации.