Commit Graph
853 Commits
Author SHA1 Message Date
tzhouam f04fdf79da Track CPU talker controls and mobile speech-head profiles 2026-09-24 08:01:05 +08:00
tzhouam d71d39f656 Audit mobile speech heads and S25 VLA latent impact 2026-09-24 07:56:17 +08:00
tzhouam 1949c31f80 Advance Qualcomm TTS and InternVLA component qualification 2026-09-24 07:32:21 +08:00
tzhouam ea373e3cbf Audit X Elite CPU vocoder and isolate TFLite conversion parity 2026-09-24 07:16:15 +08:00
tzhouam e4a4477929 Update device-model matrix with Qualcomm TTS component evidence 2026-09-24 07:04:24 +08:00
tzhouam 152d67ab86 Audit Qualcomm Qwen3-TTS vocoder parity and profile 2026-09-24 06:48:14 +08:00
tzhouam bd39e903e1 Profile Spark attention across Qualcomm edge devices 2026-09-24 06:11:15 +08:00
tzhouam c5f47b22fd Profile repeated Radeon MiniCPM-o requests and record memory regression 2026-09-24 03:09:21 +08:00
tzhouam 5dd5d70671 Profile native Windows Radeon InternVLA policy stage 2026-09-24 02:24:16 +08:00
tzhouam 752357d318 Profile native Windows CPU InternVLA through Omni 2026-09-24 02:05:26 +08:00
tzhouam 48646da78e Add admitted InternVLA policy stages and update device matrix 2026-09-24 01:42:41 +08:00
tzhouam 9df5ac8836 Run InternVLA synthetic policy with Radeon Cosmos handoff 2026-09-24 01:12:27 +08:00
tzhouam b796c787ec Profile InternVLA Cosmos encoder on Radeon 890M and update matrix 2026-09-24 00:51:17 +08:00
tzhouam e6ea35ca12 Qualify scoped WSL CPU Qwen3-TTS Omni complete requests 2026-09-24 00:41:14 +08:00
tzhouam 10ae2818c7 Profile MiniCPM-o GGUF Omni complete path on WSL CPU 2026-09-24 00:21:11 +08:00
tzhouam fa5aadca6f Record MiniCPM-o GGUF Omni desktop qualification depth 2026-09-23 23:02:10 +08:00
tzhouam 13cc723c71 Qualify scoped MiniCPM-o Radeon hybrid path 2026-09-23 22:43:20 +08:00
tzhouam 445ca92ef1 Record MiniCPM-o CPU GGUF complete-path evidence 2026-09-23 22:22:54 +08:00
tzhouam bb8735effc Add native Windows CPU Qwen TTS Omni stage and profile evidence 2026-09-23 21:18:21 +08:00
tzhouam 8569995591 Add bounded Omni Qwen3-TTS CPU Radeon whole-session stage 2026-09-23 20:52:43 +08:00
tzhouam 34beb7f01e Add bounded Omni llama.cpp Spark text stage for Windows CPU and Radeon 2026-09-23 20:30:28 +08:00
tzhouam 4fee1dbe39 Profile Qwen3-TTS hybrid Radeon and CPU route 2026-09-23 19:59:04 +08:00
tzhouam 54c086acae Record native Windows CPU Qwen3-TTS scoped E2E evidence 2026-09-23 19:19:13 +08:00
tzhouam 03d6cb9a93 Qualify standalone Spark text on Windows CPU and Radeon 890M 2026-09-23 18:57:41 +08:00
tzhouam 34295f3eb3 Qualify Spark output-head component on AMD NPU and update E2E matrix 2026-09-23 18:32:13 +08:00
tzhouam 10221f0665 Qualify scoped MiniCPM-o image and audio paths on WSL CPU 2026-09-23 17:44:02 +08:00
tzhouam b29a6ca99f Document Windows MiniCPM-o image and audio end-to-end runs 2026-09-23 17:29:13 +08:00
tzhouam a8fdb1babf Validate MiniCPM-o audio input to speech on WSL GPU 2026-09-23 17:09:37 +08:00
tzhouam 0d00ba4701 Validate MiniCPM-o image to speech on WSL GPU 2026-09-23 17:03:31 +08:00
tzhouam 8a4559c46c Validate MiniCPM-o speech pipeline on native Windows GPU 2026-09-23 16:54:17 +08:00
tzhouam 2f5d0edcf7 Qualify scoped MiniCPM-o CPU speech and Windows InternVLA policy paths 2026-09-23 16:21:28 +08:00
tzhouam c0deaa76ba Repair MiniCPM-o and InternVLA scoped E2E paths 2026-09-23 15:15:07 +08:00
tzhouam b039b6a5bd Enable scoped Qwen3.8 Omni inference and CPU TTS compatibility 2026-09-23 10:01:21 +08:00
tzhouam 75b65f859b Add local E2E profiling evidence and support roadmap 2026-09-22 19:25:02 +08:00
tzhouam ab2f2a3d65 Audit all mobile and PC model pairings with archived evidence 2026-09-22 13:54:34 +08:00
tzhouam 1887d8294b Present support as mobile and PC by model matrix 2026-09-22 13:31:08 +08:00
tzhouam 5c75d5bb0a Document support as model and PC configuration pairings 2026-09-22 13:20:50 +08:00
tzhouam 723c550209 Integrate portable edge graph backends with Omni runtime
Extract versioned stage contracts, model shared CPU/iGPU/NPU memory constraints, and add explicit graph routes, reservations, output acknowledgements, and worker retirement. Fix native Windows shared-buffer lifetime and host paths. Document qualified hardware paths and remaining rollout gates.
2026-09-22 13:12:33 +08:00
tzhouamandClaude Fable 5.1 33de5d8629 Merge vLLM-Omni v0.29.0rc1 into edge-infer/omni-0.29.0
The pair for vLLM v0.29.0: rc1's docs pin vllm==0.29.0 and a static scan of
rc1's vllm.* imports against the v0.29.0 tree finds nothing missing, while
our 0.28-based tree needs seven modules v0.29.0 no longer has
(vllm.inputs.preprocess, entrypoints.launcher, openai.cli_args,
openai.engine.protocol, serve.utils.server_utils, layers.batch_invariant,
models.hunyuan_v1).

