Concepts개념
Five ideas explain almost every decision in this repository.
이 저장소의 결정 대부분은 다섯 가지 생각으로 설명됩니다.
Only torch._C is replacedtorch._C 만 교체한다
PyTorch is mostly Python: nn.Module, functional, optimisers, pytree, all source. The native part is torch._C: ATen tensors, the dispatcher, autograd. PyTorch's mobile build forces BUILD_PYTHON off, so that module cannot be built for a phone. torchnative vendors the Python tree unmodified and supplies _C. The chase target shrinks from “the whole torch API” to “the ATen op set”, which is far more stable.
PyTorch 는 대부분 파이썬입니다: nn.Module, functional, 옵티마이저, pytree 가 전부 소스입니다. 네이티브는 torch._C (ATen 텐서, 디스패처, autograd) 뿐입니다. PyTorch 의 모바일 빌드는 BUILD_PYTHON 을 끄므로 그 모듈을 휴대폰용으로 만들 수 없습니다. torchnative 는 파이썬 트리를 그대로 벤더링하고 _C 를 공급합니다. 추격 대상이 “torch API 전체” 에서 훨씬 안정적인 “ATen op 집합” 으로 줄어듭니다.
One door, and refusals that name themselves하나의 문, 그리고 이름을 대는 거부
Every operator reaches its kernel through _aten_dispatch. Tensors carry a representation (Dense, Quantized, Vulkan, Complex, Meta) and a kernel that asks for a dense tensor refuses every other kind. A silent fallback to the CPU is therefore not avoided by discipline; it cannot be expressed.
모든 연산자는 _aten_dispatch 를 거쳐 커널에 닿습니다. 텐서는 표현 (Dense, Quantized, Vulkan, Complex, Meta) 을 가지며, 밀집 텐서를 요구하는 커널은 나머지를 전부 거부합니다. 그래서 조용한 CPU 폴백은 규율로 피하는 것이 아니라 아예 표현할 수 없습니다.
Fixed front end, swapped back end앞단은 고정, 뒷단만 교체
The user keeps the real transformers model and the real from_pretrained and generate. For an accelerator, torchnative replaces leaves or submodules in place, CoreML on Apple, ExecuTorch/QNN on Android, OpenVINO for the Intel NPU on Windows. A compiled blob is an implementation detail behind a module, never something you hold. NPUs take whole subgraphs, which is why graph capture comes first.
사용자는 진짜 transformers 모델과 진짜 from_pretrained·generate 를 그대로 씁니다. 가속기가 필요하면 torchnative 가 잎이나 서브모듈을 제자리에서 교체합니다. Apple 은 CoreML, Android 는 ExecuTorch/QNN, Windows 의 Intel NPU 는 OpenVINO. 컴파일된 블롭은 모듈 뒤의 구현 세부이지 사용자가 쥐는 물건이 아닙니다. NPU 는 서브그래프를 통째로 받으므로 그래프 캡처가 먼저입니다.
A weight delta whose lifetime is its type수명이 타입에 박힌 가중치 델타
Test-time learning nests: TTL contains TTA, which contains TTT. Federated learning is a layer above them, because it is the only one whose state leaves the device. What runs through all of them is one object (a delta over base weights) differing only in lifetime and destination. torchnative.delta.Delta owns the base, the offset and the lifetime questions, so a method such as Tent holds no state at all.
테스트 타임 학습은 중첩입니다: TTL 안에 TTA, 그 안에 TTT. 연합학습은 상태가 기기를 떠나는 유일한 경우라서 그 위에 얹히는 층입니다. 이들을 관통하는 것은 하나의 물건 (베이스 가중치 위의 델타) 이고, 수명과 행선지만 다릅니다. torchnative.delta.Delta 가 베이스·오프셋·수명 질문을 소유하므로 Tent 같은 방법은 상태를 갖지 않습니다.
TTL test-time learning
└─ TTA test-time adaptation # no labels, no source data
└─ TTT test-time training # an auxiliary task trained in advance
FL federated learning # a layer above: state leaves the device
Agreement is the bar기준은 일치다
A number here is one of three grades: builds, reaches or agrees. Only agreement (element-wise, against upstream, in a separate process) supports the word drop-in. Tolerances are derived: upstream is re-run in float64, and the threshold is the 90th percentile of upstream's own float32 error.
이곳의 숫자는 빌드됨, 도달함, 일치함 세 등급 중 하나입니다. drop-in 이라는 말을 지탱하는 것은 일치함 (별도 프로세스에서 upstream 과 원소 단위 비교) 뿐입니다. 허용오차는 유도합니다: upstream 을 float64 로 다시 돌려 upstream 자신의 float32 오차의 p90 을 씁니다.