Задать вопрос
  • Как воспользоваться LLamaSharp?

    @rPman
    Оригинальные веса llama были выложены кажется на github
    magnet:?xt=urn:btih:ZXXDAUWYLRUXXBHUYEMS6Q5CE5WA3LVA&dn=LLaMA

    получаешь что то типа
    7B/checklist.chk
    7B/params.json
    7B/consolidated.00.pth
    13B/...
    ...
    tokenizer_checklist.chk
    tokenizer.model

    тебе нужны все tokenizer* файлы в корне и один из каталогов, соответствующий размеру модели (7B и 13B не знают русского и слабоваты)

    Этот c# проект - это биндинг к оригинальному проекту llama.cpp, там есть python скрипт convert.py (зависимости ставь сам, недостаточно requirements.txt нужен еще pytorch и еще что то, сам разберешься, в windows я не помогу) для конвертации из huggingface формата в суперэффективный ggml (этот формат постоянно меняется, где то раз в месяц, поэтому бессмысленно качать готовые, так как они будут привязаны к конкретной версии llama.cpp), его главная фича - mmap, веса не грузятся в память приложения а остаются в файловом кеше ОС, т.е. повторный запуск приложения моментальный.

    Будь готов к нескольким конвертациям, модели большие, особенно 65B, на диске тебе потребуется как минимум один раз хранить f16 версию (2 байта на вес, т.е. 130Gb для 65B модели) после его можно (но не обязательно) сконвертировать в формат с квантизацией (на вес будет требоваться к примеру 4 бита или 8), это значительно ускоряет работу ценой незначительного ухудшения качества.

    python convert.py --outtype f16 --outfile llama-7b-q4_0.ggml /torrents/LLaMA/7B
    вместо f16 можешь поставить f32, требования к памяти взлетят до 4 байт на вес но в теории это может быть тоже быстро (если критично, проведи бенчмарки), мои тесты показывают что f16 медленнее q4_0

    Опционально можешь провести квантизацию:
    ./quantize llama-7b-f16.ggml llama-7b-q4_0.ggml 2
    тут 2 это тип квантизации
    usage: ./quantize model-f32.bin [model-quant.bin] type [nthreads]
      type = "q4_0" or 2
      type = "q4_1" or 3
      type = "q5_0" or 8
      type = "q5_1" or 9
      type = "q8_0" or 7
    Очевидно что q4_... потребуют половину байта на вес (требования к 64b модели будут примерно 42+5GB ram), разница версий квантизации в скорости и качестве (q4_0 быстрее и чуть хуже q4_1 но я уверен что без синтетических тестов эту разницу на практике не заметишь даже между q16 и q4, она там единицы процентов, но вот скорость значительно отличается).

    Для работы llama.cpp нужен один файл .ggml (внутри и веса и токенизер) его и пиши в путь до модели.

    Поэкспериментируй с количеством threads в настройках, их нужно писать меньше чем позволяет процессор (тем более с гипертреадингом), так же я хз как у него с поддержкой gpu, она появилась относительно недавно, оптимизация по какому то одному конкретному тяжелому расчету.
    Ответ написан
    Комментировать
  • Как обычно имеют дело с разными разрешениями?

    @rPman
    Когда железо было медленным и простым, все измерялось в пикселах и разработка 'гвоздями прибивалась' к определенному разрешению, и если размер экрана увеличивался, в лучшем случае увеличивается область видимости объектов, но в худшем потребует реализацию масштабирования (например 2x2 пиксела на точку реализовать проще всего).

    Сейчас же видеокарты, даже встроенные в процессор, способны прекрасно масштабировать текстуры, а значит экран становится виртуальным и формально его свойства будут зависеть от настроек камеры (или view) движка, который будет 'смотреть' на объекты в виртуальном пространстве, не привязанном к пикселам... В этом смысле разработчикам, которые хотят сэкономить ресурсы и ужать текстуры, приходится выкручиваться, чтобы вернуться к пиксел-в-пиксел технологиям.
    Ответ написан
    Комментировать