모바일 및 임베디드 장치는 컴퓨팅 리소스가 제한되므로
애플리케이션 리소스의 효율성을
유지하는 것이 중요합니다 Google에서는 데이터 침해와 관련해
TensorFlow를 개선하는 데 사용할 수 있는 권장사항과 전략을 소개합니다.
라이트 모델 성능
작업에 가장 적합한 모델 선택
작업에 따라 모델 복잡도 사이에서 절충해야 함
지정할 수 있습니다 작업에 높은 정확성이 필요한 경우
복잡한 모델입니다. 정밀도가 낮은 작업의 경우
디스크 공간과 메모리를 덜 사용할 뿐만 아니라
더 빠르고 에너지 효율적입니다. 예를 들어 아래 그래프는
정확성과 지연 시간을 절충해야 합니다.
휴대기기에 최적화된 모델의 한 가지 예는
모바일에 최적화된 MobileNets
살펴보겠습니다 Kaggle
모델은 여러 다른
모바일 및 임베디드 기기에 맞게 특별히 최적화된 모델입니다.
전송을 사용하여 자체 데이터 세트에 나열된 모델을 다시 학습시킬 수 있습니다.
있습니다.
모델 프로파일링
작업에 적합한 후보 모델을 선택했다면
모델을 프로파일링하고 벤치마킹하는 것이 좋습니다. LiteRT 벤치마킹
도구
에는 연산자별 프로파일링 통계를 표시하는 기본 프로파일러가 있습니다. 이렇게 하면
성능 병목 현상과 가장 큰 영향을 미치는 연산자를 이해하는 데 도움이 됩니다.
컴퓨팅 시간이 단축됩니다.
또한 LiteRTRTT를 사용할 수도 있습니다.
trace를 사용하여
표준 Android 시스템 추적을 사용하여 Android 애플리케이션의
GUI 기반 프로파일링을 통해 시간별로 연산자 호출을 시각화합니다.
있습니다.
그래프에서 연산자 프로파일링 및 최적화
특정 연산자가 모델에 자주 나타나는 경우
연산자가 가장 많은 시간을 소비하는 것을 알았다면
해당 연산자를 최적화하는 방법을
살펴보겠습니다 이 시나리오는 TensorFlow
Lite에는 대부분의 연산자에 최적화된 버전이 있습니다. 그러나 다음을 수행할 수도 있습니다.
작업을 수행해야 하는 제약 조건을 알고 있다면 더 빠른 버전의
연산자가 실행됩니다. 커스텀 연산자 가이드를 참고하세요.
모델 최적화
모델 최적화는 일반적으로 더 빠르고 속도가 빠른 더 작은 모델을 만드는 것을 목표로 합니다.
에너지 효율이 높아져 휴대기기에 설치할 수 있습니다.
LiteRT는 양자화와 같은 여러 최적화 기법을 지원합니다.
LiteRT는 여러 연산자에 다중 스레드 커널을 지원합니다. 다음을 수행할 수 있습니다.
스레드 수를 늘리고 연산자 실행 속도를 높일 수 있습니다. 증가
하지만 스레드의 수가 늘어남에 따라 모델이 더 많은 리소스를 사용하고
강력합니다.
일부 애플리케이션의 경우 지연 시간이 에너지 효율보다 더 중요할 수 있습니다. 나
인터프리터 수를 설정하여 스레드 수를 늘릴 수 있음
스레드가 포함될 수 있습니다.
그러나 다중 스레드 실행은 성능을 향상시키는 대가를 치러집니다.
동시에 실행되는 다른 항목에 따라
변동이 있을 수 있습니다 이것은
특히 모바일 앱의 경우에 그렇습니다. 예를 들어 개별 테스트는
단일 스레드의 속도가 더 빨라지지만, 다른 앱이 동시에 실행되면
단일 스레드보다 성능이 저하될 수 있습니다.
중복 사본 제거
애플리케이션을 신중하게 설계하지 않으면 중복 사본이 있을 수 있습니다.
모델에서 출력을 읽을 때 사용됩니다. 반드시
중복 사본을 제거할 수 있습니다. Java와 같은 상위 수준 API를 사용하는 경우
문서에서 성능 관련 주의사항을 주의 깊게 확인하세요. 예를 들어
ByteBuffers를 다음과 같이 사용하면 Java API가 훨씬 더 빠릅니다.
입력입니다.
플랫폼별 도구로 애플리케이션 프로파일링
플랫폼별 도구(예: Android)
Profiler와
계기는 부를 제공함
프로파일링 정보를 제공합니다. 경우에 따라
성능 버그가 모델에 없을 수도 있지만
상호작용하지 않아도 됩니다 플랫폼을 숙지합니다.
플랫폼별 특정 프로파일링 도구 및 권장사항을 살펴봅니다.
기기에서 제공되는 하드웨어 가속기를 사용하여 모델이 이점을 얻을 수 있는지 평가
LiteRT는 더 빠른 하드웨어로 모델을 가속화하는 새로운 방법을 추가했습니다.
GPU, DSP, 신경망 가속기처럼 작동합니다 일반적으로 이러한 가속기는
대체하는 위임 하위 모듈을 통해 노출됨
일부에만 집중합니다 LiteRT는 다음과 같은 방법으로 대리인을 사용할 수 있습니다.
GPU 대리자는 OpenGL/OpenCL 및 Metal을 사용하는 Android 및 iOS에서 사용할 수 있습니다.
로 나뉩니다. 사용해 보려면 GPU 대리자를 참고하세요.
다음에 대한 액세스 권한이 있는 경우 직접 대리인을 만들 수 있습니다.
사용할 수 없습니다. LiteRT를 참조하세요.
위임을 참조하세요.
일부 가속기는 여러 유형의 모델에서 더 잘 작동한다는 점에 유의하세요. 다소 유용함
위임은 부동 소수점 모델 또는 특정 방식으로 최적화된 모델만 지원합니다. 그것은
각 대리자를 벤치마킹하여 좋은지 확인하는 것이 중요합니다.
선택할 수 있습니다 예를 들어, 모델이 아주 작은 경우
모델을 GPU에 위임할 가치가 없습니다. 반대로 가속기는
는 산술 강도가 높은 대형 모델에 적합합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-24(UTC)"],[],[],null,["# Performance best practices\n\nMobile and embedded devices have limited computational resources, so it is\nimportant to keep your application resource efficient. We have compiled a list\nof best practices and strategies that you can use to improve your TensorFlow\nLite model performance.\n\nChoose the best model for the task\n----------------------------------\n\nDepending on the task, you will need to make a tradeoff between model complexity\nand size. If your task requires high accuracy, then you may need a large and\ncomplex model. For tasks that require less precision, it is better to use a\nsmaller model because they not only use less disk space and memory, but they are\nalso generally faster and more energy efficient. For example, graphs below show\naccuracy and latency tradeoffs for some common image classification models.\n\nOne example of models optimized for mobile devices are\n[MobileNets](https://arxiv.org/abs/1704.04861), which are optimized for mobile\nvision applications. [Kaggle\nModels](https://www.kaggle.com/models?framework=tfLite) lists several other\nmodels that have been optimized specifically for mobile and embedded devices.\n\nYou can retrain the listed models on your own dataset by using transfer\nlearning.\n\nProfile your model\n------------------\n\nOnce you have selected a candidate model that is right for your task, it is a\ngood practice to profile and benchmark your model. LiteRT [benchmarking\ntool](https://github.com/tensorflow/tensorflow/tree/master/tensorflow/lite/tools/benchmark)\nhas a built-in profiler that shows per operator profiling statistics. This can\nhelp in understanding performance bottlenecks and which operators dominate the\ncomputation time.\n\nYou can also use [LiteRT\ntracing](./measurement#trace_tensorflow_lite_internals_in_android) to profile\nthe model in your Android application, using standard Android system tracing,\nand to visualize the operator invocations by time with GUI based profiling\ntools.\n\nProfile and optimize operators in the graph\n-------------------------------------------\n\nIf a particular operator appears frequently in the model and, based on\nprofiling, you find that the operator consumes the most amount of time, you can\nlook into optimizing that operator. This scenario should be rare as TensorFlow\nLite has optimized versions for most operators. However, you may be able to\nwrite a faster version of a custom op if you know the constraints in which the\noperator is executed. Check out the [custom operators guide](./ops_custom).\n\nOptimize your model\n-------------------\n\nModel optimization aims to create smaller models that are generally faster and\nmore energy efficient, so that they can be deployed on mobile devices.\nLiteRT supports multiple optimization techniques, such as quantization.\n\nCheck out the [model optimization docs](./model_optimization) for details.\n\nTweak the number of threads\n---------------------------\n\nLiteRT supports multi-threaded kernels for many operators. You can\nincrease the number of threads and speed up execution of operators. Increasing\nthe number of threads will, however, make your model use more resources and\npower.\n\nFor some applications, latency may be more important than energy efficiency. You\ncan increase the number of threads by setting the number of interpreter\n[threads](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/lite/interpreter.h#L346).\nMulti-threaded execution, however, comes at the cost of increased performance\nvariability depending on what else is executed concurrently. This is\nparticularly the case for mobile apps. For example, isolated tests may show 2x\nspeed-up vs single-threaded, but, if another app is executing at the same time,\nit may result in worse performance than single-threaded.\n\nEliminate redundant copies\n--------------------------\n\nIf your application is not carefully designed, there can be redundant copies\nwhen feeding the input to and reading the output from the model. Make sure to\neliminate redundant copies. If you are using higher level APIs, like Java, make\nsure to carefully check the documentation for performance caveats. For example,\nthe Java API is a lot faster if `ByteBuffers` are used as\n[inputs](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/lite/java/src/main/java/org/tensorflow/lite/Interpreter.java#L175).\n\nProfile your application with platform specific tools\n-----------------------------------------------------\n\nPlatform specific tools like [Android\nprofiler](https://developer.android.com/studio/profile/android-profiler) and\n[Instruments](https://help.apple.com/instruments/mac/current/) provide a wealth\nof profiling information that can be used to debug your app. Sometimes the\nperformance bug may be not in the model but in parts of application code that\ninteract with the model. Make sure to familiarize yourself with platform\nspecific profiling tools and best practices for your platform.\n\nEvaluate whether your model benefits from using hardware accelerators available on the device\n---------------------------------------------------------------------------------------------\n\nLiteRT has added new ways to accelerate models with faster hardware\nlike GPUs, DSPs, and neural accelerators. Typically, these accelerators are\nexposed through [delegate](../performance/delegates) submodules that take over\nparts of the interpreter execution. LiteRT can use delegates by:\n\n- GPU delegate is available on Android and iOS, using OpenGL/OpenCL and Metal, respectively. To try them out, see the [GPU delegate](../performance/gpu).\n- It is possible to create your own delegate if you have access to non-standard hardware. See [LiteRT\n delegates](../performance/delegates) for more information.\n\nBe aware that some accelerators work better for different types of models. Some\ndelegates only support float models or models optimized in a specific way. It is\nimportant to [benchmark](./measurement) each delegate to see if it is a good\nchoice for your application. For example, if you have a very small model, it may\nnot be worth delegating the model to the GPU. Conversely, accelerators are a\ngreat choice for large models that have high arithmetic intensity."]]
