Как я тестировал локально новый Qwen 3.6 и Gemma 4

Соглашусь, что если задача не сложная, то достаточно формата Markdown. Для более сложного промта, с помощью которого надо решить сложную задачу, лучше использовать XML. Можно и комбинировать эти форматы в одном промте. Вообщем приймущества и недостатки есть у обоих и выбор того или иного формата уже на усмотрение человека.

Как я тестировал локально новый Qwen 3.6 и Gemma 4

Взял промт из статьи и улучшил его в формате XML. Загрузил модель Gemma-4-26b-a4b в LM Studio на Mac mini m4 24gb. Пришлось повозиться с настройками так как в 24Gb с трудом помешается, точно не на максимальных настройках. Пришлось контекст уменьшить и ещё некоторые настройки ухудшить, из-за этого много нагрузки на CPU ложилась.

Модель справилась на 4. Примерно один час заняло, если бы помощнее была у меня конфигурация и памяти побольше, то было гораздо быстрее

Вот сылка: https://github.com/MaratGaZa/example-page-mortgage-calc

Как я тестировал локально новый Qwen 3.6 и Gemma 4

Сейчас промт это фактически код и поэтому с промтом нужно эсперемнтировать. Я сейчас пишу серьезные промты в XML формате, так получаеться более структивироанно. И системный промт тоже важен так как он будет в общем контексте вместе со всеми промтами, которые вы дадите модели. Вот примерный промт для в формате XML:
```XML
<role>
<!-- Назначение: Роль исполнителя изменений. Пример: Senior Developer, implementing strictly by spec --> Senior Software Engineer / Implementation Agent
</role>

<task>
<!-- Назначение: Что нужно сделать в коде. Пример: внедрить stateful систему --> Реализовать изменения в проекте строго по спецификации.
</task>

<inputs>
<!-- Назначение: Источники истины. Пример: - context-dump.md - change-request.md -->
<input>context-dump.md</input>
<input>change-request.md</input>
<input>source code</input>
</inputs>

<execution_rules>
<!-- Назначение: Строгие ограничения выполнения. Пример: - не ломать код - не выходить за scope -->
<rule>Следовать change-request.md без отклонений</rule>
<rule>Не изменять лишние модули</rule>
<rule>Сохранять обратную совместимость</rule>
<rule>Не добавлять лишние зависимости</rule>
</execution_rules>
<execution_strategy>
<!-- Назначение: Как по шагам выполнять работу. Пример: 1. анализ 2. план 3. реализация -->
<step>Проанализировать архитектуру проекта</step>
<step>Определить точки интеграции изменений</step>
<step>Внедрять изменения пошагово</step>
<step>После каждого шага проверять стабильность</step>
</execution_strategy>

<implementation_order>
<!-- Назначение: Порядок внедрения фич. Пример: history → limit → summarization -->
1. storage истории
2. ограничение контекста
3. суммаризация
4. system prompt
5. logging
</implementation_order>

<validation>
<!-- Назначение: Проверка результата. Пример: - история работает - лимиты работают -->
<check>История сохраняется</check>
<check>Контекст ограничивается</check>
<check>Суммаризация работает</check> <check>System prompt всегда присутствует</check>
<check>Логи создаются</check>
</validation>

<output>
<!-- Назначение: Что должен вернуть агент. Пример: изменённый код + legacy report --> Изменённый код проекта + legacy-warning.md с анализом проблем.
</output>

<legacy_analysis>
<!-- Назначение: Анализ долгов и проблем. Пример: - performance bottleneck - архитектурный долг --> Описать технический долг, узкие места и архитектурные проблемы. </legacy_analysis>
```

Ну, LLM, погоди…

А mlx как запускаете? Через нативную библиотеку: Python или другие инструменты?

Ну, LLM, погоди…

Как запускаете модели MLX? Я использовал LM Studio. Ollama и llama.cpp не поддерживают mlx пока. Вроде mlx должен быть более производительными на mac, так как и это нативная библиотека от Apple. Ещё на mac можно сделать кластер с помощью exo: https://exolabs.net/ и https://github.com/exo-explore/exo