LinkedIn kept AI serving costs flat by replacing frontier models with narrow ones

LinkedIn launched Hiring Assistant with OpenAI models performing most of the work. It now routes established tasks—including candidate search, ranking against a recruiter’s criteria and drafting outreach—to smaller open-weight models customized in-house. OpenAI’s models remain the teachers and the default for new capabilities; once a task is stable, LinkedIn distils the required behaviour into a cheaper specialist.

The company says those replacements produce similar results for their assigned tasks while costing up to 67% less to run than the OpenAI models it used a year ago. That comparison is historical: OpenAI has since cut prices and released more efficient models, and LinkedIn did not disclose whether its specialists remain cheaper than OpenAI’s current offerings. The more robust result is operational. Hiring Assistant passed 25,000 business customers, up from 20,000 in September, while overall serving cost stayed roughly flat. LinkedIn also expects no increase in GPU spending in the fiscal year ending June 2027 despite wider use of its AI features.

This is not a story about abandoning frontier models. They remain valuable for developing features whose task boundary and evaluation criteria are still moving. The cost advantage appears after a workflow becomes narrow enough to measure: candidate retrieval can be checked against a query, rankings can be compared with recruiter choices, and outreach can be constrained by templates and policy. A general model is then an expensive runtime for knowledge already captured in the product.

LinkedIn has an unusual advantage. Microsoft’s arrangement lets it use OpenAI models without paying ordinary API prices, and permits it to distil their outputs into its own models. Many customers are contractually barred from using OpenAI outputs to build competing models. LinkedIn therefore saved as much as 67% on compute alone; a company paying full model fees might save more, but may not possess the same training rights or volume of labelled product interactions.

The scalable architecture is a ladder rather than a single model choice: frontier model for exploration, product data for evaluation, a smaller model for the settled task, and continued escalation when the specialist is uncertain. That shifts the economically important question from “Which model is best?” to “How quickly can a company turn an expensive general capability into a measured, replaceable component?”