AI Engineer Portfolio

Omid Navadehrazi

AI Engineer

Building AI systems from model to deployment — across local LLMs, RAG, Computer Vision, Edge AI, and distributed ML.

Based in Italy Authorized to work in Italy without employer sponsorship Open to opportunities across Europe Focus roles: AI Engineer | LLM Engineer | Computer Vision Engineer

View Projects LinkedIn Download CV

At a glance

Applied AI across models, systems, and hardware.

PNRR · e.INSPrimary Edge AI project within Ecosystem of Innovation for Next Generation Sardinia, with additional technical contribution to RESTART / WatchEDGE.

4 prototypesEdge AI devices field-tested across 2 outdoor locations in Italy as part of a custom embedded monitoring platform.

~375 msWarm mean TTFT during end-to-end AWS integration testing with 7B open-weight LLM on an NVIDIA data-center GPU.

1,800 → 820 sOne-epoch training time under controlled network congestion after selecting a more suitable two-node combination instead of using all four nodes.

Selected work

Systems built around real constraints.

Work samples spanning local LLM systems, real-time Edge AI, and distributed training on constrained infrastructure.

Featured project · 01

Local LLM & RAG System

Designing, deploying, and optimizing a local LLM stack for latency-sensitive conversational applications.

Professional project | Architecture and application details anonymized

7B open-weight LLMAWS · NVIDIA data-center GPU~375 ms warm mean TTFT1–8 concurrent requests tested

Anonymized local LLM and RAG architecture diagram

From architecture to measured behavior

The system separates model serving, retrieval, and session context so each layer can be tested independently. Performance was validated through both end-to-end AWS integration tests and a separate controlled concurrency benchmark.

Local LLM performance chart showing TTFT, throughput, and concurrency results

Tested across infrastructure

AWS · NVIDIA data-center GPULocal · NVIDIA RTX Series GPUOn-Premise · NVIDIA GPU ServerCPU baseline environment

Developed and validated the same modular LLM service across cloud, local GPU, lab-server, and CPU environments. Hardware comparisons were used to isolate inference bottlenecks, not presented as one controlled before/after benchmark.

The challenge

A latency-sensitive conversational AI system needed to move toward local, privacy-conscious inference on controlled infrastructure while remaining responsive enough for real-time interaction.

The system also needed contextual retrieval, conversation isolation, streaming responses, and an architecture that could support future model replacement rather than being tied permanently to one LLM.

My responsibility

I own the LLM layer end-to-end, including model evaluation and selection, local serving, RAG, APIs, conversational context, benchmarking, performance optimization, concurrency testing, and integration with the wider AI system.

My approach

1. Compare local modelsTested multiple local LLM candidates, including Llama-family alternatives, using representative Italian conversational prompts.

2. Select for interactionSelected 7B open-weight LLM as the current candidate based on practical evaluation of Italian naturalness, relevance, instruction following, and conversational coherence.

3. Build local servingDeployed local inference with Ollama and exposed the service through Python and FastAPI using OpenAI-compatible streaming APIs.

4. Design contextual retrievalBuilt a FAISS-based RAG architecture using multilingual semantic embeddings, relevance filtering, persistent knowledge management, and controlled retrieval.

5. Manage conversationsImplemented isolated session memory, conversation context, persistence, and cleanup to prevent state leakage between independent interactions.

6. Measure the pipelineProfiled retrieval, TTFT, generation latency, throughput, and concurrent-request behavior instead of treating total response time as a single metric.

7. Optimize system behaviorUsed GPU-backed inference, streaming, context management, inference configuration, and pipeline-level engineering without fine-tuning the model.

8. Validate concurrencyTested simultaneous requests from concurrency 1 through 8 to identify the practical latency/throughput operating region.

The result

End-to-end AWS integration: running 7B open-weight LLM on an NVIDIA data-center GPU, 2/2 real integration calls completed successfully across 16 conversation turns. Warm latency measured approximately 375 ms mean TTFT, 398 ms P95 TTFT, 890 ms mean generation time, and 1.19 s P95 generation time. Streaming, RAG, memory, call/session continuity, isolation, and cleanup all passed.

