Repository navigation
docs: the readme leads with agents building an engine per model, workload and gpu - #49
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
3973323 to
67d1fec
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3973323241
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| **Safe.** Zero trust: every kernel is pinned by SHA-256, every buffer it | ||
| touches is declared, and nothing ships without a verdict against the | ||
| reference. The engine stays the same, so a change can only break the |
There was a problem hiding this comment.
When users load a third-party module such as the preceding Hugging Face example, SHA-256 verifies its identity but does not constrain its memory accesses. The repository's own trust-boundary documentation says the verifier proves only declaration consistency and trusts a cubin that lies about its read/write ranges (docs/manifest.md:506-509), so the claim that every touched buffer is declared can lead users to execute untrusted GPU code under a false safety assumption; qualify this as integrity checking rather than kernel sandboxing.
Useful? React with 👍 / 👎.
| ./target/release/kern run qwen3-4b --steps 320 # generate | ||
| ./target/release/kern test qwen3-4b # verdict for a change: exit 0 PASS / 1 FAIL / 2 INCONCLUSIVE | ||
| ./target/release/kern bench qwen3-4b --workload tools/profiles/quick.toml --out quick.json | ||
| ./target/release/kern server qwen3-4b --port 8000 # OpenAI-compatible server |
There was a problem hiding this comment.
In a clean source checkout, the preceding bare cargo build --release does not produce kern-serve: Cargo.toml deliberately excludes that package from default-members. Since kern server only searches for an already-built sibling or a kern-serve on PATH, this documented command fails for source builders; include cargo build --release -p kern-serve before this invocation or build both packages together.
Useful? React with 👍 / 👎.
28a12f2 to
1557521
Compare
…load and gpu The old readme stopped in August: a 3,000-line runtime claim the code has outgrown, qwen3-4b numbers, and none of the vLLM/SGLang hosting, the overnight optimization loop or the multi-GPU work. The new one opens with the loop's result (17% more requests than stock vLLM), frames each point of the models x workloads x GPUs matrix as its own manifest, and lists what agents have built on it. The named-constants reference moves into docs/manifest.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: JinYan Su <751080330@qq.com>
1557521 to
8973103
Compare
1 participant
Rewrites the README around the new positioning.
Built by agents. Built for agents. kern lets agents change the whole inference stack, fast and safely, so every model, every workload and every GPU gets a high-performance engine of its own.
docs/manifest.md.🤖 Generated with Claude Code