ErtasAI

costing-a-model-vs-an-api

Decide whether running your own model actually costs less than paying a hosted API, and at what volume the two cross over. Gathers the real inputs, token counts per request, today's provider pricing, hosting or hardware cost, and one-off training cost, then computes the breakeven point and reports it with the assumptions visible, so the number can be challenged. Use when someone asks whether self-hosting is cheaper, what a fine-tune would save, when owning a model pays for itself, or wants to justify or reject a move off a hosted API. Not for deciding whether the model is good enough, which is evaluating-a-tuned-model, and not for choosing a deployment target.

debugging-a-bad-fine-tune

Diagnose a fine-tuned model that behaves badly at inference: output that never stops or repeats forever, replies that ignore the training data, garbled or nonsense tokens, a model that answers as the wrong persona, an adapter that will not load against its base, or quality that collapsed after quantisation. Works backwards from the symptom to the cause, most often a chat template mismatch between training and inference, a missing end-of-sequence token, a tokenizer mismatch, or overfitting on too small a dataset. Use when a trained model is loaded and producing wrong output. Not for models that fail to load at all for environment reasons, not for a crash while the model is being trained, and not for deciding whether the model is good enough, which is evaluating-a-tuned-model.

evaluating-a-tuned-model

Learn whether a fine-tuned model is actually better than what it started from, instead of guessing from a few prompts that felt good. Builds a probe set from the task definition, writes a rubric, runs the tuned model against its own base model and optionally against a hosted frontier model, scores the results, and produces a scorecard you can rerun after every training run. Use when someone asks whether a fine-tune worked, whether it is good enough to ship, how it compares to the base model or to an API, or wants a regression suite for future training runs. Not for fixing a model that behaves badly at inference, which is debugging-a-bad-fine-tune, and not for measuring cost, which is costing-a-model-vs-an-api.

inspecting-a-model-bundle

Work out what is inside a model directory and what can actually run it. Reads GGUF headers, safetensors headers, adapter_config.json and config.json to identify whether it is GGUF, a LoRA adapter or a merged checkpoint, which base model it came from, which runtimes can load it directly versus which require conversion, and what defects the export left behind. Use when someone has a model folder or zip and does not know what is in it, asks what format a model is, asks whether a model runs with Ollama or vLLM or llama.cpp, or needs to check a downloaded or exported model before integrating it. Not for choosing which base model to fine-tune, not for training, and not for writing the integration code itself.

scoping-a-custom-model

Decide whether a task actually needs a custom trained model, or whether a better prompt, retrieval, a smaller hosted model, or routing between models would do the job, and if a custom model is right, work out what it has to be good at and how you will know. Use when someone says they want to fine-tune, train their own model, run AI locally, offline, or with no network connection, cut their AI bill, own their model, get a model to answer the same way every time instead of drifting, wonders if an API alone is enough, or wants a model to behave a specific way, and it is not yet clear that training is the answer. Also the entry point to the other open model skills. Not for choosing a specific base model once the decision to train is made, not for building a dataset, and not for any step after training.

shipping-a-model-in-a-flutter-app

Put a local language model inside a Flutter app and get it generating on device. Covers llamadart, which runs GGUF through llama.cpp and .litertlm through LiteRT-LM under one API on Android, iOS, macOS, Windows, Linux and Flutter web, plus LoRA adapter loading, flutter_gemma as the MediaPipe-lineage alternative, background isolate and threading behaviour, and whether to bundle the model or download it on first run. Use when the project is Flutter or Dart and someone wants on-device or offline AI, local inference, or a model running without an API. Not for React Native or Expo projects, not for iOS native Swift projects, not for Android native Kotlin projects, not for JavaScript browser apps using transformers.js or WebLLM, and not for models running on a server.

shipping-a-model-in-a-react-native-app

Put a local language model inside a React Native or Expo app and get it generating on device. Covers react-native-executorch for .pte models and llama.rn for GGUF models, choosing between them, native build configuration and model loading, streaming answers into the UI as tokens arrive, and whether to bundle the model in the binary or download it on first run. Use when the project is React Native or Expo and someone wants on-device or offline AI, local inference, or a model running without an API. Not for iOS native Swift projects, not for Android native Kotlin projects, not for Flutter, and not for models running on a server.

shipping-a-model-in-an-android-app

Put a local language model inside a native Android app written in Kotlin or Java. Covers MediaPipe LLM Inference and LiteRT-LM for .task and .litertlm models, llama.cpp through the NDK for GGUF, ML Kit GenAI and Gemini Nano where a built-in model is enough, GPU and NNAPI delegation, Play asset packs, and whether to bundle the model or download it on first run. Use when the project is a native Android app and someone wants on-device or offline AI or local inference. Not for React Native or Expo projects, not for iOS native Swift projects, not for Flutter, and not for models running on a server.

shipping-a-model-in-an-ios-app

Put a local language model inside a native iOS or macOS app written in Swift. Covers MLX on Apple silicon, Core ML conversion, llama.cpp via a Swift wrapper, choosing between them, app binary size and memory limits, background and memory-pressure behaviour, and whether to bundle the model or download it on first run. Also covers when Apple Foundation Models is the better answer than shipping your own. Use when the project is native Swift for iOS, iPadOS or macOS and someone wants on-device or offline AI or local inference. Not for React Native or Expo projects, not for Android native Kotlin projects, not for Flutter, and not for models running on a server.