Skip to main content
Eye on AI

#335 Sriram Raghavan: Why IBM Is Betting Everything on Small AI Models

60 min episode · 3 min read
·
Sriram Raghavan

Episode

60 min

Read time

3 min

Topics

Productivity, Startups, Fundraising & VC

AI-Generated Summary

Key Takeaways

  • Direct RL vs. Distillation: Training small models directly with reinforcement learning, rather than distilling from larger models, preserves both broad benchmark performance and safety alignment. Distillation improves targeted tasks like code and math but measurably degrades a model's general capabilities and strips away safety alignment — a critical liability for enterprise deployments where compliance and reliability are non-negotiable requirements.
  • Inference-Time Scaling Economics: IBM's Granite 3.3 (8B parameters) matches GPT-4o and Claude 3.5 on code and math benchmarks using inference-time scaling techniques including particle filtering and majority voting. The economic logic: a small model scaled up on-demand for complex tasks costs far less than permanently hosting a large model for all tasks, nine of which may require no heavy compute.
  • Model Parameters as a Misleading Metric: Parameter count is becoming an unreliable way to compare models. Mixture-of-experts architectures and hybrid state-space/attention models (like IBM's Bamba 2, developed with CMU and Princeton) mean a 50B-parameter model can require less memory than a 34B model. Memory footprint per user session at a given context length is a more actionable metric for hardware and deployment decisions.
  • Generative Computing via LoRA Adapters: IBM's "generative computing" framework wraps Granite models in a runtime that activates or deactivates specialized LoRA adapters — for hallucination detection, query rewriting, and uncertainty quantification — without touching base model weights. "Activated LoRAs" share the base model's KV cache, delivering 2–3x efficiency gains over standard LoRA invocations and enabling modular, programmable AI application architectures.
  • Data Quality Over Data Volume: Granite 3.3 was measurably ahead of Granite 3.0 at the halfway point of training, solely due to data quality improvements. The shift in the field has moved from maximizing model size and raw token count to curating high-quality data at every training stage — pre-training, mid-training, instruction tuning, and RL data — with IBM releasing its cleaning pipeline as an open-source project called Data Prep Kit.

What It Covers

IBM Research VP Sriram Raghavan explains why IBM trains its Granite models — currently 2B and 8B parameters — directly using reinforcement learning rather than distilling from larger models, and how combining direct RL training with inference-time scaling allows small models to match GPT-4o and Claude 3.5 on code and math benchmarks at a fraction of the cost.

Key Questions Answered

  • Direct RL vs. Distillation: Training small models directly with reinforcement learning, rather than distilling from larger models, preserves both broad benchmark performance and safety alignment. Distillation improves targeted tasks like code and math but measurably degrades a model's general capabilities and strips away safety alignment — a critical liability for enterprise deployments where compliance and reliability are non-negotiable requirements.
  • Inference-Time Scaling Economics: IBM's Granite 3.3 (8B parameters) matches GPT-4o and Claude 3.5 on code and math benchmarks using inference-time scaling techniques including particle filtering and majority voting. The economic logic: a small model scaled up on-demand for complex tasks costs far less than permanently hosting a large model for all tasks, nine of which may require no heavy compute.
  • Model Parameters as a Misleading Metric: Parameter count is becoming an unreliable way to compare models. Mixture-of-experts architectures and hybrid state-space/attention models (like IBM's Bamba 2, developed with CMU and Princeton) mean a 50B-parameter model can require less memory than a 34B model. Memory footprint per user session at a given context length is a more actionable metric for hardware and deployment decisions.
  • Generative Computing via LoRA Adapters: IBM's "generative computing" framework wraps Granite models in a runtime that activates or deactivates specialized LoRA adapters — for hallucination detection, query rewriting, and uncertainty quantification — without touching base model weights. "Activated LoRAs" share the base model's KV cache, delivering 2–3x efficiency gains over standard LoRA invocations and enabling modular, programmable AI application architectures.
  • Data Quality Over Data Volume: Granite 3.3 was measurably ahead of Granite 3.0 at the halfway point of training, solely due to data quality improvements. The shift in the field has moved from maximizing model size and raw token count to curating high-quality data at every training stage — pre-training, mid-training, instruction tuning, and RL data — with IBM releasing its cleaning pipeline as an open-source project called Data Prep Kit.
  • Multi-Agent Architecture for Enterprise AI: IBM structures enterprise AI as collections of fit-for-purpose small models and agents rather than one large generalist system. Granite 3.3 ships alongside a 2B document-processing model, a speech model, and a vision model. Agents are being built specifically for COBOL/Java software development, IT automation (via Instana, Turbonomic, Apptio), and physical asset management via Maximo — with agent observability, security delegation, and lifecycle governance as active research priorities.

Notable Moment

Raghavan argues that the massive English-language prompts used in today's agent systems are essentially poorly written software programs. Decomposing those prompts into actual programming abstractions — declared instructions, explicit requirements, external verification functions — allows a small model to match a large model's output while eliminating the need to train the model on every formatting rule.

Know someone who'd find this useful?

Episode Transcript

Wonderful to talk to you again. We've spoken on the phone. I met you here at, Yorktown Heights a few months ago. At that time, you were getting ready to release, Granite 3.2, and I wanted to follow-up on that. But I was interested in what you guys were doing. In particular, and I think it's still the case, you have a a 2,000,000,000 parameter model and an 8,000,000,000 parameter model in that 3.2 series, and and what was unique about those models, from what I understood, is that you train them directly, they're not distilled from a larger model. So can you talk a little bit about why that's an advantage? Yep, yep, absolutely. So Craig, first of all, good to see you again. Yeah. And and welcome to Yorktown. So, we'll we'll maybe wind back a little bit to our conversation. I think that was around the time when, which on scene the DeepSeq model for descending distilling. While distilling is an old technique, I'd come back to the fore. Because DeepSeq, in addition to releasing their big model, had also shown this idea that you could take smaller model. I think they had experimented with LAMA and Mistral smaller models. Yep. And said that using the big model, I could distill those LAMA and Mistral models down and get their performance on specific benchmarks like code and math benchmark to really shine well beyond the original capabilities of this model. So that's why distilling was in four. So that's when we when we had the discussion and that was with 3.2 and we have continued that actually and released 3.3 now in the same approach. So there were two reasons why we wanted to explore an alternate approach. So one is while distilling allows you to optimize, especially if you because when you distill, you are basically essentially having this bigger model teach that smaller model to do better at something. That tends to do make that smaller model do better at that that thing, but it does break some of the base training and alignment of that model. So what we had shown was, yes absolutely, lama and mistral models do better at the code and math benchmarks than they were originally doing on their own. I believe they they showed it with the LAMA 8b, I think similar to the model. But you do then lose the broader capabilities of the model. So their bench performance on broader benchmarks goes down. And more importantly it also often and we validate with measurements takes away some of the safety alignment of the models. So what we were doing was to say, we certainly see the logic of that, But as you know, our overall strategy with Gander has been really focused around small language models. And what can you do with smaller models and how far can you push them? Because there's more you can do, you open up AI to run more cheaply in wider …

Get the full transcript (10,552 words) + summary by email — free

One-time email with the complete transcript and AI summary of this episode. No account needed.

One email, no spam. We’ll also show you what SignalCast does.

Browse all Eye on AI transcripts →

You just read a 3-minute summary of a 57-minute episode.

Get Eye on AI summarized like this every Monday — plus up to 2 more podcasts, free.

Pick Your Podcasts — Free

Keep Reading

Books, tools, and gear mentioned in this episode

SignalCast may earn commission on purchases via these links. As an Amazon Associate, SignalCast earns from qualifying purchases.

Tools

  • MaximoBy guest

    by IBM

    Agents are being built specifically for COBOL/Java software development, IT automation (via Instana, Turbonomic, Apptio), and physical asset management via Maximo.
  • TurbonomicBy guest

    by IBM

    Agents are being built specifically for COBOL/Java software development, IT automation (via Instana, Turbonomic, Apptio), and physical asset management via Maximo.
  • InstanaBy guest

    by IBM

    Agents are being built specifically for COBOL/Java software development, IT automation (via Instana, Turbonomic, Apptio), and physical asset management via Maximo.
  • by IBM

    The shift in the field has moved from maximizing model size and raw token count to curating high-quality data at every training stage — with IBM releasing its cleaning pipeline as an open-source project called Data Prep Kit.
  • ApptioBy guest

    by IBM

    Agents are being built specifically for COBOL/Java software development, IT automation (via Instana, Turbonomic, Apptio), and physical asset management via Maximo.

Products

  • by IBM

    IBM trains its Granite models — currently 2B and 8B parameters — directly using reinforcement learning rather than distilling from larger models.
  • Granite 3.3By guest

    by IBM

    IBM's Granite 3.3 (8B parameters) matches GPT-4o and Claude 3.5 on code and math benchmarks using inference-time scaling techniques including particle filtering and majority voting.
  • Granite 3.0By guest

    by IBM

    Granite 3.3 was measurably ahead of Granite 3.0 at the halfway point of training, solely due to data quality improvements.
  • Bamba 2By guest

    by IBM

    Hybrid state-space/attention models (like IBM's Bamba 2, developed with CMU and Princeton) mean a 50B-parameter model can require less memory than a 34B model.

More from Eye on AI

We summarize every new episode. Want them in your inbox?

Similar Episodes

Related episodes from other podcasts

Explore Related Topics

This podcast is featured in Best AI Podcasts (2026) — ranked and reviewed with AI summaries.

Read this week's Startups & Product Podcast Insights — cross-podcast analysis updated weekly.

You're clearly into Eye on AI.

Every Monday, we deliver AI summaries of the latest episodes from Eye on AI and 192+ other podcasts. Free for one show.

Start My Monday Digest

No credit card · Unsubscribe anytime