Runtime / Research
These are framework topics. The WordPress site itself does not implement a runtime, execute WebAssembly, use WebGPU, or run model inference.
Runtime goals
Predictable resource use, explicit compatibility, modular backends, reproducible performance, and safe failure.
Native versus browser constraints
Native hosts and browser sandboxes expose different memory, thread, storage, device, and security boundaries.
Known limitations
No backend or target is considered supported until a source, version, environment, and verification date are recorded.
CPU execution
Document vectorization, thread counts, allocator behavior, cache locality, operator coverage, and fallback behavior.
GPU execution
Document device discovery, API and driver versions, buffer alignment, precision support, kernel coverage, transfer cost, and memory limits.
Memory planning and buffer reuse
Separate artifact size, model residency, context-dependent state, intermediate buffers, host memory, and device memory. Reuse requires ownership and synchronization rules.
Model loading
Validate metadata, checksums, formats, sharding manifests, license records, and resource estimates before allocation or dispatch.
Threading and workers
Record the execution model rather than assuming concurrency. Browser workers, shared memory, native threads, and asynchronous orchestration have different constraints.
Caching and persistence
Cache keys should include source revision, transformation, format, and integrity evidence. Eviction and partial failure must be visible.
Fallback behavior
A fallback may select a different backend, precision, model, context, or explicit unsupported result. Silent semantic changes are not acceptable.
Error handling
Failures should retain typed category, source, operation, recoverability, and safe user-facing context.
Metrics and tracing
Measure initialization, load, allocation, dispatch, latency, throughput, memory, and errors with stable units and benchmark correlation.