Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

[Bug]: /v1/responses bypasses model-owner filtering in the Ollama proxy

已關閉
  • 哪裡不對？
#146 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 2 天內回覆

@ilaigold 已經在處理了。

開始於 2026年10月9日。

  • #155 來自 @ilaigold —— 未關閉

評估

難度
3/5
預估耗時
半天
新手友好度
84/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
go
領域
api, backend

研究方向

Start in services/ollama-proxy/proxy.go: the inferenceEndpoints list near lines 152-165 and the handleHTTP/isInferenceRequest logic near lines 1139-1152 that populates routingModel before calling resolveCandidates. Add POST /v1/responses to the model-bearing inference routes so ownership filtering and workload accounting apply, leaving control endpoints outside filtering. Done means a regression test in the proxy's Go test suite that deliberately prefers a non-owner node, asserts it receives no /v1/responses request, and confirms the advertised owner serves it; run the package tests in services/ollama-proxy to verify.

由索引模型根據 Issue 內容生成。

描述

bug
Environment
  • PAIR release v0.1.1; installed ollama-proxy reports 0.26.2 (matches the tagged versions.json).
  • Two-node cluster: macOS arm64 client with an existing Ollama 0.5.12 installation; Ubuntu arm64 DGX Spark model host with PAIR-managed Ollama 0.40.0.
  • Only the model host advertises qwen3.6:35b-a3b-mtp-q4_K_M.
  • Codex CLI 0.160.1, Responses wire protocol.
Observed behavior

A real, isolated Codex task routed through the client's loopback PAIR proxy eventually completed and passed its eight behavior tests, but logged 32 reconnect events with:

unexpected status 404 Not Found: 404 page not found
url: http://127.0.0.1:11435/v1/responses

The same symptom occurred with a custom Responses provider and with Codex's built-in Ollama provider:

CODEX_OSS_BASE_URL=http://127.0.0.1:11435/v1 codex --oss --local-provider ollama -m qwen3.6:35b-a3b-mtp-q4_K_M

The native /api/generate route through the same proxy successfully used the remote model. The requested model is absent from the client's local engine inventory and present on the model host. I have not captured a per-request selected-node trace for the failing Responses calls; the model-filter bypass below is established directly by the tagged source.

Source-level cause

services/ollama-proxy/proxy.go at v0.1.1:

  • inferenceEndpoints includes native Ollama routes and OpenAI chat/completions/embeddings, but omits /v1/responses.
  • In handleHTTP, routingModel is populated only when isInferenceRequest returns true.
  • resolveCandidates(routingModel) therefore receives an empty model for a Responses POST, bypassing advertised-model ownership filtering. These requests also miss inference workload accounting/reservations.

Source links:

This permits Responses traffic to select an engine that does not own the requested model; an older engine that lacks the Responses API returns the observed plain 404. This is distinct from the tool-call representation question in #94.

Expected behavior / regression case

Treat POST /v1/responses as model-bearing inference. With two advertised nodes and only one owning the requested model, send the request only to that owner even when scheduler priority prefers the non-owner. Record the inference workload on the serving node. Keep control endpoints outside model filtering.

A regression test should prefer a non-owner node deliberately and assert that it receives no Responses request, while the advertised owner serves the request successfully.

主要語言
Go
星號
1.6k
分支
277
平均合併
4 天 14 小時
30 天內合併 PR
31

環境準備

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

NVIDIA/Personal-AI-Router 的其他 Issue

查看 NVIDIA/Personal-AI-Router 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。