заміряна швидкість декоду для трьох шляхів

README.md

@@ -101,9 +101,7 @@ llama-server -m gguf/model-f16.gguf --host 127.0.0.1 --port 8901 \
  "logit_bias": [[<кожен токен із цифрою>, -100]]}
 ```
 
-llama.cpp дає ~864 токени/с проти 55 у ONNX на тій самій моделі й тій самій
-якості: на 270M крок декоду впирається в запуск CUDA-ядер, а не в обчислення,
-і виграють CUDA-графи.
+Це найшвидший шлях із трьох, і з великим відривом — див. таблицю нижче.
 
 ### onnxruntime
 
@@ -122,8 +120,40 @@ out = model.generate(ids, max_new_tokens=192, do_sample=False)
 print(tok.decode(out[0, ids.shape[-1]:], skip_special_tokens=True))
 ```
 
-Це шлях для **CPU й edge**. На GPU він програє llama.cpp приблизно в 15 разів —
-чому саме, розписано нижче.
+**На CUDA обов'язково вимикайте io-binding** — інакше граф падає з
+`cudaErrorIllegalAddress` на `embed_tokens/Mul`:
+
+```python
+model = ORTModelForCausalLM.from_pretrained(
+    "skypro1111/gemma-3-270m-uk-verbalizer", subfolder="onnx",
+    provider="CUDAExecutionProvider", use_io_binding=False)
+```
+
+І майте на увазі: без явного `provider` optimum мовчки бере CPU, навіть коли
+CUDA доступна.
+
+### Скільки це коштує за часом
+
+Заміряно на RTX 3090 Ti: один рядок за раз (саме так модель і працює —
+речення за реченням), greedy, до 192 нових токенів, медіана з п'яти прогонів.
+
+| шлях | токенів/с |
+|---|---|
+| transformers, bf16, GPU | 27 |
+| onnxruntime, fp32, CPU | 31 |
+| onnxruntime, fp32, GPU | 69 |
+| **llama.cpp, GGUF F16, GPU** | **532** |
+
+llama.cpp швидший за transformers у **20 разів** — і це не про якість
+реалізації матричних множень. На моделі такого розміру крок декоду впирається
+не в обчислення, а в **накладні витрати на запуск CUDA-ядер**: сама робота
+мізерна, а ядер на крок запускається стільки ж, скільки у великої моделі.
+llama.cpp тримає CUDA-графи й тому цей оверхед майже прибирає.
+
+Звідси практичний висновок: якщо потрібна пропускна здатність — беріть GGUF.
+ONNX має сенс там, де llama.cpp незручний, і особливо на CPU: 31 проти 69
+ток/с на GPU означає, що на процесорі модель втрачає лише вдвічі, а не в
+десятки разів.
 
 ## Препроцесинг обов'язковий
 
@@ -261,9 +291,9 @@ python convert_hf_to_gguf.py <тека_моделі> --outfile model-f16.gguf --
 ідентичні ID один-в-один. Без збігу 52/52 результат вважати недійсним.
 Готовий `tokenizer.model` лежить у корені цього репозиторію.
 
-Навіщо взагалі GGUF: на 270M крок декоду впирається не в обчислення, а в запуск
-CUDA-ядер. llama.cpp тримає CUDA-графи — **864 токени/с проти 55 в ONNX**, при
-тій самій якості на якорі.
+Навіщо взагалі GGUF: це найшвидший шлях із трьох, **532 токени/с проти 27 у
+transformers** — при побайтово тій самій якості (перевірено, відповіді
+збігаються слово в слово).
 
 ---
 
@@ -279,12 +309,18 @@ python scripts/export_onnx.py --model <тека_моделі> --out ./onnx
 Готовий граф лежить у `onnx/`. Він **fp32**, тому вдвічі більший за
 safetensors — це очікувано, а не помилка експорту.
 
-Чесна засторога: на GPU ONNX для цієї моделі **програє** llama.cpp приблизно в
-15 разів (55 проти 864 ток/с), і причина не в якості реалізації, а в тому, що
-на такому розмірі все впирається в оверхед запуску ядер, а CUDA-графи
-onnxruntime для цього графа оголошує недоступними. ONNX тут має сенс для
-**CPU-інференсу й edge-сценаріїв**, де llama.cpp незручний, а не як швидший
-шлях на GPU.
+Дві речі, на які пішов час і які варто знати наперед:
+
+* без явного `provider` optimum бере CPU, навіть коли CUDA доступна — мовчки;
+* на CUDA треба `use_io_binding=False`, інакше граф падає з
+  `cudaErrorIllegalAddress` на `embed_tokens/Mul`.
+
+Чесна засторога щодо швидкості: на GPU ONNX програє llama.cpp у **7-8 разів**
+(69 проти 532 ток/с), і причина не в якості реалізації, а в тому, що на такому
+розмірі все впирається в оверхед запуску ядер, який CUDA-графи llama.cpp
+прибирають, а onnxruntime для цього графа — ні. Натомість ONNX добре тримається
+**на CPU**: 31 ток/с проти 69 на GPU, тобто втрата лише вдвічі. Саме тут його
+ніша, а не в перегонах на відеокарті.
 
 ## Тренування