openai / whisper · Architecture

GitHub metadata records Python as the primary language, and the repository's own description — 'Robust Speech Recognition via Large-Scale Weak Supervision' — is author-claimed metadata, not analyzer-established.

The reconstruction's counts: 45 analyzed files, 1 entrypoint, 95 resolved static call relations, and 12 bounded execution paths. Two top-level directories are recorded as subsystem candidates: 'whisper' and 'tests'. The analyzer's summary additionally describes the code as organized around data, notebooks, tests, and whisper.

Role records name the whisper package's modules — __init__, __main__, audio, decoding, model, normalizers (basic and english), timing, tokenizer, transcribe, triton_ops, utils — plus five test modules: test_audio, test_normalizer, test_timing, test_tokenizer, test_transcribe.

At the root, README.md, pyproject.toml, requirements.txt, and LICENSE are classified as project-level important files. whisper/transcribe.py is flagged as likely an entrypoint, and the packet's detected __main__ guard sits in that file.

cli() is the first function reached: whisper/transcribe.py holds the detected __main__ guard, and its body calls cli(): if __name__ == "__main__": cli().

Every listed bounded execution path starts at whisper/transcribe.py:__main__, reaches cli() as a local call, and terminates at an external or unresolved target with terminal_reason 'unresolved_boundary'; no cycles are recorded and no path is marked truncated. Named terminal targets include argparse.ArgumentParser, several parser.add_argument calls, and torch.cuda.is_available.

Paths end at these symbols because the analyzer records them as external_or_unresolved rather than resolving them into local code — a documented boundary, not a completed local call. The analyzer labels whisper/transcribe.py an entry/orchestration candidate (3 incoming, 18 outgoing static calls).

Roles below are inferred by the analyzer from static resolved call degree and entrypoint membership; they describe call-graph shape, not confirmed runtime responsibility.

• whisper/model.py: highest recorded degree, 22 incoming and 20 outgoing calls; service/core candidate.
• whisper/timing.py: 16 in, 9 out; whisper/utils.py: 14 in, 2 out; whisper/tokenizer.py: 12 in, 2 out — service/core candidates with high incoming counts.
• whisper/decoding.py: 11 in, 13 out; whisper/audio.py: 8 in, 5 out — service/core candidates.
• whisper/normalizers/english.py: 3 in, 3 out, service/core candidate; normalizers/__init__.py and basic.py: 1 in, 0 out each, leaf/data-boundary candidates.
• whisper/triton_ops.py: 1 in, 1 out; whisper/__main__.py: 0 in, 1 out, orchestration candidate.

The packet records 1,388 static relations — 1,207 calls and 181 imports — of which 1,233 are external_or_unresolved and 155 local.

The bounded paths stop at argparse.ArgumentParser, parser.add_argument, and torch.cuda.is_available, each recorded as an external_or_unresolved call target. torch appears on both sides of the boundary: declared as a runtime dependency in requirements.txt and reached from cli() as an unresolved external target.

The analyzer documents that reflection, runtime dependency injection, dynamic imports, monkey-patching, generated code, framework runtime wiring, and dynamic dispatch are not resolved. With 1,233 of 1,388 relations unresolved, this boundary list is where the static picture ends; behavior beyond those edges is not established by this analysis.

requirements.txt declares seven runtime dependencies: numba, numpy, torch, tqdm, more-itertools, tiktoken, and triton (>=2.0.0). Dependency records come only from requirements-style manifests; pyproject.toml dependency tables are not parsed, so this list may be incomplete.

Incoming-call concentrations suggest the rest of the code depends most on whisper/model.py, whisper/timing.py, whisper/utils.py, and whisper/tokenizer.py. Test modules are recorded with zero incoming calls and outward-only calls — for example tests/test_timing.py at 0 in and 6 out — which reads as tests exercising library modules rather than being called by them.

Because 1,233 of 1,388 relations are unresolved, the packet does not yield a complete cross-module dependency map.

This analysis is static only: reflection, runtime dependency injection, dynamic imports, monkey-patching, generated code, framework runtime wiring, and dynamic dispatch are not resolved.

Install, run, and build inference is partial, and installation commands are not verified. README claim extraction is line-based and may capture code lines rather than prose, so README-derived statements are author-claimed at most.

Manifest entries about the analyzer's actual capabilities describe the analyzer, not this repository, and are excluded from evidence. How the code's runtime framework wiring behaves is not established by this packet's static relations; the packet's unresolved teaching claim states static analysis cannot establish runtime framework behavior.

Start with the manifests and project-level important files — README.md, pyproject.toml, requirements.txt, LICENSE. A grounded teaching claim then recommends tracing the bounded execution path and inspecting unresolved boundaries before changing code.

Next, read whisper/transcribe.py from its __main__ guard and follow cli() to its unresolved edges; the detected entrypoint and the listed bounded paths both run there.

Close with the high-incoming modules — whisper/model.py, whisper/timing.py, whisper/utils.py, whisper/tokenizer.py — whose static call degree marks them as the most depended-upon parts.