I Benchmarked My AI Carb Counter on 400 Meal Photos: 8 Models, 1 Holdout Set
I build Soba, an iPhone app that looks at a photo of a meal and estimates the carbs in it. People with type 1 diabetes use numbers like that to dose insulin, so "it seems to work" wasn't a good enough answer. I ran it on 400 meal photos from two public research datasets where the carbs were weighed or recorded, and published the method, the misses and the per-meal data on the Soba accuracy page.
This post is the engineering side of that test: how the benchmark was set up, which of eight models won, and the bugs a production-path test turns up that a separate eval harness can miss. The full write-up on my blog has the per-meal-size breakdown and the comparison with published ChatGPT studies.
The setup
The photos come from Nutrition5k (Google cafeteria plates, every ingredient weighed, fixed overhead camera) and SNAPMe (95 people in the US photographing their own meals and logging them in a food record). The first is clean, controlled data. The second looks like what users actually shoot.
A few choices did most of the work:
- A script with a fixed seed drew 25 meals from each quarter of the carb range, per dataset, so no part of the range ended up under-sampled by chance.
- Cafeteria plates photographed within the same ten minutes often look nearly identical, so the script capped how many it took from one ten-minute window. The confidence intervals come from a bootstrap that resamples whole clusters (all photos from one SNAPMe participant, or from one ten-minute cafeteria window), because near-duplicate photos aren't independent samples.
- There are two disjoint sets of 200. All error analysis and prompt work happened on the first set; the second stayed untouched until a result needed confirming.
- Every photo was downscaled to 1,024 px on the long side like the app does and sent through the same server code, with the same instructions and model settings. There's no eval-only prompt.
- The main metric is the share of meals within 10 g of the reference carbs, roughly one bread unit. Failed scans count as misses (there were none).
The results in one table
| Setup | Meals | Within 10 g | Median error |
|---|---|---|---|
| Photo only, all meals | 400 | 68.5% | 5.2 g |
| Photo + text hint | 400 | 72.8% | 4.5 g |
| Photo only, cafeteria (Nutrition5k) | 200 | 77.5% | 3.9 g |
| Photo + depth data, cafeteria | 200 | 82.0% | 3.1 g |
| Photo only, own photos (SNAPMe) | 200 | 59.5% | 6.8 g |
| Photo only, meals with 60 g+ carbs | 42 | 19.0% | 25.4 g |
The headline 68.5% has a 95% interval of 64.0% to 72.9%. The last row shows the main failure. In 38 of the 42 largest meals the estimate was too low, with the median estimate at 64% of the real amount. In 30 of those 38, the model judged the food to weigh at least 15% less than it did, while its carbs per 100 g were usually close.
!Scatter plot of 400 meals: actual carbs vs Soba's estimate. Most points sit inside the ±10 g band up to about 50 g; above 60 g most fall below it.
Every meal in the test. The shaded band is ±10 g; points below the dashed line are underestimates.
The per-meal CSV is public, so you can check the headline numbers yourself with the standard library:
import csv, io, statistics, urllib.request
URL = "https://soba-app.com/accuracy/soba-carb-benchmark-2026-10.csv"
with urllib.request.urlopen(URL) as resp:
rows = list(csv.DictReader(io.TextIOWrapper(resp, "utf-8")))
errs = [abs(float(r["soba_total_carbs_g"]) - float(r["reference_total_carbs_g"])) for r in rows]
print(f"within 10 g: {sum(e <= 10 for e in errs) / len(errs):.1%}")
print(f"median error: {statistics.median(errs):.1f} g")
within 10 g: 68.5%
median error: 5.2 g
Eight models, and why the winner didn't ship
I ran eight models on the first 200 meals with Soba's prompt, one run each through OpenRouter, with the request settings Soba had before October 2026. These were separate runs, so production's numbers differ slightly from the table above:
| Model | Within 10 g | Median time |
|---|---|---|
| Gemini 3.7 Flash | 73.0% | 3.7 s |
| Gemini 3.8 Flash | 71.5% | 4.8 s |
| Gemini 3.5 Flash-Lite | 69.0% | 2.1 s |
| Gemini 3.6 Flash (production) | 67.5% | 3.3 s |
| GPT-6 Luna | 65.0% | 6.9 s |
| GPT-6 Luna Pro | 63.0% | 11.7 s |
| GPT-6.1 Sol | 58.0% | 13.1 s |
| Claude Sonnet 5.5 | 53.0% | 6.0 s |
Gemini 3.7 Flash beat production by 5.5 points. That's enough of a lead to make a switch look obvious. But when you pick the best of eight on the same 200 samples, part of the winner's lead is luck, so I ran both models on the untouched second set. They tied at 70.5%, and 3.7 Flash costs more. Production stayed on Gemini 3.6 Flash.
Two more rows need a footnote. Claude Sonnet 5.5 returned an empty food item for 41 of the 200 photos through the provider OpenRouter routed it to; on the other 159 photos it scored 66.7%, right in the pack. If the harness had silently dropped empty answers, that model would have looked competitive, and the 41 empty answers would never have shown up. And GPT-6.1 Sol overestimated carbs by 10 g on average, a bias you'd only notice by looking at signed errors.
Letting Gemini 3.6 Flash reason longer raised the share within 10 g by 4.1 points over all 400 meals, but the share within 5 g and the number of errors above 30 g stayed the same, and each scan took 6.6 seconds instead of 3.5. More thinking pushed medium errors under the line and did nothing for the large ones. I kept the fast setting.
Bugs that only a full run finds
The test pushed 3,614 requests through production code. Two problems fell out that normal traffic never surfaced:
1. The fallback model couldn't run. Soba sent a temperature parameter that the OpenAI backup didn't accept, and the request allowed only providers that support every parameter in it (OpenRouter's require_parameters option). So the OpenAI backup would have failed on every scan the moment Gemini went down. Removing the parameter moved the main model from 68.9% to 68.5%, inside run-to-run noise. The backups are now Gemini 3.7 Flash and GPT-6 Luna.
2. Repetition loops. In 9 of 3,614 requests (0.25%), Gemini repeated one phrase over and over, and the scan took 35 to 87 seconds. A cap on answer length now cuts those off early.
A spot check of ten photos wouldn't have caught either one. The loops only appeared in the latency tail of 3,614 requests, and the dead fallback only when the backup itself was called.
What extra inputs added
Since the dominant error was portion weight, I tested what extra inputs add:
- A text hint naming the foods (copied from the dataset records, no amounts) lifted the share within 10 g from 68.5% to 72.8%. It helped most on ambiguous photos, like a coffee with creamer that Soba had read as caramel sauce (162 g estimated without the hint, 5.5 g with it, 2.7 g in the food record). It didn't fix the main failure: large meals were still underestimated in 37 of 42 cases with a hint. The gain was also lopsided between the two sets (8.0 points vs 0.5), and real users won't type as precisely, so I treat it as an upper bound.
- Depth data lets the app tell the model how wide the frame is in centimeters, on iPhones with LiDAR or multiple rear cameras. Replayed from Nutrition5k's depth recordings on its 200 cafeteria photos, it lifted the share within 10 g from 77.5% to 82.0%. Large meals were still underestimated in 12 of 13 cases, and angled photos haven't been measured yet.
- The weight editor in the UI is the fallback for big plates. The app shows a weight range with each estimate and recalculates when the user enters a real weight. The real plate weight fell inside the shown range on 97 of 200 weighed plates, about half, so treat the range as a guide; typing in a weight from a kitchen scale is the reliable fix.
Takeaways for anyone benchmarking a vision LLM
1. Keep a holdout set and don't touch it while tuning. Mine stopped a model switch that the first-round numbers made look obvious.
2. Break results down by the size of what you're estimating. The 68.5% average hid a 19% result on the biggest meals.
3. Count failures as misses, and look at signed errors. Empty answers and systematic bias both disappear in a careless average.
4. Run the eval through the production code path. Mine found a dead fallback and a 0.25% latency tail that a separate eval harness could easily have missed.
5. Find the bottleneck before you shop for models. Here it was portion weight on large plates, and the inputs that carry scale (depth, a weight the user enters) go after it more directly than a model swap. Even depth left 12 of 13 large meals underestimated.
The full method, the limits (US-only meals, overhead camera on one dataset, self-reported references on the other) and the 400-row CSV are on the Soba accuracy page. The blog version has the meal-size table and how the numbers compare with published ChatGPT-4o and ChatGPT-5 studies.
Soba isn't a medical device. Its numbers are estimates: check them against labels and a scale, and follow your diabetes care plan.
2 reactions · 2 comments
Mentions
SigLIP2に匹敵する画像エンコーダーをフルスクラッチで開発した話 はじめに Noetraでは、フィジカルAIの実現に向けて、国産マルチモーダルLLMの開発を進めています。その基盤技術の一つとして、本記事では画像エンコーダーをフルスクラッチで構築した取り組みについて紹介します。 近年、国内外の企業・研究機関でマルチモーダルLLMの開発が活発化しています。多くのモデルは、言語モデルを独自開発している一方で、画像エンコーダーにはSigLIP2に代表される、非公開データで学習された高性能なモデルを利用しています。しかし、そのデータや学習過程が分からないままでは、透明性や安全性に関する懸念が残ります。 そこで我々のチームでは、自立した国産マルチモーダルLLMを実現するために、言語モデルだけでなく画像エンコーダーも自ら構築・学習することにしました。データ収集から事前学習手法、モデル構造に至るまで把握可能なスクラッチ開発は、透明性・安全性を確保するうえで重要であり、将来的な性能改善の余地も残せます。 本取り組みでは、ViT-SO400M-14-SigLIP2に対して英語ベンチマークで同等、日本語・中国語ベンチマークでより高い性能を達成しました。さらに、この画像エンコーダーをマルチモーダルLLMに適用したときに、SigLIP2を上回る性能を確認しました。この記事では、大規模画像・テキストデータを用いた画像エンコーダーのスクラッチ学習の詳細と、これを用いたマルチモーダルLLMのVisionタスクにおける初期実験の結果についてお伝えします。 学習データの構築 SigLIP2のような画像エンコーダーを学習するには、大量の画像・テキストペアが必要になります。そこで、学習データにはCC3M・CC12M・datacomp_1b・llm-jp-image-text-pairs・MINT-1T-HTML・OBELICS・OmniCorpus-CC・relaion2B-en-research-safe・relaion2B-multi-research-safe・WAONを選定しました。 ここで、MINT-1T-HTML、OBELICS、OmniCorpus-CCについては、文書の中に画像が挿入されているInterleavedデータと呼ばれる形式のため、次に示すような処理によって画像・テキストペアへの変換を行いました。 Interleavedデータの画像・テキストペアへの変換 Web上にある画像が挿入されたドキュメントには、画像とテキストのアライメントに重要な情報が豊富に含まれています。しかし、こうしたInterleaved形式のデータは、そのまま画像・テキストペアとしてCLIPなどの学習に利用することができません。そこで本取り組みでは、以下の手順でInterleavedデータを画像・テキストペアへ変換して利用しました。 各ドキュメントのすべての文章を1文ごとに分割します（ただし、5文字以下の短すぎる文はドロップします）。 画像と、その画像が含まれるドキュメント内の全本文との類似度をSigLIP2で計算します。 類似度が最も高い文をその画像のキャプションとして抽出します。なお、十分に画像と関連した文が見つからない場合は、後述する類似度フィルタリングによって除外されます。 画像・テキストペアのフィルタリング 収集したデータに対して、欠損データの除去、画像ベースのフィルタリング、言語ベースのフィルタリング、画像・テキスト類似度フィルタリング、および画像重複除去を実施し、高品質な画像・テキストペアからなる大規模学習データセットを構築しました。各工程におけるデータ数の推移を下図に示します。 欠損データの除去 テキストと画像がペアになっていないデータを削除しました。 画像ベースのフィルタリング アスペクト比（1:3以内）、画像サイズ（50px以上）でフィルタリングを行いました。 言語ベースのフィルタリング 5文字以下のデータを除外しました。また、言語フィルタも適用し、英語・日本語・中国語のデータのみを残しました。中国語については、日本語と漢字を共有していることから、OCRや文書画像理解における転移効果が期待できるため保持しています。最終的な学習データのうち、日本語は約9.0%、中国語は約3.4%を占めています。 画像・テキスト類似度フィルタリング Webから大量収集したデータには、画像と関係のないテキストペアも多く含まれるため、これらをCLIPスコアによってフィルタリングしました。 英語と中国語にはSigLIP2を用いましたが、日本語データについてはclip-japanese-base-v2を用いた方が高精度にフィルタリングできました。 画像重複除去 Web収集画像に存在する大量の類似画像を効率的に除去するため、clip-japanese-baseでも用いられているSemDeDupを採用しました。これは画像特徴量によるクラスタリング後、クラスタ内で類似度を計算することで、計算量を抑えながら意味的に重複した画像を除去する手法です。なお、類似ペアの残し方について、原論文ではクラスタ中心から遠い画像を残す仕様ですが、重複画像同士では画像間の実質的な差異がないため、テキスト側の品質を考慮して画像・テキストの類似度が高い方を残す運用としました。 最終的に各データソースから、以下の件数の画像・テキストペアを学習に利用しました。 データソース 件数 CC3M 1M CC12M 5M datacomp_1b 470M llm-jp-image-text-pairs 4M MINT-1T-HTML 58M OBELICS 110M OmniCorpus-CC 772M relaion2B-en-research-safe 649M relaion2B-multi-research-safe 240M WAON 133M 合計 2.44B Recaptionデータの利用 Webから収集したデータセットにはノイズが含まれやすいため、本取り組みでは視覚言語モデル（VLM）によって画像を説明させた、高品質なRecaptionデータも学習に取り入れました。 ここで、Recaptionにより生成された詳細かつ長文な合成キャプションをそのまま使用すると、対照学習（Contrastive Learning）の効率や精度が低下することがCLIPSという論文で指摘されています。 そこで本手法では、まずgemma-4-31B-itを用いて画像ごとに詳細な説明文を生成した上で、CLIPSに準拠して生成された文章からランダムに1文をサンプリングして学習に使用しました。これにより、計算効率の低下を抑えつつテキスト表現の多様性を向上させています。本Recaption処理は合計7億枚（700M）の画像に対して適用しました。 小規模な事前実験では、Recaptionデータを用いることでゼロショット分類（IN1K acc@1: 76.18→75.96）がわずかに低下した一方、画像・テキスト検索タスク（MSCOCO I→T R@5: 86.24→88.84など）は大幅に向上するというトレードオフが確認されました。生成キャプションは画像の大域特徴の網羅性に優れる反面、alt-text特有の固有名詞や局所特徴に関する情報が薄まるため、両者の表現にはトレードオフが存在すると考えられます。 学習設定 モデルはViT-SO400M-14-SigLIP2と同じ構造で、画像エンコーダーおよびテキストエンコーダーはいずれもランダム初期化から学習させました。ロスはシンプルな対照学習のみを用いました。解像度は224x224とし、画像のData Augmentationとして拡大縮小、カラージッター、グレースケール化を確率的に適用しました。学習率スケジュールにはCosine Schedulerを採用し、ピーク学習率を5e-4に設定したうえで、学習初期の2,000ステップをWarmup期間としました。 学習環境にはNVIDIA B200を256基（32ノード）使用し、グローバルバッチサイズ128Kにて、計40Bサンプル（2.44B枚の画像に対して約16エポック相当、SigLIP2と同規模）の学習を累計5日間にわたり実施しました。 性能評価 評価には以下のベンチマークを利用しました。 ImageNet-1K / -ja / -zh: 1,000クラスの画像認識（ja/zhはクラス名を日本語・中国語に翻訳したもの）。 ImageNet-V2: ImageNet-1Kへの過学習を防ぐために再収集されたもの。 ObjectNet: 視点・背景・回転を統制して収集された、分布シフトへの汎化性能を測る。 MSCOCO / Flickr30k: 画像とキャプションの検索性能を測る。 XM3600-ja/zh: 多言語キャプションデータセットを用いた日本語・中国語での検索性能評価。 WAON-Bench: 日本ドメイン特有の画像理解力を測る。 比較対象として、SigLIP2を内部評価した結果を用いています。 評価結果は以下の通りです。英語ベンチマークではSigLIP2と同等の精度を達成しつつ、日本語や中国語の評価においてはSigLIP2を大きく上回る精度を記録しました。特に、日本語キャプションによる画像検索（XM3600-ja）や日本ドメイン特有の画像理解（WAON-Bench）で大きな差が見られ、日本語のテキストと画像の対応付けや、日本固有の概念の理解が向上していると考えられます。 英語ベンチマーク: Model ImageNet-1K ImageNet-V2 ObjectNet MSCOCO (T→I R@5) MSCOCO (I→T R@5) Flickr30k (T→I R@5) Flickr30k (I→T R@5) SigLIP2 83.18 77.40 75.23 78.43 90.00 95.80 99.50 Ours 82.65 76.86 79.81 79.60 92.20 95.92 99.70 日本語ベンチマーク: Model ImageNet-1K-ja XM3600-ja (T→I R@5) XM3600-ja (I→T R@5) WAON-Bench acc@1 SigLIP2 52.98 71.92 77.56 79.26 Ours 64.34 97.28 98.47 98.20 中国語ベンチマーク: Model ImageNet-1K-zh XM3600-zh (T→I R@5) XM3600-zh (I→T R@5) SigLIP2 56.22 71.17 74.97 Ours 61.19 86.78 90.03 開発時の知見 最終的なモデルの学習を行うまでに、途中段階での検証によって得られた知見をご紹介します。（各項目でのベースラインは、検証を行ったタイミングによって異なっています。） WSD vs Cosine Scheduler 本取り組みでは最終的なモデル学習の計算バジェットが決まっていなかったため、中盤の学習率が一定で継続学習と相性の良いWSD（Warmup-Stable-Decay）の導入を検討しました。小規模な実験ではWSDがCosine Schedulerに対し優位性を示したものの、大規模実験では学習率一定期間における学習停滞が長引き、最終的にはCosine Schedulerの方が優れているという結果になりました。また、Cosine Schedulerにおいてはepoch数を増やすことによる性能向上も確認できています（ImageNetの精度が合計サンプル数10Bの78%から40Bで79.3%へ向上しました）。 Interleavedデータの有効性 OmniCorpusとOBELICSを用いて、Interleavedデータの追加が特にImageNetのような認識タスクの性能向上に寄与することを確認しました。Webから取得できるInterleavedデータには、画像とテキストのアライメントに有用な情報が多く含まれており、こうしたソースの活用が重要であることが窺えます。 Model IN1K acc@1 MSCOCO (T→I R@5) MSCOCO (I→T R@5) ベースライン 76.18 71.40 86.24 ベースライン+OmniCorpus+OBELICS 77.54 71.64 86.22 Data Augmentationの効果 数十億規模のデータセットを用いた学習においても、データ拡張の導入は依然として有効であり、認識・検索タスクともに一貫した性能向上が確認されました。 Model IN1K acc@1 MSCOCO (T→I R@5) MSCOCO (I→T R@5) ベースライン 78.44 73.40 86.72 ベースライン+Data Augmentation 78.72 73.62 87.40 高解像度の継続学習 解像度を上げて継続学習を行う実験も実施しました。解像度を上げることでCLIPとしてのベンチマーク性能向上は確認できました。しかし、後続のマルチモーダルLLMとして学習したときの性能向上には寄与しなかったため、最終モデルへの採用は見送りました。 Model IN1K acc@1 MSCOCO (T→I R@5) MSCOCO (I→T R@5) SigLIP2-378 84.11 78.78 90.52 Ours（224x224） 82.65 79.60 92.20 Ours（448x448で継続学習） 83.89 80.30 92.06 マルチモーダルLLMとしての評価 構築した画像エンコーダーをマルチモーダルLLMに利用したときの評価を行うため、画像エンコーダーとLLMの間にProjector（MLP層）を配置した構成で比較実験を行いました。 学習は2段階で実施しており、まずProjectorをrelaion2B-en-research-safeに対して生成した詳細キャプションで学習した後、JagleとFineVisionを用いてモデル全体を訓練しました。 評価には、以下の日本語と英語のベンチマークを利用しました。 BusinessSlideVQA: 日本のビジネスプレゼン資料などのスライド画像に関する質問応答・視覚的推論能力を測る。 ChartQA: 棒グラフや折れ線グラフなどのグラフ画像と、それに関する質問・データ読み取り能力を測る。 DocVQA: 領収書やレポート、文書画像内のテキストやレイアウトを理解して質問に答える能力を測る。 Heron: VLMが日本の知識に基づいて対話する能力を測る。 InfoVQA: インフォグラフィック（複雑な図解やデザイン化された情報画像）の視覚要素とテキストを複合的に理解する能力を測る。 JDocQA: 日本語の文書・資料画像に対する質問応答性能を評価する。 MMMU: 科学、工学、医療、ビジネスなど、幅広い学問分野の専門的な図表理解と高度な推論力を測る総合ベンチマーク。 JMMMU: 上記MMMUの日本語版。 ※ BusinessSlideVQA・Heron・JDocQAの3タスクについては評価にLLM-as-a-Judgeによる5段階評価を行い、判定モデルにはgpt-oss-120bを利用しています。評価結果を0〜1の値に揃えるために5で割った値を報告します。 自社開発中のLLMに対し、画像エンコーダーとしてSigLIP・SigLIP2・開発した我々の画像エンコーダーを組み込んだ場合の比較結果を示します。 画像エンコーダー BusinessSlideVQA (judge) ChartQA DocVQA Heron (judge) InfoVQA JDocQA (judge) MMMU JMMMU Average SigLIP 0.7181 0.7416 0.8635 0.4039 0.5764 0.6542 0.4016 0.4002 0.5949 SigLIP2 0.7383 0.7420 0.8706 0.4097 0.5866 0.6659 0.4071 0.4199 0.6050 Ours 0.7883 0.7924 0.9138 0.4214 0.6732 0.6903 0.3893 0.4115 0.6350 本モデルを採用したマルチモーダルLLMは、SigLIPとSigLIP2に対して、特にBusinessSlideVQAやJDocQAといった日本語ドキュメント理解タスクで大きく上回ったほか、幅広いベンチマークで良好な結果を示しました。 終わりに 本取り組みでは、公開データを用いて、大規模な画像・テキストペアデータから画像エンコーダーをスクラッチで学習しました。その結果、英語ベンチマークにおいてSigLIP2と同等の性能を維持しながら、日本語および中国語のベンチマーク、さらには後段のマルチモーダルLLMに利用した際のVisionタスク（特にドキュメント理解）で上回る成果を達成することができました。 SigLIP2では、非公開データや複雑なマルチタスクロス（Self-Distillationや領域予測など）を組み合わせた高度な学習設計がなされていました。 しかし本実験により、オープンデータでもデータの高品質化（フィルタリング・Recaption）と学習設定の最適化を適切に行えば、シンプルな対照学習のみでSigLIP2等の最高峰モデルに匹敵・凌駕する表現を獲得できることが示されました。 今後は開発した画像エンコーダーを用いて、強力なマルチモーダルLLMの開発に取り組んでいきます。 画像エンコーダー開発メンバー 田中幹大 田中稔之 鈴木哲平
I Benchmarked My AI Carb Counter on 400 Meal Photos: 8 Models, 1 Holdout Set I build Soba, an iPhone app that looks at a photo of a meal and estimates the carbs in it. People with type 1 diabetes use numbers like that to dose insulin, so "it seems to work" wasn't a good enough answer. I ran it on 400 meal photos from two public research datasets where the carbs were weighed or recorded, and published the method, the misses and the per-meal data on the Soba accuracy page. This post is the engineering side of that test: how the benchmark was set up, which of eight models won, and the bugs a production-path test turns up that a separate eval harness can miss. The full write-up on my blog has the per-meal-size breakdown and the comparison with published ChatGPT studies. The setup The photos come from Nutrition5k (Google cafeteria plates, every ingredient weighed, fixed overhead camera) and SNAPMe (95 people in the US photographing their own meals and logging them in a food record). The first is clean, controlled data. The second looks like what users actually shoot. A few choices did most of the work: - A script with a fixed seed drew 25 meals from each quarter of the carb range, per dataset, so no part of the range ended up under-sampled by chance. - Cafeteria plates photographed within the same ten minutes often look nearly identical, so the script capped how many it took from one ten-minute window. The confidence intervals come from a bootstrap that resamples whole clusters (all photos from one SNAPMe participant, or from one ten-minute cafeteria window), because near-duplicate photos aren't independent samples. - There are two disjoint sets of 200. All error analysis and prompt work happened on the first set; the second stayed untouched until a result needed confirming. - Every photo was downscaled to 1,024 px on the long side like the app does and sent through the same server code, with the same instructions and model settings. There's no eval-only prompt. - The main metric is the share of meals within 10 g of the reference carbs, roughly one bread unit. Failed scans count as misses (there were none). The results in one table | Setup | Meals | Within 10 g | Median error | |---|---|---|---| | Photo only, all meals | 400 | 68.5% | 5.2 g | | Photo + text hint | 400 | 72.8% | 4.5 g | | Photo only, cafeteria (Nutrition5k) | 200 | 77.5% | 3.9 g | | Photo + depth data, cafeteria | 200 | 82.0% | 3.1 g | | Photo only, own photos (SNAPMe) | 200 | 59.5% | 6.8 g | | Photo only, meals with 60 g+ carbs | 42 | 19.0% | 25.4 g | The headline 68.5% has a 95% interval of 64.0% to 72.9%. The last row shows the main failure. In 38 of the 42 largest meals the estimate was too low, with the median estimate at 64% of the real amount. In 30 of those 38, the model judged the food to weigh at least 15% less than it did, while its carbs per 100 g were usually close. !Scatter plot of 400 meals: actual carbs vs Soba's estimate. Most points sit inside the ±10 g band up to about 50 g; above 60 g most fall below it. Every meal in the test. The shaded band is ±10 g; points below the dashed line are underestimates. The per-meal CSV is public, so you can check the headline numbers yourself with the standard library: import csv, io, statistics, urllib.request URL = "https://soba-app.com/accuracy/soba-carb-benchmark-2026-10.csv" with urllib.request.urlopen(URL) as resp: rows = list(csv.DictReader(io.TextIOWrapper(resp, "utf-8"))) errs = [abs(float(r["soba_total_carbs_g"]) - float(r["reference_total_carbs_g"])) for r in rows] print(f"within 10 g: {sum(e <= 10 for e in errs) / len(errs):.1%}") print(f"median error: {statistics.median(errs):.1f} g") within 10 g: 68.5% median error: 5.2 g Eight models, and why the winner didn't ship I ran eight models on the first 200 meals with Soba's prompt, one run each through OpenRouter, with the request settings Soba had before October 2026. These were separate runs, so production's numbers differ slightly from the table above: | Model | Within 10 g | Median time | |---|---|---| | Gemini 3.7 Flash | 73.0% | 3.7 s | | Gemini 3.8 Flash | 71.5% | 4.8 s | | Gemini 3.5 Flash-Lite | 69.0% | 2.1 s | | Gemini 3.6 Flash (production) | 67.5% | 3.3 s | | GPT-6 Luna | 65.0% | 6.9 s | | GPT-6 Luna Pro | 63.0% | 11.7 s | | GPT-6.1 Sol | 58.0% | 13.1 s | | Claude Sonnet 5.5 | 53.0% | 6.0 s | Gemini 3.7 Flash beat production by 5.5 points. That's enough of a lead to make a switch look obvious. But when you pick the best of eight on the same 200 samples, part of the winner's lead is luck, so I ran both models on the untouched second set. They tied at 70.5%, and 3.7 Flash costs more. Production stayed on Gemini 3.6 Flash. Two more rows need a footnote. Claude Sonnet 5.5 returned an empty food item for 41 of the 200 photos through the provider OpenRouter routed it to; on the other 159 photos it scored 66.7%, right in the pack. If the harness had silently dropped empty answers, that model would have looked competitive, and the 41 empty answers would never have shown up. And GPT-6.1 Sol overestimated carbs by 10 g on average, a bias you'd only notice by looking at signed errors. Letting Gemini 3.6 Flash reason longer raised the share within 10 g by 4.1 points over all 400 meals, but the share within 5 g and the number of errors above 30 g stayed the same, and each scan took 6.6 seconds instead of 3.5. More thinking pushed medium errors under the line and did nothing for the large ones. I kept the fast setting. Bugs that only a full run finds The test pushed 3,614 requests through production code. Two problems fell out that normal traffic never surfaced: 1. The fallback model couldn't run. Soba sent a temperature parameter that the OpenAI backup didn't accept, and the request allowed only providers that support every parameter in it (OpenRouter's require_parameters option). So the OpenAI backup would have failed on every scan the moment Gemini went down. Removing the parameter moved the main model from 68.9% to 68.5%, inside run-to-run noise. The backups are now Gemini 3.7 Flash and GPT-6 Luna. 2. Repetition loops. In 9 of 3,614 requests (0.25%), Gemini repeated one phrase over and over, and the scan took 35 to 87 seconds. A cap on answer length now cuts those off early. A spot check of ten photos wouldn't have caught either one. The loops only appeared in the latency tail of 3,614 requests, and the dead fallback only when the backup itself was called. What extra inputs added Since the dominant error was portion weight, I tested what extra inputs add: - A text hint naming the foods (copied from the dataset records, no amounts) lifted the share within 10 g from 68.5% to 72.8%. It helped most on ambiguous photos, like a coffee with creamer that Soba had read as caramel sauce (162 g estimated without the hint, 5.5 g with it, 2.7 g in the food record). It didn't fix the main failure: large meals were still underestimated in 37 of 42 cases with a hint. The gain was also lopsided between the two sets (8.0 points vs 0.5), and real users won't type as precisely, so I treat it as an upper bound. - Depth data lets the app tell the model how wide the frame is in centimeters, on iPhones with LiDAR or multiple rear cameras. Replayed from Nutrition5k's depth recordings on its 200 cafeteria photos, it lifted the share within 10 g from 77.5% to 82.0%. Large meals were still underestimated in 12 of 13 cases, and angled photos haven't been measured yet. - The weight editor in the UI is the fallback for big plates. The app shows a weight range with each estimate and recalculates when the user enters a real weight. The real plate weight fell inside the shown range on 97 of 200 weighed plates, about half, so treat the range as a guide; typing in a weight from a kitchen scale is the reliable fix. Takeaways for anyone benchmarking a vision LLM 1. Keep a holdout set and don't touch it while tuning. Mine stopped a model switch that the first-round numbers made look obvious. 2. Break results down by the size of what you're estimating. The 68.5% average hid a 19% result on the biggest meals. 3. Count failures as misses, and look at signed errors. Empty answers and systematic bias both disappear in a careless average. 4. Run the eval through the production code path. Mine found a dead fallback and a 0.25% latency tail that a separate eval harness could easily have missed. 5. Find the bottleneck before you shop for models. Here it was portion weight on large plates, and the inputs that carry scale (depth, a weight the user enters) go after it more directly than a model swap. Even depth left 12 of 13 large meals underestimated. The full method, the limits (US-only meals, overhead camera on one dataset, self-reported references on the other) and the 400-row CSV are on the Soba accuracy page. The blog version has the meal-size table and how the numbers compare with published ChatGPT-4o and ChatGPT-5 studies. Soba isn't a medical device. Its numbers are estimates: check them against labels and a scale, and follow your diabetes care plan.