Google Goes Beyond LLMs, but SensorFM and TabFM Remain Research Tools

Google Research’s SensorFM and TabFM still demonstrate why language models are not the natural default for every kind of data. The current position is narrower than a production launch: SensorFM remains a wearable-health research model, while TabFM is downloadable but its default pretrained weights are restricted to non-commercial, non-production use.
That distinction is useful for teams deciding whether either model can enter a real pipeline. SensorFM works with aggregated wearable measurements rather than unrestricted raw waveforms, and its reported health results are research evaluations rather than clinical authorization; TabFM avoids dataset-specific weight updates, but it still depends on labeled context, bounded inputs and validation against the intended data.
SensorFM models wearable measurements without translating them into prose
SensorFM is designed to extract reusable representations from longitudinal physiological and behavioral measurements. This preserves the alignment and temporal structure of wearable records instead of expressing thousands of readings as text tokens for a general-purpose LLM.
The phrase “raw sensor data” needs qualification. Google Research’s July 9 SensorFM account specifies 34 one-minute aggregate features derived from five modalities—photoplethysmography, accelerometry, electrodermal activity, skin temperature and altimetry—and describes pre-training on more than one trillion minutes from five million consenting participants whose de-identified data were captured from September 2024 to September 2025 across more than 100 countries and over 20 Fitbit and Pixel Watch models.
Those inputs include derived measures such as heart rate, heart-rate variability, blood-oxygen saturation, motion, steps and sleep stages. SensorFM therefore operates closer to the sensor pipeline than a text model does, but it does not ingest every unprocessed electrical or optical waveform produced by a wearable.
Its training objective also accounts for fragmented records. A wearable may be charging, operating in a power-saving mode or temporarily off the wrist, so missing intervals are part of the data-generating environment rather than exceptional corruption. SensorFM’s masking approach learns from incomplete windows instead of requiring every gap to be filled before representation learning.
Broad health benchmarks do not make SensorFM a diagnostic system
The published evaluation covered 35 prediction tasks in six areas: cardiovascular health, metabolic risk, mental health, sleep, demographics and lifestyle. Across three prospective studies involving 13,985 participants, a frozen SensorFM encoder paired with a lightweight linear head outperformed a supervised feature-engineered baseline on 34 of the 35 tasks.
The subject of that result is the complete tested configuration, not SensorFM in isolation and not every possible specialist model. It shows that the learned embeddings carried useful information under the reported datasets, targets and comparison method; it does not establish universal superiority across devices, populations or clinical settings.
This boundary is particularly important for depression, anxiety and other sensitive outcomes. A representation may contain patterns that improve a research predictor without providing the evidence, calibration or clinical context needed for diagnosis. Intended-population validation, subgroup analysis, consent, governance and professional oversight remain separate requirements.
The research also explored prediction heads generated by collaborating LLM agents and health summaries grounded in SensorFM outputs. These experiments illustrate a plausible division of labor: the specialized encoder processes wearable measurements, while a language model can help construct downstream code or communicate selected results. They do not turn the encoder itself into a conversational model or establish a generally available health service.
TabFM preserves relationships across rows and columns
TabFM addresses classification and regression by treating labeled historical rows as inference context for predictions on new rows. Its pretrained parameters are not optimized again for each dataset, which is the basis for the model’s “zero-shot” label in this setting.
The label does not mean prediction without examples. TabFM still needs contextual rows with known outcomes, and its scikit-learn-style fit step prepares encoders and scalers before inference. Incorrect labels, target leakage, sampling bias or a change between historical and future data can therefore undermine results even when the foundation model’s weights remain fixed.
Google Research’s June 30 TabFM introduction describes alternating attention over rows and columns, compression of each contextualized row into a vector and in-context prediction over those vectors; it also records training on hundreds of millions of synthetic datasets and evaluation on 38 classification plus 13 regression datasets in TabArena.
The benchmark separated the basic single-pass model from TabFM-Ensemble. The latter added cross features, singular-value-decomposition features, optimized weights for a 32-member ensemble and calibration for classification. Results from that enhanced configuration should not be attributed to the bare model, because part of its performance comes from the surrounding feature and ensembling pipeline.
Downloadable does not mean deployable
TabFM’s most consequential update after its initial presentation is public access to an implementation and weights. The current Google Research repository provides TabFM v1.0.0 with JAX and PyTorch paths, identifies the project as unsupported by Google, restricts the default weights to non-commercial and non-production use, lists defaults of 500 features and 100 context rows, and states that no technical report is currently included.
The licensing distinction applies to the weights downloaded by the default quick-start flow; the repository’s source code carries a separate Apache 2.0 license. Possession of the code therefore does not grant production rights to the supplied model weights. Any prospective deployment would need to assess both layers rather than relying on the code license alone.
The documented context limits also correct the idea that an arbitrarily large table can be passed through unchanged. Larger inputs are sampled or divided so that inference operates on bounded contexts. That may be adequate for controlled experimentation, but it makes sampling design and representativeness part of the evaluation.
Google’s original TabFM publication described BigQuery integration through AI.PREDICT as forthcoming. A future-facing statement is not equivalent to documented managed-service availability, so the downloadable research package and any eventual Google Cloud offering should be treated as separate products with separate access terms, limits and support status.
Specialized models complement LLMs rather than replace them
The durable lesson is architectural, not promotional. SensorFM represents interrupted sequences of wearable features, and TabFM predicts from relationships within a structured table; an LLM can explain an output or mediate a user interaction, but neither task becomes intrinsically textual merely because a language model can accept numbers as tokens.
Specialization also does not remove ordinary deployment controls. SensorFM’s benchmark results remain tied to its cohorts, features and downstream heads, while TabFM’s convenience remains constrained by contextual examples, table limits and a weight license that excludes production. As of the current public documentation, both are useful evidence that foundation-model methods extend beyond language—and both remain research tools rather than drop-in operational replacements.
Also read:
Subscribe to our newsletter
Get the latest Web3, AI, and crypto news delivered straight to your inbox.