Рабочий процесс терминала Ollama даёт команде локальную базовую линию. Он не показывает, сохранит ли хостируемый маршрут поведение, от которого зависит приложение. Рассматривайте миграцию как контролируемое воспроизведение: сохраняйте контракт рабочей нагрузки неизменным, меняйте только маршрут и варианты моделей, а затем изучайте результаты, прежде чем переводить трафик.
Используйте OdiRouter для хостируемого сравнения, если для оценки подходит ориентированная на разработчиков платформа с единым API. Перед запуском теста проверьте актуальную OdiRouter getting-started documentation, чтобы уточнить сведения о маршруте, модели и аутентификации, применимые к вашей учётной записи.
Начните с контракта рабочей нагрузки
Прежде чем менять конечную точку, зафиксируйте важные виды работы. Небольшой контракт может охватывать от 10 до 30 репрезентативных задач: структурированное извлечение данных, объяснение кода, проверку конфигурации, суммирование журналов, классификацию обращений в поддержку или ответ в формате вызова инструмента. Контракту необходимо последовательное определение как успешного прохождения, так и сбоя.
Для каждой задачи зафиксируйте промпт, системную инструкцию, требуемый формат вывода, тайм-аут, правило приемки и при необходимости примечание для ручной проверки. «Ответ выглядит хорошо» нельзя оценивать последовательно. «Возвращает корректный JSON с risk, reason и next_action, не выдумывая имя файла» — можно.
Храните контракт в системе контроля версий. Если в ходе сравнения меняются промпт, схема инструмента, парсер или правило оценки, зафиксируйте новую версию теста вместо замены старой базовой линии.
Зафиксируйте локальную базовую линию
Прогоните контракт через терминальный путь, который уже использует приложение. Запишите локальный идентификатор модели, версию среды выполнения, параметры запроса, необработанный ответ, результат работы парсера, задержку и итоговую оценку задачи. Если клиент обращается к собственной конечной точке, используйте этот путь в качестве базового. Если используется совместимый клиент, оставьте этот клиент без изменений.
Неудовлетворительный результат может быть получен на разных уровнях. Модель может не справиться с поставленной задачей должным образом. Конечная точка может отклонить поле, вернуть ошибку в иной форме, иначе передавать потоковые данные или выдать ответ, который парсер не сможет обработать. Не относите все такие результаты к «качеству модели».
Воспроизведите контракт через размещенный маршрут.
Для первого запуска в хостинговой среде измените только переменные, необходимые для перехода. Обычно это конечная точка, учётные данные и идентификатор модели. Не настраивайте промпты, не ослабляйте парсер, не исключайте сложные случаи и не расширяйте правило оценки. Позже такие изменения могут оказаться полезными, но они отвечают на другой вопрос.
Используйте чёткую границу конфигурации, чтобы запуск можно было повторить:
export LOCAL_BASE_URL="http://localhost:11434"
export HOSTED_BASE_URL="https://your-hosted-route"
export LOCAL_MODEL="your-local-model"
export HOSTED_MODEL="your-hosted-model"
./replay-contract --base-url "$LOCAL_BASE_URL" --model "$LOCAL_MODEL" --contract contract.jsonl
./replay-contract --base-url "$HOSTED_BASE_URL" --model "$HOSTED_MODEL" --contract contract.jsonlНазвания команд приведены в качестве примеров. Сохраняйте один контракт, один путь оценки и небольшой набор объявленных переменных. Настраивайте хостинговый маршрут по актуальной документации OdiRouter, а не копируйте устаревшие сведения о конечной точке или модели в рабочую инструкцию.
Измеряйте поведение и протокол раздельно
Оцените качество ответов, затем проанализируйте поведение протокола. Полезные показатели включают долю принятых задач, долю валидных JSON, отсутствующие или лишние поля, дрейф значений enum, обёртку в Markdown, форму аргументов вызова инструмента, поведение при отказе, ошибки аутентификации, повторные попытки, тела ответов при тайм-ауте и сбои парсера.
Задержка и стоимость служат подтверждающими данными. Фиксируйте время до первого токена, если оно доступно, общую задержку, число повторных попыток, число тайм-аутов и использование токенов, если провайдер его возвращает. Сравнивайте стоимость одного принятого результата, а не принимайте низкую цену запроса за самостоятельное решение. Длина промпта, повторные попытки, параллелизм и доля принятых результатов могут изменить итог.
Установите критерий решения до повторного прогона
Выберите порог до анализа результатов хостингового запуска. Команде может потребоваться процент принятых задач (95), отсутствие отклонений от схемы для критически важных задач, частота повторных попыток в пределах допустимых значений и проверенный путь отката. Для другой рабочей нагрузки могут потребоваться другие ограничения. Внутренний разработчик-помощник способен справиться с большим количеством вариаций, чем автоматизированный процесс обработки запросов клиентов.
Примените к забегу один из трех вариантов развития событий:
Переходите, когда хостинговый маршрут проходит пороговые значения по контракту и эксплуатации.
Приостановите выполнение, если не будет выполнена критически важная задача или не будет соблюдено требование протокола.
Разделяйте, когда одни задачи подходят для хостингового маршрута, а другие должны оставаться локальными.
В записи о решении должны быть указаны версия контракта, локальная среда выполнения, локальная модель, хостинговая модель, версия конфигурации маршрута, сводка оценок, исключения, ответственный и условие следующего повторного тестирования.
Сохраняйте локальный путь и проводите повторное тестирование осознанно
Миграция не требует удаления локальной базовой линии. Сохраняйте контракт, локальные метаданные, хостинговые метаданные, записи ответов, журналы парсера и таблицу оценок. Эти артефакты помогают команде выявлять последующий дрейф в локальной среде выполнения, редакции модели, поведении конечной точки, обновлении SDK, схеме инструмента или правке промпта.
Некоторые рабочие нагрузки могут оставаться локальными из-за офлайн-использования, ограничений на обработку данных, задержки в настольном приложении или неподдерживаемой хостинговой возможности. Зафиксируйте причину и дату повторного тестирования. Задокументированное исключение можно пересмотреть. Незадокументированное исключение часто становится постоянным.
Используйте OdiRouter в качестве этапа оценки
OdiRouter может поддержать хостинговую сторону оценки, но не заменяет приёмочный тест, ориентированный на конкретную рабочую нагрузку. Начните с OdiRouter getting-started documentation, выберите маршрут-кандидат и модель на основе актуальной информации о продукте, затем повторите прогон контракта, не меняя саму работу.
Когда результаты проходят проверку, переносите только ту рабочую нагрузку, которая её прошла. Если они не проходят проверку, сохраните локальный маршрут, точно зафиксируйте сбой и повторно запустите тот же контракт после следующего существенного изменения.