latencyops 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- latencyops-0.1.0/LICENSE +15 -0
- latencyops-0.1.0/PKG-INFO +346 -0
- latencyops-0.1.0/README.md +336 -0
- latencyops-0.1.0/pyproject.toml +20 -0
- latencyops-0.1.0/setup.cfg +4 -0
- latencyops-0.1.0/src/latencyops/__init__.py +33 -0
- latencyops-0.1.0/src/latencyops/adapters.py +186 -0
- latencyops-0.1.0/src/latencyops/benchmark.py +64 -0
- latencyops-0.1.0/src/latencyops/benchmark_suite.py +112 -0
- latencyops-0.1.0/src/latencyops/capabilities.py +66 -0
- latencyops-0.1.0/src/latencyops/cli.py +54 -0
- latencyops-0.1.0/src/latencyops/comparison.py +52 -0
- latencyops-0.1.0/src/latencyops/config.py +71 -0
- latencyops-0.1.0/src/latencyops/controller.py +85 -0
- latencyops-0.1.0/src/latencyops/experiments.py +48 -0
- latencyops-0.1.0/src/latencyops/gateway.py +149 -0
- latencyops-0.1.0/src/latencyops/metrics.py +52 -0
- latencyops-0.1.0/src/latencyops/models.py +152 -0
- latencyops-0.1.0/src/latencyops/orchestrators.py +131 -0
- latencyops-0.1.0/src/latencyops/policy.py +142 -0
- latencyops-0.1.0/src/latencyops/router.py +58 -0
- latencyops-0.1.0/src/latencyops/scheduling.py +77 -0
- latencyops-0.1.0/src/latencyops/signals.py +35 -0
- latencyops-0.1.0/src/latencyops/telemetry.py +82 -0
- latencyops-0.1.0/src/latencyops.egg-info/PKG-INFO +346 -0
- latencyops-0.1.0/src/latencyops.egg-info/SOURCES.txt +28 -0
- latencyops-0.1.0/src/latencyops.egg-info/dependency_links.txt +1 -0
- latencyops-0.1.0/src/latencyops.egg-info/entry_points.txt +2 -0
- latencyops-0.1.0/src/latencyops.egg-info/top_level.txt +1 -0
- latencyops-0.1.0/tests/test_latencyops.py +936 -0
latencyops-0.1.0/LICENSE
ADDED
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
Apache License
|
|
2
|
+
Version 2.0, January 2004
|
|
3
|
+
http://www.apache.org/licenses/
|
|
4
|
+
|
|
5
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
6
|
+
you may not use this file except in compliance with the License.
|
|
7
|
+
You may obtain a copy of the License at
|
|
8
|
+
|
|
9
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
10
|
+
|
|
11
|
+
Unless required by applicable law or agreed to in writing, software
|
|
12
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
13
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
14
|
+
See the License for the specific language governing permissions and
|
|
15
|
+
limitations under the License.
|
|
@@ -0,0 +1,346 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: latencyops
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: Latency measurement and quality-aware inference planning toolkit
|
|
5
|
+
License-Expression: Apache-2.0
|
|
6
|
+
Requires-Python: >=3.12
|
|
7
|
+
Description-Content-Type: text/markdown
|
|
8
|
+
License-File: LICENSE
|
|
9
|
+
Dynamic: license-file
|
|
10
|
+
|
|
11
|
+
# LatencyOps
|
|
12
|
+
|
|
13
|
+
LatencyOps is a provider-neutral Python toolkit for measuring AI inference latency and selecting explainable execution policies under latency and quality constraints.
|
|
14
|
+
|
|
15
|
+
It is a lightweight policy and measurement layer that composes with OpenAI-compatible model endpoints and existing infrastructure. It does not contain model weights or replace OpenAI, LiteLLM, vLLM, SGLang, Hugging Face, or a production edge gateway.
|
|
16
|
+
|
|
17
|
+
## Why use LatencyOps?
|
|
18
|
+
|
|
19
|
+
Most inference applications send every request to one model with one fixed execution policy. LatencyOps makes the execution decision per request using:
|
|
20
|
+
|
|
21
|
+
- Deadline and optional TTFT/TPOT targets
|
|
22
|
+
- Quality floor and risk class
|
|
23
|
+
- Prompt and expected-output token counts
|
|
24
|
+
- Difficulty and context length
|
|
25
|
+
- Queue and cache pressure when runtime metrics are available
|
|
26
|
+
- Provider health and observed latency/quality
|
|
27
|
+
|
|
28
|
+
The planner returns an explainable execution plan, provider capability enforcement makes unsupported controls visible, and the benchmark layer measures TTFT, TPOT, end-to-end latency, p50, and p95.
|
|
29
|
+
|
|
30
|
+
A single planner can serve one application, a batch of any number of analyses, or many agents in a multi-agent workflow. The host application remains responsible for task decomposition, agent memory, tools, retries, and final aggregation. Detailed architecture notes are maintained separately for internal design review and are not part of the public README.
|
|
31
|
+
|
|
32
|
+
## Where LatencyOps sits
|
|
33
|
+
|
|
34
|
+
```text
|
|
35
|
+
Your application / agent workflow
|
|
36
|
+
|
|
|
37
|
+
| Python library import or HTTP request
|
|
38
|
+
v
|
|
39
|
+
+-----------------------------------------------+
|
|
40
|
+
| LatencyOps public policy + measurement layer |
|
|
41
|
+
| planner | capability enforcement | routing |
|
|
42
|
+
| TTFT | TPOT | end-to-end | content-free data |
|
|
43
|
+
+----------------------+------------------------+
|
|
44
|
+
|
|
|
45
|
+
v
|
|
46
|
+
OpenAI-compatible provider endpoint
|
|
47
|
+
OpenAI | LiteLLM | vLLM | SGLang | Hugging Face
|
|
48
|
+
|
|
|
49
|
+
v
|
|
50
|
+
model response
|
|
51
|
+
|
|
52
|
+
Optional runtime metrics from vLLM, SGLang, or
|
|
53
|
+
TensorRT-LLM feed queue/cache/health signals back
|
|
54
|
+
into the LatencyOps planner.
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
LatencyOps sits between the application or agent workflow and the model-serving endpoint. It can run in-process as a Python library or as an internal gateway; it is not the model server and it is not an agent framework.
|
|
58
|
+
|
|
59
|
+
## Core capabilities
|
|
60
|
+
|
|
61
|
+
- Request latency and quality contracts
|
|
62
|
+
- Content-free request profiles and telemetry
|
|
63
|
+
- Conservative model-tier and precision planning
|
|
64
|
+
- Long-context, cache-pressure, speculation, and early-exit policy signals
|
|
65
|
+
- Provider-neutral routing and adaptive provider selection
|
|
66
|
+
- OpenAI-compatible completion and chat adapters
|
|
67
|
+
- Streaming TTFT and TPOT measurement
|
|
68
|
+
- Capability-aware requested-versus-enforced plans
|
|
69
|
+
- Optional vLLM, SGLang, and TensorRT-LLM runtime signal normalization
|
|
70
|
+
- Static-baseline comparisons and workload benchmarking
|
|
71
|
+
- Optional quality outcome hooks and safe re-planning
|
|
72
|
+
- Local reference gateway for Python and non-Python clients
|
|
73
|
+
|
|
74
|
+
The current release is a dependency-light alpha/reference implementation suitable for development and controlled integration testing. It is not a hardened production serving platform.
|
|
75
|
+
|
|
76
|
+
See also:
|
|
77
|
+
|
|
78
|
+
- [`COMPARISON_WITH_EXISTING_TOOLS.md`](COMPARISON_WITH_EXISTING_TOOLS.md) for market comparison and community/commercial boundaries
|
|
79
|
+
- [`SECURITY.md`](SECURITY.md) for safe operation and reporting
|
|
80
|
+
- [`CONTRIBUTING.md`](CONTRIBUTING.md) for development and release verification
|
|
81
|
+
- [`DEPLOYMENT.md`](DEPLOYMENT.md) for the reference gateway deployment model
|
|
82
|
+
|
|
83
|
+
## Install and run
|
|
84
|
+
|
|
85
|
+
LatencyOps requires Python 3.12 or newer.
|
|
86
|
+
|
|
87
|
+
### From a GitHub checkout
|
|
88
|
+
|
|
89
|
+
PowerShell (Windows):
|
|
90
|
+
|
|
91
|
+
```powershell
|
|
92
|
+
python -m pip install .
|
|
93
|
+
latencyops --help
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
Ubuntu (bash):
|
|
97
|
+
|
|
98
|
+
```bash
|
|
99
|
+
python3 -m pip install .
|
|
100
|
+
latencyops --help
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
For development, use an editable install.
|
|
104
|
+
|
|
105
|
+
PowerShell (Windows):
|
|
106
|
+
|
|
107
|
+
```powershell
|
|
108
|
+
python -m pip install -e .
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
Ubuntu (bash):
|
|
112
|
+
|
|
113
|
+
```bash
|
|
114
|
+
python3 -m pip install -e .
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
The runtime uses the Python standard library. Model-serving systems and credentials remain external.
|
|
118
|
+
|
|
119
|
+
### From a wheel
|
|
120
|
+
|
|
121
|
+
After building or downloading a release artifact:
|
|
122
|
+
|
|
123
|
+
PowerShell (Windows):
|
|
124
|
+
|
|
125
|
+
```powershell
|
|
126
|
+
python -m pip install dist\latencyops-0.1.0-py3-none-any.whl
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
Ubuntu (bash):
|
|
130
|
+
|
|
131
|
+
```bash
|
|
132
|
+
python3 -m pip install dist/latencyops-0.1.0-py3-none-any.whl
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
### From PyPI
|
|
136
|
+
|
|
137
|
+
After the package is published to PyPI:
|
|
138
|
+
|
|
139
|
+
PowerShell (Windows):
|
|
140
|
+
|
|
141
|
+
```powershell
|
|
142
|
+
python -m pip install latencyops
|
|
143
|
+
```
|
|
144
|
+
|
|
145
|
+
Ubuntu (bash):
|
|
146
|
+
|
|
147
|
+
```bash
|
|
148
|
+
python3 -m pip install latencyops
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
The package is locally verified but has not yet been published to PyPI.
|
|
152
|
+
|
|
153
|
+
## Plan without a model endpoint
|
|
154
|
+
|
|
155
|
+
Create `request.json`:
|
|
156
|
+
|
|
157
|
+
```json
|
|
158
|
+
{
|
|
159
|
+
"prompt_tokens": 100,
|
|
160
|
+
"expected_output_tokens": 32,
|
|
161
|
+
"difficulty": 0.2,
|
|
162
|
+
"queue_pressure": 0.1,
|
|
163
|
+
"cache_pressure": 0.1,
|
|
164
|
+
"quality_floor": 0.9,
|
|
165
|
+
"risk_class": "low",
|
|
166
|
+
"deadline_ms": 1000
|
|
167
|
+
}
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
Run the installed planner.
|
|
171
|
+
|
|
172
|
+
PowerShell (Windows):
|
|
173
|
+
|
|
174
|
+
```powershell
|
|
175
|
+
latencyops plan --request request.json
|
|
176
|
+
```
|
|
177
|
+
|
|
178
|
+
Ubuntu (bash):
|
|
179
|
+
|
|
180
|
+
```bash
|
|
181
|
+
latencyops plan --request request.json
|
|
182
|
+
```
|
|
183
|
+
|
|
184
|
+
This returns an explainable plan without calling a model endpoint.
|
|
185
|
+
|
|
186
|
+
## Verified real model coverage
|
|
187
|
+
|
|
188
|
+
These are the real model paths explicitly verified in the current controlled test record. They are endpoint and latency checks, not a general model-quality ranking.
|
|
189
|
+
|
|
190
|
+
| Provider | Exact model ID | Route | Verified coverage | Runtime signal status |
|
|
191
|
+
|---|---|---|---|---|
|
|
192
|
+
| OpenAI | `gpt-4o-mini` | OpenAI-compatible OpenAI API | Model discovery and streaming smoke test with TTFT, TPOT, and end-to-end measurement | OpenAI API-level signals only |
|
|
193
|
+
| Qwen | `Qwen/Qwen3.6-35B-A3B-FP8` | LiteLLM → Qwen vLLM deployment | Authenticated model discovery, streaming smoke test, proactive request path, TTFT, TPOT, and end-to-end measurement | Direct vLLM queue/KV-cache metrics were not available through the public proxy; real tests use synthetic `SystemSignals` for planning |
|
|
194
|
+
|
|
195
|
+
The recorded Qwen smoke result was a successful `Hello!` response with TTFT `743.01 ms`, TPOT `8.22 ms`, and end-to-end latency `751.23 ms`. These values are workload-, region-, time-, and deployment-dependent and are not performance guarantees.
|
|
196
|
+
|
|
197
|
+
### Sample streaming comparison
|
|
198
|
+
|
|
199
|
+
The following sanitized aggregate is provided as an example reference. It was generated on 2026-09-03 using a synthetic single-sentence streaming workload, three runs per model, and no retained prompt or response content.
|
|
200
|
+
|
|
201
|
+
| Provider | Model | Runs | Success | TTFT p50 / p95 | TPOT p50 | End-to-end p50 / p95 |
|
|
202
|
+
|---|---|---:|---:|---:|---:|---:|
|
|
203
|
+
| OpenAI | `gpt-4o-mini` | 3 | 100% | 935.19 / 1634.29 ms | 7.58 ms | 939.58 / 1643.24 ms |
|
|
204
|
+
| OpenAI | `gpt-4.1-mini` | 3 | 100% | 753.22 / 945.96 ms | 8.82 ms | 760.25 / 954.65 ms |
|
|
205
|
+
| OpenAI | `gpt-5-mini` | 3 | 100% | 1859.08 / 1901.65 ms | 8.58 ms | 1867.66 / 1913.66 ms |
|
|
206
|
+
| Qwen | `Qwen/Qwen3.6-35B-A3B-FP8` | 3 | 100% | 750.39 / 809.08 ms | 6.39 ms | 758.88 / 815.68 ms |
|
|
207
|
+
|
|
208
|
+
These values are illustrative observations from one client, region, workload, and deployment window. They are not model-quality scores, service-level guarantees, or a substitute for running the workload against the reader's own account and endpoint.
|
|
209
|
+
|
|
210
|
+
## Configured comparison candidates
|
|
211
|
+
|
|
212
|
+
These IDs are configured as comparison or example candidates. A configured model ID is not evidence of a successful test; verify availability through the authenticated `/v1/models` response first.
|
|
213
|
+
|
|
214
|
+
| Provider | Model ID | Status |
|
|
215
|
+
|---|---|---|
|
|
216
|
+
| OpenAI | `gpt-4.1-mini` | Configured comparison candidate |
|
|
217
|
+
| OpenAI | `gpt-5-mini` | Configured comparison candidate |
|
|
218
|
+
| Qwen | `Qwen/Qwen3.5-9B` | Example configuration candidate |
|
|
219
|
+
| Qwen | `Qwen/Qwen3.6-35B-A3B` | Example configuration candidate |
|
|
220
|
+
|
|
221
|
+
## How users can use it
|
|
222
|
+
|
|
223
|
+
### Python application or evaluation job
|
|
224
|
+
|
|
225
|
+
Embed the planner in an existing Python service when you want direct control over the request lifecycle. Give each analysis item or agent task its own deadline, quality floor, risk class, and workload profile.
|
|
226
|
+
|
|
227
|
+
### Many analyses through one system
|
|
228
|
+
|
|
229
|
+
Use one planner or gateway for document analysis, research pipelines, support classification, batch evaluation, or other workloads with different request requirements. LatencyOps can select different plans per item instead of forcing every item through one global model policy.
|
|
230
|
+
|
|
231
|
+
### Multi-agent workflow
|
|
232
|
+
|
|
233
|
+
Use LatencyOps as a shared execution control plane for research, extraction, review, synthesis, or other agents. Each agent can have a different quality and deadline contract while the application retains responsibility for agent coordination and memory.
|
|
234
|
+
|
|
235
|
+
### Optional HTTP gateway
|
|
236
|
+
|
|
237
|
+
Use the gateway when multiple applications or non-Python clients need one internal policy and telemetry endpoint. Place it behind an authenticated TLS-capable edge proxy before controlled deployment.
|
|
238
|
+
|
|
239
|
+
## Synthetic gateway example
|
|
240
|
+
|
|
241
|
+
The example starts a local gateway with deterministic providers and no credentials.
|
|
242
|
+
|
|
243
|
+
PowerShell (Windows):
|
|
244
|
+
|
|
245
|
+
```powershell
|
|
246
|
+
$env:PYTHONPATH = "src"
|
|
247
|
+
python examples\synthetic_gateway.py
|
|
248
|
+
```
|
|
249
|
+
|
|
250
|
+
Ubuntu (bash):
|
|
251
|
+
|
|
252
|
+
```bash
|
|
253
|
+
export PYTHONPATH=src
|
|
254
|
+
python3 examples/synthetic_gateway.py
|
|
255
|
+
```
|
|
256
|
+
|
|
257
|
+
A completion can then be sent to `http://127.0.0.1:8080/v1/completions`, and measurements are available at `http://127.0.0.1:8080/metrics`.
|
|
258
|
+
|
|
259
|
+
## Optional configured gateway
|
|
260
|
+
|
|
261
|
+
Copy `latencyops.example.toml` to a private TOML file, set the environment variables named by `api_key_env`, and start the gateway.
|
|
262
|
+
|
|
263
|
+
PowerShell (Windows):
|
|
264
|
+
|
|
265
|
+
```powershell
|
|
266
|
+
latencyops gateway --config latencyops.toml
|
|
267
|
+
```
|
|
268
|
+
|
|
269
|
+
Ubuntu (bash):
|
|
270
|
+
|
|
271
|
+
```bash
|
|
272
|
+
latencyops gateway --config latencyops.toml
|
|
273
|
+
```
|
|
274
|
+
|
|
275
|
+
Clients can call `POST /v1/completions`; inspect `GET /metrics` for content-free measurements.
|
|
276
|
+
|
|
277
|
+
## Real endpoint tests
|
|
278
|
+
|
|
279
|
+
The real-endpoint probe reads an external dotenv file, prints only the endpoint, credential variable name, model IDs, and measured results, and never prints the credential. Set `LATENCYOPS_ENV_FILE` and `LATENCYOPS_RESULTS_DIR` to paths outside the repository. If unset, the examples use `~/.latencyops/.env` and `~/.latencyops/results`. Use approved credentials and synthetic or approved evaluation data.
|
|
280
|
+
|
|
281
|
+
PowerShell (Windows):
|
|
282
|
+
|
|
283
|
+
```powershell
|
|
284
|
+
$env:LATENCYOPS_ENV_FILE = "C:\path\to\private\latencyops\.env"
|
|
285
|
+
$env:LATENCYOPS_RESULTS_DIR = "C:\path\to\private\latencyops\results"
|
|
286
|
+
$env:PYTHONPATH = "src"
|
|
287
|
+
python examples\real_endpoint_test.py
|
|
288
|
+
python examples\real_endpoint_test.py --smoke --model "approved-model-id"
|
|
289
|
+
python examples\compare_real_endpoints.py
|
|
290
|
+
```
|
|
291
|
+
|
|
292
|
+
Ubuntu (bash):
|
|
293
|
+
|
|
294
|
+
```bash
|
|
295
|
+
export LATENCYOPS_ENV_FILE="/path/to/private/latencyops/.env"
|
|
296
|
+
export LATENCYOPS_RESULTS_DIR="/path/to/private/latencyops/results"
|
|
297
|
+
export PYTHONPATH=src
|
|
298
|
+
python3 examples/real_endpoint_test.py
|
|
299
|
+
python3 examples/real_endpoint_test.py --smoke --model "approved-model-id"
|
|
300
|
+
python3 examples/compare_real_endpoints.py
|
|
301
|
+
```
|
|
302
|
+
|
|
303
|
+
The comparison defaults to `gpt-4o-mini`, `gpt-4.1-mini`, `gpt-5-mini`, and the configured Qwen model. Override the OpenAI set without changing source files.
|
|
304
|
+
|
|
305
|
+
PowerShell (Windows):
|
|
306
|
+
|
|
307
|
+
```powershell
|
|
308
|
+
$env:LATENCYOPS_OPENAI_MODELS = "gpt-4o-mini,gpt-4.1-mini"
|
|
309
|
+
$env:LATENCYOPS_KEY_NAME = "QWEN_API_KEY"
|
|
310
|
+
```
|
|
311
|
+
|
|
312
|
+
Ubuntu (bash):
|
|
313
|
+
|
|
314
|
+
```bash
|
|
315
|
+
export LATENCYOPS_OPENAI_MODELS="gpt-4o-mini,gpt-4.1-mini"
|
|
316
|
+
export LATENCYOPS_KEY_NAME="QWEN_API_KEY"
|
|
317
|
+
```
|
|
318
|
+
|
|
319
|
+
The public workload runner tests eight OpenAI categories: factual, extraction, JSON, summarization, code, classification, reasoning, and safety.
|
|
320
|
+
|
|
321
|
+
## Local verification
|
|
322
|
+
|
|
323
|
+
PowerShell (Windows):
|
|
324
|
+
|
|
325
|
+
```powershell
|
|
326
|
+
python -m unittest discover -s tests -v
|
|
327
|
+
python -m compileall -q src tests examples
|
|
328
|
+
```
|
|
329
|
+
|
|
330
|
+
Ubuntu (bash):
|
|
331
|
+
|
|
332
|
+
```bash
|
|
333
|
+
python3 -m unittest discover -s tests -v
|
|
334
|
+
python3 -m compileall -q src tests examples
|
|
335
|
+
```
|
|
336
|
+
|
|
337
|
+
## Security and limitations
|
|
338
|
+
|
|
339
|
+
- Do not place API keys, customer data, proprietary prompts, or production configuration in this repository.
|
|
340
|
+
- Do not expose the reference gateway directly to an untrusted network.
|
|
341
|
+
- Use an authenticated TLS-capable edge proxy for controlled deployment.
|
|
342
|
+
- Queue and cache signals are real only when a configured metrics endpoint supplies them.
|
|
343
|
+
- Provider-specific controls are only applied when the provider advertises support.
|
|
344
|
+
- The package does not include model weights, GPU runtimes, hosted inference, durable queues, cancellation, circuit breakers, production backpressure, billing integration, or a complete quality evaluator.
|
|
345
|
+
|
|
346
|
+
See [`SECURITY.md`](SECURITY.md) and [`DEPLOYMENT.md`](DEPLOYMENT.md) before deployment.
|
|
@@ -0,0 +1,336 @@
|
|
|
1
|
+
# LatencyOps
|
|
2
|
+
|
|
3
|
+
LatencyOps is a provider-neutral Python toolkit for measuring AI inference latency and selecting explainable execution policies under latency and quality constraints.
|
|
4
|
+
|
|
5
|
+
It is a lightweight policy and measurement layer that composes with OpenAI-compatible model endpoints and existing infrastructure. It does not contain model weights or replace OpenAI, LiteLLM, vLLM, SGLang, Hugging Face, or a production edge gateway.
|
|
6
|
+
|
|
7
|
+
## Why use LatencyOps?
|
|
8
|
+
|
|
9
|
+
Most inference applications send every request to one model with one fixed execution policy. LatencyOps makes the execution decision per request using:
|
|
10
|
+
|
|
11
|
+
- Deadline and optional TTFT/TPOT targets
|
|
12
|
+
- Quality floor and risk class
|
|
13
|
+
- Prompt and expected-output token counts
|
|
14
|
+
- Difficulty and context length
|
|
15
|
+
- Queue and cache pressure when runtime metrics are available
|
|
16
|
+
- Provider health and observed latency/quality
|
|
17
|
+
|
|
18
|
+
The planner returns an explainable execution plan, provider capability enforcement makes unsupported controls visible, and the benchmark layer measures TTFT, TPOT, end-to-end latency, p50, and p95.
|
|
19
|
+
|
|
20
|
+
A single planner can serve one application, a batch of any number of analyses, or many agents in a multi-agent workflow. The host application remains responsible for task decomposition, agent memory, tools, retries, and final aggregation. Detailed architecture notes are maintained separately for internal design review and are not part of the public README.
|
|
21
|
+
|
|
22
|
+
## Where LatencyOps sits
|
|
23
|
+
|
|
24
|
+
```text
|
|
25
|
+
Your application / agent workflow
|
|
26
|
+
|
|
|
27
|
+
| Python library import or HTTP request
|
|
28
|
+
v
|
|
29
|
+
+-----------------------------------------------+
|
|
30
|
+
| LatencyOps public policy + measurement layer |
|
|
31
|
+
| planner | capability enforcement | routing |
|
|
32
|
+
| TTFT | TPOT | end-to-end | content-free data |
|
|
33
|
+
+----------------------+------------------------+
|
|
34
|
+
|
|
|
35
|
+
v
|
|
36
|
+
OpenAI-compatible provider endpoint
|
|
37
|
+
OpenAI | LiteLLM | vLLM | SGLang | Hugging Face
|
|
38
|
+
|
|
|
39
|
+
v
|
|
40
|
+
model response
|
|
41
|
+
|
|
42
|
+
Optional runtime metrics from vLLM, SGLang, or
|
|
43
|
+
TensorRT-LLM feed queue/cache/health signals back
|
|
44
|
+
into the LatencyOps planner.
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
LatencyOps sits between the application or agent workflow and the model-serving endpoint. It can run in-process as a Python library or as an internal gateway; it is not the model server and it is not an agent framework.
|
|
48
|
+
|
|
49
|
+
## Core capabilities
|
|
50
|
+
|
|
51
|
+
- Request latency and quality contracts
|
|
52
|
+
- Content-free request profiles and telemetry
|
|
53
|
+
- Conservative model-tier and precision planning
|
|
54
|
+
- Long-context, cache-pressure, speculation, and early-exit policy signals
|
|
55
|
+
- Provider-neutral routing and adaptive provider selection
|
|
56
|
+
- OpenAI-compatible completion and chat adapters
|
|
57
|
+
- Streaming TTFT and TPOT measurement
|
|
58
|
+
- Capability-aware requested-versus-enforced plans
|
|
59
|
+
- Optional vLLM, SGLang, and TensorRT-LLM runtime signal normalization
|
|
60
|
+
- Static-baseline comparisons and workload benchmarking
|
|
61
|
+
- Optional quality outcome hooks and safe re-planning
|
|
62
|
+
- Local reference gateway for Python and non-Python clients
|
|
63
|
+
|
|
64
|
+
The current release is a dependency-light alpha/reference implementation suitable for development and controlled integration testing. It is not a hardened production serving platform.
|
|
65
|
+
|
|
66
|
+
See also:
|
|
67
|
+
|
|
68
|
+
- [`COMPARISON_WITH_EXISTING_TOOLS.md`](COMPARISON_WITH_EXISTING_TOOLS.md) for market comparison and community/commercial boundaries
|
|
69
|
+
- [`SECURITY.md`](SECURITY.md) for safe operation and reporting
|
|
70
|
+
- [`CONTRIBUTING.md`](CONTRIBUTING.md) for development and release verification
|
|
71
|
+
- [`DEPLOYMENT.md`](DEPLOYMENT.md) for the reference gateway deployment model
|
|
72
|
+
|
|
73
|
+
## Install and run
|
|
74
|
+
|
|
75
|
+
LatencyOps requires Python 3.12 or newer.
|
|
76
|
+
|
|
77
|
+
### From a GitHub checkout
|
|
78
|
+
|
|
79
|
+
PowerShell (Windows):
|
|
80
|
+
|
|
81
|
+
```powershell
|
|
82
|
+
python -m pip install .
|
|
83
|
+
latencyops --help
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
Ubuntu (bash):
|
|
87
|
+
|
|
88
|
+
```bash
|
|
89
|
+
python3 -m pip install .
|
|
90
|
+
latencyops --help
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
For development, use an editable install.
|
|
94
|
+
|
|
95
|
+
PowerShell (Windows):
|
|
96
|
+
|
|
97
|
+
```powershell
|
|
98
|
+
python -m pip install -e .
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
Ubuntu (bash):
|
|
102
|
+
|
|
103
|
+
```bash
|
|
104
|
+
python3 -m pip install -e .
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
The runtime uses the Python standard library. Model-serving systems and credentials remain external.
|
|
108
|
+
|
|
109
|
+
### From a wheel
|
|
110
|
+
|
|
111
|
+
After building or downloading a release artifact:
|
|
112
|
+
|
|
113
|
+
PowerShell (Windows):
|
|
114
|
+
|
|
115
|
+
```powershell
|
|
116
|
+
python -m pip install dist\latencyops-0.1.0-py3-none-any.whl
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
Ubuntu (bash):
|
|
120
|
+
|
|
121
|
+
```bash
|
|
122
|
+
python3 -m pip install dist/latencyops-0.1.0-py3-none-any.whl
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
### From PyPI
|
|
126
|
+
|
|
127
|
+
After the package is published to PyPI:
|
|
128
|
+
|
|
129
|
+
PowerShell (Windows):
|
|
130
|
+
|
|
131
|
+
```powershell
|
|
132
|
+
python -m pip install latencyops
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
Ubuntu (bash):
|
|
136
|
+
|
|
137
|
+
```bash
|
|
138
|
+
python3 -m pip install latencyops
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
The package is locally verified but has not yet been published to PyPI.
|
|
142
|
+
|
|
143
|
+
## Plan without a model endpoint
|
|
144
|
+
|
|
145
|
+
Create `request.json`:
|
|
146
|
+
|
|
147
|
+
```json
|
|
148
|
+
{
|
|
149
|
+
"prompt_tokens": 100,
|
|
150
|
+
"expected_output_tokens": 32,
|
|
151
|
+
"difficulty": 0.2,
|
|
152
|
+
"queue_pressure": 0.1,
|
|
153
|
+
"cache_pressure": 0.1,
|
|
154
|
+
"quality_floor": 0.9,
|
|
155
|
+
"risk_class": "low",
|
|
156
|
+
"deadline_ms": 1000
|
|
157
|
+
}
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
Run the installed planner.
|
|
161
|
+
|
|
162
|
+
PowerShell (Windows):
|
|
163
|
+
|
|
164
|
+
```powershell
|
|
165
|
+
latencyops plan --request request.json
|
|
166
|
+
```
|
|
167
|
+
|
|
168
|
+
Ubuntu (bash):
|
|
169
|
+
|
|
170
|
+
```bash
|
|
171
|
+
latencyops plan --request request.json
|
|
172
|
+
```
|
|
173
|
+
|
|
174
|
+
This returns an explainable plan without calling a model endpoint.
|
|
175
|
+
|
|
176
|
+
## Verified real model coverage
|
|
177
|
+
|
|
178
|
+
These are the real model paths explicitly verified in the current controlled test record. They are endpoint and latency checks, not a general model-quality ranking.
|
|
179
|
+
|
|
180
|
+
| Provider | Exact model ID | Route | Verified coverage | Runtime signal status |
|
|
181
|
+
|---|---|---|---|---|
|
|
182
|
+
| OpenAI | `gpt-4o-mini` | OpenAI-compatible OpenAI API | Model discovery and streaming smoke test with TTFT, TPOT, and end-to-end measurement | OpenAI API-level signals only |
|
|
183
|
+
| Qwen | `Qwen/Qwen3.6-35B-A3B-FP8` | LiteLLM → Qwen vLLM deployment | Authenticated model discovery, streaming smoke test, proactive request path, TTFT, TPOT, and end-to-end measurement | Direct vLLM queue/KV-cache metrics were not available through the public proxy; real tests use synthetic `SystemSignals` for planning |
|
|
184
|
+
|
|
185
|
+
The recorded Qwen smoke result was a successful `Hello!` response with TTFT `743.01 ms`, TPOT `8.22 ms`, and end-to-end latency `751.23 ms`. These values are workload-, region-, time-, and deployment-dependent and are not performance guarantees.
|
|
186
|
+
|
|
187
|
+
### Sample streaming comparison
|
|
188
|
+
|
|
189
|
+
The following sanitized aggregate is provided as an example reference. It was generated on 2026-09-03 using a synthetic single-sentence streaming workload, three runs per model, and no retained prompt or response content.
|
|
190
|
+
|
|
191
|
+
| Provider | Model | Runs | Success | TTFT p50 / p95 | TPOT p50 | End-to-end p50 / p95 |
|
|
192
|
+
|---|---|---:|---:|---:|---:|---:|
|
|
193
|
+
| OpenAI | `gpt-4o-mini` | 3 | 100% | 935.19 / 1634.29 ms | 7.58 ms | 939.58 / 1643.24 ms |
|
|
194
|
+
| OpenAI | `gpt-4.1-mini` | 3 | 100% | 753.22 / 945.96 ms | 8.82 ms | 760.25 / 954.65 ms |
|
|
195
|
+
| OpenAI | `gpt-5-mini` | 3 | 100% | 1859.08 / 1901.65 ms | 8.58 ms | 1867.66 / 1913.66 ms |
|
|
196
|
+
| Qwen | `Qwen/Qwen3.6-35B-A3B-FP8` | 3 | 100% | 750.39 / 809.08 ms | 6.39 ms | 758.88 / 815.68 ms |
|
|
197
|
+
|
|
198
|
+
These values are illustrative observations from one client, region, workload, and deployment window. They are not model-quality scores, service-level guarantees, or a substitute for running the workload against the reader's own account and endpoint.
|
|
199
|
+
|
|
200
|
+
## Configured comparison candidates
|
|
201
|
+
|
|
202
|
+
These IDs are configured as comparison or example candidates. A configured model ID is not evidence of a successful test; verify availability through the authenticated `/v1/models` response first.
|
|
203
|
+
|
|
204
|
+
| Provider | Model ID | Status |
|
|
205
|
+
|---|---|---|
|
|
206
|
+
| OpenAI | `gpt-4.1-mini` | Configured comparison candidate |
|
|
207
|
+
| OpenAI | `gpt-5-mini` | Configured comparison candidate |
|
|
208
|
+
| Qwen | `Qwen/Qwen3.5-9B` | Example configuration candidate |
|
|
209
|
+
| Qwen | `Qwen/Qwen3.6-35B-A3B` | Example configuration candidate |
|
|
210
|
+
|
|
211
|
+
## How users can use it
|
|
212
|
+
|
|
213
|
+
### Python application or evaluation job
|
|
214
|
+
|
|
215
|
+
Embed the planner in an existing Python service when you want direct control over the request lifecycle. Give each analysis item or agent task its own deadline, quality floor, risk class, and workload profile.
|
|
216
|
+
|
|
217
|
+
### Many analyses through one system
|
|
218
|
+
|
|
219
|
+
Use one planner or gateway for document analysis, research pipelines, support classification, batch evaluation, or other workloads with different request requirements. LatencyOps can select different plans per item instead of forcing every item through one global model policy.
|
|
220
|
+
|
|
221
|
+
### Multi-agent workflow
|
|
222
|
+
|
|
223
|
+
Use LatencyOps as a shared execution control plane for research, extraction, review, synthesis, or other agents. Each agent can have a different quality and deadline contract while the application retains responsibility for agent coordination and memory.
|
|
224
|
+
|
|
225
|
+
### Optional HTTP gateway
|
|
226
|
+
|
|
227
|
+
Use the gateway when multiple applications or non-Python clients need one internal policy and telemetry endpoint. Place it behind an authenticated TLS-capable edge proxy before controlled deployment.
|
|
228
|
+
|
|
229
|
+
## Synthetic gateway example
|
|
230
|
+
|
|
231
|
+
The example starts a local gateway with deterministic providers and no credentials.
|
|
232
|
+
|
|
233
|
+
PowerShell (Windows):
|
|
234
|
+
|
|
235
|
+
```powershell
|
|
236
|
+
$env:PYTHONPATH = "src"
|
|
237
|
+
python examples\synthetic_gateway.py
|
|
238
|
+
```
|
|
239
|
+
|
|
240
|
+
Ubuntu (bash):
|
|
241
|
+
|
|
242
|
+
```bash
|
|
243
|
+
export PYTHONPATH=src
|
|
244
|
+
python3 examples/synthetic_gateway.py
|
|
245
|
+
```
|
|
246
|
+
|
|
247
|
+
A completion can then be sent to `http://127.0.0.1:8080/v1/completions`, and measurements are available at `http://127.0.0.1:8080/metrics`.
|
|
248
|
+
|
|
249
|
+
## Optional configured gateway
|
|
250
|
+
|
|
251
|
+
Copy `latencyops.example.toml` to a private TOML file, set the environment variables named by `api_key_env`, and start the gateway.
|
|
252
|
+
|
|
253
|
+
PowerShell (Windows):
|
|
254
|
+
|
|
255
|
+
```powershell
|
|
256
|
+
latencyops gateway --config latencyops.toml
|
|
257
|
+
```
|
|
258
|
+
|
|
259
|
+
Ubuntu (bash):
|
|
260
|
+
|
|
261
|
+
```bash
|
|
262
|
+
latencyops gateway --config latencyops.toml
|
|
263
|
+
```
|
|
264
|
+
|
|
265
|
+
Clients can call `POST /v1/completions`; inspect `GET /metrics` for content-free measurements.
|
|
266
|
+
|
|
267
|
+
## Real endpoint tests
|
|
268
|
+
|
|
269
|
+
The real-endpoint probe reads an external dotenv file, prints only the endpoint, credential variable name, model IDs, and measured results, and never prints the credential. Set `LATENCYOPS_ENV_FILE` and `LATENCYOPS_RESULTS_DIR` to paths outside the repository. If unset, the examples use `~/.latencyops/.env` and `~/.latencyops/results`. Use approved credentials and synthetic or approved evaluation data.
|
|
270
|
+
|
|
271
|
+
PowerShell (Windows):
|
|
272
|
+
|
|
273
|
+
```powershell
|
|
274
|
+
$env:LATENCYOPS_ENV_FILE = "C:\path\to\private\latencyops\.env"
|
|
275
|
+
$env:LATENCYOPS_RESULTS_DIR = "C:\path\to\private\latencyops\results"
|
|
276
|
+
$env:PYTHONPATH = "src"
|
|
277
|
+
python examples\real_endpoint_test.py
|
|
278
|
+
python examples\real_endpoint_test.py --smoke --model "approved-model-id"
|
|
279
|
+
python examples\compare_real_endpoints.py
|
|
280
|
+
```
|
|
281
|
+
|
|
282
|
+
Ubuntu (bash):
|
|
283
|
+
|
|
284
|
+
```bash
|
|
285
|
+
export LATENCYOPS_ENV_FILE="/path/to/private/latencyops/.env"
|
|
286
|
+
export LATENCYOPS_RESULTS_DIR="/path/to/private/latencyops/results"
|
|
287
|
+
export PYTHONPATH=src
|
|
288
|
+
python3 examples/real_endpoint_test.py
|
|
289
|
+
python3 examples/real_endpoint_test.py --smoke --model "approved-model-id"
|
|
290
|
+
python3 examples/compare_real_endpoints.py
|
|
291
|
+
```
|
|
292
|
+
|
|
293
|
+
The comparison defaults to `gpt-4o-mini`, `gpt-4.1-mini`, `gpt-5-mini`, and the configured Qwen model. Override the OpenAI set without changing source files.
|
|
294
|
+
|
|
295
|
+
PowerShell (Windows):
|
|
296
|
+
|
|
297
|
+
```powershell
|
|
298
|
+
$env:LATENCYOPS_OPENAI_MODELS = "gpt-4o-mini,gpt-4.1-mini"
|
|
299
|
+
$env:LATENCYOPS_KEY_NAME = "QWEN_API_KEY"
|
|
300
|
+
```
|
|
301
|
+
|
|
302
|
+
Ubuntu (bash):
|
|
303
|
+
|
|
304
|
+
```bash
|
|
305
|
+
export LATENCYOPS_OPENAI_MODELS="gpt-4o-mini,gpt-4.1-mini"
|
|
306
|
+
export LATENCYOPS_KEY_NAME="QWEN_API_KEY"
|
|
307
|
+
```
|
|
308
|
+
|
|
309
|
+
The public workload runner tests eight OpenAI categories: factual, extraction, JSON, summarization, code, classification, reasoning, and safety.
|
|
310
|
+
|
|
311
|
+
## Local verification
|
|
312
|
+
|
|
313
|
+
PowerShell (Windows):
|
|
314
|
+
|
|
315
|
+
```powershell
|
|
316
|
+
python -m unittest discover -s tests -v
|
|
317
|
+
python -m compileall -q src tests examples
|
|
318
|
+
```
|
|
319
|
+
|
|
320
|
+
Ubuntu (bash):
|
|
321
|
+
|
|
322
|
+
```bash
|
|
323
|
+
python3 -m unittest discover -s tests -v
|
|
324
|
+
python3 -m compileall -q src tests examples
|
|
325
|
+
```
|
|
326
|
+
|
|
327
|
+
## Security and limitations
|
|
328
|
+
|
|
329
|
+
- Do not place API keys, customer data, proprietary prompts, or production configuration in this repository.
|
|
330
|
+
- Do not expose the reference gateway directly to an untrusted network.
|
|
331
|
+
- Use an authenticated TLS-capable edge proxy for controlled deployment.
|
|
332
|
+
- Queue and cache signals are real only when a configured metrics endpoint supplies them.
|
|
333
|
+
- Provider-specific controls are only applied when the provider advertises support.
|
|
334
|
+
- The package does not include model weights, GPU runtimes, hosted inference, durable queues, cancellation, circuit breakers, production backpressure, billing integration, or a complete quality evaluator.
|
|
335
|
+
|
|
336
|
+
See [`SECURITY.md`](SECURITY.md) and [`DEPLOYMENT.md`](DEPLOYMENT.md) before deployment.
|