Ten files conflicted. Upstream's structure is the base everywhere; the
fork's features are re-attached to it:
- deploy_profile / apply_deploy_profile run before rc1's resolve_omni_config
  pops deploy_config (async_omni_engine, cli/serve); the deploy-profile
  selector and the resolve_model_config_path chain it needs stay in
  entrypoints/utils.py; stage_overrides takes rc1's dict type.
- config_factory keeps the lazy diffusion output-type import; the diffusion
  registry import in rc1's new config/resolver.py is made lazy for the same
  WP6 reason (TTS path must not load diffusion).
- requirements: our core/media split kept; rc1's transformers>=5.13 floor
  and kernels==0.16.1 applied in core.txt / media.txt.
- TTS: rc1's split_granularity and bounded seed plus our output_mode=
  codec_tokens, _SessionInbox cancel handling and codec DELTA accumulation;
  our private _conditioning_cache_salt is superseded by rc1's public
  tts_adapters/base.py::conditioning_cache_salt.
- stage_runtime: rc1's single ExitStack G2 path (lock released before READY)
  replaces our two-path block, with the four worker_phase names the init
  profiler consumes still emitted; _cpu_placed / host admission kept.

Not yet run against vLLM 0.29.0: the tests listed in the W6 record.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-18 09:57:20 +08:00
tzhouamandClaude Fable 5.1 4e3e8a1ebc [edge-infer] WIP snapshot: uncommitted M0/W1/W4/W5 edge work as of 2026-09-18
Verbatim copy of the edge/omni-edge working tree (tracked diffs + untracked
edge/local, tests/edge/local, docs/edge, pipeline files). Taken so that
vLLM-Omni v0.29.0rc1 can be merged on a branch without touching the
user's working tree. logs_edge/ and benchmark .npy outputs excluded.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-18 09:47:29 +08:00
tzhouamandClaude Opus 5 3834de3105 Rename the project to edge-infer, and complete the packaging audit
Renamed from vllm-embedding: nothing here is about embeddings, and the name had
come from the parent working directory. edge-infer says what it does. The
GitHub repository is renamed to match; nothing had been pushed yet.

The audit found the packaging was incomplete in two ways.

Scripts: 56 of them produced results that are published in this repo but were
not included, so the numbers could be read and not checked. Added under
benchmarks/edge_harness/experiments/ (one-off drivers: the AI Hub on-device
runs, the 4-bit GEMM microbenchmark, fidelity and parity checks, checkpoint
build and round-trip, activation capture, and the load generator used to prove
the contention guard actually refuses) and benchmarks/edge_harness/runs/ (the
24 shell drivers behind published grids). Both directories carry a README
saying plainly that they are a record of what was run rather than a supported
interface -- most hardcode absolute paths from the machine they ran on. The
supported entry points remain the tools one level up.

One broken relative link fixed (comparison.md is under docs/engines/, not
docs/analysis/). All other links and every script reference in the docs now
resolve inside the repo.

Secret scan: the token in ~/.qai_hub/client.ini is absent from the worktree and
from all 61 commits. Worth noting that an earlier version of my own check
reported a false positive, because `grep -rl ... | head` takes its exit status
from head, which always succeeds -- the same class of mistake as the measurement
errors this project keeps recording. The AI Hub scripts authenticate by reading
that file at runtime and contain no credential.

