GLM-5.3 is live. Run Z.ai's latest model on Friendli Model APIs. Try it today ➜
khazarai
Available on FriendliAI
Run this model inference on single tenant GPU with unmatched speed and reliability at scale.
Model Details
Model Provider
khazarai
Model Tree
Qwen/Qwen3.5-4B
Input Modalities
Output Modalities
Supported Functionality
| Property | Description |
|---|---|
| Model name | Qwen3.5-4B-Car-Diagnostics |
| Hugging Face repository | khazarai/Qwen3.5-4B-Car-Diagnostics |
| Base model | Qwen/Qwen3.5-4B |
| Developer | KhazarAI |
| Model type | Fine-tuned language model |
| Primary domain | Automotive diagnostics and troubleshooting |
| Primary input | Text-based vehicle symptoms, DTCs, and diagnostic measurements |
| Primary output | Diagnostic hypotheses, explanations, and verification steps |
| Model size | Approximately 4B parameters, inherited from the base model |
| Intended users | Automotive technicians, automotive students, researchers, and developers |
| Model status | Experimental |
| License | Apache-2.0, subject to confirmation of the distributed artifact's licensing and compliance with the base model terms |
Automotive troubleshooting often requires interpreting multiple signals rather than treating a diagnostic trouble code as a definitive diagnosis. Similar symptoms can arise from different faults, and replacing a component without verification can lead to unnecessary repair costs.
Qwen3.5-4B-Car-Diagnostics is intended to help organize this diagnostic process. Given a textual scenario, it can analyze relationships between symptoms, fault codes, component-swapping tests, and sensor measurements to suggest a likely fault and a next diagnostic action.
The model is intended to support tasks such as:
The model generates recommendations from the information provided in the prompt. It does not directly inspect a vehicle, read an ECU, operate diagnostic equipment, or independently verify that a proposed repair resolves the fault.
1. Diagnostic trouble code interpretation
The model can help interpret codes such as P0300, P0302, and P0303 in the context of reported symptoms and test results.
2. Fault isolation
The model can suggest procedures to distinguish between competing hypotheses, such as an ignition coil failure, a wiring fault, or a sensor-related problem.
3. Sensor and measurement interpretation
The model can analyze provided readings and explain how they may support or weaken a diagnostic hypothesis.
4. Next-step recommendations
The model can recommend a practical verification step before a component is replaced, rather than treating a symptom or trouble code as sufficient proof of failure.
5. Automotive education and research
The model can support learning, diagnostic case discussions, and research into specialized language models for automotive troubleshooting.
The model is not intended to:
The model was examined using five text-based automotive diagnostic scenarios. The cases covered intermittent ABS sensor faults, heat-related engine stalling, fuel-trim interpretation, cylinder misfires, and parasitic battery drain.
The evaluation focused on diagnostic plausibility, use of evidence, quality of the recommended next step, clarity, and unnecessary repetition.
| Test | Diagnostic scenario | Observed fine-tuned model behavior |
|---|---|---|
| 1 | ABS wheel-speed fault appearing during cornering | Produced a concise hypothesis involving a connector or ground issue. The available evidence was insufficient to establish that this was the correct cause. |
| 2 | Engine stalls when hot; crankshaft position sensor RPM signal drops to zero | Identified a failing crankshaft position sensor as the leading suspect and recommended further signal verification. Wiring and connector faults remain alternative explanations. |
| 3 | Negative long-term fuel trim combined with fuel pressure above specification | Misinterpreted the meaning of negative fuel trim and prioritized a vacuum leak. This exposed a substantive diagnostic knowledge limitation. |
| 4 | Misfire moves from cylinder 3 to cylinder 2 after swapping ignition coils | Correctly identified the moved ignition coil as the primary suspect and recommended verifying the result and checking the coil and its wiring. |
| 5 | Excessive parasitic battery draw after the vehicle is switched off | Recommended isolating the responsible circuit through fuse-by-fuse or module-by-module testing and inspecting the associated module or relay. |
The preliminary tests suggest that the model can produce useful diagnostic hypotheses and actionable troubleshooting steps in several common automotive scenarios.
Observed strengths include:
The tests also identified limitations:
Evaluation status: Preliminary qualitative testing only.
The five cases do not constitute a statistically representative automotive diagnostic benchmark. They do not establish an overall diagnostic accuracy rate, a statistically significant improvement over the base model, or reliable performance across different vehicle platforms.
No standardized accuracy percentage, comprehensive benchmark score, or claim of superiority on a broad diagnostic test suite is reported here.
A diagnostic trouble code identifies a detected condition, not necessarily the component that caused it. The model may recommend a plausible component without enough evidence to distinguish it from an electrical, mechanical, or control-system fault.
The model can make fundamental mistakes when interpreting automotive measurements. For example, under the usual OBD-II fuel-trim convention, negative fuel trim means the engine control module is subtracting fuel, generally in response to a rich condition. Positive fuel trim generally means it is adding fuel to compensate for a lean condition.
The observed fuel-trim test demonstrates that the model may nevertheless misapply this relationship. Important measurements and technical claims should therefore be independently checked.
Diagnostic procedures and specifications vary by manufacturer, model year, engine, ECU calibration, and hardware configuration. The model may not account for every vehicle-specific distinction.
If a prompt omits relevant information, such as freeze-frame data, actual fuel pressure, wiring measurements, service history, or the conditions under which a fault occurs, the model may draw an incorrect conclusion.
A coherent explanation does not prove that a diagnosis is correct. The model does not have direct access to vehicle sensors or workshop equipment unless an external system explicitly supplies that information.
The initial evaluation covers only five scenarios. It does not establish reliability across diesel engines, hybrid or electric vehicles, transmission faults, advanced driver-assistance systems, manufacturer-specific procedures, or safety-critical failures.
A recommended repair must be followed by appropriate verification. The model cannot guarantee that replacing a suggested component will resolve the underlying problem.
Automotive diagnosis can have direct safety implications. Incorrect advice may result in unnecessary component replacement, vehicle damage, emissions-system damage, or unsafe vehicle operation.
Users should:
For example, a flashing Check Engine Light can indicate an active misfire that may damage the catalytic converter. A qualified technician should assess the vehicle and determine whether continued operation is appropriate.
The model should not be used as the sole decision-maker for vehicle safety or repair authorization.
The base model is Qwen/Qwen3.5-4B.
The fine-tuned checkpoint is intended to specialize the base model toward automotive diagnostic reasoning and troubleshooting.
The following details are not specified in the information available for this model card and should be added when verified:
| Training property | Status |
|---|---|
| Fine-tuning method | LoRA |
| Training dataset and source | build-small-hackathon/nemotron-car-diagnostics-datasets |
| Number of training examples | 15K |
| Training hardware | Nvidia RTX Pro 6000 Blackwell |
| Optimizer and learning rate | adamw8_bit |
| Batch size and sequence length | 32 |
| Number of training epochs or steps | 1 |
| Training loss and convergence results | 1.70 > 1.01 |
| Independent validation results | 1.71 > 1.01 |
These fields are intentionally left unspecified rather than inferred. They should be completed from the actual training configuration and dataset records before making reproducibility claims.
For the most useful diagnostic output, provide a structured case description that includes:
Ask the model to distinguish between:
For production use, a diagnostic application should validate critical numerical relationships, incorporate vehicle-specific reference information, and require verification of safety-relevant recommendations.
A more rigorous evaluation should use a larger, independently reviewed dataset of automotive diagnostic cases.
Recommended metrics include:
The base model and fine-tuned model should be evaluated on identical cases with consistent inference settings and a predefined scoring rubric. Reference diagnoses should be established independently by qualified automotive professionals.
The evaluation should also include unseen vehicle platforms, ambiguous cases, misleading symptoms, and cases where the correct response is to request more information rather than make a definitive diagnosis.
This model is intended to support human understanding and diagnostic decision-making. It should not be presented as infallible, professionally certified, or independently validated for safety-critical automotive use.
Model outputs should be reviewed by qualified personnel before repair decisions are made. Any application built on this model should clearly communicate uncertainty, preserve relevant diagnostic context, and avoid presenting generated hypotheses as confirmed faults.
This model is based on Qwen/Qwen3.5-4B.
The upstream Qwen3.5-4B repository identifies its license as Apache-2.0. Users should review the upstream license, applicable notices, and the license metadata of the distributed fine-tuned artifact before redistribution or commercial deployment.
Upstream model documentation and technical details:
Developed by KhazarAI as an experimental effort toward specialized language models for automotive diagnostics and technical troubleshooting.
Disclaimer: Qwen3.5-4B-Car-Diagnostics is an experimental AI model. Its outputs may contain technical errors. Always verify diagnostic conclusions against physical measurements, manufacturer documentation, and qualified professional judgment.