LLM-observability превратилась в отдельную категорию инструментов примерно к середине 2024 года, когда компании начали сталкиваться с проблемами продакшен-LLM-приложений, которые обычный мониторинг не покрывал. APM-системы вроде Datadog или New Relic видят HTTP-запросы, latency и статус-коды — но не содержание промта, не качество ответа, не связь между вызовами внутри многошагового агентного пайплайна. К маю 2026 года рынок консолидировался вокруг трёх решений: LangSmith, Helicone и Langfuse.

Каждый из трёх закрывает одну и ту же базовую потребность — видеть, что происходит внутри LLM-приложения, — но делает это через разные архитектурные подходы. Выбор одного из них определяет, сколько кода придётся написать для интеграции, где будут храниться данные и что именно можно измерять.

Что именно мониторит LLM-observability

Стандартный набор метрик включает: трассировку отдельных LLM-вызовов (входной промт, ответ, модель, latency, стоимость), иерархические spans для многошаговых пайплайнов (какой вызов инициировал какой), оценку качества ответов на регрессионных датасетах, сравнение поведения при изменении промта или модели, мониторинг стоимости в разбивке по пайплайнам и пользователям.

Последний пункт часто недооценивают. При масштабировании LLM-приложения стоимость может расти нелинейно — одна функция с широким контекстом может генерировать 30–40% всех токен-расходов. Без разбивки по вызовам это невозможно обнаружить до тех пор, пока счёт за API не станет неприятным сюрпризом.

LangSmith: нулевая обвязка внутри LangChain-экосистемы

LangSmith — закрытый SaaS от той же команды, что разрабатывает LangChain. Главное преимущество банально: если приложение уже на LangChain, трассировки собираются автоматически при наличии переменной LANGSMITH_API_KEY в окружении. Нет необходимости инструментировать код — фреймворк сам передаёт все вызовы и метаданные.

Сильные стороны выходят за рамки простого логирования. Dataset-инструменты позволяют собирать примеры из продакшен-трафика и прогонять их при каждом изменении промта — это де-факто регрессионное тестирование для LLM-поведения. Менять промт, убедиться что ни один из зафиксированных production-кейсов не сломался — и только потом катить в продакшен. LangChain Evaluators дают готовые оценщики без написания кода: оценка точности, релевантности, галлюцинаций. A/B-сравнение версий промтов с метриками качества встроено в интерфейс.

Слабые стороны столь же конкретны. Стоимость: $39 в месяц за seat плюс плата за объём трассировок сверх квоты — при 10+ разработчиках это ощутимо. Self-hosted-варианта для большинства тарифов нет, что закрывает LangSmith для команд с требованиями по размещению данных. Enterprise-план с self-hosted существует, но его ценник переходит в «договорную» категорию. Вне LangChain интеграция формально возможна через явные API-вызовы, но теряется основное преимущество — автоматическая трассировка.

Helicone: proxy вместо инструментирования

Helicone выбрал принципиально другой подход: HTTP-proxy, через который проходят все запросы к OpenAI, Anthropic и любому совместимому API. Интеграция — замена base_url в SDK на адрес Helicone. Больше ничего менять не нужно: ни код, ни архитектура, ни деплоймент пайплайна.

За этим решением стоит важное следствие: полная независимость от языка и фреймворка. Proxy видит запрос, ответ, latency и стоимость без единой строки инструментирующего кода. Для простых приложений — чат-бот, API-обёртка над моделью, простой completion-сервис — это настоящая нулевая инвазивность. Команда продолжает писать код так, как писала бы без мониторинга, а данные появляются сами.

Ограничение проявляется на сложных агентных архитектурах. Если пайплайн состоит из нескольких LLM-вызовов с логикой между ними, proxy увидит каждый вызов по отдельности, но не поймёт их связь. Трассировка «шаг 1 запросил retrieval, шаг 2 получил контекст, шаг 3 сгенерировал ответ» требует либо явных последовательных API-вызовов, которые Helicone перехватывает, либо ручной разметки через Helicone SDK. На сложных пайплайнах преимущество нулевой инвазивности теряется.

Helicone доступен в SaaS и в self-hosted (Apache 2.0). SaaS бесплатен до 100K запросов в месяц, дальше $20–200 в зависимости от объёма — самая демократичная ценовая модель среди трёх. Для стартапа на ранней стадии, которому нужна хоть какая-то видимость без затрат, это быстрый старт за пять минут.

Langfuse: MIT-лицензия с полным набором возможностей

Langfuse занимает нишу между двумя другими. MIT-лицензированный продукт с полноценным self-hosted-деплойментом через Docker и Helm, и одновременно SaaS поверх той же кодовой базы. По архитектуре ближе к LangSmith — требует инструментирования в коде, — но не привязан к LangChain и работает с любым фреймворком через SDK для Python, JS, Ruby и OpenTelemetry-интеграцию.

Иерархические traces в Langfuse позволяют размечать spans на уровне шагов агента, LLM-вызовов, retrieval-операций, инструментов — всё в одном дереве с временными метками и нагрузкой каждого уровня. Это даёт ответ на вопрос «где именно тратится время в моём пайплайне» с точностью до конкретного шага, а не только суммарной latency запроса.

Prompt management с версионированием и A/B-тестированием — функция, которую Langfuse добавил в 2025 году, раньше она была монополией LangSmith. Теперь промты хранятся в Langfuse, версионируются, тэгируются и подключаются к приложению через SDK. Изменение промта не требует деплоя кода: обновил в панели Langfuse, приложение подхватит при следующем запросе. Встроенные и кастомные evaluators, регрессионные датасеты — всё на уровне LangSmith по функциональности.

Стоимость: бесплатно до 50K observations в месяц, затем $59/мес за стартовый платный план. Self-hosted требует Postgres и Redis — не нулевой операционный overhead, но вполне управляемый для команды с базовой инфраструктурной экспертизой. Self-hosted полностью бесплатен — это принципиальное отличие от LangSmith.

OpenTelemetry и стандартизация трассировок

Отдельная тема, которая становится актуальнее — стандартизация формата трассировок через OpenTelemetry (OTel). CNCF продвигает семантические соглашения для LLM-вызовов в OpenTelemetry, и все три продукта движутся в этом направлении с разной скоростью.

Langfuse поддерживает OTel-совместимые spans. Это означает: если в компании уже есть OTel-коллектор (Grafana, Jaeger, Honeycomb), можно отправлять LLM-трассировки туда же, без отдельного инструментирования для каждого продукта. LangSmith и Helicone поддерживают OTel в менее зрелом виде. По мере того как OTel-соглашения для LLM стабилизируются, lock-in на конкретный инструмент observability будет снижаться — это хорошая новость для тех, кто думает о долгосрочной архитектуре.

Как выбирать

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

Команды на LangChain без требований self-hosting — LangSmith, если бюджет допускает per-seat цену. Нулевое инструментирование и встроенные evaluators перевешивают ценовой минус при небольшой команде. Простые API-приложения без сложных пайплайнов, где нужна минимальная интеграция за пять минут — Helicone. Всё остальное, особенно агентные архитектуры с требованиями self-hosting или open-source-лицензии — Langfuse.

Главное изменение за последний год: разрыв в функциональности между тремя сократился. Каждый из них в 2025 году переписал часть предложения, ориентируясь на сильные стороны конкурентов. Langfuse добавил prompt management, Helicone добавил базовые traces, LangSmith расширил поддержку фреймворков вне LangChain. Сегодня выбор всё меньше про уникальные функции и всё больше про то, какая философия интеграции совпадает с архитектурой конкретного приложения и насколько команда готова управлять собственной инфраструктурой.