alvis/AgapHost
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

cognee-llm: correct docs — it IS cognee's LLM backbone (Kimi path)

Browse Source 
Reverse the earlier 'default to LiteLLM' recommendation: per user intent,
cognee runs its LLM on the Kimi subscription via cognee-llm (the reason the
wrapper exists). Gate-5 latency is an accepted tradeoff; LiteLLM stays a
documented fallback. Embeddings remain on LiteLLM nomic-embed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LeqyaxJF2nbRXJtae2kNB2
This commit is contained in:
alvis
2026-07-05 13:19:18 +00:00
parent eadda808d2
commit fb93655636
1 changed files with 13 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
openai/cognee-llm/README.md
View File

@@ -23,25 +23,22 @@ survive a request, let alone a container restart) + own `cognee-llm-home` volume
(`/root/.kimi-code`), same Kimi subscription as `kimi-agent`/`adolf-llm`, separate volume so (`/root/.kimi-code`), same Kimi subscription as `kimi-agent`/`adolf-llm`, separate volume so
each wrapper's CLI state stays isolated. each wrapper's CLI state stays isolated.
## Important: this should NOT be Cognee's default LLM backend ## This IS Cognee's LLM backbone
Per `docs/SPIKE-FINDINGS.md` gate 5 (P0 spike, empirically measured against a throwaway authed By design, Cognee's LLM runs on the flat Kimi subscription through this wrapper — the whole
container): reason it exists — mirroring how `adolf-llm` backs the assistant. P4 wires cognee's
`LLM_ENDPOINT` → `http://cognee-llm:8011`, `LLM_MODEL` → `openai/cognee-llm`.
- JSON output from the CLI is clean and schema-conformant when instructed — that part works. **Accepted tradeoff (SPIKE-FINDINGS gate 5).** The CLI's JSON output is clean/schema-conformant,
- **Latency is the blocker**: ~5s fixed per-invocation floor (process spawn, config/credential but it's slower than a raw API: ~5s fixed per-invocation floor + ~22-24s for a realistic
load) even for a trivial call, ~22-24s for a realistic structured extraction call. Cognify structured-extraction call, and every call is agentic. Cognify issues one call per
issues one such call per chunk/entity-extraction step, so a batch of even a few dozen chunks chunk/entity-extraction step, so large batches serialize into minutes. To protect the
reaches many minutes of wall time serialized. single-seat subscription, `MAX_CONCURRENCY = 3` bounds concurrent spawns.
- Every call is agentic (tool-call round trips are possible even for "just extract JSON"
prompts), and hammering the single-seat Kimi subscription with concurrent batch CLI spawns
risks rate-limiting/throttling that hasn't been (and shouldn't be) tested at scale.
**Recommendation: default Cognee's `LLM_API_BASE` to a LiteLLM-routed model (`judge`/local **Documented fallback (not the default):** if cognify throughput ever becomes a real problem,
qwen, per `ARCHITECTURE.md` §3.3's own stated fallback), not this wrapper.** This service stays route cognee's LLM to a LiteLLM model instead (`ARCHITECTURE.md` §3.3) — see the commented block
buildable/available as the optional, low-volume path (`http://cognee-llm:8011/v1`) — e.g. for in `cognee/cognee.env`. Embeddings already run on LiteLLM's `nomic-embed` regardless (embeddings
experimentation or if a future need specifically wants Kimi-subscription-backed structured can't go through the agentic CLI).
calls — but P4 should wire Cognee's default LLM to LiteLLM, not here.
## Smoke test ## Smoke test