Separate concurrency benchmark: testing from 1 to 8 simultaneous requests completed with 100% successful requests and zero timeouts. Observed throughput reached approximately 6.7 requests/s, with practical saturation around 2–4 concurrent requests.

These are complementary tests from different benchmark contexts and are not presented as one direct before/after comparison.

The current performance was achieved through model selection, GPU-backed serving, streaming, context management, RAG design, and pipeline-level engineering without model fine-tuning. The system remains under active development, with additional smaller and alternative local models planned for evaluation.

In short: I take ownership of an LLM subsystem from model selection and RAG design through serving, measurement, optimization, and integration.

Work sample · 02

Real-Time Computer Vision on Custom Edge AI Hardware

Taking Computer Vision from dataset preparation and model conversion to real-time inference on a custom low-power embedded platform.

Primary project: e.INS — Ecosystem of Innovation for Next Generation Sardinia · Additional technical contribution: RESTART / WatchEDGE

4 prototypes2 outdoor locations~500–700 images8-stage Hailo workflow

Edge AI deployment workflow from dataset preparation to Hailo-15H inference

From deployment workflow to field validation

The model-to-device workflow was validated on the physical platform, then the complete standalone system was tested outdoors across multiple prototype deployments.

Standalone Edge AI livestock monitoring prototype field deployment

Field prototype validation

Standalone Edge AI platform tested in outdoor environments. The visual represents the publicly presented system; unpublished implementation details are omitted.

The challenge

The project started with a custom embedded platform under active development, limited documentation, and only basic pre-integrated Hailo models demonstrated.

A reproducible workflow was needed to move custom Computer Vision models from standard ML frameworks onto the physical device and validate the complete system outside the laboratory.

My responsibility

As one of two engineers working directly on the prototype, I primarily owned the AI/software and Edge AI deployment work, while also contributing to hardware assembly, integration, testing, and weekly technical feedback with the hardware-development partner.

My approach

1. Prepare domain dataCurated approximately 500–700 livestock images and annotated object-detection bounding boxes using Roboflow.

2. Test domain trainingStarted YOLO fine-tuning experiments and identified that the initial dataset required greater scale and environmental diversity before final field deployment.

3. Export the modelBuilt a reproducible path from PyTorch YOLOv8s to a static 640×640 ONNX representation compatible with the target platform.

4. Quantize and optimizePrepared representative calibration data, performed INT8 quantization, and integrated Hailo-compatible in-graph NMS.

5. Compile for hardwareConverted the model through Hailo HAR representations and compiled it into an HEF executable for Hailo-15H.

6. Verify before deploymentValidated optimized and quantized execution with Hailo emulation before transferring the model to physical hardware.

7. Build real-time inferenceIntegrated live camera input, on-device inference, post-processing, detection overlays, H.264 encoding, and network video streaming using GStreamer.

8. Validate in the fieldHelped assemble and test 4 physical prototypes across 2 outdoor locations in Italy, while feeding technical findings back to the platform-development partner.

The result

The work established a complete reproducible deployment workflow:

PyTorch→ONNX→HAR→INT8 optimization→HEF→Emulator validation→Hailo-15H→GStreamer

The resulting standalone prototype could acquire live camera input and execute locally deployed Computer Vision models for image classification and object detection on Hailo hardware.

The platform was field-tested using 4 physical devices across 2 Italian locations. The project-specific dataset contained approximately 500–700 annotated images; full deployment of the domain-specific fine-tuned model was deferred until a larger and more diverse dataset could be collected.

The deployment workflow is also used by the hardware-development partner while the platform continues to evolve.

In short: I helped turn a custom embedded prototype into a working Edge AI platform and established the model-to-device workflow needed to run custom Computer Vision models on it.

Hardware specification: Hailo-15H platform provides up to 20 TOPS at approximately 5 W. This is a platform specification, not a personal performance result.

Work sample · 03

Resource-Aware Distributed AI Training

Using existing compute and network resources more intelligently for PyTorch distributed training in constrained environments.

Master's Thesis Project | University of Pisa / CNIT

4 heterogeneous CPU servers1 Gbps Ethernet90% controlled occupancy1,800 → 820 s/epoch

Distributed training testbed architecture and epoch-time comparison under network congestion

The challenge