README reframed for the new name and the wider scope: the repository is the
engine changes, the harness, the raw results, the baselines and the analyses,
not just a patch set.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L1ax5wYLA6XbqEL1i8L9gZ
2026-09-14 14:21:07 +08:00
tzhouamandClaude Opus 5 99ebfbbd04 docs: we do patch vLLM, at runtime -- correct two overstatements
The previous commit said "vLLM itself is not modified" and described the
changes as going "through vLLM's own extension points". Challenged on it, and
the challenge was right: those are two different claims and only one of them
holds as written.

What is true: no file in the vLLM tree or in site-packages/vllm is edited, the
checkout is clean upstream and the wheel is stock 0.28.0+cpu, so there is no
patch series to apply and no vLLM fork to maintain.

What was wrong:

1. vllm_omni/patch.py does nine _patch_* functions performing ten direct
   attribute replacements -- CpuPlatform.check_and_update_config,
   CPUWorker.load_model, torch.compiler.load_compiled_function. That is
   monkey-patching, not an extension point, and calling it one made the
   arrangement sound more robust than it is. Only the registries are genuine
   hooks: register_quantization_config, ir.ops.*.register_impl, platform
   plugins, direct_register_custom_op.

2. "The changes survive a wheel upgrade rather than being lost on it" is true of
   the registrations and overstated for the patches. Each patch is keyed to a
   specific method on a specific vLLM class; an upstream rename or behaviour
   change can break it or silently turn it into a no-op wrapper. The failure
   mode is a missing optimisation, not a crash, which is worse -- so the doc now
   says to re-run the harness after upgrading.

The section is rewritten to separate the two mechanisms, list what each patch
works around, and note that two of the three exist for upstream bugs and should
disappear when those are fixed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L1ax5wYLA6XbqEL1i8L9gZ
2026-09-14 14:07:31 +08:00
tzhouamandClaude Opus 5 9264ff81ab Include the baselines, comparisons and study documents, not just the fork
The packaging commit shipped the code and a summary of the numbers. It left out
everything the numbers are measured *against*, which is most of what makes them
checkable.

Added:

  baselines/                 llama.cpp runs (thread sweeps, NUMA sweeps, the
                             interleaved A/B passes behind the headline decode
                             figure) and the quality references: each build
                             against its own bf16 over 12 greedy prompts.
  benchmarks/.../results/    102 artifacts backing the published figures, each
                             with a provenance block naming the model,
                             quantization, thread set and build SHAs.
  docs/engines/              the engine analyses -- llama.cpp, ExecuTorch, MNN,
                             ncnn, vLLM, vLLM-Omni -- and the cross-engine and
                             device-simulation comparisons.
  docs/analysis/             the full study documents the summaries distil.
  docs/edge/comparisons.md   where this fork sits against llama.cpp and why:
                             decode is llama.cpp's, prefill is ours by ~2x, and
                             since neither engine exceeds 39% of the measured
                             222 GB/s ceiling the decode gap is the execution
                             model rather than the kernels.
  docs/edge/environment.md   pins and machine, and the correction below.

On "the modified vllm": there isn't one, and the doc says so plainly because it
is the obvious assumption. The vLLM checkout is clean upstream (0 commits
ahead, 0 uncommitted) and the installed wheel is stock 0.28.0+cpu. This fork
changes vLLM's CPU *behaviour* through vLLM's own extension points at import
time -- three CPU patches in vllm_omni/patch.py, the quantization-config
registry, the IR op registry, platform hooks -- specifically so the changes
survive a wheel upgrade rather than being lost on it. One of those patches is
why "KV sizing is not a memory lever" looked true for months: CpuPlatform
overwrote kv_cache_memory_bytes unconditionally, so the setting had no effect.
There is no patch series to apply; pin the version and let patch.py do the rest.

.gitignore gains explicit exceptions: upstream's blanket `*.json` and `results/`
rules were silently eating the measurement artifacts, which in this fork are the
substance rather than build output. Binary captures stay ignored.

No vLLM or llama.cpp source is redistributed -- only output produced with them.
NOTICE records both.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L1ax5wYLA6XbqEL1i8L9gZ
2026-09-14 14:01:12 +08:00
tzhouamandClaude Opus 5 b36a3431bd Package this fork as vllm-embedding: README, docs, roadmap, harness
Turns a branch of accumulated edge/CPU work into something someone else can
read, reproduce and continue.

README.md states what the fork is for (multimodal models on edge CPUs rather
than servers), the headline memory and speed results with their costs, and why
the numbers are worth reading -- five retracted conclusions, all measurement
errors rather than coding errors. Upstream's README is preserved at
docs/README.vllm-omni.md and NOTICE records the Apache-2.0 derivation and the
files this fork changes.

