[Question]: Error in docker logs for embedding model

[ceinstaller]

Your Question

I'm working on setting up OpenViking in a docker container in my local environment. I'm trying to use openrouter for the embedding model and a local model for everything else. Here's my ov.conf:

{
  "server": {
    "host": "0.0.0.0",
    "port": 1933,
    "root_api_key": "viking_for_hermes"
  },
  "storage": {
    "workspace": "./data",
    "agfs": { "backend": "local" },
    "vectordb": { "backend": "local" }
  },
  "embedding": {
    "dense": {
      "provider": "openai",
      "api_base": "https://openrouter.ai/api/v1",
      "api_key": "sk-or-v1-secret-key-goes-here",
      "model": "perplexity/pplx-embed-v1-0.6b",
      "dimension": 1024
    }
  },
  "vlm": {
    "provider": "openai",
    "api_base": "http://10.0.0.65:4000/v1",
    "api_key": "dummy",
    "model": "glm-flash-30B-A3B"
  }
}

The container starts, the /health and /ready endpoints both look good, but I see this message in my logs:

openviking.models.embedder.openai_embedders - WARNING - OpenAI async embedding slow call provider=unknown model=perplexity/pplx-embed-v1-0.6b wait_ms=0.01 duration_ms=1517.32

Not sure why I'm having trouble here, hoping someone can point me in the right direction.

Thanks!

Context

No response

Code Example (Optional)

Related Area

None

Before Asking

• I have checked the documentation

[qin-ctx]

Thanks for reporting this!

Looking at the current implementation, this log line does not by itself indicate a configuration error. That warning is emitted whenever an async embedding call takes at least 1 second, so a duration around 1517 ms can trigger it even if the embedding request succeeds.

The confusing part is provider=unknown. That appears to be a logging issue on our side rather than a problem with your ov.conf: the slow-call warning reads the provider name from a base config field that is not currently populated by the embedder factory, so it falls back to unknown even when provider is configured.

Also, /health and /ready being OK is expected here. Those endpoints are liveness/readiness checks for the service and core dependencies, and they do not validate embedding latency.

Since you're using OpenRouter, one thing worth checking is whether you want to add the optional extra_headers (HTTP-Referer and X-Title) commonly used with OpenRouter. But based on this warning alone, it looks like the embedding call completed and was simply slower than the warning threshold, not that the backend failed.

We'll look at improving the logging so the provider is reported correctly and this warning is less confusing.