Ваша команда ML только что потратила пять инженерных месяцев на развертывание открытого feature store. Ваш финансовый контроллер смотрит на расчетный лист по зарплате и задает вопрос, которого никто в команде не ожидал: эти $180 000 инженерного времени — это расход, который уменьшит прибыль этого квартала, или актив, который попадет на баланс? Ответ меняет ваш burn multiple, расчет runway и — если вы привлекаете финансирование — ту историю, которую рассказывает ваша финансовая отчетность. И он полностью меняется в зависимости от того, строили ли вы на Feast или купили Tecton.
Feature store — это инфраструктура, которая управляет признаками (features) для машинного обучения, хранит их и предоставляет как для обучения, так и для инференса в реальном времени. Его основная задача — предотвратить расхождение между обучением и выдачей (training-serving skew): гарантировать, что модель видит в продакшене ровно те же признаки, на которых обучалась. Архитектура состоит из пяти движущихся частей — offline store для обучающих данных, online store для выдачи с низкой задержкой, пайплайны признаков, которые вычисляют значения, центральный реестр признаков (feature registry) и serving API. Когда команды выбирают между Feast и Tecton, они выбирают между двумя совершенно разными моделями владения, и каждая модель дает совершенно разный бухгалтерский учет.
Feast против Tecton: компромисс «создавать или купить»
Feast — ведущий открытый feature store: бесплатный, развертываемый самостоятельно, гибкий. Вы сами управляете online store (обычно Redis или DynamoDB), offline store (S3, BigQuery или Snowflake), и на вас ложатся все обновления, дежурства по инцидентам и решения о масштабировании. Tecton — полностью управляемая коммерческая альтернатива, созданная членами команды, стоявшей за платформой Michelangelo от Uber. Она берет на себя online- и offline-выдачу, потоковые вычисления признаков и встроенный мониторинг признаков по корпоративному SaaS-контракту.
Стандартное сравнение выглядит так:
| Фактор | Feast | Tecton |
|---|---|---|
| Стоимость лицензии | Бесплатно (только расходы на инфраструктуру) | Корпоративные SaaS-цены |
| Online-выдача | Redis, DynamoDB — управляете вы | Полностью управляемая |
| Offline store | Parquet, BigQuery, Snowflake — настраиваете вы | Управляемый |
| Потоковые признаки | Push-модель, пайплайны строите вы | Нативные вычисления в реальном времени |
| Мониторинг признаков | Внешние инструменты, которые вы собираете | Встроенный |
| Операционная нагрузка | Высокая — ваша команда делает всё | Низкая — SLA вендора |
В бухгалтерской версии этой таблицы есть еще одна строка: где именно появляются деньги. С Tecton почти вся стоимость приходит в виде счета от вендора — расхода на подписку. С Feast строка лицензии нулевая, а реальная стоимость прячется в зарплате инженеров: недели, которые ваши дата-инженеры тратят на развертывание реестра, написание пайплайнов признаков, настройку online store и создание мониторинга, который Feast не поставляет. Инфраструктура с «нулевой стоимостью лицензии» все равно требует строки в P&L на инженерные часы, и именно этой строкой управляет ASC 350-40.
Бухгалтерский вопрос: что на самом деле говорит ASC 350-40
По U.S. GAAP расходы на внутренне используемое программное обеспечение регулируются ASC 350-40, который распределяет каждый доллар программного проекта по одному из трех этапов (общая методология изложена в нашем практическом руководстве по выбору между капитализацией и списанием в расходы):
- Предварительный этап проекта — расход по мере возникновения. Оценка вендоров, пилотные прототипы, сравнение Feast с Tecton, исследование осуществимости и сам анализ «создавать или купить». Все это сразу попадает в P&L.
- Этап разработки приложения — капитализируются подходящие затраты. Как только руководство одобрило и утвердило проект, затраты на проектирование, написание кода, конфигурирование, тестирование и интеграцию ПО капитализируются в актив и амортизируются в течение срока полезного использования. Это единственный этап, который создает актив.
- Этап после внедрения и эксплуатации — расход по мере возникновения. Обучение, поддержка, исправление ошибок и текущая эксплуатация после запуска. Новая функциональность, добавленная позже, может заново запустить капитализацию, но поддержание работы никогда этого не делает.
Чтобы войти в этап разработки приложения, должны выполняться два условия: руководство с соответствующими полномочиями одобрило проект (явно или неявно), и вероятно, что проект будет завершен, а ПО будет использоваться по назначению. Пока оба условия не выполнены, каждый доллар — это все еще расход предварительного этапа, включая «прототип», который позже станет продакшеном.
Капитализация также имеет узкое определение подходящих затрат. Прямая зарплата разработчиков, работающих над созданием, связанные с зарплатой расходы, такие как льготы, и платежи третьим сторонам — внешним разработчикам, работающим над проектом, — как правило, подходят. Конвертация данных из старой системы, обучение, поддержка, общие накладные и административные расходы — нет, даже если они понесены в период разработки приложения.
Соотнесение работ над feature store с тремя этапами
Вот как типичное создание на Feast соотносится с ASC 350-40:
Расход: оценка. Ваша команда три недели сравнивает Feast с Tecton, пробует пример пайплайна и читает документацию вендора. Предварительный этап — расход. Это верно, даже если код прототипа позже переиспользуется в продакшене; этап определяется целью деятельности в тот момент, а не тем, чем становится код.
Капитализация: создание. Руководство одобряет решение в пользу Feast и финансирует проект. Инженеры теперь развертывают реестр, пишут продакшен-определения признаков, строят batch- и streaming-пайплайны, интегрируют online store с вашим сервисом инференса и проводят интеграционное и нагрузочное тестирование. Прямая зарплата инженеров в этом окне плюс любые гонорары подрядчиков за внедрение капитализируются — при условии, что вы можете документально подтвердить, кто над чем работал и когда.
Расход: всё после запуска. Ваше дежурство настраивает задержку Redis, делает backfill признака после ошибки в пайплайне, подключает новые модели к существующим пайплайнам, обновляет версии Feast и поддерживает дашборды мониторинга. После внедрения — расход. Если через шесть месяцев вы добавите действительно новую возможность, например streaming-пайплайн для новой продуктовой линейки, это отдельное улучшение может претендовать на собственное окно капитализации.
Самый распространенный сценарий провала — отсутствие документального следа. Капитализация без одновременного учета времени по этапам проекта редко выдерживает аудит. Если время ваших инженеров не отслеживается отдельно по работе над feature store и по обычной работе, ваш аудитор спишет всё в расходы — что, возможно, и есть правильный ответ, но это должно быть решением, а не вариантом по умолчанию.
Что меняется, когда вы вместо этого покупаете Tecton
Покупка управляемого feature store переворачивает бухгалтерскую картину. Tecton — это сервисный контракт, а не ПО, которым вы владеете, поэтому плата за подписку — это операционные расходы, признаваемые в течение срока контракта: просто, предсказуемо и устойчиво к аудиту.
Тонкий момент — внедрение. Настройка SaaS-платформы под ваше использование — интеграция Tecton с вашим хранилищем данных, подключение serving API к инференсу, миграция определений признаков — следует той же логике ASC 350-40 в рамках руководства по облачным вычислениям: затраты на внедрение на этапе разработки приложения могут претендовать на капитализацию, даже если само ПО хостится у вендора. На практике внедрения Tecton достаточно коротки, чтобы многие небольшие компании списывали их в расходы по соображениям существенности. Но если ваша интеграция вырастает в шестизначные затраты инженерного времени, применяется тот же анализ этапов и тот же стандарт документации.
Здесь есть стратегическая сноска для основателей, привлекающих финансирование. Капитализация создания на Feast улучшает показатели EBITDA и валовой маржи текущего периода ценой растущего бремени амортизации и актива, который тщательно изучит команда due diligence приобретателя. Списание подписки Tecton в расходы сохраняет честность P&L в отношении run-rate burn, но делает цифры этого года более тяжелыми. Ни один из подходов не «лучше» — но инвесторы спросят, какой вы выбрали и почему, поэтому выбирайте осознанно и документируйте обоснование.
ASU 2025-06: модель этапов уходит в прошлое
Трехэтапная модель восходит к 1998 году, когда ПО создавалось последовательными водопадными фазами с четкими границами. Она плохо подходит для agile, итеративной работы над feature store — какой спринт является «предварительным», когда каждый спринт поставляется в продакшен? FASB согласился. В сентябре 2025 года он выпустил ASU 2025-06, который отменяет правила, основанные на этапах, и заменяет их принцип-ориентированным подходом, сосредоточенным на том, остается ли значительная неопределенность разработки.
По новой модели капитализация начинается, когда руководство одобрило проект, завершение и использование по назначению вероятны, и концепция прошла стадию значительной неопределенности относительно требований к производительности, подхода к разработке или осуществимости. Он вступает в силу для финансовых лет, начинающихся после 15 декабря 2027 года, с разрешенным досрочным применением. Для сборки feature store, начинающейся сегодня, практический совет не меняется: получите меморандум об одобрении, отслеживайте время по проекту и отделяйте оценку от создания. Эти привычки удовлетворяют и старым этапам, и новым принципам.
Практическое руководство для вашего feature store
Выбираете ли вы Feast, Tecton или третий вариант, пять практик сохраняют учет чистым:
Получите одобрение в письменном виде до начала создания. Письмо от CTO, одобряющее создание на Feast, бюджет и предполагаемое использование в продакшене, удовлетворяет порогу одобрения. Поставьте дату. Аудиторы запрашивают этот документ первым.
Отслеживайте инженерное время по этапам с первого дня. Оценочные прототипы — в одну корзину, работу над продакшен-сборкой — в другую, поддержку после запуска — в третью. Учет времени по тегам или маркировка спринтов одинаково подходят; воссоздание разбивки по памяти через шесть месяцев — нет.
Капитализируйте только прямые затраты. Зарплату и льготы разработчиков за часы работы над созданием плюс счета подрядчиков, привязанные к внедрению. Исключите обучение, миграцию данных из устаревших пайплайнов, распределение накладных расходов и счет за облачную инфраструктуру для работы online store — хостинг это операционный расход готовой системы, а не расход на ее создание.
Выберите срок амортизации, который сможете обосновать. Внутренне используемое ПО обычно амортизируется линейно в течение трех-пяти лет. Feature store, построенный на быстро развивающемся открытом проекте, где мажорная версия Feast может вынудить пересборку, аргументирует в пользу короткого конца. Документируйте обоснование в меморандуме о капитализации.
Проверяйте на обесценение при изменении фактов. Если вы бросаете сборку на Feast на полпути и подписываете контракт с Tecton, капитализированный актив обесценивается — спишите его. То же самое, если разворот стратегии убивает продуктовую линейку, которую обслуживал feature store. Капитализированное ПО, у которого больше нет применения, не является активом.
Частые ошибки, ведущие к аудиторским корректировкам
Ошибки, которые аудиторы находят в капитализации инфраструктуры, удручающе однотипны. Капитализация этапа оценки — сравнения вендоров, прототипа, пилота — самая частая; работа предварительного этапа никогда не подлежит капитализации, какой бы полезной она ни оказалась. Капитализация поддержки под видом разработки — вторая по частоте: настройка задержки выдачи и backfill признаков это эксплуатация, а не создание. Третья — отсутствующий меморандум: капитализированное сальдо без документа об одобрении, без анализа этапов и без обоснования амортизации списывается в расходы по общим принципам. Четвертая — амортизация по фантастическим срокам, например десять лет для инфраструктуры, привязанной к открытому проекту, который ежегодно выпускает ломающие изменения. И пятая — полное забвение облачного счета: команды, которые аккуратно капитализируют зарплату, но игнорируют шестизначный годовой run rate на DynamoDB и вычисления, искажают то самое сравнение «создавать или купить», которое изначально обосновало проект.
Отслеживайте сборку как актив, которым она может стать
Решение между Feast и Tecton обычно подают как инженерную гордость против удобства вендора. Переформулируйте его как финансовый вопрос — и компромисс обостряется: Feast превращает денежное вознаграждение в капитальный актив с хвостом амортизации, тогда как Tecton превращает ту же возможность в чистый операционный расход со сроком продления. Ваша модель runway, ваша валовая маржа и ваша история для due diligence — всё меняется вместе с выбором, и именно поэтому бухгалтерский учет заслуживает места на архитектурном ревью, а не сноски после него.
Это начинается с обычной дисциплины бухгалтерского учета: время с тегами проекта, датированное одобрение, счета подрядчиков, привязанные к сборке, и меморандум о капитализации, по которому ваш аудитор сможет пройти. Если ваши затраты на feature store сейчас лежат как недифференцированная зарплата инженеров в одном счете, вы уже потеряли возможность капитализации — записи невозможно восстановить задним числом.
Упростите управление финансами
По мере масштабирования вашей ML-инфраструктуры поддержание четких финансовых записей для решений «создавать или купить», капитализированного ПО и графиков амортизации становится необходимым. Beancount.io обеспечивает бухгалтерский учет в виде обычного текста, давая вам полную прозрачность и контроль над финансовыми данными — никаких черных ящиков, никакой привязки к вендору. Начните бесплатно и узнайте, почему разработчики и финансовые специалисты переходят на бухгалтерский учет в виде обычного текста.