Small organizations may have existing servers available for AI workloads but cannot dedicate their entire infrastructure to model training or simply purchase new hardware.

Because those machines can already be serving business workloads, adding every available node to distributed training can make performance worse when compute resources or network paths are constrained.

My responsibility

I designed and implemented the distributed-training testbed, experiments, and a Python Recommendation Tool that exposed compute availability and pairwise network conditions before launching PyTorch DDP jobs.

My approach

1. Build the testbedConfigured 4 heterogeneous CPU servers connected through a 1 Gbps Ethernet environment.

2. Standardize environmentsContainerized the PyTorch environment with Docker and used Docker Swarm to maintain consistent dependencies across nodes.

3. Measure available resourcesCollected available CPU and memory information before starting distributed jobs.

4. Measure network pathsBuilt a Python CLI tool using SSH and iPerf3 to measure pairwise throughput and generate a network-throughput matrix.

5. Launch distributed trainingUsed PyTorch DDP, torchrun, and Gloo to execute distributed training across selected CPU nodes.

6. Simulate shared infrastructureUsed a Spirent N4U traffic generator to occupy up to 90% of available network bandwidth, representing infrastructure already carrying other workloads.

7. Analyze communicationCaptured traffic using Wireshark and processed network traces with Python and Matplotlib to understand synchronization and congestion behavior.

8. Compare node combinationsMeasured epoch time across different server combinations under normal and congested network conditions.

The result

With no artificial network congestion, using all four nodes produced an epoch time of 560 s, compared with 1,026 s on a single node.

Under the congested scenario, blindly using all four nodes increased epoch time to 1,800 s.

Selecting two nodes connected through the more suitable network path completed the same epoch in 820 s, approximately 54% less time than the four-node congested configuration.

A poor two-node combination crossing the congested path required 2,716 s, demonstrating that the choice of nodes and network path could matter more than simply maximizing node count.

Node configuration	Normal network	Congested network
1 node	1,026 s	1,003 s
2 nodes, A+B	816 s	820 s
2 nodes, A+C	860 s	2,716 s
3 nodes	720 s	1,400 s
4 nodes	560 s	1,800 s

In short: I showed that constrained organizations can make better use of existing infrastructure by selecting distributed-training resources according to real compute and network conditions, rather than simply using every available server.

How I work

Measure first. Then optimize.

Understand constraints

Latency, hardware, privacy, quality, network, and integration boundaries.

Establish baseline

Measure the current system before changing it.

Design the system

Choose models, APIs, retrieval, compute, and deployment around real constraints.

Profile bottlenecks

Optimize the component responsible, not everything at once.

Validate end-to-end

Test latency, throughput, reliability, concurrency, and real-world behavior.

Toolkit

Capabilities, not a keyword dump.

LLM & Generative AI

Ollama | FAISS | Qwen

Machine Learning & Computer Vision

Python | PyTorch | YOLO | OpenCV | Roboflow

AI Systems & Backend

FastAPI | Docker | Linux | Git | AWS | NVIDIA data-center GPU | RTX 5070

Edge AI & Embedded Deployment

Distributed Systems

About

I work where AI models meet real constraints.

I am an AI Engineer based in Italy, working across LLM systems, RAG, Computer Vision, Edge AI, and distributed machine learning.

My current work focuses on local LLM serving, contextual retrieval, streaming APIs, performance benchmarking, and inference optimization. Previously, I worked on Computer Vision deployment for custom Edge AI hardware and on resource-aware distributed PyTorch training across constrained multi-node infrastructure.

I am interested in engineering roles where AI models have to move beyond experimentation and operate within real software, hardware, latency, and infrastructure constraints.

Experience

Recent work

2026 – Present

Artificial Intelligence Engineer | Kalliope / University of Pisa

2025 – 2026

Artificial Intelligence Engineer | CNIT

Computer Vision | Edge AI | Hailo | NVIDIA Jetson | Embedded Inference

2024

Artificial Intelligence Intern | CNIT

PyTorch DDP | Distributed AI | Resource Allocation | Master's Thesis

Interested in building AI systems that have to work outside the notebook?

Email: o.navadehrazi@gmail.com · Based in Italy · Authorized to work in Italy without employer sponsorship

Email LinkedIn GitHub Download CV