I run a nightly job for a side project that tags a batch of a few thousand user-submitted items with categories — nothing that needs deep reasoning, just consistent classification. I'd built it against a heavier DeepSeek model, sequentially, one request at a time, and it worked — just slowly. About 40 minutes a night, which I mostly ignored since it ran while I was asleep.
Got curious whether it was worth optimizing after it started creeping closer to an hour as my item volume grew. Two changes, tested separately so I could actually see what mattered:
Change 1 — switched to DeepSeek-V4-Flash for the tagging task specifically (kept the heavier model for one small piece of the pipeline that actually benefits from more careful reasoning). Ran my existing test set through both to confirm tagging accuracy didn't drop — it didn't, for this specific simple classification task.
Change 2 — switched from sequential to concurrent requests, which I honestly should have done regardless of which model I was using, but hadn't gotten around to.
Individually, each change helped. Together: the job went from about 40 minutes to around 6. I can't cleanly attribute the split between the two changes since I made them close together, but doing both was clearly worth more than either alone.
The lesson that generalizes past this specific job: if something feels slow, check whether you're actually using the model tier suited to the task's complexity, and separately, whether you're making requests one at a time when you don't need to. I'd been treating "the API is slow" as one problem when it was really two, and I'd only been thinking about the model choice, not the request pattern.
TL;DR: Cut a nightly batch classification job from ~40 minutes to ~6 by switching to DeepSeek-V4-Flash for the simple tagging task and switching from sequential to concurrent requests. Both changes mattered — worth checking both if your own batch job feels slower than it should.
fastrouteai.com
Top comments (0)