@camstack/types 1.2.315 → 1.2.317
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.
- package/dist/addon.js +5 -1
- package/dist/addon.mjs +5 -1
- package/dist/capabilities/composer.cap.d.ts +1 -1
- package/dist/capabilities/core-blocks.cap.d.ts +8 -8
- package/dist/capabilities/pipeline-executor.cap.d.ts +73 -0
- package/dist/capabilities/pipeline-orchestrator.cap.d.ts +460 -0
- package/dist/client.js +3 -0
- package/dist/client.mjs +3 -0
- package/dist/composition/composition-report.d.ts +3 -3
- package/dist/generated/addon-api.d.ts +21 -0
- package/dist/generated/cap-input-defaults.d.ts +1 -1
- package/dist/generated/method-access-map.d.ts +1 -1
- package/dist/generated/method-device-selectors.d.ts +2 -2
- package/dist/generated/system-proxy.d.ts +2 -2
- package/dist/index.d.ts +2 -1
- package/dist/index.js +1186 -48
- package/dist/index.mjs +1154 -49
- package/dist/pipeline/best-settings/demand.d.ts +78 -0
- package/dist/pipeline/best-settings/detector-performance.d.ts +34 -0
- package/dist/pipeline/best-settings/hardware-class.d.ts +40 -0
- package/dist/pipeline/best-settings/index.d.ts +10 -0
- package/dist/pipeline/best-settings/plan-schemas.d.ts +859 -0
- package/dist/pipeline/best-settings/recommend.d.ts +54 -0
- package/dist/pipeline/model-bound-settings.d.ts +7 -0
- package/dist/types/models.d.ts +45 -0
- package/package.json +1 -1
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Detection demand per inference device, for the Best settings recommender
|
|
3
|
+
* (D745). Pure.
|
|
4
|
+
*
|
|
5
|
+
* Demand is inferences per second a device must sustain:
|
|
6
|
+
*
|
|
7
|
+
* - a camera PINNED to a device charges its full rate to that device;
|
|
8
|
+
* - an ALWAYS-ON camera charges its rate to its standing node, split over
|
|
9
|
+
* that node's eligible devices by balancer weight (the device tier rotates
|
|
10
|
+
* ties, so the weight share is the long-run split);
|
|
11
|
+
* - ON-MOTION cameras are placed per session anywhere in the cluster, so
|
|
12
|
+
* they are charged by how many sessions a device has really carried at
|
|
13
|
+
* once: the observed 24 h peak of attached sessions on that device, minus
|
|
14
|
+
* the always-on cameras it already counts, filled with the highest
|
|
15
|
+
* on-motion rates. A device observed for less than 24 h (the hub
|
|
16
|
+
* restarted) falls back to a fixed estimate — a quarter of the on-motion
|
|
17
|
+
* cameras, at least two, spread evenly over the nodes and by weight over a
|
|
18
|
+
* node's devices — and the plan says so.
|
|
19
|
+
*
|
|
20
|
+
* Every device must also fit the single fastest camera that can land on it:
|
|
21
|
+
* one session cannot be split across devices.
|
|
22
|
+
*/
|
|
23
|
+
import type { DeviceDemand } from './plan-schemas.js';
|
|
24
|
+
/** How a camera's detection runs. `disabled` cameras charge nothing. */
|
|
25
|
+
export type BestSettingsDetectionMode = 'always-on' | 'on-motion' | 'disabled';
|
|
26
|
+
/** One camera's detection load. */
|
|
27
|
+
export interface BestSettingsCameraLoad {
|
|
28
|
+
readonly deviceId: number;
|
|
29
|
+
readonly mode: BestSettingsDetectionMode;
|
|
30
|
+
/** Detection frames per second while a session runs. */
|
|
31
|
+
readonly fps: number;
|
|
32
|
+
/** False when only the camera's own (onboard) detector runs — no pipeline root. */
|
|
33
|
+
readonly runsPipelineRoot: boolean;
|
|
34
|
+
/** The node an always-on camera stands on; null when not placed (on-motion). */
|
|
35
|
+
readonly standingNodeId: string | null;
|
|
36
|
+
/** An operator pin of this camera to one `(node, device)`. */
|
|
37
|
+
readonly devicePin: {
|
|
38
|
+
readonly nodeId: string;
|
|
39
|
+
readonly deviceKey: string;
|
|
40
|
+
} | null;
|
|
41
|
+
}
|
|
42
|
+
/** A device the balancer may place a session on. */
|
|
43
|
+
export interface BestSettingsEligibleDevice {
|
|
44
|
+
readonly nodeId: string;
|
|
45
|
+
readonly deviceKey: string;
|
|
46
|
+
readonly weight: number;
|
|
47
|
+
}
|
|
48
|
+
/** The observed peak of concurrent sessions on one device. */
|
|
49
|
+
export interface ObservedDevicePeak {
|
|
50
|
+
readonly nodeId: string;
|
|
51
|
+
/** `''` = the node's sessions as a whole (a single-device node reports no per-device rows). */
|
|
52
|
+
readonly deviceKey: string;
|
|
53
|
+
/** Most sessions attached at once in the window. */
|
|
54
|
+
readonly peakSessions: number;
|
|
55
|
+
/** How long the device has been observed (ms) — the window is complete at 24 h. */
|
|
56
|
+
readonly observedForMs: number;
|
|
57
|
+
}
|
|
58
|
+
/** The on-motion load model's knobs. */
|
|
59
|
+
export interface DemandOptions {
|
|
60
|
+
/** Share of on-motion cameras assumed concurrent when there is no full observation. */
|
|
61
|
+
readonly onMotionConcurrency: number;
|
|
62
|
+
/** Minimum concurrent on-motion sessions assumed (capped at the camera count). */
|
|
63
|
+
readonly onMotionMinConcurrent: number;
|
|
64
|
+
}
|
|
65
|
+
export declare const DEFAULT_DEMAND_OPTIONS: DemandOptions;
|
|
66
|
+
/** A full observation window. */
|
|
67
|
+
export declare const OBSERVATION_WINDOW_MS: number;
|
|
68
|
+
/** Concurrent on-motion sessions assumed cluster-wide without an observation. */
|
|
69
|
+
export declare function estimatedConcurrentSessions(cameraCount: number, options: DemandOptions): number;
|
|
70
|
+
/**
|
|
71
|
+
* Demand on every eligible device of the cluster.
|
|
72
|
+
*/
|
|
73
|
+
export declare function estimateDeviceDemand(input: {
|
|
74
|
+
readonly cameras: readonly BestSettingsCameraLoad[];
|
|
75
|
+
readonly eligible: readonly BestSettingsEligibleDevice[];
|
|
76
|
+
readonly peaks: readonly ObservedDevicePeak[];
|
|
77
|
+
readonly options?: DemandOptions;
|
|
78
|
+
}): readonly DeviceDemand[];
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Measured YOLOv9 detector latency per hardware class × accelerator, and the
|
|
3
|
+
* person accuracy each model reaches at its shipped floor — the data the Best
|
|
4
|
+
* settings recommender picks from (D745).
|
|
5
|
+
*
|
|
6
|
+
* Transcribed from `docs/benchmarks/detector-latency.json` (latency) and
|
|
7
|
+
* `docs/benchmarks/model-floors.json` (person precision / recall at the
|
|
8
|
+
* shipped floor). `__tests__/detector-performance.spec.ts` holds both tables
|
|
9
|
+
* equal to those files, so a re-measurement replaces the JSON and this file
|
|
10
|
+
* together. Only the YOLOv9 t/s/m family is here: the cluster runs ONE family
|
|
11
|
+
* (YOLOv9 — the one that runs well on every accelerator class measured), and
|
|
12
|
+
* tier c is not offered (a few recall points for 25–50 % more latency).
|
|
13
|
+
*/
|
|
14
|
+
import type { AcceleratorKind, HardwareClassId } from './plan-schemas.js';
|
|
15
|
+
/** One measured (or derived) latency cell. */
|
|
16
|
+
export interface DetectorLatencyCell {
|
|
17
|
+
/** Single-request median latency. */
|
|
18
|
+
readonly p50Ms: number;
|
|
19
|
+
/** Throughput ceiling of one accelerator running only this model. */
|
|
20
|
+
readonly fps: number;
|
|
21
|
+
/** False for a cell derived from another column (scaled), not measured. */
|
|
22
|
+
readonly measured: boolean;
|
|
23
|
+
}
|
|
24
|
+
/** `modelId → cell` for one (hardware class, accelerator) column. */
|
|
25
|
+
export type DetectorLatencyColumn = Readonly<Record<string, DetectorLatencyCell>>;
|
|
26
|
+
/** The latency table: hardware class → accelerator → column. */
|
|
27
|
+
export type DetectorPerfTable = Readonly<Partial<Record<HardwareClassId, Readonly<Partial<Record<AcceleratorKind, DetectorLatencyColumn>>>>>>;
|
|
28
|
+
/** Person precision / recall of one model at its shipped person floor. */
|
|
29
|
+
export interface DetectorAccuracy {
|
|
30
|
+
readonly personPrecision: number;
|
|
31
|
+
readonly personRecall: number;
|
|
32
|
+
}
|
|
33
|
+
export declare const DETECTOR_PERF: DetectorPerfTable;
|
|
34
|
+
export declare const DETECTOR_ACCURACY: Readonly<Record<string, DetectorAccuracy>>;
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Static hardware classification for the Best settings recommender (D745).
|
|
3
|
+
*
|
|
4
|
+
* A node is classified from the facts its platform probe already reports —
|
|
5
|
+
* `cpuModel`, `arch`, `gpu`, `npu` — never from a benchmark. The class picks a
|
|
6
|
+
* column of the measured latency table (`detector-performance.ts`); a node
|
|
7
|
+
* whose CPU matches no measured class is `unknown` and the recommender leaves
|
|
8
|
+
* it alone, saying so.
|
|
9
|
+
*
|
|
10
|
+
* `cpuModel` is the host's CPU string even inside Docker (`os.cpus()`), which
|
|
11
|
+
* is why it is the discriminator: "Intel(R) Core(TM) Ultra 7 265K",
|
|
12
|
+
* "Intel(R) N100", "Apple M2", "Apple M3 Pro".
|
|
13
|
+
*/
|
|
14
|
+
import type { HardwareInfo } from '../../interfaces/platform.js';
|
|
15
|
+
import type { AcceleratorKind, HardwareClassId } from './plan-schemas.js';
|
|
16
|
+
/** Apple silicon generation and variant, parsed from `cpuModel`. */
|
|
17
|
+
export interface AppleChip {
|
|
18
|
+
readonly generation: number;
|
|
19
|
+
readonly variant: 'base' | 'pro' | 'max' | 'ultra';
|
|
20
|
+
}
|
|
21
|
+
/** How a node was classified. */
|
|
22
|
+
export interface HardwareClassification {
|
|
23
|
+
readonly hardwareClass: HardwareClassId;
|
|
24
|
+
/** The CPU string the class was read from, for the plan's reasons. */
|
|
25
|
+
readonly cpuModel: string;
|
|
26
|
+
readonly apple?: AppleChip;
|
|
27
|
+
}
|
|
28
|
+
/**
|
|
29
|
+
* Classify a node. Apple base chips (M1–M4) map to the measured M2 column, the
|
|
30
|
+
* Pro/Max/Ultra chips to the measured M3 Pro column — the M2 was measured at
|
|
31
|
+
* 1.0–1.2× the M3 Pro on the Neural Engine, so the generation inside a variant
|
|
32
|
+
* matters less than the column's own error.
|
|
33
|
+
*/
|
|
34
|
+
export declare function classifyInferenceHardware(hw: HardwareInfo): HardwareClassification;
|
|
35
|
+
/**
|
|
36
|
+
* The accelerator kind of one of a node's device keys (`openvino:npu`,
|
|
37
|
+
* `openvino:gpu`, `coreml:all`, `edgetpu:usb`, `cpu`, `onnx:cpu`, …). `null`
|
|
38
|
+
* for a key this table has no column for.
|
|
39
|
+
*/
|
|
40
|
+
export declare function acceleratorKindOf(deviceKey: string, hw: HardwareInfo): AcceleratorKind | null;
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Best settings (D745): the static-hardware × measured-latency × demand
|
|
3
|
+
* recommender of ONE detector family for the whole cluster, and the shapes of
|
|
4
|
+
* its plan. See `recommend.ts`.
|
|
5
|
+
*/
|
|
6
|
+
export * from './hardware-class.js';
|
|
7
|
+
export * from './detector-performance.js';
|
|
8
|
+
export * from './demand.js';
|
|
9
|
+
export * from './recommend.js';
|
|
10
|
+
export * from './plan-schemas.js';
|