Если говорить об llama.cpp, то с ним чем проще, тем оказалось эффективнее: все что касается gpu/cpu - в auto, вручную только установил экспериментально лично на своем железе parallel в 1 и mtp в 2, контекст да, квантую в 8 и ещё кастомный jinja шаблон специфично под qwen, но это не к эффективности относится. Ну и в целом последние сборки llam'ы все лучше и лучше делают свою магию, ускоряя TFT, так и MTP. Уж не знаю чего делают, но работает вполне приемлемо.
Сами документы - на глазок, а точнее на корректность выполнения по сути, проверяю глазами, да. Но технически также сравниваю скорость, объем раздумывания, смотрю, что модель там в своих размышлениях делала. Строго ли следовала инструкциям. Грузила ли нужные инструменты в правильной последовательности.
Это ошибка так ориентироваться. Надо взять свои собственные привычные сценарии использования и на них прогнать. Вот и поймете. Я так по своим задачам вынужденно сделал выбор в пользу qwen 3.6 moe против Gemma 4 26b, потому что именно в конкретных задачах квен выдала просто идеальный результат (создание документов по образцам, написание договора, due diligence контрагента по всяким апи и реестрам в тырнете, напиисание протоколов, решений в корпоративной сфере).
На 4070 без ti гонял и так и эдак. На moe модели увеличения скорости больше, чем на 10-15 процентов не получил. Задачи агентные в основном, на чистой генерации простыни текста, разумеется, быстрее, чем при частых префиллах контекста.
А вот dense модели буквально ускоряются почти в два раза, но у меня это понеслось не с параметром 4, а с параметром 2 токена. Но речь о том, что трудно в целом использовать в работе, например, модель 27b, которая не влезает полностью в видео, и скорость работы 3.5 или 7 токенов в секунду не сильно принципиальна. Чрезмерно ужатые кванты на порядок тупее хорошей и быстрой moe модели на 35b, которая и так пахала где-то на 40-50 т/с, и mtp даёт минимальный прирост, но не забываем, что на сейчас главный минус - mtp нельзя запустить вместе с vision мультимодальностью у qwen.
При этом почти весь РАМ забит (28 из 32 Гб), а видео память только 6 из 12 Гб. Может есть куда двинуть ползунки еще? Контекст поставил 65535, кинул длинную агентную задачу (найти файл, в нем взять список из 10 товарных знаков, по каждому сходить в интернет и проверить срок действия и последние изменения), выполняет все, но сильно медленно конечно. Слабое место - прцессинг промпта (ну или вывода инструментов, в моем случае снапшота chrome dev tools). Агентную задачу выполнил на отлично, выполнял 33 минуты с половиной. Но круто, пока это первая и последняя модель, локально справившаяся с агентной задачей.
Я html пользовался от безысходности. Там в целом все сложнее, чем можно в двух словах описать. В общем, docx обязательное условие, в нем проще всего всем участникам составить и только он был у всех, к примеру, проект договора, дальше самим или с моей помощью расставить тэги для подстановки, а потом этот шаблон просто будет использоваться для генерации готовых документов приложением.
Вся идея в том, что шаблоны то и делают секретари, бухгалтеры и из доступных средств имеют только ворд, и еще тут усилия предстоят объяснить что такое ${var}.
По мне, так дополнительный движок Ashley к LibGDX в разы упрощает понимание игростроя в связке с ООП и дает правильную концепцию деления игровых сущностей, игровых систем и рендеринга. Не знаю насчет Java, но с Kotlin оно спаривается очень хорошо, плюс есть свои ktx на все библиотеки, еще более упрощающие синтаксис.
class Game {
private lateinit var store: Store
private lateinit var question: Question
fun init(context: Context) {
this.store = StoreFactory.getStore(context)
question = store.getQuestionById(1)
}
Когда идиоматичнее так:
class Game(context: Context) {
private val store = StoreFactory.getStore(context)
private var question = store.getQuestionById(1)
А это вы просто пишете с помощью Kotlin на другом каком-то языке, кажется, паскале:
fun getAnswers(): List<Answer> {
val list: MutableList<Answer> = ArrayList(this.answers)
val shouldAdd: Int = 4 - list.size
for (i in 1..shouldAdd) {
list.add(Answer("", -1))
}
return list
}
Я бы предложил так (хотя сама идея добавить пустышками до нужного кол-ва так себе, явно неразумное ограничение, с которым нужно бороться в другом месте):
Rx и Mvp уже пару лет вытесняются Kotlin coroutines и Mvvm/Mvi. Активити фрагментами или вообще Compose. Для json есть библиотеки Kotlin serialization, для андроида — gson, moshi и т.д.
Оставляю, чтоб было что улучшить при следующем взгляде на код) Я потом вынес в константу ключ, по которому взаимодействуют фрагменты, а строки для различения классов, так как используются только в одном месте, оставил бы.
Если говорить об llama.cpp, то с ним чем проще, тем оказалось эффективнее: все что касается gpu/cpu - в auto, вручную только установил экспериментально лично на своем железе parallel в 1 и mtp в 2, контекст да, квантую в 8 и ещё кастомный jinja шаблон специфично под qwen, но это не к эффективности относится. Ну и в целом последние сборки llam'ы все лучше и лучше делают свою магию, ускоряя TFT, так и MTP. Уж не знаю чего делают, но работает вполне приемлемо.
Сами документы - на глазок, а точнее на корректность выполнения по сути, проверяю глазами, да. Но технически также сравниваю скорость, объем раздумывания, смотрю, что модель там в своих размышлениях делала. Строго ли следовала инструкциям. Грузила ли нужные инструменты в правильной последовательности.
с 5090 я и без курения это сделаю) у меня 4070.
Это ошибка так ориентироваться. Надо взять свои собственные привычные сценарии использования и на них прогнать. Вот и поймете. Я так по своим задачам вынужденно сделал выбор в пользу qwen 3.6 moe против Gemma 4 26b, потому что именно в конкретных задачах квен выдала просто идеальный результат (создание документов по образцам, написание договора, due diligence контрагента по всяким апи и реестрам в тырнете, напиисание протоколов, решений в корпоративной сфере).
Это еще тогда +1 Гб на mmproj в память и -1 Гб для базы, не сильно нужно в целом мне)
На 4070 без ti гонял и так и эдак. На moe модели увеличения скорости больше, чем на 10-15 процентов не получил. Задачи агентные в основном, на чистой генерации простыни текста, разумеется, быстрее, чем при частых префиллах контекста.
А вот dense модели буквально ускоряются почти в два раза, но у меня это понеслось не с параметром 4, а с параметром 2 токена. Но речь о том, что трудно в целом использовать в работе, например, модель 27b, которая не влезает полностью в видео, и скорость работы 3.5 или 7 токенов в секунду не сильно принципиальна. Чрезмерно ужатые кванты на порядок тупее хорошей и быстрой moe модели на 35b, которая и так пахала где-то на 40-50 т/с, и mtp даёт минимальный прирост, но не забываем, что на сейчас главный минус - mtp нельзя запустить вместе с vision мультимодальностью у qwen.
Есть же уже mtp сборка от unsloth
При этом почти весь РАМ забит (28 из 32 Гб), а видео память только 6 из 12 Гб. Может есть куда двинуть ползунки еще? Контекст поставил 65535, кинул длинную агентную задачу (найти файл, в нем взять список из 10 товарных знаков, по каждому сходить в интернет и проверить срок действия и последние изменения), выполняет все, но сильно медленно конечно. Слабое место - прцессинг промпта (ну или вывода инструментов, в моем случае снапшота chrome dev tools). Агентную задачу выполнил на отлично, выполнял 33 минуты с половиной. Но круто, пока это первая и последняя модель, локально справившаяся с агентной задачей.
Также благодарю за подсказу по настройкам. Сопоставимый уровень железок, только cpu другой, i7 12700KF, LM STUDIO не хочет больше 4 ядер отдавать.
Это нормальная скорость или можно и лучше? Сейчас схожу в opecode на использовании инструментов ее проверю.
Я html пользовался от безысходности. Там в целом все сложнее, чем можно в двух словах описать. В общем, docx обязательное условие, в нем проще всего всем участникам составить и только он был у всех, к примеру, проект договора, дальше самим или с моей помощью расставить тэги для подстановки, а потом этот шаблон просто будет использоваться для генерации готовых документов приложением.
Вся идея в том, что шаблоны то и делают секретари, бухгалтеры и из доступных средств имеют только ворд, и еще тут усилия предстоят объяснить что такое ${var}.
Интересно, насколько они сами знают свой продукт? Таких вопросов не задаст тот, кто хоть раз двигал изображение в Ворде.
Спасибо!!!!!
Никто не заставляет идти на поводу одисейщиков. Я как летал, так и летаю по настроению.
О, да!!! Спасибо. Наконец-то. Я бы книжку купил на эту тему как про Doom)
По мне, так дополнительный движок Ashley к LibGDX в разы упрощает понимание игростроя в связке с ООП и дает правильную концепцию деления игровых сущностей, игровых систем и рендеринга. Не знаю насчет Java, но с Kotlin оно спаривается очень хорошо, плюс есть свои ktx на все библиотеки, еще более упрощающие синтаксис.
Когда идиоматичнее так:
А это вы просто пишете с помощью Kotlin на другом каком-то языке, кажется, паскале:
Я бы предложил так (хотя сама идея добавить пустышками до нужного кол-ва так себе, явно неразумное ограничение, с которым нужно бороться в другом месте):
Rx и Mvp уже пару лет вытесняются Kotlin coroutines и Mvvm/Mvi. Активити фрагментами или вообще Compose. Для json есть библиотеки Kotlin serialization, для андроида — gson, moshi и т.д.
Оставляю, чтоб было что улучшить при следующем взгляде на код) Я потом вынес в константу ключ, по которому взаимодействуют фрагменты, а строки для различения классов, так как используются только в одном месте, оставил бы.