Не столько изобретает, сколько приходит туда же, куда проектные институты пришли лет девяносто назад. Я в таком работаю и однажды не удержался: разложил шесть маленьких локальных моделей (1–2B) по схеме бюро Альберта Кана. Дисциплины, внутридисциплинарная проверка, междисциплинарная, нормоконтроль. И замерил, что из всей этой оргструктуры реально несёт нагрузку.
Оказалось, только деление на дисциплины. Самая слабая из работающих моделей от него выросла с 0,175 до 0,700, а весь «рой» поверх лучшей одиночной модели добавил +0,05. Делить работу доверил скрипту: LLM-планировщик в соседнем прогоне справлялся в 22% случаев.
Так что ревью и эскалация — да, но ревью должно быть тупой детерминированной проверкой. Модель-проверяльщик у меня отвергала заведомо правильный эталон в 76,8% случаев.
38 т/с там ровно потому, что Next - MoE: на каждый токен читаются только активные эксперты. Для масштаба: плотная Qwen3.8-27B в Q8_0 читает 25,4 ГиБ весов на каждый токен. Моя десктопная DDR4 выдаёт около 17 ГБ/с, и потолок вышел 0,6 т/с. Ни раскладка по памяти, ни подкачка, ни закрепление его не сдвинули.
Скорость генерации на таких машинах — это пропускная способность памяти, делённая на байты на токен. NPU в эту формулу для генерации почти не входит.
Насколько портит — меряется, и дёшево: KL-дивергенция к базовой модели на своём тексте, llama-perplexity с --kl-divergence. Для gpt-oss я откалибровал пороги так: до 0,003 разницы не видно, до 0,01 дёшево, но терпимо.
Только текст берите свой. На чужом корпусе перплексия gpt-oss показывала мне ерунду, а на её родном формате всё встало на место. И KV-кэш туда же: q4_0 обошёлся в +10,7% перплексии, а не в 1,5%, как я сам раньше писал.
Место в списке влияет не только на кэш. Я мерил на маленьких моделях ( 1-2B, 18 записей в контексте) - запись на первой позиции находилась в 61проц случаев, на 17-й - в 21проц. Монотонно, без провала посередине. Причём модель не начинала чаще говорить «нет», доля «да» почти не менялась, она просто чаще тыкала не в те записи. Для девяноста инструментов я бы ждал того же: хвост списка путается с соседями. мне помогла нарезка на блоки по 6, разрыв между головой и хвостом упал с 0.204 до 0,021. На 27B не проверял.
Тут вопрос не в автоматизации, а в том, кто решает структуру работы. Я как-то дал модели самой решать, как разбить задачу на части, - справлялась в 22% случаев. Когда разбивку делал скрипт по заранее заданной схеме, а модели только заполняли свои куски, самая слабая из них выросла с 0,175 до 0,700.
Папки в ICM - по сути та же схема, только руками. Для сильной модели с одним промптом выигрыш будет меньше, но сам принцип мне кажется верным.
Про 256 против 768 - совпадает с моим опытом: поиск куда менее чувствителен к наворотам, чем кажется. Я на своём архиве заметок и переписок сравнивал поиск через граф связей с тупым косинусом по эмбеддингам. Граф дал 64,9%, плоский косинус 70,3%.
Граф пригодился, но уже после поиска - посмотреть соседей найденного. Так что текстовые файлы плюс плоский индекс, по-моему, правильный выбор, а не упрощение.
Зелёные проверки сразу после правки - отдельная ловушка, если их пишет тот же агент, что и правку. Я как-то подал заведомо правильное решение в тесты, сгенерированные моделью: 129 наборов из 168 его завернули. А самый неприятный случай был обратный. Код считал гласные и забывал про заглавные, а тест ровно этого и ждал. Тест и баг совпали в одном непонимании задачи, проверка сказала PASS, починка даже не запустилась. Поймал только внешний тест, написанный руками. С тех пор решающая проверка у меня всегда снаружи агента.
Если весь прирост на повторных попытках, то честный контроль - те же попытки без доставки решения. У меня на модедях от 360M до 1,7B один только пересэмпл кода, без всяких подсказок, поднял решаемость с 0,833 на одной попытке до 0,958 на восьми. Засчитывал, если хоть одна попытка прошла эталонные тесты. Попытки сами по себе покупают очень много. и бюджет я бы сравнивал по каждому вызову, а не суммами. У меня равные суммы трижды прятали перекос: одна ветка просто чаще упиралась в лимит токенов.
С -ub 4096 осторожнее, если модель не влезает в видеопамять целиком. У меня на 6 ГБ с gpt-oss-20b оптимум вышел -ub 1536 на 16k контекста и 1024 на 65k, дальше начиналась молотьба — экспертов гоняло туда-обратно.
А MTP я мерил и остыл. Черновик принимался на все 100%, только срабатывал на 7 токенах из 128. Потолок выигрыша 5,5%, а проход стоит одного чтения модели, итог в ноль. Сначала мне показалось 1,76×, но это была амортизация прохода, пришлось отозвать.
Не столько изобретает, сколько приходит туда же, куда проектные институты пришли лет девяносто назад. Я в таком работаю и однажды не удержался: разложил шесть маленьких локальных моделей (1–2B) по схеме бюро Альберта Кана. Дисциплины, внутридисциплинарная проверка, междисциплинарная, нормоконтроль. И замерил, что из всей этой оргструктуры реально несёт нагрузку.
Оказалось, только деление на дисциплины. Самая слабая из работающих моделей от него выросла с 0,175 до 0,700, а весь «рой» поверх лучшей одиночной модели добавил +0,05. Делить работу доверил скрипту: LLM-планировщик в соседнем прогоне справлялся в 22% случаев.
Так что ревью и эскалация — да, но ревью должно быть тупой детерминированной проверкой. Модель-проверяльщик у меня отвергала заведомо правильный эталон в 76,8% случаев.
38 т/с там ровно потому, что Next - MoE: на каждый токен читаются только активные эксперты. Для масштаба: плотная Qwen3.8-27B в Q8_0 читает 25,4 ГиБ весов на каждый токен. Моя десктопная DDR4 выдаёт около 17 ГБ/с, и потолок вышел 0,6 т/с. Ни раскладка по памяти, ни подкачка, ни закрепление его не сдвинули.
Скорость генерации на таких машинах — это пропускная способность памяти, делённая на байты на токен. NPU в эту формулу для генерации почти не входит.
Насколько портит — меряется, и дёшево: KL-дивергенция к базовой модели на своём тексте, llama-perplexity с --kl-divergence. Для gpt-oss я откалибровал пороги так: до 0,003 разницы не видно, до 0,01 дёшево, но терпимо.
Только текст берите свой. На чужом корпусе перплексия gpt-oss показывала мне ерунду, а на её родном формате всё встало на место. И KV-кэш туда же: q4_0 обошёлся в +10,7% перплексии, а не в 1,5%, как я сам раньше писал.
Место в списке влияет не только на кэш. Я мерил на маленьких моделях ( 1-2B, 18 записей в контексте) - запись на первой позиции находилась в 61проц случаев, на 17-й - в 21проц. Монотонно, без провала посередине. Причём модель не начинала чаще говорить «нет», доля «да» почти не менялась, она просто чаще тыкала не в те записи. Для девяноста инструментов я бы ждал того же: хвост списка путается с соседями. мне помогла нарезка на блоки по 6, разрыв между головой и хвостом упал с 0.204 до 0,021. На 27B не проверял.
Тут вопрос не в автоматизации, а в том, кто решает структуру работы. Я как-то дал модели самой решать, как разбить задачу на части, - справлялась в 22% случаев. Когда разбивку делал скрипт по заранее заданной схеме, а модели только заполняли свои куски, самая слабая из них выросла с 0,175 до 0,700.
Папки в ICM - по сути та же схема, только руками. Для сильной модели с одним промптом выигрыш будет меньше, но сам принцип мне кажется верным.
Про 256 против 768 - совпадает с моим опытом: поиск куда менее чувствителен к наворотам, чем кажется. Я на своём архиве заметок и переписок сравнивал поиск через граф связей с тупым косинусом по эмбеддингам. Граф дал 64,9%, плоский косинус 70,3%.
Граф пригодился, но уже после поиска - посмотреть соседей найденного. Так что текстовые файлы плюс плоский индекс, по-моему, правильный выбор, а не упрощение.
Зелёные проверки сразу после правки - отдельная ловушка, если их пишет тот же агент, что и правку. Я как-то подал заведомо правильное решение в тесты, сгенерированные моделью: 129 наборов из 168 его завернули. А самый неприятный случай был обратный. Код считал гласные и забывал про заглавные, а тест ровно этого и ждал. Тест и баг совпали в одном непонимании задачи, проверка сказала PASS, починка даже не запустилась. Поймал только внешний тест, написанный руками. С тех пор решающая проверка у меня всегда снаружи агента.
Если весь прирост на повторных попытках, то честный контроль - те же попытки без доставки решения. У меня на модедях от 360M до 1,7B один только пересэмпл кода, без всяких подсказок, поднял решаемость с 0,833 на одной попытке до 0,958 на восьми. Засчитывал, если хоть одна попытка прошла эталонные тесты. Попытки сами по себе покупают очень много. и бюджет я бы сравнивал по каждому вызову, а не суммами. У меня равные суммы трижды прятали перекос: одна ветка просто чаще упиралась в лимит токенов.
С -ub 4096 осторожнее, если модель не влезает в видеопамять целиком. У меня на 6 ГБ с gpt-oss-20b оптимум вышел -ub 1536 на 16k контекста и 1024 на 65k, дальше начиналась молотьба — экспертов гоняло туда-обратно.
А MTP я мерил и остыл. Черновик принимался на все 100%, только срабатывал на 7 токенах из 128. Потолок выигрыша 5,5%, а проход стоит одного чтения модели, итог в ноль. Сначала мне показалось 1,76×, но это была амортизация прохода, пришлось отозвать.