| --- |
| title: README |
| emoji: 馃寫 |
| colorFrom: red |
| colorTo: gray |
| sdk: static |
| pinned: false |
| --- |
| |
| # Own your intelligence with Triody |
|
|
| A dedicated endpoint built around your traffic, and a model trained on your data. Both keep getting better after |
| they ship, run by a system that improves with every customer. |
|
|
| [triody.ink](https://triody.ink) 路 [Blog](https://triody.ink/blog) 路 [Console](https://app.triody.ink) 路 |
| [Talk to us](https://calendar.app.google/NE52d4hS5Y69haeLA) |
|
|
| ## What you own |
|
|
| Bring the model, a sample of real traffic, and a target. We build the endpoint around them, train the model on your |
| data, and keep improving both after they go live. |
|
|
| - **Inference built around your traffic.** Your real request mix, not a generic benchmark, decides the kernels, |
| engine, batching, quantization, and card. |
| - **A model trained on your data.** We post-train an open model on your data and your outcomes. The weights are |
| yours, and they serve on the same endpoint. |
| - **Verified before it ships.** A candidate, whether a config or a checkpoint, replaces what runs only after it |
| holds correctness and your SLO on held-out traffic. |
| - **Never finished.** Traffic drifts, models update, and new cards land. The system measures again and adapts, and |
| only verified gains ship. |
|
|
| ## One loop across the whole stack |
|
|
| The fastest setup is never a single switch. Kernels, serving engine, batching, quantization, hardware, traffic |
| shape, and the weights themselves all push on each other. |
|
|
| 1. **Find the bottlenecks.** Profile the stack on your real traffic to see where latency or throughput is lost: |
| scheduling, decoding, kernels, memory pressure, or hardware fit. |
| 2. **Try many paths.** Generate candidates across batching, decoding, quantization, engines, kernels, hardware, |
| and training recipes, and measure every one of them. |
| 3. **Ship the measured winner.** Promote the fastest verified candidate, then keep profiling production traffic as |
| load, models, and hardware change. Every solved endpoint shortens the next search. |
|
|
| We run on whatever the numbers favour. vLLM, SGLang, TensorRT-LLM and our own kernels are all candidates, across |
| NVIDIA, AMD and Ascend. |
|
|
| ## What we publish here |
|
|
| Checkpoints, deployment recipes and benchmark data behind the numbers on [our blog](https://triody.ink/blog). Every |
| number comes with its hardware, quantization, workload shape, and baseline. |
|
|
| Have a model and real traffic? Write to [kyriecai.me@gmail.com](mailto:kyriecai.me@gmail.com). |
|
|