docs/edge/:
  methodology.md  the measurement discipline, which is the most transferable
                  thing here: what each of the five retractions was, and the
                  rule it left behind. Includes the two traps specific to this
                  stack -- vLLM's AOT compile cache keying on config so two
                  arms sharing an artifact load the wrong graph, and allocated
                  not being resident until mincore(2) says so.
  results.md      every measured figure with its spread and baseline, and an
                  explicit note that the four memory levers overlap and must
                  not be added.
  cpu-4bit.md     the two 4-bit paths, the packed layout as measured rather
                  than assumed, why the path choice is a config field, and the
                  GPTQ output-head trap that invalidated a whole round of W4A8
                  numbers.
  harness.md      how to run a comparison, and the two arguments that matter
                  more than they look (--context-len, --prompt-len), each of
                  which has produced a wrong conclusion by being left at its
                  default.

ROADMAP.md orders by whether the verification method is correct rather than by
expected size, lists what is done with results, what is next with expected
gains and how each would be verified, and -- at equal length -- what was
considered and rejected, including the CPU megakernel with the measurements
that rule it out for now.

benchmarks/edge_harness/ brings the tooling into the repo so the numbers are
reproducible: the grid runner, the single-run benchmarks, the memory ledger,
the fidelity metric, the Android agent suite, the quantizers, and the tests
that pin the harness's judgement. 82 tests pass from the new location.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L1ax5wYLA6XbqEL1i8L9gZ
2026-09-14 13:25:32 +08:00
tzhouamandClaude Opus 5 c4e61133fb [Edge][CPU] Fused norms off by default, and register the switches this branch added
Two corrections and the paperwork they imply.

The fused-RMSNorm registration defaulted to *on*, which contradicts the
measurement it was committed with: those kernels are 3.6x and 4.5x faster in
isolation but measured 72.7 tok/s against 74.0 end to end, because inductor
already fuses the native norm into the residual add and an opaque call breaks
that fusion. The implementations stay registered, so the provider remains
selectable through `kernel_config.ir_op_priority` on a machine where the trade
lands differently; only the default ranking is left alone now, and the test
asserts both states rather than just the opt-in one.

The four switches this branch added (VLLM_OMNI_AOT_CACHE_SHIM,
_CPU_FUSED_NORMS, _CPU_RELEASE_MEMORY, _SPARK_GATE_REDUCTION) were not in the
reviewed environment-variable inventory, so
`test_statically_resolvable_environment_accesses_are_classified` failed. They
are classified now, the reviewed count moves 28 -> 32 with a note saying why,
and each has a row in docs/configuration/environment_variables.md carrying the
measurement that justifies its default.

`VLLM_OMNI_CPU_FAST_SAMPLER` and `VLLM_OMNI_STEP_STATS_SYNC` remain
unclassified and that test still fails on them. They arrived in 6ce8de1b, in
files this branch does not touch, so they are left to whoever owns that work
rather than documented from a guess.

Under `-m "core_model and cpu"`: 2593 passed before these fixes with 9
failures, of which two were mine. The rest are CUDA-only tests in a CPU venv
("Torch not compiled with CUDA enabled") plus test_qnn_export.py, which
another session is actively editing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-12 14:55:24 +08:00
Zhou TaichangandClaude Opus 5 aff7d64948 [Rebase] Rebase to vLLM 0.29.0 (#7230)
Signed-off-by: tzhouam <tzhouam@connect.ust.hk>
Signed-off-by: Zhou Taichang <tzhouam@connect.ust.hk>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-09-10 12:08:28 +08:00
Weiming Liaoandwangyu 35a83a0885 [NPU][CI] Add A5 and 310P CI support (#6875)
Signed-off-by: Weiming Liao <liaowm5@gmail.com>
Co-authored-by: wangyu <53896905+yenuo26@users.noreply.github.com>
2026-09-10 02:16:14 +00:00
Guangjian Dong faad918588 [Doc] Document num_outputs_per_prompt for /v1/videos (#7341)
Signed-off-by: Guangjian <hiro20833@gmail.com>
2026-09-10 08:00:13 +08:00
andyluo7andHongsheng Liu c94cf4ddde [CI][ROCm] Match CUDA/NPU L2/L3 label routing (#6966)
Signed-off-by: andyluo7 <andy.luo@amd.com>
Co-authored-by: Hongsheng Liu <liuhongsheng4@huawei.com>
2026-09-09 13:47:15 +00:00
NumberWan 038c9b948f [Bugfix] Resolve #6931 hub FA3 on torch 2.13 via kernels 0.16.1 (#7185)
Signed-off-by: NumberWan <wantszkin2003@gmail.com>
2026-09-09 10:20:34 +00:00