Как квантовать FP16-модель через Ollama API /api/create

• Квантование выполняется POST /api/create с параметрами model, from и quantize.
• Источник должен быть не квантованным, например float16; API не обещает корректное повторное квантование готового Q4.
• В документации перечислены типы q4_K_M, q4_K_S и q8_0; q4_K_M и q8_0 отмечены как recommended.
• При потоковом ответе этапы включают quantizing, verifying conversion, writing manifest и финальный success.
• Новая модель должна иметь отдельное имя, чтобы исходник оставался доступным для сравнения.

Каждый пункт выше превращается в отдельную проверку. Не объединяйте их в одну расплывчатую проверку вроде «запрос прошёл». Например, HTTP 200 не заменяет проверку status в теле, а подсказка type checker не заменяет runtime-валидацию. Такой подход особенно важен в агентных системах, где модельный ответ, tool call и локальная бизнес-логика имеют разные жизненные циклы.

Что подготовить

• отдельное тестовое окружение и зафиксированную версию зависимости или сервера;
• обезличенный вход без API-ключей, cookie, реальных реквизитов и персональных данных;
• fake tool или model stub, если сценарий способен вызвать внешний side effect;
• лог событий с точными полями, но без полного пользовательского диалога;
• автоматическую проверку, завершающую процесс ошибкой при несовпадении контракта.

До запуска определите, какой эффект допустим. Проверка чтения может обращаться к тестовому endpoint, но публикацию, оплату, удаление и отправку сообщений следует заменить счётчиком или sandbox-реализацией. Retry и resume нельзя тестировать на реальной операции, которую опасно выполнить дважды.

Пошаговая настройка

1. Через /api/show или локальную спецификацию подтвердите, что source действительно FP16; не определяйте это только по догадке из имени.
2. Задайте новое имя, например support:q4km, и quantize:"q4_K_M".
3. Для простого автоматического теста установите stream:false и проверяйте финальный success; для progress используйте NDJSON parser.
4. После завершения найдите оба имени через /api/tags и проведите отдельный качественный тест на фиксированном наборе запросов.

После каждого шага фиксируйте наблюдаемый результат. Если проверяется порядок, храните массив событий. Если тип — используйте isinstance или строгий runtime-флаг. Если HTTP API — проверяйте и status code, и обязательные поля тела. Если состояние сервера — подтверждайте его отдельным read-only endpoint.

Готовый минимальный пример

Сохраните код в отдельный файл. Заполнители в угловых скобках нельзя отправлять как реальные digest или идентификаторы. Пример намеренно останавливается при несовпадении: тихое продолжение превратило бы ошибку в ложный успех.

const source = "llama3.2:3b-instruct-fp16";
const target = "support:q4km";
const res = await fetch("http://localhost:11434/api/create", {
  method: "POST",
  headers: {"content-type": "application/json"},
  body: JSON.stringify({
    model: target,
    from: source,
    quantize: "q4_K_M",
    stream: false
  }),
});
if (!res.ok) throw new Error("quantize HTTP " + res.status);
const data = await res.json();
if (data.status !== "success") throw new Error(JSON.stringify(data));
const tags = await (await fetch("http://localhost:11434/api/tags")).json();
for (const name of [source, target]) {
  if (!tags.models.some(x => x.name === name)) throw new Error("missing " + name);
}
console.log({source, target, quantize: "q4_K_M"});

Для Python запускайте файл в virtualenv проекта. JavaScript-пример сохраните как .mjs и используйте Node.js с глобальным fetch. Не смешивайте глобальную и проектную версии SDK. Перед первым интеграционным запросом выведите только безопасные параметры: endpoint, имя тестовой модели и версию, но никогда токен.

Реалистичный вход

Вход: подтверждённая локальная FP16-модель llama3.2:3b-instruct-fp16; результат сохраняется отдельно как support:q4km.

Ожидаемый результат

Ответ create содержит status success, а tags показывает source и target. Гайд не обещает конкретный размер, скорость или качество: их измеряют на вашей машине отдельно.

Запишите это ожидание в assert или явный throw. Естественно-языковой текст может меняться, поэтому тестируйте стабильный инвариант. Для типов это класс объекта, для approval — число interruptions и executions, для blob — точный status, для create — финальное поле success и независимое присутствие новой записи.

Обязательный негативный тест

Попробуйте передать уже квантованный source либо вымышленное значение quantize. Операция должна завершиться ошибкой, а автоматизация не должна удалять или перезаписывать исходник.

Негативный сценарий запускайте в том же окружении. Он должен сломать ровно проверяемое условие, а не весь стенд. Сетевая недоступность не равна 404, TypeError не равен отказу модели, новый Runner не равен resume, а старое имя в каталоге не доказывает успешную пересборку. Эти различия следует выразить кодом.

Копируемый prompt для ревью

Проверь процедуру квантования: source подтверждён как FP16, target имеет отдельное имя, тип входит в официальный список, success и обе записи tags проверяются, метрики не выдуманы.

Ответ верни таблицей: проверяемое условие, доказательство из кода или лога, PASS/FAIL, минимальное исправление. Не додумывай версии, статусы и результаты. Если доказательства нет, ставь FAIL.

Прикладывайте к prompt минимальный код и очищенный лог. После ответа вручную откройте указанные строки: языковая модель может принять комментарий за работающую проверку. Prompt помогает организовать ревью, но не заменяет запуск тестов.

Как проверить результат независимо

Сделайте таблицу минимум из трёх строк: штатный ввод, намеренно ошибочный ввод и пограничное значение. Для каждой укажите ожидаемую ветку, наблюдаемый признак и фактический результат. Если используется provider stub, считайте модельные обращения. Если tool fake — считайте исполнения. Если API — сохраните status и минимальный JSON без чувствительных данных.

Повторите тест дважды. Второй запуск не должен неожиданно удваивать side effect, использовать старый объект или принимать кешированный результат за новый. Для операций создания выбирайте уникальное тестовое имя и после проверки сверяйте именно его. Для content-addressed blobs сравнивайте полный SHA-256, а не начало строки.