<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>LLM on Tyler Collins</title>
    <link>https://www.tk11br.ca/tags/llm/</link>
    <description>Recent content in LLM on Tyler Collins</description>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>2022-2026 Tyler Collins. Content licensed under CC BY-NC 4.0.</copyright>
    <lastBuildDate>Thu, 15 Oct 2026 12:00:00 -0400</lastBuildDate>
    <atom:link href="https://www.tk11br.ca/tags/llm/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Your LLM Loop Is a Batch Job</title>
      <link>https://www.tk11br.ca/posts/your-llm-loop-is-a-batch-job/</link>
      <pubDate>Thu, 15 Oct 2026 12:00:00 -0400</pubDate>
      <guid>https://www.tk11br.ca/posts/your-llm-loop-is-a-batch-job/</guid>
      <description>800,000 small requests in a day slows a shared LLM service down for everyone. If your workload looks like that, a batch job on a GPU node will finish sooner.</description>
      <content:encoded><![CDATA[<p>Today I had to rate limit a user on SHARCNET&rsquo;s internal LLM service for the first time. In the last 24 hours they had sent about 800,000 requests, and every single one was under 500 tokens.</p>
<p>To be clear, they didn&rsquo;t do anything wrong. The service is set up to let them do it. They had a pile of small work and a working endpoint, so they wrote some sort of loop. I probably would have done the same. But a loop that sends hundreds of thousands of tiny prompts is a batch job, and this was a really good reminder of why batch clusters are still super important.</p>
<h2 id="what-that-load-does-to-a-shared-service">What that load does to a shared service</h2>
<p>A shared LLM endpoint is set up for lots of people asking questions here and there, interactive use. One person sending 800,000 of them back to back is a pretty different workload. Spread over a day, that&rsquo;s roughly nine requests per second, all day and all night.</p>
<p>Every one of those requests costs something before the model even sees it. Each is a network round trip with its own connection overhead and its own spot in the queue. It also messes with caching. Inference servers lean on caches to keep things quick for the people already using them, and a steady flood of unrelated prompts pushes that useful state out. Time-to-first-response goes up for everyone, including the person asking a single question in a chat window who did nothing different.</p>
<h2 id="why-a-batch-job-is-faster">Why a batch job is faster</h2>
<p>On a GPU node in a batch job, you get the whole device to yourself. Nobody else&rsquo;s traffic is in the queue, and there&rsquo;s no network between your data and the model.</p>
<p>The bigger win is how the work gets handed over. Offline inference with a tool like <a href="https://docs.vllm.ai/">vLLM</a> takes the entire list of prompts at once and packs them onto the GPU as tightly as it can. Small prompts are where that pays off most, because one small prompt on its own leaves most of the GPU idle. Hand it 800,000 together and it keeps the device busy the whole time. You load the model once, point it at your dataset, and collect the results when the job ends.</p>
<h2 id="if-this-is-you">If this is you</h2>
<p>If your workflow loops over a dataset and calls an LLM once per row, please don&rsquo;t forget about classic HPC. Write it as a batch job, run it on a GPU node, and keep the shared service for the interactive stuff it&rsquo;s good at.</p>
<p>You&rsquo;ll get more done quicker, and everyone else gets their response times back!</p>
<h2 id="related-posts">Related posts</h2>
<ul>
<li><a href="/posts/serial-farms/">Serial Farms: Package Options and When to Switch to Farming</a></li>
</ul>
]]></content:encoded>
    </item>
  </channel>
</rss>
